« Le FHS du LSB est bien, mais “ / ” est un sacré bordel, il faut tout de même l’avouer. » Ceux qui auront compris cette phrase seront certainement d’accord. Pour les autres, LSB signifie Linux Standard Base, cela définit tout un ensemble de standards autour de GNU/Linux, dont… le FHS, qui est le Filesystem Hierarchy Standard, qui définit l’emplacement des fichiers.
À la racine, c’est‐à‐dire la base du système de fichiers, notée « / », on range notamment les données et les programmes statiques dans « /usr », bien. Ensuite, on range les binaires dans « /bin » et « /sbin », et les bibliothèques dans « /lib » et « /lib64 ». Oui, mais voilà, on range aussi des binaires dans « /usr/bin » et « /usr/sbin », et des bibliothèques dans « /usr/lib » et « /usr/lib64 ».
La proposition vient de Harald Hoyer et Kay Sievers, deux développeurs Red Hat, et est soutenue par Lennart Poettering. L’héritage de 30 ans d’UNIX est clairement à simplifier. Le but est de :
- fusionner
« /bin »,« /sbin »et« /usr/sbin »dans« /usr/bin »; - déplacer le contenu de
« /lib »dans« /usr/lib »; - déplacer le contenu de
« /lib64 »dans« /usr/lib64 »; - créer des liens symboliques pour rester compatible :
-
« /bin »vers« /usr/bin », -
« /sbin »vers« /usr/bin », -
« /lib »vers« /usr/lib », -
« /lib64 »vers« /usr/lib64 ».
-
Facile à retenir : « sbin », c’est has been ! Hum.
Ceci faciliterait grandement le montage et démontage des systèmes de fichiers, le démarrage du système, les instantanés (snapshots), la virtualisation, etc..
Aller plus loin
- Fedora to simplify filesystem hierarchy (226 clics)
- From: Lennart Poettering / Subject: Re: UsrMove feature (132 clics)
- Filesystem Hierarchy Standard sur Wikipédia anglais (40 clics)
- Filesystem Hierarchy Standard sur Wikipédia francophone (168 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la messe est dite
Posté par Aris Adamantiadis (site web personnel) . Évalué à 10.
Pareil. Il suffit d'avoir le support de ce personnage critiqué et critiquable pour que le projet soit lui-même critiqué.
Si il faut faire des modifications, elles doivent être plus importantes que simplement fusionner ces répertoires. Il faut supprimer le /tmp global (et tous les endroits world-writable), simplifier les 3 ou 4 endroits où l'on trouve de la doc (/var, /usr/doc, /usr/share/doc,...), virer tout ce qui est configuration et données statiques de /var, réordonner le bordel de /etc, etc.
Et surtout ne pas annoncer qu'on a le support de gens notoirement détestés dans la communauté.
[^] # Re: la messe est dite
Posté par Grunt . Évalué à 2.
Le /tmp global c'est bien, mais il aurait plutôt sa place dans /var, non? Le /home aussi d'ailleurs.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: la messe est dite
Posté par Vroum . Évalué à 5.
/tmpet/var/tmpne garantissent pas la même durée de vie aux données./var/tmpest persistant au reboot (fichiers de cache divers que tu ne veux pas réindexer à chaque redémarrage ou les fichiers d'historique par exemple) tandis que/tmpsera vidé automatiquement à chaque redémarrage.Dans le cas de
/tmp, il est alors possible d'utiliser le système de fichier tmpfs qui te permet d'accélerer les temps d'accès en moyenne.(voir certains commentaires plus bas pour d'autres détails)
[^] # Re: la messe est dite
Posté par Grunt . Évalué à 3.
Beuh? Tu peux très bien vider /var/tmp tout comme /tmp est actuellement vidé.
Par contre, argument reçu pour le tmpfs.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: la messe est dite
Posté par François Chaix (site web personnel) . Évalué à 1.
Là où l'on voit que les devs de fedora aiment bien donner des coups de pied dans ce genre de fourmilière, c'est que justement dans fedora, le /tmp n'est pas vidé à chaque redémarrage. D'ailleurs ça m'embête bien sur le PC de ma compagne (équipé de fedora), car /tmp s'encrasse.
Je crois qu'il supprime les fichiers quand ils ont dépassé une certaine limite d'âge.
La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
[^] # Re: la messe est dite
Posté par Grunt . Évalué à 4.
Je te parie une bière que tu peux le paramétrer (durée de conservation des fichiers, nettoyage à chaque démarrage, nettoyage à partir d'une certaine taille), en cherchant 5 minutes.
NB: je n'ai jamais utilisé Fedora.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: la messe est dite
Posté par GeneralZod . Évalué à 4.
Tu as gagné ta bière, c'est le script /etc/cron.daily/tmpwatch (par défaut, c'est 30 jours la durée de conservation des fichiers dans /tmp)
Au passage, tmpwatch est maintenu par fedoraproject.org ==> https://fedorahosted.org/tmpwatch/
[^] # Re: la messe est dite
Posté par Stéphane Klein (site web personnel) . Évalué à 10.
Oui mais ce que j'aime bien chez Lennart Poettering, c'est qu'il se bouge le cul pour faire des propositions (et même les réaliser), il n'hésite pas à mettre des coups de pied dans la fourmilière… Après il n'est pas parfait mais il a de l'énergie… veut faire avancer les choses.
Je ne suis pas un spécialiste du domaine, je ne porterai pas de jugement sur le bien fondé de l'idée ou non.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la messe est dite
Posté par GeneralZod . Évalué à -1.
avahi, pulseaudio, systemd pour ses principales oeuvres, qui sont soit des briques de bases d'une distro GNU/Linux soit en passe de le devenir.
Si il faisait que de la merde, je pense qu'on l'aurait oublié depuis longtemps.
[^] # Re: la messe est dite
Posté par FreeB5D . Évalué à 10.
Aucune trace de ces «briques de base» dans ma Slackware 13.37. Linux != Fedora.
[^] # Re: la messe est dite
Posté par GeneralZod . Évalué à 4.
Tu oublies Debian, OpenSuSE, Mageia, Frugalware, ArchLinux etc ... Sans oublier les gadgets à base de linux (WebOS, MeeGo, OpenWRT, etc ...). Malhonneteté cd key.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la messe est dite
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
avahi est une daube en entreprise... C'est encore un protocole à la Apple conçu pour le familial ou la PME.
Avahi ne me dérange pas en soi tant qu'il ne devient pas une dépendance nécessaire à l'environnement de bureau...
[^] # Re: la messe est dite
Posté par Batchyx . Évalué à 5.
Avahi n'est pas un protocole, c'est une implémentation de découverte de service pour le bureau. Après le fait que ça soit de la merde en barre "architecturée" par Lennart et le fait qu'il ne supporte rien d'autre que zeroconf, qu'il ne pourra jamais rien supporter d'autre que zeroconf et que tu puisse crever si tu veux remplacer Avahi par autre chose, c'est la faute d'Avahi et de Lennart, ce n'est pas la faute de zeroconf.
zeroconf fait ce pour quoi il à été prévu (remplacer AppleTalk). C'est parfaitement normal qu'il réponde pas à tout les besoins. Ce qui n'est pas normal, c'est qu'Avahi ne propose pas d'utiliser un autre protocole fait avec ses petites mains et que Lennart soit aussi condescendant envers ceux qui cherchent à résoudre ce problème avec des patches.
[^] # Re: la messe est dite
Posté par Albert_ . Évalué à 2.
c'est surtout que cela ne sert a rien. Demarre avahi et essaye donc de t'en servir pour partager un fichier avec quelqu'un utilisant un ipad. Cela ne marche pas.
[^] # Re: la messe est dite
Posté par GeneralZod . Évalué à 3.
quel est le putain de rapport avec Avahi ? zeroconf c'est de la publication/découverte de service, après c'est un autre service qui prends le relais. T'as vu où dans la norme msDNS que ça gérait le partage de fichiers ? Il n'y a aucune honte à consulter pour ses problèmes de malcomprenance !
[^] # Re: la messe est dite
Posté par Albert_ . Évalué à 1.
Ouhais je suis pas rentre dans les details. En gros, avahi avec ssh service qui est non vu et donc non accessible par un ipad a la con. Maintenant ca marche (peut etre) super bien sur ... Fedora/RH encore une fois mais bon sur Opensuse et ubuntu cela ne sert a rien.
Putain on critique Microsoft de faire des trucs qui tourne uniquement sous leurs OS pourris mais Fedora/RH c'est un chouilla dans la meme categorie a force.
[^] # Re: la messe est dite
Posté par Batchyx . Évalué à 3.
Suis les conseils de GeneralZod: Consulte.
Avahi ne publie que les services qui s'enregistrent auprès de lui ou qui sont définis par l'administrateur. Si on peut criser sur le fait que l'admin n'a aucun contrôle fin sur les services que des simples utilisateurs peuvent publier, pour une fois Lennart laisse l'administrateur configurer les services qu'il veut publier.
OpenSSH ne supporte pas Avahi (il a raison !), donc il faut soit que l'administrateur se bouge son PWD dans /etc/avahi/services, soit que sa distribution le fasse pour lui.
Personnellement, moi j'aime pas quand une distrib à comme valeur par défault de lancer un serveur SSH avec login par mot de passe activé, et crie à tout le monde qu'on à un service SSH d'ouvert. Et faut croire que je suis pas le seul, si j'en crois les distribs que tu cite ;)
[^] # Re: la messe est dite
Posté par Albert_ . Évalué à 2.
Merci de me prendre pour un con mais je suis au courrant de cela et les fichiers sont bien la ou ils doivent etre puisque c'est moi qui les ais mis. Mais ceci est un tres tres bon exemple de ce qu'est Avahi: un truc absolument pas fait pour le commun des mortels. Cela lui aurait troue le cul de mettre les fichiers la ou il fallait et de mettre des options de configuration/demarrage dans une GUI? Ah merde c'est vrai il bosse chez RH et donc utiliser Gnome...
Et rate pour les distribs en question, elles font cela comme il se doit mais du coup ce truc lance au demarrage n'est qu'un gros truc inutile.
[^] # Re: la messe est dite
Posté par Batchyx . Évalué à 1.
Pour Lennart, ça serait plutôt openssh qui n'est pas fait pour le commun des mortels, puisqu'il ne supporte pas Avahi. Et non, Avahi ne peut pas automagiquement détecter des services qui ne dépendent pas de lui. Si il le faisait, alors ça deviendrai vraiment un logiciel effrayant et un trou de sécurité béant, donc non, il va pas rajouter des fichiers tout seul pour des services qu'il connaît pas. Quand à l'interface de configuration, c'est à la distrib de la faire. Comme pour tout les démons.
Avahi est déjà assez pourri comme ça, arrête de vouloir le rendre encore plus merdique.
[^] # Re: la messe est dite
Posté par Albert_ . Évalué à 5.
avahi, pulseaudio, systemd pour ses principales oeuvres
Tu es en train de tirer une balle dans le pied...
[^] # Re: la messe est dite
Posté par GeneralZod . Évalué à 1.
Je m'en sers pour le partage de médias (audio, vidéo), d'écran (vinagre \o/), éditeur collaboratif (Gobby), dépôt mercurial (extension zeroconf) etc ... ça n'évolue pas, le protocole zeroconf n'a pas évolué, mais en même temps pour de la découverte de services, ça fait déjà très bien son taff, faut pas pousser mémé dans les orties.
Il a fallu plusieurs années pour que ça marche correctement sur Ubuntu parce que les mainteneurs de pulseaudio dans Ubuntu sont des gros mongols qui sont pas foutus d'envoyer un mail au mainteneur upstream. En 4 ans, j'ai jamais eu de soucis avec PA que ce soit sur Fedora, openSUSE, Debian, ArchLinux, Mandriva, Frugalware, etc ...
ça fait un an que j'utilise au quotidien et mis à part peut-être launchd, y a pas mieux.
[^] # Re: la messe est dite
Posté par pasScott pasForstall . Évalué à -9.
C'est quelle partie exactement de découverte automagique de service que tu considères inutile dans la vraie vie?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: la messe est dite
Posté par barmic . Évalué à 2.
Tu trouve ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la messe est dite
Posté par Alek_Lyon . Évalué à 7.
À titre personnel, il m'est extrêmement désagréable de voir des images dans les commentaires de linuxfr. Je trouve que cela gâche la qualité des débats, trolls et poilades de ce site.
Quand il s'agit en plus d'un gif animé, je ressens alors la forte pulsion de fabriquer une poupée vaudou pour que l'auteur du post rêve de lolcats des nuits entières jsuqu'à qu'il se repente.
Bref, je ne comprends vraiment pas pourquoi il est possible de poster des images. Mais, comme je ne suis pas dictateur sur ce site, je me contente de mettre un petit -1.
Par contre, serait-il possible de convenir de ne poster que des images "SFW" (Safe For Work), c'est à dire qui ne vont pas décrédibiliser complètement celle ou celui qui expliquera à son ou sa boss que lire linuxfr est de la "veille technologique" et peut donc se faire pendant les heures de travail ? Surtout quand il s'agit d'une dépêche portant sur un sujet sérieux ! Évidemment je ne m'en prendrais qu'à moi même si tombais sur ce genre de gif en ouvrant un journal qui s'appellerait "Jolies Nimages".
[^] # Re: la messe est dite
Posté par barmic . Évalué à 1.
La force du web (et plus précisément du HTML, c'est de pouvoir modifier au niveau client la gueule de ce qu'on télécharge. Tu peut très bien bloquer les images.
Ça peut être utile à de vrai choses comme montrer des graphiques. Si ça ne plaît vraiment pas le suivi est là pour ça.
Tu as tout a fait raison. C'est une erreur de ma part.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la messe est dite
Posté par Alek_Lyon . Évalué à 2.
Un lien vers un tel graphique me paraît suffisant.
Pourquoi je n'aime à ce point là pas les images dans les commentaires ? Parce que je crois que sur le long terme, la forme a une influence sur le fond. Assez empiriquement, j'ai l'impression qu'une forme dépouillée encourage des discussions de qualité (encore une fois, qu'il s'agisse de sujet sérieux, de poilade ou de troll), tandis qu'une forme où tout est permis, poussée à l'extrême, bah ça fait un forum où il n'y a plus que des smileys, des avatars, des signatures de dix lignes et des gifs animés. Bon je n'ai vraiment pas peur que linuxfr devienne un jour comme ça ; même avec une forme permissive, cela dépend quand même essentiellement des participants. Mais, à mon avis, dans une certaine mesure, et à participants égaux, une forme un peu austère favorise une discussion de meilleure qualité. Bloquer les images individuellement ne résoudrait rien à mes yeux.
Merci, je range tout de suite ma poupée vaudou. ;-)
[^] # Re: la messe est dite
Posté par barmic . Évalué à 2.
Au passage l'astuce que j'utilise quand je surf sur linuxfr au boulot c'est d'utiliser l'extension policy request et de débloquer les images qui m'intéressent uniquement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# les binaires, bof
Posté par coïn . Évalué à 8.
Bof, c'est une proposition peu intéressante.
L'emplacement des binaires n'est pas trop un problème en soit. un coup de $PATH ou de which et ça roule.
Non, le vrai problème est /etc
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Et quel est le problème avec
/etcau juste ?[^] # Re: les binaires, bof
Posté par JGO . Évalué à 10.
On y trouve des fichiers où il faut écrire au boot ou pendant le fonctionnement de la machine (mtab, resolv.conf...) ce qui oblige à des contorsions s'il faut que / soit read-only (voir p.ex. http://wiki.debian.org/ReadonlyRoot ).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Non,
/run./var, c'est plutôt pensé pour les données variables de services, comme le courrier électronique. Il était utilisé pour les fichiers liés au fonctionnement des serveurs eux-mêmes, mais/runa été créé pour cet usage.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Non en effet, il n'est pas dans la FHS pour le moment, mais il a été adopté par plusieurs distributions afin de simplifier le démarrage, justement. Parce qu'au démarrage, on a besoin d'un tel répertoire, et que
/var/{run|lock}ne sont pas forcément disponibles à ce moment-là.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: les binaires, bof
Posté par nud . Évalué à 7.
Le plus parlant est udev, qui est démarré très tôt (typiquement tu n'as que la partition root qui est montée), et qui, avant l'invention de /run, mettait ses données "runtime" dans /etc/.udev, ce qui n'était pas très propre.
Il y a d'autres services qui faisaient de même à divers endroits, et, bien évidemment, rien de standardisé ou prédictible.
Donc je trouve que /run est plutôt bien venu, même s'il n'était pas utile du temps où le FHS a été créé, le temps béni du mknod.
[^] # Re: les binaires, bof
Posté par B16F4RV4RD1N . Évalué à 7.
http://xkcd.com/927/
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: les binaires, bof
Posté par reno . Évalué à 7.
Chuuut, /run est je crois aussi soutenu par Lennart Poettering.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Exact, mais contrairement à ce délire de
/usr, c'était une bonne idée.[^] # Re: les binaires, bof
Posté par oinkoink_daotter . Évalué à 4.
Moi j'aimerais bien savoir pourquoi debian (et peut être d'autres) s'obstinent à coller les fichiers de zone de bind et les document root apache dans des sous répertoires de /var.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ça aurait plutôt sa place dans
/srven effet, mais l'organisation de/srvest laissée à discrétion de l'administrateur, par conséquent une distribution ne peut pas y imposer d'organisation a priori.[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Un gestionnaire de paquet ne devrait pas avoir le droit d'écrire dans /srv /opt et /usr/local
Il y a un espace pour a distrib et un espace pour l'administrateur système. J'ai une SUSE avec des paquets propriétaires qui mettent des merdes partout, c'est absolument ingérable...
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
C'est ce que je dis. C'est la raison pour laquelle les serveurs empaquetés utilisent par défaut des répertoires de données dans
/var. À l'administrateur d'organiser/srvet d'y faire pointer ses serveurs.[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
J'ai bien compris que tu avais compris ;-) Je complétais simplement...
[^] # Re: les binaires, bof
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Ben typiquement ça varie (transfert de zone par exemple).
Pour www ça se discute, sous FreeBSD c'est dans /usr/local/www et ça me plait pas trop non plus.
les pixels au peuple !
[^] # Re: les binaires, bof
Posté par claudex . Évalué à 3.
Je croyais que /usr/local était réservé à l'admin système.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: les binaires, bof
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
C'est un peu un pré-requis du système, en single user la racine est montée en read-only.
les pixels au peuple !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: les binaires, bof
Posté par Axel . Évalué à 5.
Chez Apple c'est ce qu'ils ont fait, à peu de chose près. Ils ont bien compris que demander son avis à la communauté était tout sauf productif.
[^] # Re: les binaires, bof
Posté par reno . Évalué à 3.
Même pas la peine de changer de kernel: il y a GoboLinux.
Personnellement je trouve que tout ce bazar est causé par les hiérarchie des systèmes de fichier classique (qui sont d'ailleurs insuffisante car on y ajoute des liens) et j'espère qu'un jour on passera à un système par label, plus besoin de se casser la tête avec "LA HIERARCHIE UNIQUE PARFAITE", chacun voit son système de fichier en regardant les labels qui l’intéresse..
[^] # Re: les binaires, bof
Posté par alice . Évalué à 4.
C'est quoi un système par label?
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
J'imagine que c'est un gros sac où tous les fichiers sont mis en vrac, sans noms ni hiérarchie, mais avec des étiquettes clef=valeur. Au lieu de ranger, on étiquette, et au lieu d'aller consulter par un nom précis, on cherche.
[^] # Re: les binaires, bof
Posté par Tonton Th (Mastodon) . Évalué à 3.
WinFS ?
[^] # Re: les binaires, bof
Posté par reno . Évalué à 3.
Un système ou un fichier est identifié par une série de nom sans que ce soit nécessairement hiéarchique, un peu comme on trie son courrier avec gmail.
L'avantage tu peux avoir des tags utiles pour les admin sys (présence dans l'early boot ou pas, sur quel disque) sans que ça interfère avec les utilisateurs 'normaux'.
[^] # Re: les binaires, bof
Posté par alice . Évalué à 2.
L'idée est intéressante, mais est-ce que la gestion des droits ou l'analyse d'un système de fichier ne va pas devenir un cauchemar?
[^] # Re: les binaires, bof
Posté par reno . Évalué à 1.
Pas beaucoup plus que l'existant: les labels existent déjà on appelle ça un "chemin".
C'est juste qu'il sont contraint à être hiérarchique ce qui est souvent trop contraignant..
D'ailleurs, on a inventé les liens pour contourner cette contrainte, les labels généralisent juste ça.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Référence nécessaire. Les liens physiques sont une fonctionnalité normale d'un système de fichiers qui découple le nom du contenu, et les liens symboliques une fonctionnalité permettant une indirection, mais de là à dire qu'ils ont été introduit pour ça…
[^] # Re: les binaires, bof
Posté par totof2000 . Évalué à 4.
Ah, comme les adresses IPV6, les identifiants de partition ou de disque par exemple ? Pourquoi ne pas utiliser les inodes tant qu'on y est ? C'esst vrai, c'est débile retenir un nom de fichier.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Notez que, vu ce que j'en pense, j'aurais probablement mieux fait de s/vrac/bordel/…
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 5.
Bien que j'ai le même avis que toi sur ce système, ton exemple est biaisé parce que la seule opération ensembliste possible est l'union, alors que l'intersection serait utile et la différence aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Bah, avec tous les outils Unix qu'on a on devrait bien y arriver. Avec des fichiers temporaires, hélas, certes. Mais bon, les outils pour lister en faisant des opérations ensemblistes sur des répertoires, ça se code…
[^] # Re: les binaires, bof
Posté par BB . Évalué à 8.
Autant faire du relationnel avec les outils qui vont bien : un base relationnelle et le langage de requête adéquat.
…
Et on appellerait ça Nepomuk.
[^] # Re: les binaires, bof
Posté par reno . Évalué à 2.
Certes, mais le problème après est qu'il faut que ça marche et que ce soit performant.
J'attends de voir les retours sur 4.7.3, ça a l'air intéressant.
Note bien qu'un système de fichier normal a déjà un coût important puisque qu'il masque l'organisation du disque et si tu accèdes a plusieurs fichiers c'est dans un ordre assez aléatoire plutôt que d'utiliser l'ordre des blocks sur les disque (*).
Sauf ce coût là, on y est tellement habitué que personne n'y pense (et puis proposer d'utiliser les numéros de blocks plutôt que des noms de fichier, ça va pas aller bien loin ;-) ), mais si Nepomuk a un cout en perf raisonnable, je serai vraiment curieux de voir ce que les devs de GoboLinux peuvent faire avec Népomuk..
*: dans le papier: As an example, a tar of the Linux kernel tree was 82.5 seconds using GNU tar, while our modified tar completed in 17.9 seconds.
[^] # Re: les binaires, bof
Posté par BB . Évalué à 4.
Oh ! Nepomuk fonctionne pas trop mal. C’est plutôt le bouzin complet et intégré qui a la hoquet quand ça lui chante… Perso. les bugs qui me sautent ou m’ont sauté à la figure sont surtout du côté de l’indéxeur (il faut bien réaliser que ce truc doit avaler n’importe quelle série de données binaires et arriver à trouver à quoi ça peut bien correspondre… c’est un boulot horrible à mettre en place). Et que je sache c’est surtout à l’indexeur qu’on en veut (ralentissements dûs à la première indexation, base gigantesque, …).
[^] # Re: les binaires, bof
Posté par Guillaume Knispel . Évalué à 4.
C'est un peu comparer des pommes et des carottes que de dire que "un FS à un coût car il est vient par dessus d'un bloc layer et que ce dernier est plus rapide si l'on se contente de lire des blocs dans un ordre intelligent". D'ailleurs le papier cité montre simplement sur ce point qu'on peut optimiser en faisant des choses intelligente dans l'userspace, ce qui est normal, le noyau n'ayant pas d'oracle à sa disposition capable de lui dire ce que l'userspace est en train de vouloir faire d'un point de vue de très haut niveau. Le noyau étant encore moins capable de patcher automatique à la volée l'userspace en question pour lui faire faire des choses plus intelligentes, il faut bien qu'un humain s'en occupe.
J'accorde néanmoins qu'il est bon de rappeler que les FS ne sont pas magiques aux personnes à qui ça aurait pu échapper.
[^] # Re: les binaires, bof
Posté par Guillaume Knispel . Évalué à 2.
Tu t'es pris pour MS (et sur un projet ayant échoué, si je ne m'abuse...) ?
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Sous *nix, un fichier est identifié par le numéro majeur et le numéro mineur du périphérique sur lequel il est stocké, et par son numéro d'i-nœud. Il a par ailleurs un certain nombre de noms, ce nombre pouvant être positif ou nul — ce dernier cas se produisant lorsqu'on supprime le dernier nom d'un fichier qui est toujours ouvert par un processus.
En particulier, un fichier n'est pas identifié par son nom, et peut avoir plusieurs noms. Que te faut-il de plus ?
[^] # Re: les binaires, bof
Posté par reno . Évalué à 2.
Un système de hard link pour les répertoire et je pense qu'on doit avoir un système assez souple.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ah, exact. Pas de chance, c'est impossible, entre autre pour une raison imparable : dans un répertoire qui a plusieurs noms, c'est qui .. ?
[^] # Re: les binaires, bof
Posté par bad sheep (site web personnel) . Évalué à 0.
Celui du contexte :-)
Seul problème effectivement, le comportement ne serait plus le même qu'avec les liens symboliques (truc qui pose d'ailleurs tout un tas de problèmes n'étant pas toujours très intuitif, par ex, créer
ln -s /usr/bin ~/monbin
puis regarder le résultat de
ls -l ~/monbin/..
Ce n'est pas impossible, preuve en est, c'est ce qui est utilisé par Mac OS X pour réaliser timemachine (le système d'archivage d'Apple).
[^] # Re: les binaires, bof
Posté par BB . Évalué à 2.
En même temps, demander un système de fichier non hiérarchique … puis se plaindre que les répertoires ne peuvent pas bénéficier des « tags » à base de ln dans un système hiérarchiques… c’est… comment dire… schizophrène ?
[^] # Re: les binaires, bof
Posté par reno . Évalué à 2.
Tu n'as pas bien suivi le débat.
Il me demandait ce qui manque quand on a un système de fichier hiérarchique + les hard link par rapport a un système a base de tags, et je lui ai répondu:
les hards links sur les répertoires.
Si on a ça les 2 sont équivalents, oui.
[^] # Re: les binaires, bof
Posté par BB . Évalué à 1.
Faudrait savoir, en fait vous voulez un système de fichier taggé-mais-qui-a-quand-même-une-hiérarchie ? Parce que l’idée que je me fais d’un système de fichier par tag, c’est très précisément l’idée d’abandon d’une hiérarchie.
[^] # Re: les binaires, bof
Posté par Damien Thébault . Évalué à 1.
Les idées c'est:
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Les répertoires, ça sert à faire une hiérarchie. Par conséquent, vous ne voulez pas de répertoire, donc vous n'avez pas besoin de liens physiques sur les répertoires.
[^] # Re: les binaires, bof
Posté par Sufflope (site web personnel) . Évalué à 4.
Ouais super, t'expliques à quelqu'un qui veut des tags comment les simuler de façon très chiante avec un système hiérarchique, il te montre qu'il manque des trucs, et maintenant tu lui réponds qu'il en a pas besoin.
T'as oublié tes pilules...
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 6.
Je ne comprends pas. Dans un FS non hierarchisé la notion de répertoire n'existe pas, non ?
Un fichier n'est contenu que par un ensemble de libellé.
Tanguy Ortolo, pense qu'il serait possible avec un hack un peu tordu d'utiliser les dossiers et les lien en dur comme des tags. Je ne vois pas l'utilité de faire des lien en dur sur des dossiers.
Si c'est pour hiérarchiser les tag, je ne vois pas l'intérêt d'avoir souhaité au départ ne pas avoir de hiérarchie. Parce que si c'est pour dire qu'il faut créer un tag bin dans le tag usr par exemple c'est réinventer la roue.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par oinkoink_daotter . Évalué à 3.
Oui enfin, tout le merdier BSD sous-jacent ainsi que les services récupérés d'ailleurs fonctionnent encore avec des /bin, des /usr des /var et peut-être même /etc (en plus des jolis /Applications, /Developer, /System /Users - qui sont par ailleurs localisés - ).
[^] # Re: les binaires, bof
Posté par pasScott pasForstall . Évalué à -6.
Non. C'est juste le finder qui change le nom affiche, mais ouvre un terminal et fait un cd tu verras que le nom du répertoire ne change pas.
Idem avec cmd shift g dans le finder.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: les binaires, bof
Posté par François (site web personnel) . Évalué à 0.
Tu devrais passer à OSX toi ;-)
[^] # Re: les binaires, bof
Posté par JGO . Évalué à 10.
Pfiu ça fait beaucoup de répertoires... Pourquoi ne pas les regrouper dans un répertoire principal que l'on appellerait, euh... Documents and Settings ?
[^] # Re: les binaires, bof
Posté par myocastor . Évalué à 4.
moi j'appelle etc "Eléments Textuels de Configuration" ...
ça revient au même ...
[^] # Re: les binaires, bof
Posté par stopspam . Évalué à 5.
Tant qu'à faire pourquoi "/ProgramFiles" pour /bin, ça serait nettement plus simple pour ceux qui sont passés de Windows à Ubuntu.
[^] # Re: les binaires, bof
Posté par Trollgouin . Évalué à 2.
Personnellement, j'aimerais avoir un /usr/etc où se trouverait la config des logiciels installés dans /usr. Après tout, c'est bien fait comme ça pour /usr/local/etc...
Sinon
* Le coup du /run sorti de /var, c'est très bien! Et mettons mtab et consorts par la même occasion!
* La fusion des bin ne me semble avoir que des inconvénients (déjà évoqués).
* j'ai du mal avec /var/www aussi. Je mettrais bien www dans /home, ne serait-ce que pour des raisons de simplification de mes sauvegarde...
J'ai un peu l'impression que ces messieurs pensent beaucoup aux desktops personnels et oublient d'autres déploiements de Linux (Terminaux plus ou moins légers, embarqué...).
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
/etc/localce serait une bonne idée en effet. En revanche, il y a déjà/etc/opt, par exemple. Je ne sais pas où tu as vu un/usr/local/etcmais c'est horrible./var/wwwc'est déprécié, tu peux mettre tes sites sous/srv, avec une convention à ta discrétion, par exemple/srv/www. Les serveurs Web fournis par les distributions sont configurés avec/var/wwwparce que justement, comme l'organisation de/srvest laissé à la discrétion de l'administrateur, ils ne peuvent pas faire de choix arbitraire dedans.[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Excusez-moi, je voulais bien sûr dire que c'était suranné.
[^] # Re: les binaires, bof
Posté par neil . Évalué à 4.
T'as jamais utilisé FreeBSD ?
[^] # Re: les binaires, bof
Posté par Tonton Th (Mastodon) . Évalué à 3.
Certaines de mes machines de dèv en ont un, et je ne vois pas pourquoi c'est horrible.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ah, pour mtab, excellente idée, l'avoir sous /etc est une horreur.
[^] # Re: les binaires, bof
Posté par nud . Évalué à 5.
[^] # Re: les binaires, bof
Posté par Damien Thébault . Évalué à 2.
Par défaut, c'est le cas, dans le ./configure:
Donc "./configure --prefix=/usr" va utiliser /usr/etc.
Par exemple, dans debian/ubuntu:
samba:
bind:
Si ta distribution fait comme ça et que tu n'es pas d'accord, tu peux toujours te plaindre, changer de distro ou créer la tienne ^^.
[^] # Gainsbourg
Posté par gregR ☯ (site web personnel) . Évalué à 10.
http://gregr.fr
[^] # Re: les binaires, bof
Posté par MyLordAngus . Évalué à -4.
On peut quand même se poser la question si avoir autant de répertoires pour des binaires ça ne fait pas un peu beaucoup tout de même. J'ai d'ailleurs toujours un peu de mal à saisir la différence entre bin et sbin (si je me rappelle, on trouve dans /bin les binaires essentielles au démarrage du système, et les autres c'est dans /sbin).
Par contre lier les 4 répertoires dans /usr/bin, ça risque d'être un joli bazar ce répertoire après vu le nombre de binaires présents.
[^] # Re: les binaires, bof
Posté par Toufou (site web personnel) . Évalué à 7.
à l'origine
dans /bin c'est les commandes de base des utilisateurs
dans /sbin celles réservées aux admins
tout est expliqué là : http://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Pas besoin de préciser « à l'origine » : c'est toujours le cas.
[^] # Re: les binaires, bof
Posté par nud . Évalué à 3.
Sauf pour systemd qui fout ses trucs dans /bin au lieu de /sbin
[^] # Re: les binaires, bof
Posté par Jux (site web personnel) . Évalué à 10.
C'est pour ça que Lennart veut tout changer maintenant. Il a pas bien lu la doc quand il a implémenté systemd et maintenant il préfère changer la distrib.
[^] # Re: les binaires, bof
Posté par MyLordAngus . Évalué à 2.
D'ailleurs c'est intéressant à noter que sous certaines distributions qui semblent suivre la FHS (Debian par exemple), sbin n'est pas le $PATH de l'utilisateur normal et il faut devenir root pour accéder aux binaires. Alors que pour d'autres (ArchLinux par exemple), sbin a été ajouté au $PATH pour le simple utilisateur, ce qui fait que du coup on ne voit plus trop la différence entre bin et sbin pour ces cas là.
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est la 'touch' debian ;-)
[^] # Re: les binaires, bof
Posté par gpe . Évalué à 9.
Et c'est très bien ainsi. Dans les programmes dans sbin ne sont pas utiles à un utilisateur normal.
Vouloir fusionner bin et sbin ne me semble pas une bonne idée.
[^] # Re: les binaires, bof
Posté par briaeros007 . Évalué à 4.
normalement oui.
Je reviendrais quand même sur deux trois comme
- lsof
- ifconfig / ip
Parce que ces programmes permettent d'accéder à des informations utiles (et aussi les modifier si on su, d'où le fait qu'elles sont dans /sbin).
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
which lsof
/usr/bin/lsof
Chez debian, ip et lsof sont utilisables par les utilisateurs. Pas ifconfig car je l'ai déjà dis, ifconfig est obsolète...
[^] # Re: les binaires, bof
Posté par briaeros007 . Évalué à 2.
sur certaines redhat lsof est dans /usr/sbin (ou dans /sbin je sais plus) .
[^] # Re: les binaires, bof
Posté par jben . Évalué à 6.
pas besoin de devenir root pour accéder aux binaires. Pour les exécuter généralement oui. Par exemple pour zieuter ce qu'ifconfig cause, il suffit de taper un /sbin/ifconfig, pas besoin d'être root pour cela.
[^] # Re: les binaires, bof
Posté par Damien Thébault . Évalué à 0.
Donc au final, autant laisser /sbin dans le PATH, c'est toujours frustrant de devoir mettre le chemin complet pour accéder en lecture-seule à des commandes.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.
[^] # Re: les binaires, bof
Posté par Sufflope (site web personnel) . Évalué à 4.
Mmmh ? Bah alors, et l'anti-Minitel 2.0 ? Si un utilisateur non-admin expose un service (sur un port > 1000 évidemment) il peut vouloir utiliser ifconfig en lecture seule pour savoir quelle adresse communiquer à ses amis, non ?
La séparation /bin /usr/bin je veux bien, mais /sbin pas dans le $PATH c'est limite de la sécurité par l'obscurité.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Il ne s'agit pas de sécurité mais de commodité. L'utilisateur ordinaire préfère probablement ne pas être encombré par des commandes qui ne lui servent pas. S'il préfère les avoir en autocomplétion, super, il a aussi le droit de modifier son $PATH.
Avec cette séparation bin/sbin, on a le choix entre disposer facilement de toutes les commandes ou seulement celles destinées à une simple utilisation. Sans cette séparation, ben on n'aurait pas le choix !
[^] # Re: les binaires, bof
Posté par Sufflope (site web personnel) . Évalué à 0.
Faisons un répertoire / par binaire alors, comme ça chacun pourra bien configurer son PATH comme il veut. Et ça change pas que ton « si t'as pas le droit de l'utiliser en écriture, alors t'en as pas besoin en lecture » était une bonne grosse connerie.
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Mais bordel, on a le choix ! Séparer
/binet/sbinpermet aux gens de régler leur $PATH selon leurs besoin.[^] # Re: les binaires, bof
Posté par B16F4RV4RD1N . Évalué à 6.
je te rappelle qu'on est en train de répondre à :
ça reste toujours séparé en /bin et /sbin
Et va te laver la bouche au savon, c'est mal de jurer.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: les binaires, bof
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu n'as pas beaucoup de choix. Ton argument fait qu'on doit mettre une binaire par répertoire, pour le choix.
cd va être /bin/cd/cd
ls va être /bin/ls/ls
etc...
Comme ça, tu auras les choix, tu règles ton $PATH vraiment suivant ton besoin, parce que 2 répertoires séparés bizarrement, ben c'est pas un choix.
Pourquoi t'arrêter à 2 répertoires arbitraires alors que ton argument impose de faire un répertoire par binaire?
[^] # Re: les binaires, bof
Posté par wismerhill . Évalué à 9.
Mauvais exemple, cd est une commande interne du shell, il n'y a pas de binaire correspondant ;-)
[^] # Re: les binaires, bof
Posté par Zenitram (site web personnel) . Évalué à 0.
C'est malin, on m'avais toujours dit que tout était fichier sous Linux, on m'a menti!
[^] # Re: les binaires, bof
Posté par boq . Évalué à 10.
cd n'a pas de sens a exister en dehors du shell en fait. Il se contente de changer le répertoire de travail. Si c'était une commande externe, ça changerai le répertoire travail de la commande cd, mais celui du shell resterait inchangé.
[^] # Re: les binaires, bof
Posté par Anonyme . Évalué à -2.
Et si le shell substitue "cd" par ". cd" en dur dans son code source ? Hein ? Hein ?
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 2.
Il faudrait que ce soit un script shell qui utilise une commande built-in du shell.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Non, pas plus. Si c'est un sous-processus, c'est mort, il ne peut pas agit sur le répertoire courant de son processus père.
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 2.
. ou source ça permet d'éxecuter un script shell dans le shell courant.
Une commande built-in c'est une commande du shell qui ne crée pas de nouveau processus (c'est ce que font cd, echo, set, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par Anonyme . Évalué à 1.
Plus sérieusement, en revenant à la réponse de M. Barret, je ne comprends pas. N'est-il pas possible de manipuler l'environnement depuis un exécutable ? Le fameux dernier paramètre dans cette signature :
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 3.
Les dossier courant n'est une variable d'environnement (bien que certains shells ont une variable
$PWD). Pour changer de dossier ont utilise l'appel systèmechdir(2)oufchdir(2).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Et puis, autoriser cela remettrais cause les principes d'UNIX d'héritage père fils ou un fils n'influe pas sur le père (pas de variable globale). C'est une des raisons de la solidité du modèle UNIX et de sa robustesse face au virus et autres cochonneries. C'est pour cela que je ne suis pas toujours fanatique de système de GUI moderne qui oublie un peu tout cela - bus global pour faire des espèces de variable globale (avec plus de gestion de la notion de groupe principale et d'autres choses amusantes).
Dans les anciens gestionnaire de fenêtre, on faisait un restart ou un reload pour avoir une prise en compte. Par parfait mais on ne faisait pas des modifications tous les jours. Maintenant, on met du dbus partout mais un jour, un ver va se propager la dedans et on devra avoir un firewall dbus !
[^] # Re: les binaires, bof
Posté par Anonyme . Évalué à 2.
La seule raison pour laquelle mon . cd ne marchait pas c'était à cause de la création de processus, en effet.
Par contre, essayez "set PWD=[path]" et vous verrez que vous avez changé de répertoire (en bash 4.1 du moins).
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 2.
Oui mais ça ne marche que pour bash (ça ne marche pas pour dash ni pour zsh).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
C'est peut être que ifconfig devrait être dans /bin mais pas forcément pour tous les programmes de /sbin.
D'ailleurs, il faut utiliser la commande ip qui EST dans /bin
ip link show
Mettre la commande ifconfig dans /sbin, c'est un moyen de la déprécier... (bien que je la trouve plus simple que ip).
[^] # Re: les binaires, bof
Posté par reno . Évalué à 4.
Désolé mais si ip et ifconfig sont dans 2 répertoires séparés, alors que ce sont 2 commandes "synonymes" quelque part ça montre assez bien le coté plutôt arbitraire de la séparation..
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
La commande ifconfig est obsolète... elles ne sont pas donc synonymes à 100%. Il me semble normal de "cacher" de l'utilisateur une commande obsolète mais de la garder un certain temps quand même pour les anciens scripts !
[^] # Re: les binaires, bof
Posté par coïn . Évalué à 1.
ca aurait été plus malin et plus clair de mettre dans un répertoire genre /deprecatedbin ou/dbin ca aurait été plus clair je trouve.
[^] # Re: les binaires, bof
Posté par claudex . Évalué à 3.
Ça aurait péter tous les scripts qui utilise le chemin d'accès complet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: les binaires, bof
Posté par Juke (site web personnel) . Évalué à 6.
Le vendredi 04 novembre 2011 à 23:41 +0100, Sytoka Modon a écrit :
> ifconfig est obsolète.
t'a un lien qui decris pourquoi ?
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En cherchant 30s, j'ai retrouvé cela...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538433
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html
Je crois qu'il y a des soucis avec IPv6... je ne sais plus bien. Debian pousse iproute2 qui installe la commande ip qui gère aussi les routes.
Je dois dire que 90% de mes scripts utilisent encore ifconfig... La migration va être longue ;-)
[^] # Re: les binaires, bof
Posté par pasScott pasForstall . Évalué à -8.
Debian pousse le dernier gadget de chez apple? étonnant.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: les binaires, bof
Posté par Florent Fourcot . Évalué à 5.
En réalité, la différence est relativement fondamentale. Ifconfig et ip n'ont pas la même façon de discuter avec le noyau. ip utilise netlink, qui permet de rajouter facilement des nouvelles options et est très flexible.
ifconfig quand a lui utilise encore les ioctl. L'objectif est de ne plus ajouter d'ioctl pour les services réseaux (car c'est lourd, Wikipedia explique bien pourquoi), et toutes les nouveautés à ce sujet du noyau doivent donc passer par ip (ou tout autre outil qui discute par netlink).
Pour l'utilisateur final qui n'a pas de gros besoins la différence reste surtout dans l'affichage... Personnellement je trouve ip plus pratique à l'usage, car il fait toute la configuration de la couche IP à lui tout seul (alors que sinon faut utiliser ifconfig, route...).
[^] # Re: les binaires, bof
Posté par kna . Évalué à 1.
Sous debian, archlinux, slackware et gentoo (au moins), la commande ip est dans /sbin
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
which ip
/bin/ip
J'avais fais l'essais avant de le dire (je suis sous debian squeeze).
[^] # Re: les binaires, bof
Posté par kna . Évalué à 1.
Ah ok, sous debian, c'est plus subtil :
[^] # Re: les binaires, bof
Posté par Juke (site web personnel) . Évalué à 3.
Le vendredi 04 novembre 2011 à 22:18 +0100, Sytoka Modon a écrit :
> ip link show
ip addr show plutot non ?
[^] # Re: les binaires, bof
Posté par briaeros007 . Évalué à 2.
[~]$ which ip
/sbin/ip
Ben pas chez moi
[^] # Re: les binaires, bof
Posté par nud . Évalué à 2.
En fait ça ne veut rien dire, si le binaire est présent/symlinké dans /sbin et /bin, ça dépend de l'ordre de ton $PATH.
[^] # Re: les binaires, bof
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Bof bof, quand on admine on le fait en utilisateur normal et on passe root seulement si besoin est.
Après la frontière est parfois floue, sous FreeBSD ping est dans /sbin (ben oui, commande système et en suid root) par exemple.
les pixels au peuple !
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 2.
C'est dommage je sais pas sous FreeBSD, mais sous linux il y a une capabilities qui permet de ne pas lui donner suid root (CAP_NET_RAW, je ne pense pas qu'il constitue une faille, en tout cas moins que le suid).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
which ping
/bin/ping
Sous dedian, ping n'est pas sous sbin. C'est idiot de mettre sous /sbin un binaire suid qui a justement vocation a être utiliser par quelqu'un d'autre que root.
Il ne faut pas se leurrer, les capabilities, c'est juste découper le bit suid en petit morceau plus petit. Il ne faut pas dire qu'il n'y a pas de suid, il y a un suid limité...
Question, la commande montre les capabilities ?
[^] # Re: les binaires, bof
Posté par Damien Thébault . Évalué à 1.
http://kernelnewbies.org/Linux_3.0#head-c5bcc118ee946645132a834a716ef0d7d05b282e
[^] # Re: les binaires, bof
Posté par barmic . Évalué à 5.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: les binaires, bof
Posté par eric1803 . Évalué à 1.
Surtout que tous les gens qui ont mis un /usr et un / sur différente partitions seront dans la mouise (c'est à dire l'ensemble des PC que j'ai installé)
# Grosse connerie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ce serait une grosse connerie, ça.
/usr/(s)binexiste aujourd'hui précisément pour être séparé de/(s)binafin de permettre des installation où, par exemple,/usrserait sur NFS, et ne pourrait être monté… qu'à une certaine étape du démarrage, avant laquelle/(s)binsuffirait.Bref, dans Fedora et autre ils font ce qu'ils veulent, mais cette idée ne s'imposera pas de façon générale. Debian ne pourra pas y adhérer, notamment.
[^] # Re: Grosse connerie
Posté par dguihal . Évalué à -10.
Autant fusionner usr/bin et bin je suis plutot contre, mais fusionner bin et sbin je suis 100% pour
Pour rappel le s de sbin ne signifie static ce qui est complètement outdated a l'heure actuelle
[^] # Re: Grosse connerie
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 10.
Absolument pas, le "sbin" est la pour stocker les programmes dédiés a l'administration système et/ou rservés au super utilisateur,
et le "s" est pour "system".
http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
[^] # Re: Grosse connerie
Posté par Marotte ⛧ . Évalué à 2.
Moi je croyais que le s était pour setuid bin ?
D'ailleurs setuid tout court signifie en vérité set uid = 0 non ?
Les noms de répertoires dans Unix sont sur trois lettres car à l'époque on comptait chaque octet. Maintenant ça paraît inutile vue la puissance que l'on a, même dans l'embarqué. Mais qui sait si un jour on aura pas besoin d'un Unix pour un nano-ordinateur biologique avec une mémoire de 4ko ? Je suis pour garder les noms de répertoire à trois ou quatre caractères. Après on peut effectivement adapter : /run vs /var/run par exemple.
Je me suis toujours demandé d'où venaient ces noms :
/bin : facile, c'est binary.
/usr : user ?
/var : variable ?
/etc : là c'est plus dur, et cætera ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Grosse connerie
Posté par Physche . Évalué à 1.
Cet acronyme est complètement anachronique et n'a aucun sens dans l'histoire d'Unix. Le nom du répertoire /etc provient bien de "et caetera".
De plus, des noms des répertoires que tu as cité, aucun d'entre-eux n'a réellement existé sous Unix.
[^] # Re: Grosse connerie
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Sous AIX (ou HP-UX j'ai un trous), le home du compte root était directement sous / !
J'adore les UNIX propriétaire ;-)
[^] # Re: Grosse connerie
Posté par Misc (site web personnel) . Évalué à 2.
/usr => Unix System Ressource
http://fr.wikipedia.org/wiki/Usr
[^] # Re: Grosse connerie
Posté par Physche . Évalué à 1.
Il s'agit encore d'un anachronisme. Le nom "usr" signifie "users", c'est a dire le répertoire personnel des utilisateurs. Sa fonction a néanmoins bien changé sur les dérivés d'Unix récents.
[^] # Re: Grosse connerie
Posté par Marotte ⛧ . Évalué à 3.
Tu veux dire rétroacronyme plutôt non ?
[^] # Re: Grosse connerie
Posté par Physche . Évalué à 1.
C'est effectivement un rétro-acronyme, mais c'est aussi un anachronisme parce que sa définition ne correspond pas du tout à l'utilisation qui était faite de ce répertoire à l'époque.
[^] # Re: Grosse connerie
Posté par Toufou (site web personnel) . Évalué à 1.
Tu as une source ou un exemple stp ?
Je n'ai jamais vu /usr utilisé comme /home à part peut-être sous novell (je ne me rappelle plus très bien : je n'utilise plus de novell depuis ... hooouuu longtemps :)).
[^] # Re: Grosse connerie
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
A mes souvenirs, sous IRIS (SGI), les homes étaient sous /usr/people... mais tout cela est vieux !
[^] # Re: Grosse connerie
Posté par oinkoink_daotter . Évalué à 1.
Sous Slowlaris, c'est dans /export/home avec un re-montage rigolo dans /home par l'automounter. Grruuuiiiikkkk !
[^] # Re: Grosse connerie
Posté par Guillaume Knispel . Évalué à 4.
non
Non. setuid signifie set uid = uid of owner. Si l'owner est 0, ce qui est courant, le résultat est bien set uid = 0. Mais en aucun cas setuid tout court signifie systématiquement que de mettre uid = 0
[^] # Re: Grosse connerie
Posté par Misc (site web personnel) . Évalué à 5.
L'idée est que le montage de / est fait par l'initrd , donc à quoi ça sert d'avoir des binaires dans /bin et /sbin quand ils sont déja dans l'initrd.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Grosse connerie
Posté par Naha (site web personnel) . Évalué à 1.
À pouvoir se passer d'initrd ? C'est encore utile sur certaines architectures.
[^] # Re: Grosse connerie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Il y a aussi des systèmes qui n'ont pas d'initrd du tout, des BSD par exemple, je pense. Or la FHS n'est pas spécifique à Linux, même si on sait déjà que Lennart n'en a rien à foutre des autres Unices.
[^] # Re: Grosse connerie
Posté par Guillaume Knispel . Évalué à 10.
Je peux aussi me customiser un système GNU/Linux facilement sans initrd, et il serait appréciable que des hippies n'essayent pas de niquer tout l'écosystème au pretexte que OIN C'EST COMPLIQUÉ YA DEUX REPERTOIRE BOUHOUH JE PEUX PLUS DORMIR. Lennart est notoirement connu pour n'en avoir rien à battre de toutes les fonctions existantes et des uses case qui ne l'intéressent pas, ce qui fait que même quand il a des idées intéressantes sur d'autres point, sa tendance à vouloir répandre ses softs à sa sauce partout (et le fait qu'il y arrive pas mal, en plus) en fait un type dangereux pour les gens qui utilisent vraiment les Unix comme des Unix et non pas comme des Windows/Mac Os X inférieurs.
[^] # Re: Grosse connerie
Posté par CrEv (site web personnel) . Évalué à 1.
Oué enfin sur ce point j'aurais tout de même séparé windows et mac question unix...
[^] # Re: Grosse connerie
Posté par Fopossum . Évalué à 10.
Que certaines distribs n'utilisent pas d'initrd ?
Désolé, mais quand je compile mon kernel, je mets en dur dedans le mini pour démarrer (FS, réseau et affichage) et le reste en module (carte tuner ou sondes températures par exemple). Donc, je n'ai pas besoin d'initrd.
L'initrd aurait même plutôt tendance à me casser les baballes d'ailleurs.
Mon kernel n'a pas vocation à booter sur 42000 configs différentes donc pas besoin de me trimballer tout le kernel ou presque en modules chargés direct au cas où j'aurais le matos X ou Y.
Pour le reste, cette propale est Linux-centric et non, perso, le FHS tel qu'il est pour l'instant à moi me parait bien.
Merger /bin et /sbin d'un côté et /usr/bin et /usr/sbin de l'autre me paraît être juste une grosse connerie.
Déjà, si le FHS était appliqué correctement en entreprise, ça serait un gros plus. Marre de voir des "/application" "/logiciels" "/projets" "/mescouilles" etc. Avant de modifier la norme, essayons d'appliquer celle déjà en vigueur.
cd /pub && more beer
[^] # Re: Grosse connerie
Posté par fyah . Évalué à 2.
Je plussoie avec vigueur !!!
Je ne me remets toujours pas des chemins débiles type /var/opt/etc ou /etc/opt/usr que je me tape tous les jours au taff ....
[^] # Re: Grosse connerie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
/var/optc'est standard./etc/optaussi.[^] # Re: Grosse connerie
Posté par CrEv (site web personnel) . Évalué à 2.
Ou alors cela montre que le FHS n'est, dans l'intégralité des cas :
Et d'ailleurs si certains développeurs veulent modifier la norme c'est bien que le besoin existe, même si ça ne convient peut-être pas à tous les cas de figure (ça reste une question).
[^] # Re: Grosse connerie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Non non non, ça montre seulement que ce n'est pas compris. Dans l'immense majorité de ces abus, il existe un chemin standard qui conviendrait, seulement le responsable n'était pas au courant parce qu'il n'a pas la FHS en livre de chevet, c'est tout.
[^] # Re: Grosse connerie
Posté par CrEv (site web personnel) . Évalué à -1.
Absolument pas.
A moins que tu arrives à prouver qu'une seule solution existe, je ne vois pas comment tu peux affirmer cela.
D'ailleurs, tu en montres tout de suite un exemple : s'il est nécessaire d'avoir la FHS en livre de chevet pour savoir où placer ses fichiers, que c'est compliqué et qu'il y a potentiellement un problème.
D'ailleurs le simple fait que certains cherchent d'autres solutions, y compris dans l'écosysteme linux, c'est qu'il y a une raison.
Et on voit aussi que d'autres font différemment sans problème (oui, mac)
[^] # Re: Grosse connerie
Posté par Octabrain . Évalué à -1.
Comment faire un / crypté si on n'a pas de initrd ?
[^] # Re: Grosse connerie
Posté par briaeros007 . Évalué à 3.
chiffrement hardware ?
[^] # Re: Grosse connerie
Posté par Moonz . Évalué à 5.
Ha, toi aussi tu caches des secrets industriels par stéganographie dans /bin/ls ?
[^] # Re: Grosse connerie
Posté par Dorian . Évalué à -3.
C'est un besoin assez spécifique, et tu peux très bien ajouter le dossier NFS dans ton PATH, ou mettre carrément un lien symbolique de /bin vers ton dossier NFS
Et ce n'est pas changer pour changer (vive le progrès !), mais plutôt une amélioration logique et réfléchie d'une tare qu'il nous reste de l'héritage d'UNIX et que tout le monde avait fini par accepter.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Grosse connerie
Posté par Damien Thébault . Évalué à 2.
Sur Hurd ils avaient prévu de supprimer /usr et de simplement utiliser unionfs à la place, ce qui est quand même beaucoup plus élégant que d'avoir plusieurs niveaux de hiérarchie (/bin, /usr/bin, /usr/local/bin) et d'utiliser beaucoup PATH.
Pour ajouter des binaires provenant d'un montage NFS, il suffit de le monter quelque part (/mnt/nfs?) et d'ajouter /mnt/nfs à l'unionfs principal.
[^] # Re: Grosse connerie
Posté par Jean B . Évalué à 6.
Pourquoi avaient ? Hurd est mort ?
[^] # Re: Grosse connerie
Posté par Damien Thébault . Évalué à 3.
De mon point de vue oui.
En gros, quand le projet Hurd/L4 a commencé à avancer, les gars de Hurd/L4 se sont aperçus que Hurd était mal conçu, les gars de Hurd ont dit que L4 n'était pas adapté à Hurd et ont dit qu'il vallait mieux attendre le prochain micronoyau.
(ensuite ça a fait la même chose avec Coyotos)
(ensuite ils se sont dit que le micronoyau devait aller de pair avec la définition du système, ils ont commencé à travailler sur Viengoos et Hurd-NG)
On est en 2011, il n'y a rien de neuf depuis Hurd/Mach dans les années 90.
[^] # Re: Grosse connerie
Posté par pasScott pasForstall . Évalué à -10.
Effectivement.
Pour être mort, faut deja avoir vécu.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Grosse connerie
Posté par Michaël (site web personnel) . Évalué à 4.
Un autre avantage de l'utilisation de plusieurs préfixes où les préfixes sont associés à des systèmes de fichiers distincts: c'est utile pour la récupération des erreurs.
Avec des partitions séparées:
- on réduit le temps de récupération de la racine du système de fichiers s'il a été mal démonté;
- on cloisonne les corruptions de données et on augmente les chances de garder un système racine sain;
- on peut effectivement monter le système racine en read-only, pour éviter la corruption des fichiers système par une application malveillante.
[^] # Re: Grosse connerie
Posté par nud . Évalué à 1.
Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?
[^] # Re: Grosse connerie
Posté par Michaël (site web personnel) . Évalué à 6.
Ben il ne devrait pas, c'est justement à être sur une autre partition que
/que sert/usr![^] # Re: Grosse connerie
Posté par nud . Évalué à 2.
Je n'ai pas d'opinion forgée sur le sujet, mais je suppose que c'est la raison pour laquelle Lennart est pour la fusion de /bin et /usr/bin.
[^] # Re: Grosse connerie
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Ca prouve une chose si cela est vrai, c'est que systemd est beaucoup trop rigide pour tout baser dessus et il ne tiendra pas 10 ans à cette allure...
Bref, cela me fait plus penser à un problème de conception !
[^] # Re: Grosse connerie
Posté par nud . Évalué à 1.
Si tu lis les liens que j'ai mis (ce que tu n'as visiblement pas fait), tu verras que le problème ne se situe pas au niveau de systemd proprement dit mais d'autres services très communs qui sont invoqués au début du processus de boot principalement via des règles udev. Les problèmes sont liés aux locales, aux libs (notamment dbus), aux bases de données USB/PCI et autres trucs liés.
[^] # Re: Grosse connerie
Posté par barmic . Évalué à 6.
pourquoi il ne le monte pas plutôt alors ? Gérer ce genre de dépendance c'est je trouve le B-A BA de ce que devrait faire un système d'init.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Grosse connerie
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
J'ai fais exprès de ne pas lire le lien pour simplement réagir sur la forme.
Ce que j'en pense est que systemd a vouloir tout gérer dès le début me semble avoir un problème de conception s'il est aussi rigide. Il me semble normal qu'une partie du système ne soient pas monté au tout début (/usr ou autre (des services sous /srv...)). Si des programmes ont besoin de /usr, soit il faut les démarrer plus tard, soit il faut déplacer les dépendances de /usr vers /, soit il faut que le service se lance en mode dégradés puis se recharge au fur et à mesure des montages.
L'ordre de montage et le lancement des services a toujours été un jeu subtil (bidouille _netdev dans fstab...). Une bonne archi doit pouvoir gérer cela. Je ne dis pas que c'est simple !
Peut être systemd avec dbus et tout le tralala est un peu gros pour être le job 1... Pourquoi pas un systemd minimal qui au fur et à mesure du boot chargerait des greffons ?
[^] # Re: Grosse connerie
Posté par nud . Évalué à 2.
Sauf que le problème principal ici ce sont les règles udev, et que udev prédate systemd. Et tu as besoin de udev pour trouver tous tes disques. Et sans /usr tu ne peux pas trouver les disques USB ou les controleurs PCI vu que c'est là que se trouvent les bases de données. Systemd proprement dit n'a pas de dépendances dans /usr. Comme il le dit sur la page, systemd est ici uniquement le messager, pas le problème.
On pourrait peut-être désemberlificoter tout cela, mais apparemment tout le monde s'en fout, ou en tout cas personne ne s'y intéresse suffisemment que pour corriger le problème.
[^] # Re: Grosse connerie
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Pourquoi ne pas tout simplement mettre les bases de données USB et PCI dans /lib ? On a bien un /lib/modules ! D'après ce que tu dis, cela semble plus un bogue udev que systemd...
[^] # Re: Grosse connerie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Tiens, d'ailleurs c'est le cas historiquement…
[^] # Re: Grosse connerie
Posté par Michaël (site web personnel) . Évalué à 3.
De ma vie je n'ai jamais eu
/et/usrsur la même partition! Au risque de passer pour un jeune dinosaure…Sous FreeBSD que j'utilise depuis 2000, l'outil d'installation crée une partition différente pour
/usr' et je n'ai jamais vu l'intérêt d'y changer quelque chose: l'ensemble des fichiers écrits dans/a une taille peu fluctuante entre les mises-à-jour (du moins, mon dossier/` n'a jamais explosé!).Je ne parvies ni à me souvenir ni à retrouver un petit texte que j'avais lu expliquant pourquoi un dossier et une partition
/usravaient été introduits, et quelles nouvelles raisons pour son introduction avaient été trouvées au fur et à mesure que certains progrès techniques rendaient caduques les anciennes.# Fedora
Posté par pamputt . Évalué à 1.
Si j'ai bien compris, ce changement en concerne que les prochaines versions de FEDORA. Il ne s'agit pas de changer la LSB ?
[^] # Re: Fedora
Posté par GeneralZod . Évalué à 2.
Non, c'est des changements proposés dans le FHS et qui semblent réaliser l'unanimité autour.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# euhhh
Posté par AhmetD (site web personnel) . Évalué à 10.
Corrigez-moi si je me trompe mais pour moi :
- /sbin : les binaires systèmes essentiels (ex: ifconfig, su, sh ...)
- /usr/sbin : les binaires systèmes non-essentiels (ex: route, ...)
- /bin : les binaires applicatifs essentiels
- /usr/bin : les binaires applicatifs non-essentiels
idem avec lib.
Donc pourquoi vouloir tout mélanger ?! C'est comme ranger les couteaux à poisson avec les couteaux à viande. tssss
[^] # Re: euhhh
Posté par Naha (site web personnel) . Évalué à 4.
Je te corrige car tu te trompe :
$ which route
/sbin/route
routeest un utilitaire essentiel, comment tu fais pour communiquer avec le monde extérieur si tu ne peux pas configurer tes routes ?[^] # Re: euhhh
Posté par jiyuu . Évalué à 6.
Idem.
[^] # Re: euhhh
Posté par Naha (site web personnel) . Évalué à 3.
Erf la honte.
/me se flagelle à coups de câble Ethernet.
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
câble catégorie 5 ou 6, pas câble Ethernet, ce serait confondre la fonction avec l'usage. D'ailleurs tu en fais un usage légitime qui n'a rien à voir avec le protocole Ethernet, à ce que je vois.
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Argh. Ce serait confondre la nature avec la fonction.
/me se flagelle à coup de fibre monomode.
[^] # Re: euhhh
Posté par Naha (site web personnel) . Évalué à 5.
Bon je vois que vous avez tous décidé de me faire chier aujourd'hui, j'abandonne :-D
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
C'est pour ça qu'il faut lire DLFP aux toilettes !
[^] # Re: euhhh
Posté par AhmetD (site web personnel) . Évalué à 0.
C'est pas faux et c'est vrai que je suis en /sbin après vérification :)
Par contre sous Debian et SLES tu es en /sbin et sous Solaris en /usr/sbin.
[^] # Re: euhhh
Posté par B16F4RV4RD1N . Évalué à 1.
je ne suis pas admin système de haut vol (seulement du mien de système), alors je peux dire des conneries (ça ne changera pas bcp de d'habitude...), mais si je trouve nécessaire de séparer les binaires systèmes "sensibles" des autres (/usr/sbin et /usr/bin), par contre je trouve idiot de dupliquer des emplacements de binaires en pseudo catégories, cf. les fameux /usr/games/ /usr/share/games (wtf ?) /usr/local/games etc), ça veut dire quoi, que les jeux c'est moins important que par exemple un éditeur xml ?
Quitte à séparer les binaires, pourquoi ne pas les mettre dans /usr/share/programme1, /usr/share/programme2 etc (ou équivalent plus parlant), en même temps que les données et la notice ? Comme ça quand on en a marre de jouer à kdiamond, on supprime /usr/share/kdiamond et il ne reste pas des bouts de logiciel un peu partout (dans /usr/man/kdiamond, dans /usr/doc/kdiamond/html, dans /usr/bin/kdiamond etc). Ah mais oui il y a le gestionnaire de paquets pour s'occuper de cela... et pour les programmes compilés maison, c'est dans /usr/local/doc/machin etc . Au final, au bout de 6 mois on ne sait plus si on a installé ce logiciel via le gestionnaire de paquets ou à la main et ça devient un beau bordel.
Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre. Il y a des bidouilles pour simuler cela (par exemple http://freecode.com/projects/libetc que je n'ai pas eu le courage de tester, par peur de tout casser), mais il faudrait peut-être le faire de manière plus systématique et par défaut sur toutes les distributions.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Non, ça veut dire qu'un type au travail n'en a pas besoin, et peut ainsi ne pas s'encombrer d'une autocomplétion sur les jeux, par exemple. Et s'il les veut, eh bien il change son $PATH, il a le droit aussi.
La séparation entre logiciels d'administration, logiciels d'utilisation et jeux est pertinente. On pourrait aller plus loin mais il faut un compromis ; celui-ci est probablement historique, et assez pratique pour qu'on n'ait pas envisagé de le changer.
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
… dans /opt/logiciel. Et ça reste très propre.
http://standards.freedesktop.org/basedir-spec/latest/. De rien.
[^] # Re: euhhh
Posté par sifu . Évalué à 2.
Malheureusement, tout le monde n'a pas l'air de la respecter ...
https://bugzilla.mozilla.org/show_bug.cgi?id=259356
Chez moi, cela reste un joyeux bordel. Cache, données temporaires, configuration, on y trouve de tout !
[^] # Re: euhhh
Posté par Octabrain . Évalué à -3.
En attendant : http://ordiluc.net/fs/libetc/
[^] # Re: euhhh
Posté par Octabrain . Évalué à -3.
Moinssez-moi, je suis complètement à la masse
[^] # Re: euhhh
Posté par barmic . Évalué à 2.
Je me demande si un jour des logiciels comme vim, emacs et ceux qui se configure via ${HOME}/.Xdefault y passeront.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: euhhh
Posté par B16F4RV4RD1N . Évalué à 2.
sauf que make install généralement installe ça dans /usr/local/share (make prefix=$chemin/machin install n'est pas toujours pris en compte, et parfois certains binaires s'attendent à trouver les données dans un dossier particulier, genre /usr/lib/logiciel), et s'il faut faire des modifications compliquée pour installer un logiciel, autant faire un paquet.
merci, je connais, et ça reste très peu suivi, y compris sur des projets récents, c'est une vraie plaie.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: euhhh
Posté par oinkoink_daotter . Évalué à 1.
C'est pour ça qu'il vaut mieux mettre le prefix=/usr/local/bidule lors de l'appel du ./configure au cas où il y aurait des variables fixées en dur lors de cette phase ou de la compilation.
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Ça, c'est une violation de la FHS. Si tu as besoin d'un préfixe, tu as le choix entre
/,/usr,/usr/localet/opt/logiciel. Mais certainement pas/usr/local/logiciel.[^] # Re: euhhh
Posté par briaeros007 . Évalué à 1.
moi j'utilise "$HOME/dvp/" , c'est pas FHS, mais ca sépare le système d'un utilisateur particulier.
Sinon, dans /opt/bin /opt/lib/ etc... (enfin quand j'ai le courage).
[^] # Re: euhhh
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça c'est encore une violation de la FHS. Si tu veux classer les binaires, les bibliothèques et tout séparément, tu as
/usr/localpour ça./optn'est pas un préfixe, c'est un répertoire pour des préfixes distincts.[^] # Re: euhhh
Posté par Toufou (site web personnel) . Évalué à 0.
Au passage, il ne me viendrais pas a l'idée de mettre des binaires dans /usr/local, /opt est là pour ça.
[^] # Re: euhhh
Posté par Sylvain Sauvage . Évalué à 2.
/usr/local est bien pour les applications… mais locales : /usr/local ne devrait pas être sur NFS (p.ex.).
/opt peut être déporté (NFS…).
[^] # Re: euhhh
Posté par Toufou (site web personnel) . Évalué à 1.
beh /usr/local peut aussi être déporté (/usr existe pour cette raison) et d'après la FHS /usr/local est dédié aux -données- locales, alors qu' /opt est dédiés aux programmes optionnels => http://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Donc tu peux considérer un programme (une lib ou autre) comme une donnée mais dans ce cas, quelle différence entre /opt et /usr/local ?
[^] # Re: euhhh
Posté par Sylvain Sauvage . Évalué à 3.
Ce n’est pas parce que /usr est déporté que /usr/local l’est.
/usr/local est, je cite wp:en (un peu plus complète que wp:fr) : « [a t]ertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/ ». data est donc bien ici à prendre au sens large, sinon pourquoi bin et lib ?
Il y a aussi une note complétant cette description : « Historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network). » qui redit bien la non-déportation de /usr/local.
Et le reste de la note : « Most of the time /usr/local/ is used for installing software/data that are not part of the standard operating system distribution (in such case, /usr/ would only contain software/data that are part of the standard operating system distribution). It is possible that the FHS standard may in the future be changed to reflect this de-facto convention). » me conforte dans l’idée que /usr/local contient des applications.
Donc, oui, il y a toujours eu un chevauchement entre /opt et /usr/local dans le but, surtout pour lorsqu’on ne déporte rien, mais /opt contient un répertoire par application¹ (/opt/openoffice/{bin,lib,…}, /opt/jdk/{bin,lib,…}) alors que /usr/local est une hiérarchie comme / et /usr (avec l’utilisation du programme stow pour rendre tout ça plus propre).
¹ Une note renvoie sur la bonne section de la FHS
[^] # Re: euhhh
Posté par Toufou (site web personnel) . Évalué à 1.
Après quelques recherches (plus) approfondies, voici ce que j'ai trouvé :
Concernant /usr/local :
tu as raison concernant les programmes : c'est une hiérarchie, du même type que /usr, dédiée au programmes installés par localement par l'admin et qui ne doivent pas être affectés par les mises à jour du système (contrairement à /usr qui lui peut être mis à jour par la distribution). (source : http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY)
En revanche, d'après cette source c'est partageable par un groupe d'hôtes donc la note de wikipedia est incorrecte : si plusieurs hôtes peuvent se partager un /usr/local commun c'est qu'il n'est pas obligatoire de stocker sur l'hôte cette hiérarchie, ou alors je ne comprend pas comment tu la partage (par rsync ???).
Concernant /opt :
/opt est destiné aux "add-on application software packages". Il y a toutefois une hiérarchie optionnelle prévue dans /opt (/opt/bin, /opt/lib, etc.) mais elle est réservée à l'admin et les softs doivent être dans des répertoires dédiés et doivent pouvoir fonctionner sans les repertoires /opt/bin et assimilés.
Pour ma part, je comprends qu'on y met "logiciels additionnels packagés". En gros, les trucs ne faisant pas partie de la distribution mais packagés par le fournisseur : java-sun, eclipse si tu l'installes toi même, firefox, perl si tu ne prend pas celui de la distro (oui j'utilise aussi une debian ;)) ...
Donc de ce que j'en comprends, la différence profonde entre /opt et /usr/local c'est, outre la structure, que les programmes de /opt sont susceptibles d'êtres mis à jour par le système du fournisseur du package logiciel (firefox, cpan, eclipse...), alors que ceux de /usr/local ne doivent pas être affectés par un tel système.
Pfiou, on va y arriver :)
[^] # Re: euhhh
Posté par barmic . Évalué à 2.
Perso dans /opt, je met les logiciels Java qui ont juste besoin d'être dézipé (netbeans, glassfish, maven, tomcat, etc …).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: euhhh
Posté par nud . Évalué à 1.
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ?
[^] # Re: euhhh
Posté par gouttegd . Évalué à 4.
Amen sur ce point, mais ce n’est pas aux distrbutions d’y faire quelque chose… Une convention a été proposée, c’est aux développeurs upstream de l’implémenter dans leurs logiciels.
libetc est une bidouille, le jour où les distributions auront recours à ce genre de choses pour pallier aux déficiences des logiciels on sera arrivé au niveau de Microsoft, qui virtualise le système de fichiers ou la base de registre pour permettre à des applications codées avec les pieds (par des développeurs qui se croient encore sous Windows 9x, et qui cherchent à stocker les préférences directement dans
C:\Program Filesau lieu de %HOME% par exemple) de fonctionner à peu près correctement.[^] # Re: euhhh
Posté par gouttegd . Évalué à 3.
s/pallier aux déficiences/pallier les déficiences/(Honte sur moi — mais quand même, il a trop raison ce mec.)
[^] # Re: euhhh
Posté par Michaël (site web personnel) . Évalué à 3.
Sur la partition racine vont les fichiers nécessaires à l'amorce du système et son entretien, tout le reste dans
/usr: c'est la règle qui définit essentiel.# différencier les binaires linkés statiquement des autres.
Posté par Sebastien MICHEL (site web personnel) . Évalué à -2.
/sbin est aussi utilisé pour stocker des binaires statiques. Ces binaires peuvent avoir plusieurs raisons d'être:
* pour le démarrage sans répertoire de librairies
* en cas de problème -démarrage dégradé-
* En cas de problème ou d'environnement spécial avec ld preload (/etc/ld.so.preload)
# Vendredi
Posté par Julien Gilbert . Évalué à 10.
Le portable sur les genoux, au coin du feu, avec un bon gros troll sur DLFP... un vendredi comme au bon vieux temps.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Vendredi
Posté par Nonolapéro . Évalué à 1.
J'aurais tendance à dire que c'est un vendredi chargé en trolls entre cette dépêche, celle sur KDE 3.5 et le journal sur Gnome Shell. Heureusement qu'il n'y a rien sur le code de la route ni sur une question de société tel que l'avortement.
[^] # Re: Vendredi
Posté par Juke (site web personnel) . Évalué à 1.
Le vendredi 04 novembre 2011 à 16:37 +0100, Nonolapero a écrit :
> Heureusement qu'il n'y a rien sur le code de la route ni sur une question de société tel que l'avortement.
C'est triste ton opinion sur la façon de conduire des avorteuses grecques.
# /lib64
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
est une bidouille fait au moment de l'amd64.
Debian a beaucoup bossé la question du multi-arch et a proposé une solution générique qui est en cours d'implémentation dans dpkg notamment. Pourquoi ne pas reprendre la solution debian ici ?
Pour le reste, c'est du Lennart, un peu tout refaire pour des raisons de ménage. A vrai dire, ca semble pas spécialement intéressant au premier abord...
Pour le /tmp global, debian le vide à chaque boot et c'est génial. Les tmp chez les utilisateurs ne sont jamais nettoyé... C'est pas bon non plus !
[^] # Re: /lib64
Posté par GeneralZod . Évalué à 0.
Pourquoi Debian a pas repris la solution RPM ? ça doit faire des années qu'on le fait dans Fedora, SuSE ou Mageia (et ses ancètres).
[^] # Re: /lib64
Posté par gilles renault (site web personnel, Mastodon) . Évalué à -4.
Je retourne régulièrement tester les fedora, et à chaque fois la lenteur de la gestion des pacakges rpm me gonfle! Dpkg/apt me semble beaucoup plus rapide.
[^] # Re: /lib64
Posté par GeneralZod . Évalué à 6.
ça n'a juste aucun rapport avec le multi-arch.
[^] # Re: /lib64
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Il dit qu'il n'a plus de genoux.
[^] # Re: /lib64
Posté par Prae . Évalué à 3.
M'enfin! monsieur n'est pas une tapette, voyons !
[^] # Re: /lib64
Posté par CrEv (site web personnel) . Évalué à 2.
Dans ce cas va tester urpm* et tu verra que la lenteur n'est pas forcément liée à rpm.
Bon après, franchement les paquets ça s'installe pas tous les jours (ou alors on a pas du tout le même usage...)
[^] # Re: /lib64
Posté par Guillaume Knispel . Évalué à 2.
Effectivement, perso j'ai tendance à installer / desinstaller des paquets au moins toutes les semaines, et certaines semaine tous les jours. Certains dev peuvent potentiellement installer des paquets des dizaines de fois par jour.
[^] # Re: /lib64
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Mauvaise question. La bonne question, c'est : pourquoi RedHat n'a pas repris la solution DEB au lieu de développer son propre système RPM ? Désolé si je brise vos rêves, mais le premier système de gestion de paquets, c'est celui de Debian, hein.
[^] # Re: /lib64
Posté par vladislav askiparek . Évalué à 3.
Parce que le premier n'est pas forcément le meilleur?
Le preuve: avant, il y avait des téléphones portables, maintenant il y a l'iphone...
Ok, c'est pas le meilleur exemple mais bon..
[^] # Re: /lib64
Posté par Altor . Évalué à 10.
Désolé si je brise vos rêve, mais le premier système de gestion de paquets (encore maintenu), c'est celui de slackware, hein.
[^] # Re: /lib64
Posté par vladislav askiparek . Évalué à 8.
Ah merde! Donc dans ce cas, le premier était le meilleur.
[^] # Re: /lib64
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
parce que Debian a généralisé cela au multi-arch ou on peux faire un mix avec de l'ARM par exemple. C'est très bien expliqué par Raphaël Hertzog dans dpkg.
http://lists.debian.org/debian-devel-announce/2011/06/msg00002.html
http://wiki.debian.org/Multiarch/
La source initiale mais j'en suis pas sur...
http://raphaelhertzog.fr/2011/07/06/mes-activites-debian-en-juin-2011/
[^] # Re: /lib64
Posté par O'neam Anne . Évalué à 2.
Sous ArchLinux, /tmp est un tmpfs, ce qui fait qu'il est toujours supprimé lorsque l'ordinateur s'éteint. Auparavant, il s'agissait simplement d'un répertoire dont le contenu était supprimé lors de l'extinction et/ou de l'allumage, ce qui faisait entre autre que si l'ordinateur était coupé brusquement (typiquement, une coupure de courant), en démarrant sur un autre système d'exploitation, on pouvait aller regarder les fichiers dans /tmp.
Maintenant, je suis peut-être un peu cruche, mais je ne vois pas ce qui empêche de reproduire ces deux comportements d'être appliqués à l'échelle de chaque utilisateurs plutôt qu'à l'échelle du système. Il y a bien moyen de faire exécuter des scripts lors de la connexion et déconnexion d'un utilisateur.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: /lib64
Posté par barmic . Évalué à 3.
L'utilisation de tmpfs pose d'autres problèmes. Certains logiciels utilisent /tmp pour leurs fichiers temporaire. Quand le fichier temporaire fait 4Gio (par exemple pour créer une image iso et la graver sans demander à l'utilisateur d'effectuer les deux étapes séparément.
Le problème dont tu parle devrais, je pense, pouvoir se faire sur disque avec un système de fichier en espace utilisateur (avec FUSE).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par Juke (site web personnel) . Évalué à 2.
Le vendredi 04 novembre 2011 à 17:11 +0100, Barret Michel a écrit :
> Quand le fichier temporaire fait 4Gio
Où est le probleme puisqu'une fois la ram utilisée, il le mettra sur le disque dans la partition de ton choix ?
[^] # Re: /lib64
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
J'ai eu du mal à comprendre, donc pour ceux qui seraient dans mon cas : swap.
[^] # Re: /lib64
Posté par BB . Évalué à 3.
C’est quand même un peu couillon de faire un tmpfs pour au final le retrouver dans le swap. Au final il aurait été plus simple de laisser le système gérer le cache disque (dont un /tmp en dur) tout seul comme un grand…
[^] # Re: /lib64
Posté par Octabrain . Évalué à 1.
Parce que le swap n'est de toute façon pas aussi grand que l'est la partition de /tmp ?
Sérieusement, sur un desktop avec 4Go de ram, je vois pas l'intérêt du swap. D'ailleurs je l'ai viré de mes ordis, si ya plus de ram, ya plus de ram. Je vais pas attendre 3 minutes devant un écran complètement freezé que le kernel foute tout en swap, et tant pis pour le programme trop gourmand, il aurait été inutilisable de toute façon.
[^] # Re: /lib64
Posté par barmic . Évalué à 6.
D'une part c'est pas le problème soulevé.
D'autre part si un jour tu te met à faire de l'hibernation avec tes machines, tu remettra des partitions de swap, je pense.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par Octabrain . Évalué à -6.
Hibernation je m'en fous, et encore plus avec un système de fichiers crypté, j'ai du mal à voir comment ça serait possible.
[^] # Re: /lib64
Posté par Sufflope (site web personnel) . Évalué à 9.
Et pourtant ça marche : l'initrd se charge de restaurer le système hiberné après que tu as fourni ce qu'il faut pour déchiffrer le disque (et donc l'état hiberné). Tu devrais essayer un peu les distribs post 2006 :-D
[^] # Re: /lib64
Posté par barmic . Évalué à 5.
He ben tant mieux pour toi mais ne nous dis pas que :
Parce que oui il y en a toujours des cas d'utilisation (et oui tu n'es pas le seul utilisateur au monde).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par briaeros007 . Évalué à 2.
enfin même avec un desktop. Tu as une appli qui commence à faire n'importe quoi et phagocyte la ram, tu es "content" d'avoir du swap
-> 1°) pour éviter de planter la machine et permettant d'avoir une solution de repli
-> 2°) détecter le problème avec le ralentissement de la machine (bon ok c'est pas normalement le but escompté).
Perso j'ai 8Go de ram, et j'utilise principalement mon pc en desktop, ben j'ai une partoch de swap (et des fois j'ai même rajouter temporairement un fichier de swap).
Par contre la règle de deux fois la ram pour la swap...
[^] # Re: /lib64
Posté par barmic . Évalué à 3.
Personnellement je met la même taille plus 100 Mio pour faire de l'hibernation. 2 à 8 Gio c'est quoi sur des disques qui font facilement plus de 500 Gio.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par Sufflope (site web personnel) . Évalué à 3.
Pareil sur portable.
Ça par contre c'est un peu moins pertinent avec la déflation d'espace avec les SSD.
[^] # Re: /lib64
Posté par barmic . Évalué à 3.
Pas encore essayer ces choses là. Mais en effet les ssd sont petits et leur taille diminue avec le temps.
Je pense que le plus important avec ce genre de matos c'est de limiter les écritures (pas de atime, limiter les log, jouer sur les quota ou l'espace disque réservé à root pour ne pas sur charger le disque, FS non-journalisé mais transactionnel, …).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par Sufflope (site web personnel) . Évalué à 2.
Bah toi qui fais du Java / RoR / ché plus quoi, tu devrais. Sur mon portable pro j'ai gagné presque 50% de temps de compilation sur mon projet Grails / Spring / ant :-D
Sinon ce que je voulais dire c'était pas trop une question de longévité (pas constaté de souci, en même temps c'est un SSD Intel, pas une merde noname), mais juste que quand t'as un disque de ~100Go (une taille raisonnable pour un SSD), d'un coup tu la sens plus, la partoche de 10Go de swap, que sur un HDD de XTo.
[^] # Re: /lib64
Posté par barmic . Évalué à 2.
Tu as tout a fait raison. Mon seul frein c'est le prix. Ils commencent a devenir abordable mais pas assez pour que j'en achète un sans en avoir un vrai besoin.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par wismerhill . Évalué à 2.
D'un autre côté, avec les inondations de la semaine dernière, le prix des disques dur va monter, donc les SSD auront l'air comparativement plus abordables.
[^] # Re: /lib64
Posté par Octabrain . Évalué à 1.
Si la machine se met à swapper, c'est souvent parce qu'une appli se met à démesurément consommer de la ram, parce que je ne suis pas proche de la limite en temps normal.
Et le temps que le kernel le fasse, l'écran est proche du gel complet, et la seule chose que je cherche à faire à ce moment là, c'est un xkill de l'appli qui bouffe tout. Si je ne met pas de swap, c'est le kernel qui s'en charge pour moi, je gagne du temps.
Quand tout le système va a la vitesse de firefox réécrit en java et sur un 486, tu t'en fous un peu, tu penses plutôt "stopper ça" le plus vite possible.
[^] # Re: /lib64
Posté par barmic . Évalué à 3.
Soit tu as défini une taille de tmpfs inférieur et le programme renvoie une erreur (ou se vautre c'est selon), soit il n'a pas ce genre de problème et c'est la mémoire que les programme peuvent utiliser qui va manquer à ce moment là tu swap et ça fait mal aux performance de la machine (et de son utilisabilité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /lib64
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
Avec pam_mount, j'ai bien un ~/tmp en tmpfs par utilisateur. Pour le /tmp, j'ai arrêté le ramdisk, c'est trop petit :)
[^] # Re: /lib64
Posté par jeberger (site web personnel) . Évalué à 3.
AMA, la bonne solution c'est d'avoir des « vrais » (i.e. pas de tmpfs) /tmp et /var/tmp (éventuellement fusionnés et symlinkés) et d'utiliser tmpwatch [1] dans une tâche cron quotidienne pour assurer le nettoyage. Comme ça:
[1] http://fedorahosted.org/tmpwatch/
[^] # Re: /lib64
Posté par gik . Évalué à -1.
Il ne faudrait pas induire les gens en erreur. Il n'y a pas de /tmp en tmpfs par défaut sous ArchLinux. Vous avez dû suivre le wiki à propos du SSD.
https://wiki.archlinux.org/index.php/Maximizing_Performance#Mounting_.2Ftmp_to_RAM
[^] # Re: /lib64
Posté par O'neam Anne . Évalué à 2.
Tu m'a fait douter, je suis allé vérifier ici :
http://www.archlinux.org/packages/core/any/filesystem/
Il me semble que cela confirme qu'il y a bien un tmpfs par défaut. Le wiki n'est pas à jour, ce qui peut arriver.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: /lib64
Posté par Effraie (site web personnel) . Évalué à 1.
si si, sur les installations récentes. j'en ai fait l'expérience récement en voulant compiler un gros truc sur une installation fraiche sur un netbook (avec "seulement" 1 giga de ram)
\Ö<
[^] # Re: /lib64
Posté par boq . Évalué à 2.
Ça date de cet été. Zieute ton
/etc/fstab.pacnew[^] # Re: /lib64
Posté par Moulator . Évalué à 1.
Pour la durée de vie des fichiers dans /tmp sous Debian, c'est réglable (voir TMPTIME dans /etc/default/rcS).
Reynald
# FHS for human beings
Posté par internet . Évalué à 0.
Attention, je vais troller :
Et pourquoi on ne reprendrait pas tout à zéro, avec des noms lisibles par des êtres humains?
/usr, /tmp, /home, /mnt, /etc, /dev, /sys, /proc, /var ça voulait sûrement dire quelque chose à une époque.
/Devices à la place de /dev
/configuration à la place d' /etc
/Logs pour les journaux systèmes
/Applications pour TOUTES les applications
/Libraries pour TOUTES les bibliothèques
/Users pour les répertoires utilisateurs
/Shared à la place de /srv
etc, etc..
Ah bah oui, c'est fortement inspiré de Mac OS, mais faut avouer qu'ils avaient mis le doigt sur un truc.
[^] # Re: FHS for human beings
Posté par Grunt . Évalué à 10.
Ce n'est toujours pas lisible pour les êtres humains non anglophones. Je propose que les distributions s'adaptent à chaque langue, c'est encore mieux.
Ah, le bonheur d'aller farfouiller dans /Périphériques pour dépanner un système en vrac, ça n'a pas de prix :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: FHS for human beings
Posté par internet . Évalué à 2.
UTF-8 pour tous et auto-complétion!
Il faudrait que ce soit le shell qui s'occupe de l'internationalisation dans ce cas.
En locale US, on ferait cd /Devices
En locale FR, on ferait cd /Périphériques ou cd /Devices, ça reviendrait au même, d'ailleurs je crois que sous Win 7 ça marche comme ça, on peut taper C:\Utilisateurs ou C:\Users.
[^] # Re: FHS for human beings
Posté par Grunt . Évalué à 10.
Merde, j'ai été pris au sérieux :(
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: FHS for human beings
Posté par internet . Évalué à 10.
Merde, j'ai été pris au sérieux :(
[^] # Re: FHS for human beings
Posté par lolop (site web personnel) . Évalué à 9.
C'est pas beau, faut que ça soit lisible par quelqu'un qui n'y connais rien, avec un système moderne rien ne vaut des noms qui décrivent bien ce qu'il y a derrière:
En ligne de commande, même avec la complétion, ça va être un plaisir. Et pour les scripts...
Pfff. N'ont que ça a faire chez Fedora ?
L'utilisateur simple reste principalement dans son /home/moncompte. Et ensuite, c'est le PATH qui indique où on cherche les binaires, donc que ça soit dans différents directory, ça n'a pas d'impact - le PATH a même l'avantage qu'on peut en ajouter certains si l'on veut.
Feraient mieux de pousser/patcher et remonter en amont pour que les logiciels adoptent les normalisations XDG de stockage des préférences.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: FHS for human beings
Posté par internet . Évalué à 1.
Il ne s'agit pas forcément de rendre l'arborescence Linux accessible à tout le monde, mais de faciliter l'apprentissage pour ceux qui veulent mettre les mains dans le cambouis, ou les développeurs qui veulent savoir où mettre leurs fichiers. Ça incitera d'ailleurs ces dernier à continuer de développer pour Linux.
Une certaine interprétation du KISS.
[^] # Re: FHS for human beings
Posté par Guillaume Knispel . Évalué à 5.
T'as du fumer des trucs chelou. Si tu veux mettre les moins dans le cambouis tu peux aller acheter quelques livres chez ton libraire préféré, qui t'expliqueront très bien à quoi sert /usr and co. C'est quoi la prochaine étape sinon, recoder tous les programmes de l'univers en visual basic pcq c'est plus simple à lire que du C++, et croire qu'un type lambda sans formation va magiquement savoir coder après avoir lu 3 lignes de VB sans aucune autre documentation ?
[^] # Re: FHS for human beings
Posté par internet . Évalué à 1.
[sarcasme]
Rassure-toi, mon matos est de qualité.
[/sarcasme]
Revoir la FHS des distribs Linux n'est pas crucial puisqu'effectivement tout est documenté. Mais c'est tout de même devenu un certain bordel avec les années, alors si on peut simplifier les choses autant le faire. Moins le processus d'apprentissage est long, plus nombreux sont les gens à maîtriser l'outil.
Quand je parle de mettre les mains dans le cambouis, je ne parle pas de recoder les programmes. Je pense plus aux développeurs qui viennent d'autres OS et qui veulent comprendre assez vite comment packager leurs applis pour Linux, puisqu'ils ont déjà plusieurs plateformes à supporter.
[^] # Re: FHS for human beings
Posté par lolop (site web personnel) . Évalué à 6.
Perso je pense que les personnes qui se mettent a développer leurs softs sont capables de lire et comprendre le FHS, je ne crois pas que ça soit ça qui freine le fait de développer sous Linux.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: FHS for human beings
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Pas de souci, il suffit de mettre dans un fichier .directory la traduction en 42 langues du nom du dossier et de modifier les appels systèmes pour aller lire le nom dans ce fichier !
A oui mais c'est risqué de faire ça au un aussi bas niveau. Faisons le que pour les outils graphiques alors et pour les dinos qui utilisent la ligne de commande, à eux de connaître le vrai nom.
-> []
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: FHS for human beings
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Les attributs étendus ont été inventé, c'est fait pour servir !
[^] # Re: FHS for human beings
Posté par coid . Évalué à -1.
Tu oublies l’essentiel.
Comment un linuxien pourra frimer face aux noobs si tout le monde peut comprendre ? Un système utilisable sans prendre la peine de lire des tonnes de pages de manuel, c’est vraiment trop nul. Ça fait user-friendly kikoolol. Les trucs intelligibles, c’est pour les neuneus.
En plus, ça voudrait dire que même Microsoft avait de l’avance (un peu). Impensable. Blasphématoire.
[^] # Re: FHS for human beings
Posté par internet . Évalué à 4.
Et bien dans ce cas, forkons!
MultideskOS 2, Linux for Mesdames Michus!
[^] # Re: FHS for human beings
Posté par Patrick Lamaizière (site web personnel) . Évalué à 5.
Je suggère un C:\ avec tout dedans.
les pixels au peuple !
[^] # Re: FHS for human beings
Posté par Martin Peres (site web personnel) . Évalué à 3.
C'est exactement ce que fait GoboLinux: http://www.gobolinux.org/
[^] # Re: FHS for human beings
Posté par weonbin . Évalué à 1.
Ca ouvre des perspectives intéressantes je trouve
[^] # Re: FHS for human beings
Posté par Grunt . Évalué à 2.
Un meilleur fonctionnement, peut-être. :°
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: FHS for human beings
Posté par Sevechjo . Évalué à 1.
Ce qui paraît séduisant chez Gobolinux, c'est la possibilité d'installer et de désinstaller proprement et simplement (et sans base de donnée) plusieurs versions d'un même programme ou d'une même librairie.
De même que le système des recettes, qui installe directement une application à partir des sources du site web d'origine, sans modification, ni passage par l'intermédiaire d'un dépôt. Théoriquement, vu qu'on peut refaire ses propre recette en quelques lignes. Il y a moyen de suivre les derniers mise à jour presqu'en temps réel.
En théorie. En pratique ça rend le système compliqué à utiliser pour un débutant. J'imagine que ça doit rappeler la Slackware à ses débuts :-)
# Win32
Posté par Obsidian . Évalué à 10.
Peut-être bientôt :
mv /usr /system32[^] # Re: Win32
Posté par goupixg6 . Évalué à 3.
toudoup bruit de la fenetre "admin" de vista
[^] # Re: Win32
Posté par Tonton Benoit . Évalué à 2.
En fait system32 c'est plutôt un genre de /etc/lib oO
[^] # Re: Win32
Posté par Guillaume Knispel . Évalué à 3.
Avec tous les binaires 64-bits dedans. Les 32-bits iront dans /LoL64 (en plus il rox ce nom) avec :
quelque part dans Linux.
Et un dev chargé de maintenir ça expliquera dans des blogs post a quel point cette idée est brillante et à quel point on aime nos utilisateur et on se soucis de la retrocompatibilité.
[^] # Re: Win32
Posté par nud . Évalué à 3.
Sauvez des compilos, utilisez sizeof().
[^] # Re: Win32
Posté par Batchyx . Évalué à 4.
Utilisez sizeof() - 1, tu veux dire.
[^] # Re: Win32
Posté par Obsidian . Évalué à 2.
Contrairement à une idée répandue (et compréhensible), « sizeof » ne prend pas de parenthèse en C. On n'est obligé de les mettre que lorsque c'est la taille d'un type que l'on mesure (même syntaxe qu'un cast, donc).
# Logique ?
Posté par Tonton Benoit . Évalué à 3.
Pourquoi /usr/bin dans ce cas ? Si y'a plus de séparations entre les programmes la raison d’être d'/usr disparaît, alors pourquoi le garder ?
Évoluer d'accord, mais les choses ont étés créées avec une certaine logique et il faut conserver une logique, pas forcement celle du dépars. Si tu te contente de patcher à la gruïk sans te soucier la cohérence de l'ensemble « à partir d'aujourd’hui on balance tout dans /usr/bin », j’imagine dans 25 ans :
Encore quelques idées du genre et ça va être sympas à étudier la FHS...
[^] # Re: Logique ?
Posté par Misc (site web personnel) . Évalué à 4.
L'idée est de pouvoir mettre /usr sur une partition séparé pour pouvoir faire des snapshots btfs, pour monter ça en readonly, etc. Chose un chouia moins facile à faire avec /. C'est expliqué dans le thread donné en lien.
# Poettering
Posté par Altor . Évalué à 10.
Bref, pour résumer, on a un type qui pense pouvoir révolutionner le démarrage des distributions linux, qui casse complètement toutes les compatibilités posix et qui se rend compte que si /usr est monté à part, plus rien ne marche. Du coup au lieu de dire que son système est mal fichu dès le départ, il veut rompre avec plus de 40 ans d'organisation parce qu'il pense que ce sera mieux. Belle mentalité.
Une fois qu'il se rendra compte que l'organisation des fichiers proposés ne convient pas aux cas x ou y, il fera changer udev, puis X, puis bash et là, plus rien ne marchera.
Je ne dis pas qu'il ne faut pas de changement, juste qu'il faut normaliser au maximum et que oui, ça prend du temps. Si on regarde xmpp, il a mis énormément de temps à être normalisé, mais maintenant tout le monde l'utilise.
Honnêtement, l'utilisateur lambda n'en a rien à faire de l’arborescence et de la différence entre /bin, /usr/bin … L'admin système lui a appris avec cette arborescence et n'a pas besoin de se compliquer la vie, refaire ses scripts… Surtout s'il utilise plusieurs systèmes Unix. Le débutant admin apprendra comme tout le monde. Ce n'est quand même pas très compliqué. Les développeurs/mainteneur de paquets n'auront pas à maintenir plusieurs arborescences avec toutes les erreurs possibles.
[^] # Re: Poettering
Posté par claudex . Évalué à 2.
Encore une fois, ce n'est pas systemd qui a du mal avec /usr mais udev.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Poettering
Posté par Altor . Évalué à 7.
Oui, mais ça marchait bien avec l'ancien système d'init non ?
De toute façon, ça rejoint quand même mon propos, puisque udev a remplacé hald alors qu'il était lui-même "révolutionnaire" et il (udev) est linux-only.
[^] # Re: Poettering
Posté par claudex . Évalué à 2.
Je ne suis pas sûr mais si j'ai bien compris, ça marche mais pas tout le temps (ou ça marche mais il y a des comportements étrange après). Du coup, comme ils ne veulent pas d'un truc bancale, ils ne le prenne pas en charge.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Poettering
Posté par nud . Évalué à 1.
udev n'a pas vraiment remplacé hald... c'est un peu comme si tu disais que alsa a remplacé arts. Il n'y a pas remplacement, il y a juste "cette couche intermédiaire ne sert à rien".
udev a plutôt remplacé devfs et hotplug, et le problème est identique avec sysvinit.
[^] # Re: Poettering
Posté par Étienne . Évalué à 3.
Pas mieux qu'avec systemd.
Étienne
[^] # Re: Poettering
Posté par GeneralZod . Évalué à 7.
Tu résumes mal. Primo, Posix n'a jamais normalisé le démarrage ni le la hiérachie du système de fichiers. Secundo, pour le démarrage, même au sein des init SysV, la portabilité est quasi-inexistante en dehors des systèmes LSB (et la plupart des distros y compris Debian fournissent des scripts non-LSB). Ça fait des années qu'il y a un consensus au sein des distros GNU/Linux pour passer à autre chose, pendant un moment, c'était Upstart, mais il était de fait abandonné par son mainteneur et n'a pas su créer une communauté autour de lui quand systemd a été lancé.
Pour avoir écrit des scripts d'init pour plusieurs distros, je préfère largement les unités systemd bien carrés au bordel actuel à base de scripts shells et de routines spécifiques à chaque distro.
Tertio, le FHS c'est une initiative faite par les distros GNU/Linux pour normaliser la hiérarchie, sauf qu'elle n'est pas parfaite et qu'aucun membre ne l'a respecte. Lennart a permis de ressusciter le groupe de travail en lançant des discussions pertinentes, les discussions pour le FHS 3.0 sont ouvertes à tous, et les choix finaux seront votés.
Faut arrêter la paranoïa anti-Lennart, c'est une grande gueule avec des opinions très tranchées (notamment sur *BSD° certes, mais c'est un type super compétent et avec qui on peut bosser. Si vous voulez parler à des murs, essayez de bosser avec les mainteneurs d'Unity ou de XBMC sur une autre plateforme que celle de référence.
[^] # Re: Poettering
Posté par Altor . Évalué à 4.
C'est vrai qu'au moins il essaye de faire changer les choses. La seule chose que je reproche, c'est que ça n'a pas l'air structuré et que l'on change de solution tous les quatre matin.
[^] # Re: Poettering
Posté par Batchyx . Évalué à 10.
C'est surtout que les lennarteries sont toujours des solutions globales qui impose des changements à toutes les applications de telle sorte que les dites applications finissent toujours par dépendre de cette solution. Et si tu veux faire la même chose avec une alternative, tu fini toujours par crever.
Alors qu'avant on avait pas de problèmes pour faire tout ce qu'on voulait avec des logiciels indépendants et des protocoles un peu indépendants.
[^] # Re: Poettering
Posté par Obsidian . Évalué à 3.
Un peu comme Steve Jobs, quoi…
[^] # Re: Poettering le Uwe Boll du monde Unix
Posté par Gabin . Évalué à -3.
Ce n'est pas tant qu'il bouge son "cul", il y a RedHat derrière et cela lui donne un poids certains.
Moi ça me dérange que l'avenir de Linux soit dirigé par cette boîte multimilliardaire et part le Uwe Boll du monde Unix.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.