freem a écrit 5059 commentaires

Ah oui ok, rien a voir avec le boot donc.

Pour installer des paquets, que soit des pilotes ou des logiciels, il faut utiliser apt ou un frontal (je te conseilles aptitude d'ailleurs, plus simple d'usage selon moi).
Les pilotes graphiques avec Debian commencent par "xserver-xorg-video-", le reste dépend de ton matériel.

Mais je me demande si tu n'as pas juste pas de gestionnaire de login, genre xdm, lightdm, gdm… parce que, si je comprends bien, tu as juste un prompt "machine login: _"?

PS: il y a un bouton répondre en dessous des commentaires pour continuer le fil.

Sinon, sans compromis: il peut utiliser l'option -U, --database-root PATH de updatedb (ainsi que -d, --database DBPATH de locate, bien sûr) pour mettre la base de données dans son $HOME, ce qui à mon humble avis est nettement plus propre que de mettre un truc relatif à des données utilisateur dans une partition système.
Accessoirement, s'il mets ça dans ses fichiers utilisateurs, le mécanisme sera portable et plus performant:

• plus performant parce que pour un disque mécanique il y aura moins de déplacements des têtes de lecture;
• plus performant parce que j'ose imaginer que locate ne charge pas tous les fichiers quand ils sont segmentés (et, pour le coup, ça serait bien une segmentation par «zones», on peut espérer que locate n'ira pas chercher dans la db de /usr quand l'utilisateur cherche un fichier dans /home?);
• plus performant parce que l'on peut supposer que seul le $HOME nécessite une mise à jour sans événement scripté (genre un apt update ou apt install)
• plus portable parce que le $HOME sera un peu plus indépendant du système (donc, il pourra être trimbalé d'une machine à une autre avec moins de conséquences… en supposant que le locate de l'autre système supporte les mêmes options, bien sûr).

Si tu as un SSD tu peux te dispenser de locate et plutôt utiliser find.

C'est aussi vrai s'il crée souvent des fichiers: find n'a pas besoin de mettre à jour une base, même s'il est plus lent. Personnellement, je sais que je n'utilise jamais locate, pour cette raison. Après… je devrais peut-être, peut-être qu'il est plus simple de trouver un truc avec locate en excluant un dossier et ses enfants (je crains que je ne comprendrais jamais comment marche --prune… :/)

Ou alors, en partant de l'assertion que le ending ne change jamais, attendre le 1er "\r\n" XOR "\r[^\r]" XOR "[^\r]\n", retenir ce que c'est et ne compter que les occurrences de ce marqueur?

Hum… c'est moi, ou REST, c'est: t'envoies une requête, tu lis la réponse et rien n'est remémoré par le serveur (enfin, hors logs bien sûr)?

Salut.

Déjà:

Voila, desolé si c'est un peu confus

Ça fait plaisir de voir quelqu'un faire autre chose que «Ça marche pas, HELP!!».

1) suis je sur la bonne voie si je concentre ma recherche sur un probleme de kernel?

J'en doute: si le problème venait du noyau, tu aurais quelques messages relatifs au fait que le noyau à commencé à se charger. Sauf, bien sûr, si il y a un splash screen (j'ai toujours détesté ces trucs: c'est certes joli, mais tu ne sais jamais si tout est normal ou si y'a un truc qui merde, et je ne dis pas ça que pour le splash de démarrage de linux, hein, je hais tous les splash, ceux sous windows, ceux sous linux, ceux du boot… TOUS!). Mais à priori tu as tenté de le désactiver donc ce serait surprenant?
Grub n'affiche rien?

2)une install de mint 17 avec un kernel 3.16 puis un upgrade reste t elle une bonne option? (avec ou sans upgrade de noyau)

Je ne vois pas pourquoi ça ne marcherait pas. Au pire, en faisant l'upgrade, tu auras le choix entre l'ancien et le nouveau… si l'ancien à fonctionné.

3)debian ou Ubuntu pour debuter sachant que mon principal interet pour la version Ubuntu reste les themes plus facilement customisables, l acces aux PPA ainsi que la communauté plus large, meme si la debian semble plus stable.

Prendre la 1ère distro qui marche ne me semble pas idiot, en soit. À titre personnel, je m'installe toujours 2 distros sur mes disques maintenant: si jamais la distro de tous les jours merde (j'ai une config un peu moins automatisée que la moyenne, du coup j'ai un peu peur qu'un jour je fasse une bêtise qui flingue le système principal ;)), j'ai un fallback comme ça.
Du coup, tu pourrais peut-être faire pareil:

• tu te fais une partition pour le gestionnaire de boot (je crois que, de toute façon, avec GPT+Grub, il n'y a pas le choix, mais vu que j'utilise syslinux… autant préciser), mais pas pour la partition /boot: ce sont deux choses différentes (le /boot séparé ne sert pas à grand chose en pratique, et si tu mets tous tes kernels de tous tes systèmes sur la même partition, grub risque d'y perdre son latin…)
• tu te mets une partition whatever qui juste marche sur un bout (20G devraient suffire si c'est juste des outils de dépannage) de disque dur (si c'est un mécanique, vises plutôt la fin, ça ne change pas grand chose mais en théorie la fin du disque est moins rapide que le début),
• tu installes le système principal sur le reste,
• tu choisis au boot lequel tu veux démarrer.

Bon courage.

C'est beau le concept de securite sous Mac…

C'est pas le jour, mais tant pis:

if( false == need_security )
  goto insecure;
  goto insecure;

return true;

insecure:
return false;

hop moi.

Sans compter que l'affichage des messages va prendre du temps au CPU qu'il pourrait utiliser pour exécuter les tests unitaires ou la compilation.

Je ne pense pas être le seul ici à rediriger la sortie de compilation des trucs qui ne sont pas à moi vers /dev/null (pour les trucs à moi, c'est pas la peine, je compile en -Wall -Werror et -Weverything ou -Wextra selon le compilo, donc normalement mon code est warn-free (ok, ok, j'admets en désactiver quelques-uns explicitement, genre -Wc++98-compat et -Wc++98-compat-pedantic quand je compile avec std=c++11)) parce que le ressenti (le mien et celui de Xosview) est que la compilation est plus rapide? Et tant pis pour la sortie (je relance si ça rate, en -j1 et sans rediriger, comme ça je peux essayer de corriger un truc pas trop illisible)?

au-dessus de 50ms pour des ordinateurs modernes avec de la charge

J'imagine que ça dépend du réglage du kernel, parce que perso, même en pleine compilation bien brutale, je n'ai pas l'impression que mes terminaux lagguent? Ou alors je suis mou du bulbe, c'est pas impossible, mais ça serait contradictoire avec le ressenti prétendu des gens qui arrivent jamais à suivre ce que je fais sur mes écrans PC :)

quand je vois un pote taper Ctrl+n ou Ctrl+t en pleine session pour "ouvrir un autre shell" j'écrase une larme :|

Je ne vois pas pourquoi? Il faut bien appuyer sur des touches, pour avoir accès à un nouveau terminal (peu importe qu'il gère un shell ou autre) non?

provient de windows, pas de linux, si j'en crois une recherche rapide.

Compte tenu du fait que j'aie déjà vu ce message en absence de disque dur, je doute que windows soit à incriminer ici.

Pour diagnostiquer le problème, il serait pas mal de savoir quelques détails (un jour, il faudrait faire une FAQ pour debug les problèmes de boot…):

• la machine cible utilise-t-elle un BIOS ou un UEFI?
• quelle est la sortie de sudo fdisk /dev/sda (si, bien sûr, sda correspond bien au disque sur lequel la distribution est censée être installée, le plus simple et le plus sûr étant de débrancher physiquement tout disque non concerné par les manipulations) puis utiliser la commande "p" (pour print).

Dans le cas ou la machine utilise UEFI et que le «legacy boot» est désactivé, quelle partition est-elle utilisée pour EFI? Que dis fdisk à son sujet (touche "i")? Sinon, y-a-t-il une partition marquée bootable ("i" sur chacune successivement devrait faire le taf je pense)?

Si tu n'as pas accès à un système *nix sur la machine cible, tu peux faire ces opérations à partir d'un live CD, par exemple.

Pour certaines je n'ai pas honte, mais celle-la oui, comme précisé :)

C'est vrai, mais je pense que le problème n'est pas lié au mécanisme de surcharge des opérateurs en lui-même (les fonctions à la con derrière des noms débiles, ça existe aussi après tout), qui permets des choses plutôt sympa (concaténer des chaînes de caractères, additionner des vecteurs mathématiques, déréférencer un pointeur intelligent, par exemple) mais du fait qu'il n'est pas possible d'implémenter plusieurs opérateurs d'un coup, ou qu'il n'est pas possible à ma connaissance que le compilo génère le code des opérateurs si des méthodes pré-définies existent déjà (et n'allez pas me dire que ça casserait la compat', ils l'on fait pour std::begin, std::end, etc…).

l'unary -() ), c'est bien galère.

Tu n'as pas mentionné operator,() :)

si tu es amené à coder toi-même ton propre conteneur, c'est aussi peut-être que tu es en train de faire quelque chose de compliqué

Hum… il suffit d'avoir besoin de performances ou de fiabilité. Avec la STL, il n'existe aucun moyen simple de diagnostiquer l'usage mémoire, ce qui implique qu'on n'est jamais trop sûrs quand le conteneur va nécessiter une réallocation et donc pourrir les itérateurs ou tout simplement que l'on ne peut savoir combien de mémoire une collection consomme (amuses-toi à calculer la RAM bouffée par une map…).

Sinon, la STL n'implémente aucun conteneur pour gérer les chaînes de caractères: std::string se contente de gérer des chaînes d'octets supposément caractères ASCII, ou éventuellement des wchar.

Il n'y a aucun ring buffer non plus.

Les tableaux associatifs sont habituellement implémentés en tant que RBTree, consommateurs en mémoire (une chiée de pointeurs sur 8 octets, donc de très probables cache miss en cascade).

Pas moyen de gérer une destruction automatique de ressource qui ne soit pas de la RAM. Pas moyen de gérer la destruction de RAM allouée par une lib utilisant le modèle hourglass sans overhead (hourglass: passer par une API «simple» sans exceptions ni RTTI pour facilité la stabilité d'ABI, par exemple pour un mécanisme de plugins).

Mais bon, je suis d'accord, tant qu'on veut juste faire la fonctionnalité en prototype, la STL dispose de tout ce qu'il faut.

J'ai même l'impression que la philosophie de la POO se perd complètement quand on adopte des pratiques basées sur les templates.

Pour moi, les deux approches sont complémentaires. Tu cites les conteneurs standards, et justement ils montrent la complémentarité: sans eux, en C++, on serait obligé de soit réimplémenter les conteneurs pour chaque type, soit les implémenter une seule fois et que chaque noeud prenne un void* et un void_free( void* ). Outre le problème de la RAM, il y a le problème de la type safety donc.

Quand je code en C++, j'utilise des classes, de l'héritage, des templates, des fonctions… en fonction de ce dont j'ai (supposément) vraiment besoin.

de nombreux logiciels imposent l'utilisation d'un C++ allégé (sans templates, sans héritage multiple, sans pointeurs nus…)

Ils en interdisent rarement la totalité des exemples, mais un jeu (encore que, je n'ai jamais vu les pointeurs nus être interdits).

Perso, je sais que dans mes projets j'essaie d'éviter d'utiliser les exceptions par exemple: tout bêtement parce qu'il n'existe aucun moyen à ma connaissance de s'assurer qu'elles sont toutes gérées correctement (non, try{}catch(...){abort();} après 10 niveaux d'encapsulation ou rien n'est attrapé, ce n'est pas une façon correcte de le faire), et que donc ça reviens à un printf("j'ai glissé chef!\n");abort(); (voire pire, parce qu'on ne sait même pas dans quel fichier et à quel ligne les choses ont commencé à merder).
Mais pas de bol, le C++ malgré son "you pay for what you use" ne fournit aucun conteneur «semi-dynamique» (qui ne grossisse pas de façon implicite, histoire que l'on ait une chance d'éviter les crash parce que le kernel à attribué de la mémoire qu'il n'a pas réservée en réalité) ou exception-free, donc si je veux utiliser la STL, je l'ai dans l'os (sauf à ré-implémenter mes propres conteneurs, forcément, ce qui n'est pas nécessairement difficile mais pénible) sur ce point.
Du coup, bah je n'utilise pas les exceptions tout en sachant que mon code peut exploser parce que les outils dont je dépend eux en utilisent éventuellement (ça peut être une lib qui en utilise une alors que la doc n'a pas été mise à jour, par exemple).

les templates bien utilisés permettent d'éviter la duplication de code, et en améliorent la maintenabilité

J'invoque les 2 implémentations de la STL (seul outil dont je ne puisse me passer qui utilise réellement les template à fond) avec lesquels j'ai le plus travaillé en contre-exemple: libstdc++ et libcpp.

Tu serais vraiment très, très fort si tu arrivais à me convaincre que ces trucs sont maintenables grâce aux templates (avec mention spéciale pour la libstdc++ qui est vraiment, vraiment dégueulasse, un simple appel à size() fait passer par une chiée de fonctions dont l'indentation est un mélange d'espaces et de tabulations!).

Il me faut aussi mentionner le fait que les compilateurs que j'utilisent (g++ et clang) optimisent même en -O0 -g les templates, rendant ingérable le debug sans connaître les mécanismes internes (bien qu'il faille reconnaître ici qu'au moins libstdc++ fournit une solution de contournement pour gdb, si on a python3 disponible) ainsi que le fait que l'endroit qui génère une erreur de compilation est toujours noyé dans 2 pages de diagnostic (au moins, avec clang, on arrive à s'y retrouver grâce aux couleurs, mais ça reste sous-optimal) qui sont souvent tout sauf pertinents.

Alors, c'est vrai, tu as précisé «bien utilisés», mais du coup, aurais-tu des exemples de code, post C++11 (enfin, si t'en trouves du pré C++11 tu auras encore plus mon respect) qui n'ait pas ces problèmes d'utilisation?

Honnêtement, dans le fond, je suis relativement d'accord (j'ai quelques utilitaires templates qui sont bien utiles pour libérer automatiquement des ressources sans overhead (chose que la STL ne sait pas faire), mais sincèrement, selon moi pour qu'un template rende du code maintenable il ne faut pas abuser des fonctionnalités qu'ils offrent. Avec mention spéciale pour la récursion et donc les variadic. Je ne dis pas que ça n'a aucun intérêt, mais quand on on arrive à faire ça pour un switch, à part pour le fun, j'ai un sérieux doute.
Peut-être que le switch est plus lisible, mais si pour détecter un bug même trivial il faut passer 2 heures à éplucher des indirections…

*: au sujet des conteneurs pénibles:

• devoir implémenter operator== quand operator!= l'est (pour rappel: il y 10 opérateurs de comparaison au total, qui peuvent s'implémenter avec 2 seulement!), et le seul intérêt «réel» de les implémenter séparément que je vois, c'est pour obfusquer le code et le rendre plus buggué, peut-être pour un futur IOCPPCC?
• idem pour les divers opérateurs d'accès dans leurs formes const/non-const
• idem pour les itérateurs, bien que le jour ou je suis tombé sur un article mentionnant l'idée de passer un paramètre template booléen pour la constance à changé ma vie. Je ne m'emmerde jamais à utiliser et encore moins implémenter les reverse iterators, j'ai autre chose à faire qu'écrire du boilerplate après tout.

La motivation des développeurs n'est pas dans la recherche d'un binaire plus petit ou plus optimisé mais dans le fait d'utiliser le même compilateur sur toutes les plateformes.

Si ça avait juste été une question de qui à la plus grosse (enfin, la plus petite) je n'aurai pas posté ça.
Je pense que ce n'est pas juste de pouvoir utiliser le même compilo sur windows que sur les autres OS le gros point (sinon j'imagine qu'ils auraient juste utilisé GCC ou mingw en fonction de l'OS), mais vraiment d'utiliser Clang lui-même (et ses outils d'analyse et de debug) en gardant une ABI compatible (donc de pouvoir utiliser les libs C++ & co de MS, j'imagine qu'elles doivent avoir des avantages techniques, bien que je ne voies pas lesquels).

M'enfin, je reconnais que mon bookmark est mal tourné (en plus d'en avoir compris plus que prévu de travers… oups)

Voilà pourquoi je ne te comprenais pas.

Ce n'est pas a moi que tu répondais :)

Enlightenment ne m'intéresse pas plus que ça, je cherche plutôt à récupérer des morceaux pour les coller sur mon i3 :)

J'ai cru lire dans un des liens que tu comptes réécrire cet lib en C from scratch. Une raison en particulier? Performance? Portabilité?

LXDE est un DE minimal, tu as la liste des composants développés par le projet ici.

Si par dock tu entends un truc flashy avec pleins d'effets graphiques, c'est pas trop la philosophie, clairement. Par contre, si c'est juste ajouter des raccourcis dans la barre de menu, voire ajouter ou modifier la-dite barre, ça, par contre, semble faisable.

Ceci dit, il ne faut manifestement pas avoir peur d'éditer des fichiers de configuration à la main. C'est un DE minimal quoi (le plus léger que je connaisse en tout cas, après faut passer aux gestionnaires de fenêtres indépendants. Ça me fait penser que je n'ai pas entendu parler de lxqt depuis quelques temps…).

e ne comprend pas pourquoi tu veux faire deux partitions sur ta clé,

À priori, ça ne viens pas de l'OP, mais d'un obscur tuto qu'il semble avoir trouvé. Typiquement, je dirais que la, vu qu'il parle de clé usb live, je ne serai pas surpris qu'une partition serve de partition système en lecture seule et une autre contienne les données de persistance et de partage entre les systèmes.

"il suffit" de réduire la partition de Windows

.

tu pourrais ajouter

Sauf que

je vois mal ma mère se mettre à linux et pour ma part c'est un pc que j'utilise 3j par mois quand je rend visite à mes parents.

c'est pas sur son PC, et qu'il ne veut pas modifier la machine de ses parents, ce qui se peut comprendre, parce que réduire une partition n'est pas une tâche anodine.

Je pense que le plus simple, c'est encore d'installer à partir du CD d'installation, en fait. Surtout si ta clé USB ne sera utilisée que pour ça.

Personnellement, pour un système simple (BIOS et pas UEFI, une seule machine donc un seul type de CPU), je prendrais un clé ou un disque dur externe (mieux vaut le disque dur en fait, c'est plus robuste, je ne compte plus les clés USB flinguées suite à une écriture trop intensive…), et j'installerai directement mon système dessus, et si j'étais débutant je laisserai la procédure d'installation faire son taf toute seule.

Petit conseil tout de même: débrancher les périphériques de stockage inutile pendant l'installation (disques durs, clés, cartes SD, etc…) pour éviter que l'installateur n'altère lesdits périphériques.

Après, je peux aussi t'expliquer comment installer un système multiboot avec 2 ou 3 distribs supportant UEFI et BIOS (mais pas secure boot) ainsi que diverses architectures matérielles et une partition NTFS sur la clé, mais ça me semble pas le sujet :)

C'est pas faux, je suis trop habitué à penser aux petits projets et aux sites, j'imagine.

Attention, tu vas bientôt te répondre à toi même ;-)

Par chance, les devs de dlfp ont prévu le coup: 

Parce que tu crois que c'est un étudiant ?

Effectivement, rien ne le laisse supposer :)

ta maman a dû bien t'éduquer :p

Elle à fait son maximum, mais je suis doté d'un entêtement non négligeable, du coup malgré ses efforts louables je ne garantit pas le résultat :D

Le milieu du logiciel libre est probablement l'un des plus agressifs, machistes, et communautaires qu'il soit.

Hum… pour qu'un milieu soit machiste, il me semble bien qu'il faut avoir un moyen d'identifier le sexe de l'interlocuteur, et ça ne me semble pas hyper simple quand une grande partie des gens utilise une fausse identité, un pseudonyme.
J'ai perso déjà bien du mal à regarder à qui je répond (je ne répond pas vraiment à une personne, mais à un texte, au fond), alors être macho me semble un peu difficile, du coup. Et naïvement, j'aurai tendance à considérer que la plupart des gens font comme ça?

Il faut bien avouer que zenitram n'est pas super bon sur la forme, et j'ai plutôt tendance à essayer de comprendre le fond des choses au lieu de m'arrêter sur la forme (enfin, ça dépend de ma forme, si j'ose dire).

J'ai pris son exemple surtout pour montrer que ici, un message qui se mange un -10 sans avoir de +, c'est probablement parce qu'il y a autre chose derrière qu'une volonté d'un groupe de descendre quelqu'un pour le jeu: justement malgré les problèmes de forme de zenitram, certains (ensemble qui varie en fonction du texte en question) considèrent une partie (ensemble qui… bref) de ses messages comme pertinents.