Sytoka Modon a écrit 4551 commentaires

sinon, man udev qui doit bien expliquer quelque part comment forcer un peripherique (PCI ou USB) à toujours avoir le meme
/dev/xyz

Ca, c'est facile à faire entre ""

Ce qu'il veut faire et qui m'intéresse aussi et d'attribuer à une personne A tout ce qui est branché sur le port A usb et réciproquement, atribué à la personne B ce qui est branché sur le port usb B.

La question, comment relier sur le port USB du PC, l'équipement branché qui peut être un clefs UBS lambda avec un règle utilisateur (ou DISPLAY...) ?

Exemple poussé à fond. Je branche la clef ayant l'UID JHJKYUY sur le port A, elle se monte sur le bureau de la personne A, je la branche maintenant sur le port B alors elle se monte sur le bureau de la personne B. Pourtant c'est la même clef. L'ID de la clef ne sers ici à rien, c'est l'ID du port qui est utile mais qu'en faire et comment l'utiliser pour que la clef JHJKYUY se monte sur le bon bureau ?

Eh ben moi, j'ai essayé et au bout de 10 jours, j'ai remis gdm2 avec mon ancienne configuration car c'était complètement insupportable... Pourquoi faire compliquer alors que c'était simple. Ainsi, j'ai dès le boot toujours deux bureaux sur F7 et sur F8. Par ailleurs, je suis toujours sous F8 même lorsque je me logue en premier !

Dans tous les cas, je suis moi intéressé par la solution finale qui si elle est plus générale que GNOME me convient encore plus.

Chez moi, c'est du mono-seat mais F7-> ma copine et F8 moi. Je lui allouerais bien un port pour sa clef et un port pour moi. En pratique, c'est presque le même problème bien car c'est bien une question de DISPLAY qui différencie les deux sessions.

Ne me parlez du changement d'utilisateur, ce truc venant de Windows, ergonomique, lent (et dépendant de l'environnement de bureau). Ctrl+Atl+Fx et on change de session, à l'ancienne et très efficace ;-)

Donne moi un programme pratique pour avoir une console sur le port série ? J'en ai juste besoin pour me connecter sur les commutateurs ou certaine baie de stockage... Screen est vraiment ce que j'ai trouvé de mieux, et en plus, il permet d'enregistrer la session.

tmux ne permet pas de faire

tmux /dev/ttyUSB0

alors que screen si. screen est très pratique pour tout ce qui est port série.

Tahoe-LAFS is a Free and Open cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to function correctly, including preservation of your privacy and security.

https://tahoe-lafs.org/trac/tahoe-lafs

Ce qu'il manque, un vrai connecteur fuse fonctionnel j'ai l'impression (qui permettrait ensuite le partage samba...)

Sinon, il y a glusterfs qui a un mode de synchronisation asynchrone... mais il y a un maître dans ce cas là !

Ben oui, si je branche une clef USB (formaté en FAT) sur le port A, elle va au bureau A et idem avec le port USB B...

Il faut donc pouvoir assigner un port et non un équipement. A noter que certain équipement d'acquisition s'assigne un port avec LabView (Windows) et qu'il est alors impossible d'utiliser ce matériel sur un autre port ensuite ! Réfléchir a 2 fois avant de brancher ses trucs la sur un PC...

Debian et la FSF, j'ai l'impression que c'est je t'aime moi non plus depuis le début.

Debian a sa propre définition du libre via les DFSG. Debian n'a jamais considéré la GNU FDL comme une licence libre (il y a des paragraphes a ne pas utiliser si on veut pouvoir mettre la doc dans un paquet debian).

http://fr.wikipedia.org/wiki/Principes_du_logiciel_libre_selon_Debian

Debian a sa propre structure financière qui sers d'ailleurs à d'autres projets : la SPI.

Mark Shuttleworth a été développeur Debian avant de partir dans l'espace. Tant qu'il sera à la tête d'Ubuntu, je ne pense pas qu'il fera un fork de Debian car dans ses interview, il a toujours un grand respect pour Debian je trouve.

C'est dramatique si systemd est un et un seul programme qui tourne avec le PID=1 ! Le PID=1, c'est un peu comme le compte root, c'est un programme à part qu'on ne relance jamais... Il est très important qu'il y ai le moins possible de mise à jour de sécurité sur ce programme par exemple sinon on va se retrouver dans le situation de Windows à devoir rebooter en permanence (cela s'est amélioré).

Dans mes scripts d'init, j'ai aussi une cible status qui me dis un peu plus que ca marche ou pas. Souvent, je fais un cible init a utiliser une fois la première fois... Bref, avoir un vrai langage est un plus.

Simplifier les scripts d'init est effectivement une bonne chose. Avoir un shell réduit comme dash pour Debian est une bonne voie. Enrober tout cela d'un "runit" serait mieux. Un init en petite brique permet de changer une brique par une autre, de rajouter des briques non prévu au début (gestion des cgroup qui n'était pas au programme il y a 10 ans)...

Je viens de m'amuser à faire un

( cd /etc/init.d ; wc * | sort -n )

La grande majorité des scripts sous debian fait moins de 150 lignes en comptant les commentaires. On pourrait faire quelques factorisation ici ou la mais c'est globalement propre. Ce qui est un peu crade coté programmation, ce sont les meta commande INIT INFO en commentaire dans ce même fichier. D'un autre coté, c'est aussi la technique utilisé par les gestionnaires de batch sur les machines de calcul...

Bref, simple, robuste et ouvert sur les innovations du futur

A mon sens, ce sont surtout les USA qui foutent la merde coté unité. Il est vrai que moi-jour-année, c'est illisible et surtout illogique, mais leur miles, galons, farenheit, pouce, peid... et j'en passe. Nos enfants passent leur temps au primaire à apprendre des règles idiotes d'ortografe française (chous, caillous, hibous...) mais les petits américains doivent perdre leur temps à changer les unités pour faire des calculs.

Les anglais roulent à gauche. Sur les voitures, ils ont perdus mais sur les trains, ils ont gagné, les trains roulent à gauche sauf le métro qui roule à droite ! A noter que les USA ont inversé si je me souviens le sens de circulation gauche droite mais je ne me souviens plus quand. Coté mondial, je ne connais pas la proportion droite/gauche. En asie, une partie des voitures a le volant à droite même s'il roule à droite, je crois que ce sont des voitures d'occasion japonaise....

Sur une machine de calcul, on utilise les CPUSET et les CGROUP pour tuer tout ce qui reste d'un job après que le walltime soit terminé. La problématique ici est la même donc comme dis ci-dessus, les CGROUP permettent de faire le boulot.

Sinon, le CACHE de socket, cela ne permet pas de mettre en cache les données pour le serveur syslog en attendant qu'il se lance ;-)

J'ai pas regarder systemd de près mais si c'est bien le processus PID=1 qui fait tout cela, ça craint ! J'espère qu'il se fork ou qu'il envoie des petits...

sysvinit sous debian gère le lancement parallèle des services. D'ailleurs, je crois que c'est une version qui provient à la base de Suse.

Sinon, comme dis dans un autre post, il y aussi la voie très intéressante qui avait été lancé avec runit (et socklog) sur des idées d'ailleurs à la base de D. J. Bernstein (daemontools)

http://smarden.org/runit/

L'idée de base semble dans le même esprit mais découpé en plein de petit programme faisant une et une seule chose... L'idée fondamentale est d'avoir un programme initial "/sbin/init" (PID=1) le plus petit possible ce qui me semble dans la logique même...

Je ne vois pas pourquoi les programmes "modernes" s'évertuent à vouloir par défaut être en mode serveur et à tout regrouper dans une seule instance ce qui est problématique en cas de plantage (iceweasel, geany...).

Les IHM qui écrivent les fichiers perdent souvent les commentaires, l'indentation... Je sais qu'il y en a qui y arrive mais c'est pas le plus courant. Le dernier exemple qui me passe par la tête est backuppc qui fait un dump de l'objet config et donc perds tous tes commentaires (d'ailleurs, c'est pas nickel nickel d'avoir fait un dump mais bon).

Ceci dis, l'exemple que tu prends n'est pas le plus facile. J'ai quelques fichiers /etc/network/interfaces qui définissent plus de 20 interfaces réseaux et peut être qu'un interface.d aurait été pas mal. D'ailleurs, le fichier qui me pose le plus de soucis à gérer automatiquement pour le moment est /etc/ssh/sshd_config. Dommage qu'on ne puisse inclure les fichiers d'un dossier dedans car comme c'est un fichier TRES sensible, c'est toujours délicat de faire des grosses modifications dedans !

Et que dire des autres architecture que debian supportent ... qui souvent d'ailleurs bloque la sortie de la distribution.

L'aspect multi-arch et multi-OS permet d'être plus robuste avec des API claire, stable et identifié pour la plupart. Cela donne aussi du temps au temps. C'est parfois énervant mais c'est aussi important. Ceci dis, il ne faut pas non plus s'ankyloser, il y a un temps pour tout !

Ce que j'aime bien dans un système UNIX, c'est qu'il y a plein de bout en script au coeur du système, c'est donc assez facile d'intervenir dessus et de l'adapter. C'est aussi une grande force anti-virale... J'aimerais bien que PAM par exemple soit plus facilement scriptable qu'actuellement.

J'ai déjà pris l'exemple du serveur SMTP Qpsmtpd programmé en langage de script. Très facile d'aller y modifier un truc ou deux alors que c'est quasiment impossible à un admin système de base comme moi si c'était un Postfix ou un Exim.

Il est vrai qu'un coeur en script, c'est pas forcément la joie pour les GUI ;-) Sinon, il y a un outil assez sympa, Config::Model, qui pars sur l'idée que plutôt que de vouloir tout uniformiser, tout normaliser, la diversité peux avoir du bien donc c'est à la surcouche de s'adapter. Personnellement, je ne l'utilise pas car vi me suffit dans 99% des cas.

Un système binaire peut à mon avis être intéressant dans le cas de forte charge mais avec un nombre d'entrée pré-définit. une base de type RRD à rotation automatique permet alors un accès direct en écriture. Cela pourrait aussi être un backend à syslog et pourrait servir par exemple pour des log de firewall...

Sinon, les GUI pour lire les log sont tout sauf pratique. C'est bon pour les petits dépannage du genre un installateur d'un soft Windows qui au premier click téléphone déjà a sa hotline ;-) Jamais pu utilisé les journaux Windows tellement c'est peu pratique...

Si j'ai bien compris une partie des débats, un des problèmes majeurs est que syslog n'est pas lancé en premier donc que faire en attendant que syslog soit opérationnel ? systemd ne pourrait pas ouvrir le port le syslog, écouter et tamponner en RAM (ou ailleurs) en attenant que syslog démarre et reprenne le tout ? J'ai cru comprendre que systemd était capable de maintenir les descripteurs de fichier lors d'un redémarrage de service ?

Sans boucle et en monoligne... Je suis juste passé par ldd. Pourquoi utilises tu objdump ?

 ldd /bin/bash | awk '{print $1}' | xargs -r dpkg -S 2>/dev/null | cut -f 1 -d ':' | sort -u | xargs -r dpkg -l | grep ^ii | awk '{print $2,$3}'

Solution simple

./depends.sh /bin/bash | sort -u

En https, de plus en plus les navigateurs mettent le nom de domaine ou plus précisément la fin du nom de domaine. Je n'aime pas cela car cela revient à simplifier l'arbre DNS avec un seul sous domaine.

Exemple virtuel :

https://www.linuxfr.org -> linuxfr.org

Sous domaine

https://www.machin.linuxfr.org -> linuxfr.org

Sauf que en pratique, je gère le domaine "machin.linuxfr.org" de manière autonome et que je n'ai, au final, que peu à voir avec "linuxfr.org". Que le www saute car il représente le nom de la machine, pourquoi pas, mais pourquoi faire sauter une partie du nom DNS de domaine ?

Exact, à part un ingénieur en instrumentation qui ne supportais pas LabView, tous les autres expérimentateurs ont fait ce choix là. Du coup, le marché est captif pour National Instrument. En interne, la gestion des versions des différents programmes de pilotage est du coup ... folkorique. Si quelqu'un sais comment gérer de manière simple dans le temps et de manière collaborative les programmes LabView, je suis preneur.

De plus en plus de chercheur utilisent Python à la place de Matlab (ou Octave ou Scilab...). On se retrouve cependant avec le même problème que la suite MS Office, c'est jamais compatible à 100%. Si c'est la suite elle-même (ou Matlab), la non compatibilité d'une version à une autre passe mieux...

Ne pas avoir confiance totale dans une boite ne signifie que tout ce qu'elle fait est de la merde ;-) Pourquoi de suite prendre une position extrême ?

Par ailleurs, dans les exemples que tu donnes, il y a une différence entre aider à maintenir un système et développer un nouveau système... Par exemple, les débuts de network-manager ont été très difficile, l'outil était beaucoup trop lié au fait d'avoir une IHM graphique.

Avec le temps et tous les contributeurs, les outils se bonifient ou trouvent des remplaçant, c'est tant mieux ;-)

Je parle de mon labo car c'est plus intéressant que chez moi, il y a un peu plus de poste à gérer... C'est pas juste un truc avec 10 machines. L'informatique personnelle, un PC = une IP = une personne ne m'intéresse pas particulièrement.

Sinon, j'aime effectivement bien le Perl (et le CPAN), plus que Python par exemple mais je déploie aussi des trucs en Python, PHP... Quand au dev, je n'en fais plus beaucoup mais je préfère poser des questions parfois candides puis changer d'avis ensuite s'il le faut.

Tiens, ca m'intéresse de savoir quelques grosses conneries que j'aurais dites car je ne doute pas d'en avoir dis quelques unes ;-) Au moins, je pourrais me faire un coup d'auto-dérision lundi à la pause café !

Ca parait simple mais cela met tout sur un seul processus... Via la séparation, le démon de relance pourrait être dans un cgroup différent par exemple. L'idée en soi est assez séduisante je trouve.

Et puis, depuis quand l'utilisateur final s'intéresse à la tripotée de démon qui tourne ? L'architecture du processus numéro 1 ne me semble pas avoir une quelconque interaction directe avec l'utilisateur.

J'ai jamais dis que c'était facile.

Si c'est un bête SIGCHLD, pourquoi ne pas le rajouter au processus init actuel ? Il fait comment en cas de fork ?