Ho que voici un joli bug du logiciel Bumblebee. Ça mérite une nomination pour le bug de l'année !
Petit message ému à tous nos chers développeurs : un bug, ça arrive, c'est pas grave. Le pauvre utilisateur que je suis vous remercie en tout cas de les corriger !
# quand même
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 10.
parfois quand même un peu (/usr c'est quand même /usr)
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: quand même
Posté par Grunt . Évalué à 8.
Si c'est bien rattrapé, tu perds pas de données uniques (i.e. non retrouvables sur les interwebs avec de l'huile de coude).
À part d'éventuels /usr/local/*
Je préfère perdre /usr que /home ;)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: quand même
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
/usr/home par défaut sous FreeBSD
[^] # Re: quand même
Posté par Damien Thébault . Évalué à 4.
Historiquement /lib et /bin contenaient les binaires indispensables au boot du système, et /usr/ était ensuite monté (contenant /usr/lib et /usr/bin) pour les logiciels. (disquettes ou autres).
D'ailleurs, dans Hurd il a ensuite été proposé d'utiliser unionfs à la place du système obsolète de /usr/, et donc de supprimer /usr/ (pour des raisons de compatibilité, /usr/ serait un lien symbolique vers /).
Donc la question c'est, pourquoi avoir /usr/home, puisqu'il suffit de monter dans /home à la place et on peut le faire assez tard (et on peut le faire avant que /usr/ soit monté).
À moins que ça ne soit pas un point de montage, mais directement un dossier. Donc un / tout petit, un gros /usr avec les logiciels ET les données utilisateurs. (Bizarre quand même, quand tout le monde, y compris les utilisateurs les plus débutants, ont une partition pour leur OS et une autre partition pour leurs données).
[^] # Re: quand même
Posté par Anonyme . Évalué à -1.
J'ai jamais compris la hiérarchie sous les UNIX :)
Par exemple, pourquoi le
$HOMEde root n'est pas dans/home? Pourquoi/homequand il y a/usr(je trouve/usr/homelogique) ? Pourquoi les scripts de démarrage vont dans/etcet pas dans (je vais dire une connerie, mais c'est juste un exemple)/boot?Y a plein d'incohérences dans ce genre dans la hiérarchie.
[^] # Re: quand même
Posté par redo_fr . Évalué à 10.
parce que dans les entreprises, souvent (autrefois? Encore aujourd'hui?) le $HOME n'était qu'un point de montage NFS (NIS/"Yellow page") et que 'root' peut avoir besoin d’accéder à son $HOME sans le réseau? :)
Parce que /usr et /home "peuvent" être des partitions séparées (et qu'un montage dans un montage peut poser problème)
Parce que /boot n'existe pas dans une architecture "standard" SYSTEM V ?
Ou bien parce que certains scripts de démarrage doivent être dans '/' (donc dans /etc) et que /boot n'est pas forcément monté sur un système (c'est déconseillé pour des raisons de sécurité :)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: quand même
Posté par Zenitram (site web personnel) . Évalué à 3.
et si le problème est que tu n'arrive pas à monter /home? Si /home est innaccessilbe (disque de données HS)?
de ce que je comprend, /usr sert à stocker des données "récupérables" non uniques à ta personne (programmes, libs...)
Si j'ai un problème avec la machine, /usr part à la poubelle.
/boot, c'est pas pour booter? /etc c'est pas de la configuration après le boot?
Ca me parait au contraire pas idiot... Le nommage n'est pas du tout sexy (surtout "etc"!), mais la logique se tient (à peu près)
[^] # Re: quand même
Posté par shbrol . Évalué à 6.
D'un autre coté, je préfère largement un nom court comme "etc" plutôt qu'un truc à rallonge avec des espaces dedans comme on voit souvent chez les voisins d'en face, qui auraient appelé ca "Editable Text Configuration"...
[^] # Re: quand même
Posté par BFG . Évalué à 1.
"/conf" aurait tout de même été plus lisible.
[^] # Re: quand même
Posté par shbrol . Évalué à 5.
Voui, mais il semble qu'a l'origine des temps, il n'y avait pas la dedans que des fichiers de configuration, mais aussi tout ce qu'on n'avait pas pu caser ailleurs, avec des scripts (rc), des donnees administratives (passwd), et cetera.
Pour rester lisible, logique et court, "/mess" aurait été pas mal, mais bon...
[^] # Re: quand même
Posté par CrEv (site web personnel) . Évalué à 4.
dans ce cas un
/miscalors[^] # Re: quand même
Posté par redo_fr . Évalué à 1.
il faut voir aussi qu'à l'origine, la mémoire et le disque étaient très limités et donc, un caractère économisé c'était mieux (d'où les trigrammes des répertoires: /bin /usr /tmp /var /etc et les digrammes des binaires: ls, cp, dd, rm, ...)
/mess, /misc <-- 4 caractères ( vilain gourmand en octets ! :D )
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: quand même
Posté par CrEv (site web personnel) . Évalué à 2.
/boot
/home
/proc
/root
(pour ne pas citer /media, /initrd, /lib64 arrivés plus tard, ni /lost+found)
[^] # Re: quand même
Posté par redo_fr . Évalué à 2.
Je parlais de l'origine :)
Dans les années '70, tous ces répertoires n'existaient pas, c'est Linux qui les a amené parce que dans les années '90, on avait déjà plus de mémoire et de disque dur, donc on pouvait "se permettre".
lost+found est effectivement une exception.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: quand même
Posté par DLFP est mort . Évalué à 2.
Et pire que tout, on a maintenant /media !
Je me demande si je peux le supprimer vu que je n'utilise que /mnt et que ça me fait perdre du temps niveau autocomplétion.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: quand même
Posté par Grunt . Évalué à 3.
J'ai cru lire une fois que le nombre de caractères limités, sur les commandes et les dossiers standards sous Unix, c'était pour s'adapter à des terminaux qui n'affichaient pas en retour la commande tapé, afin d'éviter les erreurs de frappe.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: quand même
Posté par ymorin . Évalué à 10.
Non, non. La vraie raison, c'est que les gros geeks barbus aux cheveux longs étaient des grosses faignasses. Moins y'avait de touches à taper, mieux ils se portaient...
Donc, tant que le mot restait reconnaissable (eg. usr -> user, etc -> editable text files, bin -> binaries, lib -> libraries...), pas de soucis, on raccourcissait.
Et pour tous ces répertoires/fichiers souvent modifiés (à l'époque, pas de DHCP, de DNS tel qu'on le connait, pas d'auto-completion...), c'était plus rapide à taper. Et les modifier était réservé à ces gros geeks bouffeurs de pizzas, et souvent ils en étaient les seuls utilisateurs. Alors, faire un truc compréhensible par le commun des mortels, pensez-vous...
Il y avait aussi la propension toute naturelle chez les mêmes geeks poilus d'utiliser un langage à eux, leur jargon. Et dans ce jargon, les voyelles étaient souvent éludées. Pas toujours, juste souvent. Il fallait quand même que le mot reste reconnaissable...
Et surtout, les terminaux était petits, donc plus les noms étaient courts, plus les listings étaient compacts, plus on pouvait en mettre à l'écran. D'où le nom de ls : list short.
Hop,
Moi, barbu aux cheveux longs, bouffeur de pizzas. Mais pas gros ni trop poilu ! ;-)
Oh, et en parlant de jargon.
[^] # Re: quand même
Posté par Grunt . Évalué à 1.
k, 1 gt it. fukin l4m3rs frm the past.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: quand même
Posté par beagf (site web personnel) . Évalué à 10.
Ce n'est pas des incohérence, c'est de l'histoire et de la logique.
À une époque l'espace coûtait cher et les données étaient stockées sur différent type de supports. Sur un disque local et relativement rapide d'accès (pour l'époque) mais tout petit car cher, on stockait le minimum pour faire démarrer le système et faire un peu de maintenance.
Donc sur cet espace il fallait les binaires et librairie de base et le home de root pour qu'il puisse ce loger pour la maintenance en cas de problèmes.
Une fois que ce système minimum était chargé, on pouvait monter dans /usr le reste du système stocké en local aussi mais un support moins cher, plus lent mais avec plus d'espace comme un lecteur de bandes magnétiques.
C'est dommage que ce soit plus lent mais c'était le prix à payer pour avoir l'espace pour stocker un système complet.
Les utilisateurs on aussi leur données de stockées sur un support différents: sur un serveur de données qui est connecté à tous les autres et qui permet à chaque utilisateurs d'avoir ces données n'importe où. (les début du cloud en fait... mais sur bandes magnétiques...)
Donc on monte ça sur /home et le root n'est pas dedans car lorsqu'on ce connecte en root ce serveur n'est pas forcément déjà accessible.
Et dernière question : pourquoi ne pas monter /home dans /usr/home ? Tout simplement parce que sur un même serveur tu peux vouloir démonter le /usr pour en monter un autre. Les bandes magnétiques sont pas forcément suffisament grosses pour stocker tous les programmes nécessaire aux différents utilisateurs, et plus une bande est longue plus le temps d'accès moyen est long.
Tu peux avoir un /usr pour les mathématiciens et un pour les physiciens et une fois de temps en temps tu changes. Si le /home est monté ailleurs c'est plus simple.
Donc, d'un point de vue historique c'est parfaitement logique.
[^] # Re: quand même
Posté par netsurfeur . Évalué à 5.
L'historique est exact dans les grandes lignes, le premier Unix que j'ai utilisé en 1983 (HPUX) s'installait sur des disques de 5 ou 10 Mo (ce ne pas une faute de frappe). Il faut dire que le système complet tenait sur 20 Mo.
Par contre, je suis surpris par ta description de systèmes de fichiers sur bandes magnétiques.
Les seuls que j'ai connus étaient des «recovery tapes» (l'équivalent du «live CD» avant que les CD existent). On ne les utilisait qu'en dernière extrémité (disque non bootable) car les temps d'accès étaient extrêmement longs.
Utiliser une bande magnétique pour une des partitions du système était inimaginable. Même si les temps d'accès avaient été supportables, les bandes ne fonctionnent correctement qu'en accès séquentiel. Les accès aléatoires résultant de l'organisation du système de fichiers provoquent des avances rapides et rembobinages incessants qui usent très vite les mécaniques et les bandes.
[^] # Re: quand même
Posté par beagf (site web personnel) . Évalué à 4.
J'avoue avoir simplifié un peu par flemme et pour rendre le contraste un peu plus fort pour bien faire comprendre l'idée.
Le système que j'avais en tête date à peu près de ton époque si je ne me trompe pas: fin 70 ou début 80. Je ne l'ai pas utilisé moi même car à cette époque mes doigts étais trop petits pour le clavier ;-) mais j'en ai beaucoup discuter avec un de ces grincheux qui regrettais la belle époque...
Les calculateurs n'était pas très riches en disque-durs et donc seul la base du système étais installée en permanence. Une fois que la base avait bootée elle chargeait depuis des bandes magnétique le reste du système sur un autre disque qui était ensuite monté sur /usr.
Quand une équipe avait finis ses calculs, on pouvait mettre les bandes de l'équipe suivante qui venais remplacer l'autre sur le disque.
J'ai pas garder le souvenir exact de tous les détails, ce qui m'a le plus amuser c'est toutes les anecdote sur comment s'arranger pour que les changement soient retarder le plus possible pour profiter du maximum de temps de calcul avant de ce faire virer par « ces emmerdeurs de physiciens qui font des trucs inutiles à côté des magnifiques calculs de mathématiques fondamentales... ».
Une autre époque où l'on s'amusait différemment... mais quand je vois comment ça ce passe dans mon labo, je me dit qu'au final le résultat est toujours le même, quelle que soit la puissance de calcul disponible, on se bat toujours pour l'utiliser...
[^] # Re: quand même
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Pour être accessible même si
/homene l'est pas./homeest souvent un système de fichiers dédié,/rootjamais.Parce que ça n'a tout simplement rien à voir. Le nom
/usrest historique, mais son contenu, c'est des logiciels et leurs données et bibliothèques, pas des fichiers des utilisateurs.Parce qu'ils sont considérés comme des fichiers de configuration, et que de toute façon, il ne concernent pas le bootstrap qui ne se conçoit que comme de quoi charger le noyau. Typiquement par exemple,
/bootcontiendra un chargeur de démarrage fortement dépendant de la plate-forme.[^] # Re: quand même
Posté par FreeB5D . Évalué à 2.
Il y a au moins un intérêt, c'est que ça me permet d'avoir une partition /boot commune en multiboot Linux/Linux (je le fais avec Slackware/Arch).
[^] # Re: quand même
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Le coup du /usr/home (avec un lien /home), je pense que c'est un truc historique de l'installateur que personne n'a pris le temps de changer.
Par défaut pw crée les $HOME dans /home
static struct userconf config =
{
0, /* Default password for new users? (nologin) */
0, /* Reuse uids? */
0, /* Reuse gids? */
NULL, /* NIS version of the passwd file */
"/usr/share/skel", /* Where to obtain skeleton files */
NULL, /* Mail to send to new accounts */
"/var/log/userlog", /* Where to log changes */
"/home", /* Where to create home directory */
0777, /* Home directory perms, modified by umask *
Ceci dit c'est un OS pour lequel tu n'as pas franchement besoin de monter /usr
Tous les logiciels hors système de base étant dans /usr/local, c'est plutôt lui qu'il faut monter à part.
Du coup :
/
/usr/local/
/usr/home
/tmp
/var
Ça fait un partitionnement cohérent.
[^] # Re: quand même
Posté par patate . Évalué à 5.
Ça se discute, /home j'ai juste à détarer le backup de la veille, 10 minutes maxi, /usr faut tout réinstaller, plusieurs heures au minimum!
[^] # Re: quand même
Posté par BFG . Évalué à 4.
Pour les utilisateurs qui font des sauvegardes uniquement.
Pour l'utilisateur lambda qui ne fait pas de sauvegardes, la réinstallation de /usr se résume à mettre le CD de sa distribution, cliquer à répétition sur "suivant", car un utilisateur lambda se contente souvent de l'environnement complet GNOME ou KDE et les quelques logiciels non-intégrés viendront après.
[^] # Re: quand même
Posté par swilmet . Évalué à 4.
L'utilisateur lambda n'utilise pas Bumblebee.
# dans le même style
Posté par Troy McClure (site web personnel) . Évalué à 6.
Comment perdre betement son home:
http://article.gmane.org/gmane.comp.audio.jackit/24312
[^] # Re: dans le même style
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
/home, sweep /home.
# Licence
Posté par flagos . Évalué à 2.
Et en plus, c'est sous licence Beer-ware !
Si jamais vous aviez le /usr qui vous grattait, vous savez ce qu'il vous reste a faire..
# Et les tests ?
Posté par Thrillseeker . Évalué à 4.
Qu'un bug arrive, ce n'est pas grave, que ce bug soit commité ce n'est pas grave, qu'il soit releasé sans que personne ne s'en soit aperçu, cela arrive régulièrement. Sauf dans ce cas précis, on ne peut pas ne pas s'apercevoir de ce bug et cela signifie pour moi que personne n'a exécuté la ligne qui bug, donc personne n'a testé le script d'installation.
Du code qui est exécuté en root nécessite plus d'attention que le reste, surtout si il fait des rm. Le plus drôle n'est donc pas le bug en lui-même, mais qu'il soit arrivé dans une release sans problème et que des personnes ont réinstallé leur système à cause de cela.
Alors, certes, ce n'est pas évident à tester, les scripts sont différents pour Ubuntu, Fedora et Opensuse... es-ce le prix de la diversifié de linux ou juste la fainéantise des développeurs ? Je penche pour la fainéantise et l'excès de confiance en leur code.
[^] # Re: Et les tests ?
Posté par BFG . Évalué à 2.
Ces tests sur les paquets sont à faire sur un système/une machine (éventuellement machine virtuelle) dédiée. Il faut donc mettre en place cette infrastructure (et il faut des compétences particulières pour le faire !).
Comme c'est un projet libre et qu'on veut en général que toute autre personne puisse lancer les mêmes tests que les développeurs principaux, simplement à partir du dépôt de code, il faut donc documenter cette infrastructure et la rendre reproductible chez tout autre potentiel futur développeur.
Tout cela peut être particulièrement lourd et long à mettre en place.
C'est aussi une question de moyens, je ne sais pas combien il y a de développeurs, mais en plus le projet semble être divisé, et les efforts sont encore plus fragmentés.
[^] # Re: Et les tests ?
Posté par ckyl . Évalué à 4.
Regarde le commit qui a mené au truc. C'est vraiment une typo à la con. Effectivement il aurait fallu tester mais faire les tests pour toutes les plateformes c'est un enfer qui demande une grosse infra et énormément de de temps. En pratique c'est irréalisable pour la plupart des projets.
En général tu commit sur du code que tu vas exécuter donc tu as la plateforme sous la main pour vérifier mais dans ce type de commit y'a des grandes chances que tu corriges juste un truc rapporté par un utilisateur et que tu n'ai pas le moyen de tester les changements. La ça tombe vraiment au mauvais endroit mais celui qui n'a jamais commité une typo débile me jette la pierre. Fainéantises est donc un bien grand mot, je t'invite à valider un projet sur X versions de Y distribs pendant quelques mois et on en reparle.
[^] # Re: Et les tests ?
Posté par Thrillseeker . Évalué à 0.
_
A vrai dire, je ne faisais même pas référence à une infrastructure sophistiquée de tests. Seulement qu'il existe des testeurs qui possèdent la plateforme correspondante et qui teste le code avant la release (une release candidate quoi). De telle sorte qu'une personne qui télécharge la release ne se retrouve pas avec du code que personne n'a exécuté.
Dans le cadre de ce projet, il faut déjà un nvidia avec la technologie Optimus, et ensuite à première vu, il faut tester les trois distributions supportées (Ubuntu, Fedora et Opensuse). Donc trois testeurs maxi pour le script d'installation, mais là n'est pas le problème. Le problème c'est juste que c'est chiant car ce n'est pas le travail d'un développeur de s'occuper de tout cela.
A vrai dire, dans ce type de commit, dans un vrai projet, quand moi je rapporte un bug, le gars me demande de tester à partir du repository (master, voire dans une branche spéciale), et une fois que j'ai confirmé que ça marche cela passe en release (ou dans la branche master). Cela ne demande pas plus de ressource et ajoute une sécurité.
N'oublie pas que dans mon message j'ai également indiqué: es-ce le prix de la diversifié de linux , tu penches donc de ce coté là. Pour ma part, je suis un vrai fainéant et j'assume: je ne gère en général qu'une seule distribution.
[^] # Re: Et les tests ?
Posté par swilmet . Évalué à 4.
Ici c'est plutôt le script de désinstallation.
# Sécurité supplémentaire dans les gestionnaires de paquets?
Posté par Maclag . Évalué à 7.
Si je ne m'abuse (au moins pour les deb), un empaquetage sans vérification ne permettrait pas d'exécuter la commande, parce que /usr n'appartient pas au paquet bumblebee.
Me trompe-je?
Jamais regardé comment c'était fait en pratique d'ailleurs.
[^] # Re: Sécurité supplémentaire dans les gestionnaires de paquets?
Posté par 16aR . Évalué à 0.
Non, j'en doute, il n'y a pas un utilisateur créé pour chaque paquet installé.
Si tu fais de la merde dans ton script qui sera exécuté en root, tu fais de la merde dangereuse.
Je ne crois pas qu'il y'ai une politique debian spécifique a ce sujet. (créer obligatoirement un utilisateur pour un paquet spécifique, excepté les daemons peut être ?)
[^] # Re: Sécurité supplémentaire dans les gestionnaires de paquets?
Posté par Maclag . Évalué à 2.
Je crois que tu as manqué d'imagination!
Après vérification, Debian vérifie bien quel fichier appartient à quel paquet, grâce à une base de données des paquets et pas en créant un nouvel utilisateur à chaque fois (heureusement d'ailleurs, j'imagine pas le bordel dans /etc/passwd!!).
On trouve d'ailleurs de temps en temps un bug tel que "paquet refuse de s'installer parce que fichier machin appartient à autre paquet" ou dans le genre.
Je n'ai pas vérifié, mais je ne vois pas d'obstacle à l'implémentation de la même fonctionalité pour RPM. Donc elle y est peut-être déjà!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.