freem a écrit 5019 commentaires

Pour la taille des partitions, moi, je serais partit sur 100G windows, 50G Ubuntu système, 50G ubuntu utilisateur (le dossier home), le reste en partagé (NTFS, parce que windows nativement ne sait pas lire les ext4, même s'il existe des pilotes, je trouve qu'ils s'intègrent très mal) pour pouvoir jongler entre les systèmes.

Le noyau 64 bits c est surtout pour profiter des 8go de ram (3go pour l hote et 2go *2 machines virtuelles)

C'est une confusion tellement fréquente… un noyau 32 bits peut gérer plus de 4Gio de RAM physique, sans problème. Après tout, ils gèrent bien des disques durs de capacités nettement plus grande…

Le truc, c'est qu'un noyau 32 bits est incapable d'allouer plus de 4Gio de RAM (voir: PAE) à un processus unique, de mémoire.

Le réel avantage des noyaux 64 bits, c'est la capacité d'utiliser les registres CPU à fond, et ce, au détriment des caches L1,L2 puisque du coup certains types de données sont 2 fois plus gros sans que cette capacité double soit forcément utile. Mais quand on se mêle de savoir comment est fichu un processeur, on entre dans des chose que 95% des gens à minima n'ont pas besoin de savoir :)

À priori, oui, mais moi idem je n'ai pas encore fini, j'ai juste vu l'annonce me faut le temps de me refaire un perso… ou récupérer un perso mais la flemme, le jeu est pas super dur et je vais plus me souvenir de ce qu'il faut que je fasse :D

Les développeurs sous KDE utilisent pas plutôt kdevelop?

Sauf que vim… enfin, vi, à un avantage de poids: il est dans le standard POSIX. Savoir utiliser vi un minimum (et donc vim) implique d'être capable de se démerder «sur la majorité des systèmes Unix actuels» ce qui est un avantage non négligeable contre emacs ou visual machin ou truc bidule.

Ah, et aussi, pas besoin d'interface graphique, DONC utilisable via ssh (bon, ça, emacs et nano aussi, mais emacs est pas installé par défaut sur les distros que j'ai utilisées et nano est franchement limité en fonctionnalités).

les IDE apportent tellement de fonctionnalités, et sont tellement bien intégrés avec les différents outillages que ça devient difficile de continuer à faire de la pub pour les bons vieux éditeurs pour doigts magiques.

Le problème, c'est que je ne connais aucun IDE qui s'intègre à mon shell aussi bien qu'un éditeur de texte du type vi (s'applique aussi à emacs, pour le coup je suppose).
Mais bon, oui, pour ceux qui aiment aller chercher la souris, les IDEs modernes sont superbes. J'en ai utilisés, j'ai même commencé par ça.
Je préfère mon i3+vim, merci (faut que j'arrive à me mettre à kakoune, mais je n'arrive pas à trouver en moins de 15min comment avoir la coloration syntaxique pour le C, le C++ et le sh à minima).

Effectivement, du whitespace aurait été plus adapté, je n'ai jamais vu de langage aussi clair.

Au fait, tu n'as pas dit que Debian fonctionnait?

Si c'est le cas, pourquoi ne pas l'utiliser? Les autres distributions que tu as citées sont bâties sur Debian après tout?

Je ne fais pas partie du projet, je me suis contenté d'annoncer la v1 ici :)

Pourquoi y a-t-il un repo sur sourceforge ET sur github ?

Je n'étais pas au courant pour le projet sourceforge, mais je pense que c'est le classique: ils ont commencé sur sourceforge, et ont migré par la suite.

Il n'est pas possible de changer les raccourcis en jeu

Le contrôle est à mon avis une grosse faiblesse de flare, ne serait-ce que le fait que l'on ne puisse pas utiliser tous les boutons d'une souris 3 boutons + molette, je trouve ça dommage. Mais bon, c'est une version 1, je pense que ce genre de trucs s'améliorera avec le temps.

C'est dommage car quand on commence un jeu c'est toujours la galère.

Mon 1er réflexe est systématiquement d'aller regarder les options avant de jouer.

Ils ont commencé à se mettre en «mode sous-marin» lorsqu'ils ont commencé à travailler sur «Empyrean Campaign», probablement parce qu'un mode solo n'est pas forcément très rejouable (il n'y a aucune génération procédurale, donc la rejouabilité est très limitée).

Et en fait, ce n'est pas du sous-marin pur et dur, puisque l'on peut trouver un forum ainsi que des projets github, tant pour le moteur de jeu que pour la campagne, mais c'est plutôt disparate et bien moins encadré qu'openmw ou d'autres projets de jeux (ou de «simple» moteur), clairement.

Enfin, c'est de ma faute, j'aurai du poster ces liens dans le journal, aussi :)

Grub, c'est le menu au boot qui t'affiches une liste de systèmes à démarrer. De mémoire, la touche F2 ne sert à rien?

Sinon, les options de noyau:

• splash c'est pour afficher une image au lieu des journaux de démarrage. Ne la mets pas, ce sera plus simple pour essayer de comprendre ce que fait le système et où il bloque;
• quiet c'est pour dire au noyau d'être silencieux, idem, pour débugguer, ne la mets pas;
• acpi sert à activer des choses comme l'extinction douce quand tu appuies sur le bouton d'alumage pendant moins de 5s;
• nomodeset semble servir à ne pas jouer avec le mode graphique via le kernel;

Quant à Xorg, c'est le serveur graphique. Si il ne peut pas se lancer, tu arrives sur une invite en console qui te demande un nom d'utilisateur (en affichage normal) puis le password associé (rien n'est affiché pendant cette phase) afin d'arriver sur un shell (invite bash).
Pour qu'il se lance automatiquement, il faut (entres autres) un gestionnaire de session (je simplifie, hein) qui en théorie est installé automatiquement par les distributions classiques (Debian, fedora, Ubuntu, mint, etc).

Concrètement, quelle est la dernière chose que tu vois quand tu fais une installation par défaut avec Ubuntu?
Autres questions:

• quel fichier ISO de Ubuntu as-tu téléchargé?
• as-tu vérifié l'intégrité du fichier ISO?
• quel processeur et quelle carte graphique as-tu si il y en a une installée?

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)