freem a écrit 5019 commentaires

Réponse rapide: j'ai fait le pas quand j'ai commencé à avoir 2H de train matin et soir, et que je n'avais qu'un netbook (écran 12", 1Gio de RAM) sur moi. Même les IDEs les plus légers (Code::Blocks pour moi à l'époque) consommaient pas mal de RAM et de place à l'écran, sans parler de l'utilisation clavier pénible.

Réponse plus élaborée:

I3 (un TWM) m'a permis de transformer mon DE en IDE vraiment à mes ordres, pilotable à 100% au clavier de manière agréable.
Moins lourd que XFCE, et forcément encore moins que XFCE+Code::Blocks, même avec un grand nombre de terminaux ouverts.
Pour l'espace écran, la quasi absence de décorations de fenêtres et la gestion en tuile font que c'est naturellement aisé d'avoir toutes les infos utiles sous le nez. La gestion des workspace deviens elle aussi plus naturelle qu'avec un WM classique.

Quand j'arrêtais d'utiliser mon netbook et que je retrouvais mon dual screen (avec écrans pas de la même taille, tant qu'à faire), ça m'évitais aussi de poncer le bureau avec la souris (il a vraiment un creux au niveau de ma main droite, pour le coup, même je doute que c'est juste le code :D).

Pour le reste, je trouve le shell plus efficace pour retrouver un bout de code précis dans une arborescence, et zsh permets vraiment de se déplacer rapidement dans les dossiers, avec son autocomplétion type cd d/p/c/s/<tab> qui deviens cd developpement/projets/courant/source/.

Pareil, je n'ai jamais vraiment aimé les debuggueur des IDEs sous linux, ils ont beau être intégrés, c'est jamais vraiment passé. Ma solution actuelle est un pis-aller comparé à mes souvenirs d'ollydbg par exemple (que j'utilisais certes sans avoir le source originel, je l'avoue). Malgré ses défauts, cgdb dans i3 me permets de redimenssionner facilement au clavier la fenêtre du debuggueur, de lancer un debug distant sur une architecture différente (c'est un besoin récent, mais j'ai essayé vite fait avec code::blocs: sans succès. Vite fait, j'ai bien dit.).

Je préfère aussi utiliser git en ligne de commande, ce qui me permets d'utiliser les commandes comme je le veux, surtout que, le shell implique que le man est toujours rapide à aller chercher.

Il y a aussi le fait de devoir créer un projet à chaque petit bout de code «juste pour voir un truc» qui m'était insupportable.

Bref, pas mal de raisons, certaines matérielles, d'autres de goût. Je ne pense pas que ça soit important, du moment que les gens savent utiliser leurs outils.

Je te conseille d'en tester plusieurs, parce que le choix est vaste.

J'ai pas mal utilisé Code::blocks quand j'utilisais encore des IDEs. Il y a aussi QtCreator, KDevelop, NetBeans, Eclipse…

Pour ceux que je n'ai jamais testés: geany, codelite

Citations plus ou moins dans l'ordre de complexité (du moins vers le plus) selon moi. Complexité logicielle d'une part (plus ou moins lié au poids et à la vitesse de lancement), et d'utilisation (interfaces des plus simples aux plus riches).

Après, certains (dont moi) se passent aisément d'IDE tout court. Ça nécessite un peu plus d'apprentissage, mais je pense que ça vaut le coup:

• un éditeur de texte avancé (vim, emacs, notepad++, mais il y en a d'autres),
• un compilateur (gcc, clang),
• pour les projets plus complexes un outil pour gérer le compilateur (cmake, make, scons, ninja, autotools, le choix est vaste, mais la plupart des projets (que je connais) de nos jours semble utiliser cmake),
• un débuggeur (gdb, lldb) (qui sera de toute façon nécessaire pour débugger avec un IDE, savoir s'en servir directement un minimum permets de contourner les limitations des IDEs).

Pour le debugguer, je conseille de choisir un frontal parce que sinon, c'est trash. J'ai souvenir d'avoir utilisé:

• cgdb (celui que j'utilise ces derniers temps)
• ddd
• xxgdb

Mais il en existe d'autres. Je ne suis honnêtement pas vraiment satisfait par ceux que j'ai essayé, par contre. Je n'en ai pas utilisé certains autres, pour des raisons qui n'ont rien a voir avec leur qualité:

• nemiver
• kgdb

Ah oui, en effet, j'aurai du aller lire la description d'e2fsprogs:

Ce paquet fournit des programmes […] de systèmes de fichiers basés sur ext2/3/4. Il comprend aussi le programme « badblocks », qui peut être utilisé pour rechercher les mauvais blocs sur un disque ou tout autre périphérique de stockage.

Merci pour ces précisions.

ne permettent pas nécessairement de lever le dilemme

Il semblait essayer de se coucher, alors c'est p'tet voulu?

Ben en gros, il demande pourquoi Ubuntu dispose, depuis plusieurs années, d'une version d'une lib X11 plus récente que ce que Debian propose dans Buster.

La raison de ce questionnement semble être que ça empêche Debian d'intégrer le bureau regolith qui propose un paradigme basé sur un gestionnaire pavant (i3, manifestement).

Pour le coup, j'ai un peu ri, et j'ai découvert qu'il existe un DE basé sur des TWM, donc j'ai aussi pertinenté.

on a inventé les rustines pkg-config et ldconfig.

Et si j'aime tant coder avec une machine qui tourne sous linux, malgré l'absence de debuggueur vraiment clean (hors IDE, parce que non, les debuggueurs dans les IDE ne sont pas la panacée, dans certains j'étais obligé de créer un projet pour debugger un code qui tiens sur 3 fichiers…) contrairement à windows, c'est bien grâce à ces «rustines», qui simplifient tant la vie.

Par contre, je n'appellerais pas ça des rustines, vu que ça permets de facilement installer des libs de plusieurs archis sur la machine, installées parfois par le système, parfois par l'utilisateur, sans foutre le merdier en collant tout dans un dossier unique, en permettant de mettre chaque lib dans son propre dossier…

Je ne sais pas, les "coreutils" sont-ils vraiment profondément liés au noyau? Ça m'étonnerais un peu quand même, vu qu'à la base l'objectif est de fournir une distro complète, noyal inclus.
Et pour avoir lu quelques morceaux des variantes d'OpenBSD, de NetBSD et de FreeBSD à des binaires de coreutils, je dirais que porter ceux de NetBSD ou d'OpenBSD devrais être pas si complexe.

Reste les outils type udev ou ceux qui touchent à la sécurité comme selinux, apparmor et les cgroups, mais je ne crois pas qu'ils fassent partie du projet GNU.

Les gens ici sont bien bons de te nourrir

C'est pour combler mon manque de bonnes actions :)

P'tet bloquée par le pelage trop volumineux du troll?

Ça donne envie, ça fait un moment que je voudrais me débarrasser de claws-mail (qui est pas mal, mais j'ai quelques désagréments avec, et il fait partie des derniers logiciels qui me forcent encore à utiliser la souris).

Il faudrait que je revérifie dans les logs de mes repo, me semble que j'avais suivi certains de ses conseils, qui ont cassé certains scripts, tandis que d'autres trucs auraient pu être signalés.
Peut-être que je me repose sur certains comportements bordeline, aussi, faudrait que je le repasse sur mes scripts les plus "poussés".

memtest86+ dans le Grub.

Marrant, je pensais que c'était un module de syslinux, mais manifestement c'est un binaire à part, qui s'utilise donc peu importe le bootloader.

(est-ce dans buzybox ?) on a badblocks

Nope, pas busybox. Celui-la ne sert qu'à remplacer les outils de base du shell. apt-file search badblock | grep -v man semble suggérer e2fsprogs pour le binaire, mtools en aurait une version aussi, et smartmontools en cause. Le dernier me semblerait le plus adapté pour le coup, moins limité à des systèmes de fichier spécifiques.

C'est un peu vieux, mais j'ai pas trouvé mieux (c'est pour le taf à la base). De ce que j'ai lu (p'tet 1/3) c'est plutôt bien expliqué, malgré que l'auteur part du principe que l'on connaît les specs du hardware, ce qui est pas mon cas, mais avec un peu de démerde je commence a m'en sortir.

Les partitions réseau (NFS, CIFS ou autres) ont souvent un point de montage dédié […][dans] le /home/$USER par exemple

C'est ce que je faisais, à un moment. Et j'ai arrêté, parce bon, pourrir le réseau et la vitesse de mon système au moindre find, c'est pénible.

Mais oui, /mnt me sers plus, à moi, à des montages temporaires type clé usb pour partition normalement pas montée. Pour les médias, me semble que Debian utilise /media/foobar?

Je découvre à l'instant que /usr peut (théoriquement) être partagé entre plusieurs machines quand /var est spécifique à la machine. Je ne connaissait pas cette ségrégation historique. Même si je m'abstiendrais bien d'utiliser un /usr partagé, ça semble un peu casse gueule (même avec un parc matériel+OS homogène).

Je m'en sers au taf, pour booter des bécannes dont l'install est scriptée (histoire de changer divers paramètres en fonction du type d'install, surtout) et qui bootent sur un PXE (ou équivalent pour Das U-Boot) le but étant de pouvoir procéder à plusieurs install en parallèle.
Bon, par contre, mon bazar est loin, très loin d'être nickel, c'est de la bricole (mais bricole qui permets de gagner un temps non négligeable, en évitant toute modif malheureuse du serveur qui fait le déploiement, et même si ça arrivait, j'ai juste à rollback la VM).

Je pense que sur des réseaux avec du diskless, ça aurait tout son sens, par exemples les machines à disposition du public: le / en lecture seule, les /var, /tmp et autre volatiles en RAM. On peut aussi imaginer coller les /home sur du NFS/CIFS/Whatever (avec quotas) si les utilisateurs ont besoin de persistance mais qu'on s'en méfie comme de la peste.

Autre usage potentiel, c'est une bécane bien montée en terme de perf, et les utilisateurs se logguent sur des rPI. J'ai jamais vu en pratique, mais je pense que ce n'est plus si déconnant à l'ère du minitel 2.0 ou "tout le monde" au final se contente de se connecter sur une collection de sites web.

En terme de régénération hard/licence de parc, ça serait bien moins cher que refaire un parc complet de vraies tours, et, si le réseau tiens la route, y'a moyen que ça soit limite plus rapide que les réseaux de windows infectés que j'ai déjà vus dans ma carrière, ou qui sont ralentis par un AV trop mal dimensionné.

Là on est parti pour le scénario Die Hard 4.

Hé oui, vivement le 5!

Je connais le terme de baremetal.

Le problème, c'est que j'ai déjà vu des gens considérer que le devsys, il fait du dev au niveau kernel voire plus bas. Pour d'autres, c'est juste du code qui sert aux autres programmes.

J'ai aussi déjà vu des admins parler de baremetal pour parler de daemons déployés sans VM ni containers. Dans leur cas, ça se comprend j'imagine (dur d'imaginer plus bas niveau d'un point de vue sysadmin, puisque moins de couches impliquerait de ne pas avoir de kernel au final, et donc, pas besoin d'admin sys?).

Allez faire un tour dans le SI des gros industriels.

De ce que j'en sais, les petites boîtes sont aussi loin de ce genre de trucs, surtout quand il s'agit de déployer du soft qui est sur du matos à 500Km, sans intervention (pseudo-)physique peu chère et avec des compétences régulièrement plus qu'improvisées.

Dans ce type de boîtes, les curieux qui aiment le low levels ils sont utiles, parce qu'ils peuvent toucher à plus d'un domaine même sans exceller dans leurs domaines annexes. Dans mon cas, docker, bah… installer plusieurs OS (une image est quasi un OS complet au final) sur une ROM de 4Gio, disons que, j'ai pas envie. Genre, vraiment pas. Surtout quand on les contacte via des forfait de 30Mio/mois via 3G.

Une autre distribution qui marche bien dont on a pas parlé (je suis p-e passé à côté) c’est RHEL :

En même temps, c'est (à ma connaissance) la 1ère distro commerciale a succès, mais c'est vrai qu'on l'a zapppée. La seconde (toujours selons mes connaissances) étant Ubuntu, qui a commencé par cibler un public totalement différent (utilisateurs plutôt que serveurs), choix sensible quand on voit le résultat (aka: ça a marché et ils sont sur les serveurs et autres du coup).

Je proteste, Zenitram a toujours au moins un argument qui tiens la route un minimum, ou une attaque en règle sur un argument passé, la, y'a rien. Zenitram, aides-le donc, sinon on va s'ennuyer demain!!!

Ben moi je suis content, après une journée de taf, ça défoule de basher un troll. Le prendre a la légère, le sourire aux lèvres, en le voyant s'exciter espérant un petit '+1', et se rater, ça me fait garder en plus confiance dans ce site et sa communauté.

Et donc, pas les tiens? Ma foi, je crois qu'on devrais tous reconnaître ici que c'est bien toi le meilleur. Côté mauvaise foi.

Avis très intéressant. Comme quoi, d'un troll raté ne poussent pas que les poils.

Selon moi, ceux qui n'ont, grosso modo, connu qu'un seul OS sont ceux qui sont nés qu'après 1995: avant ça, je doute que les gens n'aient pas connus de windows 9X et donc par plantage interposé, MSDOS, qui n'est pas la même chose que la famille WinNT.

Je crois que Win9X malgré ses défauts était bien plus bidouillable que la famille WinNT (base de registre basée sur des UUID (je suppose, hein, ça date) et non des chaînes de caractères, pas de fichiers de scripts d'«init» (autorun.bat, sysconfig?) faciles à trouver ou bien documentés, difficulté/impossibilité d'avoir un vrai mode bas niveau: toujours une interface graphique obligatoire et un shell castré comparé à MSDOS6) ce qui a peut-être tendance a rendre le sujet plus intéressant.

De ce fait, je ne pense pas que les jeunes developpeurs soient très attirés par la programmation système, du moins autant que ne pouvaient l'être la jeunesse entre 1995 et 2000.

Reste à savoir ce qu'on appelle programmation système. Est-ce le fait de coder sans OS, en «bare-metal», ou le fait de coder des softs/scripts à destination des autres logiciels, conçus pour être scriptés?
Dans le 1er cas (baremetal) je pense que sur mes 4 jeunes collègues (moins de 3 ans qu'ils sont sortis de l'école, sur un total de 5 collègues dev), 1 seul est intéressé. Dans le 2nd cas, j'en ajoute un. Ce ratio est pas trop mal, d'autant que ce sont des univers qu'ils n'ont pas découverts à l'école. Moi non plus d'ailleurs.

Il est vrai que le web, les containers, l'IA, sont des sujets qui font beaucoup de bruit, mais l'IoT ou le «devops» (quoique cela puisse vouloir dire) ne sont pas silencieux non plus, je miserais personnellement plus sur une baisse des dev de softs end-user natifs qu'une baisse des dev «bas-niveau», surtout parmi les contributeurs à des projets open-source, avec des impacts désagréables (je me souviens de pgadmin3, codé en C++, il marchait nickel, j'ai essayé récemment le 4, j'ai été dégoûté, trop lent, buggué, dépendances à n'en pas finir…)

Après on doit pouvoir en remplacer seulement quelques uns pour pouvoir s'appeler autrement que GNU/Linux, au grand dam de Stallman.

Dans le cas de Debian, je pense que la complexité de faire ça est liée aux scripts de [pré/post|install/rm]. Par le passé, on aurait pu ajouter rc.d, mais à l'ère de systemd je pense que c'est de moins en vrai.

Je suis, par exemple, persuadé qu'il est possible de remplacer en grande partie coreutils par busybox, et PAM par un truc qui ne segfault pas les applis liées à la glibc si on ose utiliser ldap avec une config pas top (vécu récemment, sur buster), peut-être en portant le mécanisme d'auth d'openbsd vers linux? Pour ce qui est du compilo, ma foi, clang devrais marcher, et je suis sûr que si on cible moins large que Debian, ça finirai en 100% de build.

il ne travaille sur Windows®).

Mince, je le pensais pourtant fan de minix! Quelle déception, mais c'est vrai que la source que je viens de trouver indique que clairement slackware est sa favorite (oupa… niark)

Je proteste, mon script (et d'autres que j'ai fait, c'est pas la 1ère fois que je joue avec debootstrap) n'a rien à voir, en terme de qualité et finitions, je suis à la ramasse!

Par contre merci du partage, une fois décortiqué (parce que bon, il est aussi 1000 fois plus verbeux que ce que je fais) y'a moyen d'en tirer pas mal de connaissances!

Par exemple:

• au niveau des conventions de codage, j'ai encore tant à apprendre sur le shell (faudrait que je trouve un outil d'analyse statique en vrai);
• je vois une p'tite for-loop sur une variable STATIC_ETH qui m'intéresse pas mal, sans la copier, je pourrais p'tet y trouver des choses intéressantes;

peut etre une feature à lui ajouter.

Avant d'ajouter des features à un truc qui marche, je pense que je ferais mieux de travailler mon truc bancal pour le rendre plus convainquant que ça, j'espère que la communauté de linuxfr m'en voudra pas trop si je me sers encore des journaux pour me servir de notes :)