Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
MoxSite a écrit :Je pense que les fichiers de type "sockets" sont créés/recréés au démarrage du système ou au lancement d'un programme qui utilise ces sockets. C'est bien ça ? ou ils sont permanents ?
Il peut y avoir les deux. En général, les sockets temporaires sont créées dans des emplacements spécifiques comme /run ou /tmp, comme les autres fichiers temporaires. Et puis, on peut en dire autant des "tubes nommés" (pipe/fifo), alors pourquoi les traiter différemment ? A mon avis ce n'est pas tant le type de fichier que l'emplacement qui doit être pris en compte.
Bonjour,
Merci pour ces précisions. Je pense effectivement que vous avez raison pour l'emplacement, c'est un paramètre à prendre en compte aussi.
MoxSite a écrit :pour les sockets, ce n'est pas nécessaire
Pourquoi ?
Je pense que les fichiers de type "sockets" sont créés/recréés au démarrage du système ou au lancement d'un programme qui utilise ces sockets. C'est bien ça ? ou ils sont permanents ? Si oui, dans ce cas il faut les copier ?
ba pour une copies efficace tout les fichiers et dossiers
Ce c'est que je fais, en copiant les dossiers, liens, et les fichiers réguliers, mais il semble que sous Linux, il y a différents types de fichiers, du coup je voulais savoir s'il faut les prendre en compte :
Source : http://zero202.free.fr/cs3-svsf/html/ar01s02.html
Bon pour les sockets, ce n'est pas nécessaire, mais pour les fichiers spéciaux ou fifo, faut-il les copier ?
MoxSite a écrit :Ce que j'aimerai savoir, c'est lequel de ces deux fichiers (pointeur) a été créé en premier.
Pour cela, il faudrait que le système de fichiers enregistre la date de création d'une entrée de répertoire et pas seulement de l'inode vers lequel elle pointe. Je doute que ce soit le cas des systèmes de fichiers classiques comme ext4. Ce serait peut-être possible avec un système de fichiers totalement journalisé comme NILFS qui permet de retrouver tout l'historique des méta-données.
Bonsoir,
Oui tout à fait, mais pour ce que je veux faire le principe de l'inode me convient parfaitement. Puis que les noms des fichiers se sont de simples pointeurs, il me suffit de créer n'importe lequel en premier, le résultat est le même. Vive Linux 
Ce que j'aimerai savoir, c'est lequel de ces deux fichiers (pointeur) a été créé en premier.
Merci à vous
Cette commande va aussi créer un fichier (nommé golang) dans : /proc/sys/fs/binfmt_misc
Tout ce passe bien, mais après redémarrage, le fichier golang n'est plus présent dans le répertoire. Savez-vous d’où ça peut venir ?
Bonne année à vous, et merci pour votre aide :-).
alors , quand tu mets des dépôts dans le sources.list , ils ont tous la même priorité .
d'où souvent pagaille entre les versions .
le fichier préférences sert à gérer les priorités entre les versions et donc , de fait , à éviter la pagaille .
dans tes sources , stretch est désactivé ,
sid est activé avec une priorité de 100 (faible) , dans ton fichier préférences et
buster est activé avec une priorité par défaut (500) donc supérieure à sid .
tout çà fait que , en l'état actuel de tes sources , c'est buster qui est installé et actif
avec sid "en secours" .
si tu veux une "full buster" , commentes le dépôt sid et , si tu y tiens , sauvegarde (en bak) ton fichier préférences .
comme çà , en cas de besoin , tu le retrouvera .
passé le 6 juillet , tu pourra supprimer le dépôt sid et aussi le fichier préférences (je préfère pas pour ce dernier) .
si tu n'as plus les sources sid , le fichier préférences ne sert à rien , tu peux l'effacer ou le garder .
Excellent ! Merci pour toutes informations, je comprends enfin la priorité des chiffres 
Le fichier de sources donne tous les paquets que tu pourrais avoir. C'est le système d'épinglage avec le fichier preferences ou les fichiers dans preferences.d qui détermine ce que le système installe. Tu peux le voir avec la commande
apt policy
Tu as ce tuto là qui explique bien https://debian-facile.org/doc:systeme:apt:pinning
Je m'en doutais bien puisque le fichier porte bien son nom :-).
Pour information, voici ce que renvoie la commande :
Ah, Ok, donc, là, tu es bien en Testing (j'avais effectivement omis de signaler qu'il était possible de fractionner ce fichiers en plusieurs en les plaçant le dossier preferences.d
). Donc, pour conserver Buster, il suffira de faire comme l'a dit Debian-Alain et supprimer (ou déplacer pour en conserver une copie) ce fichier /etc/apt/preferences.d/testing-avec-sid
Après le 6 juillet une fois la mise à jour effectuée correctement, je garde quand-même le fichier "/etc/apt/preferences.d/testing-avec-sid" ? Cela ne risque pas de me faire passer en la nouvelle Testing/SID (Debian 11) ? Ou si le fichier sources qui détermine tout, j'imagine que oui ?
Ah, Ok, donc, là, tu es bien en Testing (j'avais effectivement omis de signaler qu'il était possible de fractionner ce fichiers en plusieurs en les plaçant le dossier preferences.d
Parfait, merci beaucoup pour vos réponses. Je vais sauvegarder ces deux fichiers en lieu sûr et suivre la procédure donnée Debian-Alain. Ainsi comme dit le proverbe, je saurai d'où je suis venu si je me perds big_smile.
Excellente journée à vous .
J'utilise bien testing + sid non ?
Pour passer en stable dois-je supprimer le fichier "/etc/apt/preferences.d/testing-avec-sid" ?
Salut
Avec un tel sources.list, c'est le fichier /etc/apt/preferences qui détermine la distribution utilisée. Si tu n'en a pas, tu es en Sid, et pas en Testing
Bonjour,
Je n'ai pas ce fichier. J'avais suivi un tuto sur ce site il me semble à l'époque pour utiliser Buster en mettant "unstable" pour pécher dedans en cas où un paquet n'est pas disponible dans testing ou inversement. En tout cas je n'ai pas eu de problème majeur depuis. A part au début, le système marche comme une horloge c'est incroyable pour quelque chose qui n'est pas tout à fait stable . J'avais aussi installé un paquet pour "blacklister" les paquets qui avaient des bugs importants.
Il suffira de supprimer la ligne "unstable" puis faire la mise à jour normalement ?
Un langage général qui compile en natif, pas trop dur à apprendre : ocaml.
En plus avec le typage fort qui est inféré automatiquement à la compilation
c'est vraiment agréable. L'avantage par rapport à l'haskell (que je préfère) est
qu'il est plus rapide à apprendre et tu peux aussi faire de la programmation
impérative, et tu as aussi de la programmation orienté objet (il existe bien
un Ohaskell, mais déjà haskell est très marginal en France, alors…).
Évidemment, il y a aussi le côté fonctionnel de ocaml qui peut être déroutant au début
mais rien n'oblige de faire de la programmation fonctionnelle en ocaml (personnellement
je trouverais très triste de ne pas faire de programmation fonctionnelle… mais c'est une histoire
de goût, et aussi, pas mal d'algo s'exprime avec plus d'élégance qu'en programmation impérative).
Après il y a go qui a le vent en poupe, ou rust, mais je ne pourrais pas t'en parler puisque je ne les ai
jamais pratiqué. Rust est plus orienté bas niveau semble-t-il et go est plus généraliste et
ça compile vite (ocaml aussi d'ailleurs…).
Franchement je ne changerai pour rien au monde. Je suis tombé amoureux de Go 
. Ce que j'aime aussi dans un langage c'est sa syntexe, celle de go elle est sexy je trouve, pas beaucoup de mots clé et énormément de potentiel. Par exemple avec Go pour stocker des sessions (données) en mémoire, c'est un jeu d'enfant. Il permet aussi de faire de la programmation bas niveau il me semble.
On peut aussi l'utiliser pour faire des programmes avec une interface graphique en utilisant GTK ou Qt, comme celui-ci par exemple :
https://github.com/therecipe/qt
La force de Go c'est aussi son équipe de développement, il ne faut pas oublier que dernier Go il y a Google pour assurer son évolution, c'est une valeur sûre pour moi. Il y a aussi go 2.0 en préparation et l'équipe semble prendre en considération les demandes des utilisateurs qui veulent une programmation générique simple et une gestion des erreurs plus intuitive.
Pour Rust, j'ai voulu essayé un jour, je le trouve compliqué et pas assez sexy .
Ouais, tu peux très bien déclarer un pointeur dans une structure qui pointe sur une fonction assez facilement en Go (histoire de créer une "méthode"), mais la notion d'héritage sur les struct est pas vraiment intuitive je trouve
Voici un exemple d'héritage que j'utilise pour un petit CMS orienté MVC :
C'est bien plus qu'un simple pointeur :-). Le code ci-dessus fait exactement la même chose qu'une classe en PHP ou Python.
go learning(user, channel)
Je suis en train d'apprendre ce langage. Malheureusement au boulot je n'arrive pas à me détacher de Php et Java, mais j'avoue que le Go à un énorme potentiel. Même si dans mon cas la transition From Java To Go est terriblement frustrante. Les choses simples sont souvent les meilleures, mais j'ai l'impression de perdre en souplesse niveau conception en Go. Je suis beaucoup trop habitué à mes classes (abstraites ou non) et à mes interfaces, sans parler des designs patterns (Builder et Fluent, AbstractFactory, Singleton ect) https://debian-facile.org/img/smilies/x … _panic.gif
Ayant fait beaucoup de PHP, au début j'avais l'impression que Go était contre-nature sans les "classes" (héritage, POO), en fait, c'est juste que je n'avais pas compris . Les "struct", c'est comme les classes, elles permettent de faire de la POO et supportent l'héritage.
Du coup en terme de place, l'exectuble ne fait plus que 2Mo au lieu de 100, sacré gain
Tout à fait, c'est une bonne chose si on doit développer plusieurs programmes avec interface graphique. Pour Windows tout dans un fichier de 20Mo, c'est vraiment génial, c'est beaucoup mieux que Python :-). Sinon pour les programmes sans interfaces, Go est juste.. comme dire, l'invention du siècle !
You can start your app either by running project-name or project-name.sh. If you use project-name, your app will run using Qt5 libraries that installed by your system package manager, therefore make it looks native in your platform. On the other hand, if you use project-name.sh, your app will run by dynamic linking the included libraries which will use the fusion style
C'est ce texte qui donne l'explication. Si tu joue le .sh ça utilise les libs embarqués dans le dossier. Si tu lances la commande sans le .sh il utilise le Qt de ta machine.
Bonjour,
Effectivement, j'ai fait le test, c'est bien ça. Merci pour tes réponses :-)
Ton alimentation serait compatible haswell, mais ça reste à valider: https://www.corsair.com/fr/fr/blog/hasw … r-supplies
Par la suite, teste juste la modification du bios sans le script python (ni le paramètre du noyau "idle=nomwait" si tu l'as appliqué) pour voir si ta machine reste stable.
Après, il est possible qu'un nouveau noyau linux et des mises à jour de bios corrigent le problème.
Très bien, je vais tester les deux options, si la machine reste stable d'ici un mois, je garde juste la solution du bios, puis je testerai un mois de plus. Je mets tout ça sur mon agenda pour ne pas oublier, ainsi si vous pouvez (l'équipe) remonter les bugs à l'équipe de Debian.
En tout cas, depuis ces modifications, plus aucun bug, j'ai l'impression d'avoir une nouvelle machine, c'est stable et très réactif, du bonheur à l'état pur ! Pourvu que reste ainsi .
Une fois qu'une mise à jour du bios est disponible, je vais l'appliquer, puis voir aussi avec les nouveaux noyaux.
