David Demelier a écrit 676 commentaires

Mon préféré (copier/coller que tout le monde fait) dans mon poste actuel c'est le :

void DoSomething()
{
    m_mutex.lock();

    try {
        DoSomethingElse();
    } catch (...) {
        m_mutex.unlock();
    }

    m_mutex.unlock();
}

git is great because linus did it, mercurial is better because he didn't

Je suis aussi fou du C++ (presque juriste). J'en ai d'abord fait personnellement puis j'ai commencé à être développeur professionnel. Dès ma première expérience, j'ai vite déchanté. Je suis tombé sur une équipe sympathique mais ne connaissant rien des nouvelles normes (C++11, on était en 2013 à cette époque) donc j'ai du tout leur apprendre et j'ai commencé à faire des présentations du C++ moderne. J'ai fait ça à mon entreprise, à une école, un LUG, etc. Même après ça, mon équipe continuait de faire du C++98 ou autres idioms désuets ce qui a commencé à m'attrister, étant personnellement extrêmement exigeant.

J'ai quitté cette entreprise au bout de 3 ans et rejoint plusieurs autres et je me suis rendu compte que c'était malheureusent partout pareil. Peu de gens s'intéressaient à la nouveauté, certains me le disaient explicitement « j'avoue, je n'ai pas regardé les nouveautés ». Donc avec le temps j'ai commencé à beaucoup déprimer à force de travailler avec des personnes ne souhaitant pas se mettre à jour. C'est simple, j'ai jamais trouvé quelqu'un plus fort que moi en C++ (en entreprise j'entends bien). Et n'allez pas croire que je me vante, c'est juste un fait objectif. À chaque fois que j'apprends une nouvelle chose simple à un collègue, on me répond « je connaissais pas ». Notez aussi, j'ai jamais fait une seule ligne de C++ dans mon cursus universitaire ; c'est bien parce que je suis passionné et curieux que j'ai pu accumuler toutes ces connaissances sur le C++. Pour faire simple, le C++17 n'était pas finalisé que je connaissais tous les changements apportés.

Pour en revenir à ma situation professionnelle, j'ai l'impression que selon les langages on peut être vite déçu si l'on est très exigeant comme moi. Et personnellement ça me fatigue et me donne envie d'une reconversion professionnelle totale. Car en réalité, j'aime coder pour moi sans avoir à faire à une quelconque autre personne venant interférer mon code dès lors qu'il ne me ressemble pas. Et à l'heure actuelle, quand je rentre chez moi le soir je n'allume même plus mon ordinateur pour coder mes projets libres perso que j'aime. Et c'est pas faute d'avoir du mauvais matériel, j'ai tout ce qu'il me plait, mais la motivation n'est plus là.

Maintenant, j'aimerais savoir si certains d'entre vous étaient développeurs (tous langage) et ont aussi fait une reconversion professionnelle ? si oui vers quoi ? quand ? pourquoi ? comment ?

Ça me taraude de plus en plus.

git is great because linus did it, mercurial is better because he didn't

Justement les applications KDE en QML sont homogènes parce que Plasma fournit une API QML donc tant que les applications les utilisent ça restera propre.

git is great because linus did it, mercurial is better because he didn't

Je confirme, je viens de recevoir une notification en me connectant sur Crédit Mutuel que je serai dans l'obligation d'utiliser l'application pour valider les paiements.

/me soupire.

git is great because linus did it, mercurial is better because he didn't

Merci de démontrer mon propos : si tu n'utilises pas une version récente de Gnome 3 et wayland (si tu préfères Kde ou Xfce et que la carte vidéo est une nVidia, tant pis pour toi) et que tu n'utilises que des softs utilisant bien GTK3, alors oui, ça fonctionne convenablement. Dans tous les autres cas de figure, tu vas pleurer à force de plisser les yeux :D

Oui enfin même Mate et Xfce ont migré vers Gtk 3. Et pour ce qui est de KDE ça fait aussi un moment que ça tourne sous Qt 5. Alors sauf très vieilles applications on s'en sort plutôt bien (exit gimp qui tarde la migration). Note que Wayland n'est pas nécessaire pour le haute définition. Je n'utilise pas toujours GNOME et je m'en sors très bien (une petite variable d'environnement et ça roule).

Et quoi qu'il en soit, que le HiDPI fonctionne ou pas ne change rien à mon propos, à savoir des résolutions supérieures au full-HD (1920x1024) sur une dalle de moins de 15" ne sert à rien d'autre qu'à se la raconter sur les forums : "la mienne (de dalle) est plus grosse que la tienne"… ;)

Je ne vois pas le rapport avec la taille de l'écran. Certaines télévisions font aussi que du full hd et mon téléphone de 5" fait aussi que full hd. Chaque périphérique est utilisée à une distance différente.

Plus la résolution est grande, plus la définition sera propre. Et quand je compare mes écrans full hd de mon travail avec mon 4k à la maison je dis qu'il n'y a pas photo. Pourtant je ne les utilise principalement que pour développer mais le rendu des polices est tout simplement sublime. En repassant au travail j'ai l'impression que mes polices d'écritures deviennent floues après avoir utilisé mon 4k.

Ah et mon écran 4k n'est pas spécialement hors de prix non plus. Donc pas de quoi se la péter.

git is great because linus did it, mercurial is better because he didn't

Note : je suis pro redmine

Je ne pourrais pas dire que redmine (ni bugzilla) soit tombé en désuétude. Il manque certaines fonctionnalités modernes c'est vrai mais il est encore largement développé et utilisé par quelques gros projets. D'ailleurs les quelques questions que j'ai posées sur le forum ont rapidement eu réponses par les développeurs eux mêmes.

• https://bugs.alpinelinux.org/projects/alpine/issues
• http://bugs.ruby-lang.org (quelle surprise !)
• http://redmine.lighttpd.net
• https://redmine.replicant.us
• moi

redmine ❤

git is great because linus did it, mercurial is better because he didn't

Côté Qt, la mode est au QML. C'est joli, ça fait des belles animations fluides mais ça n'a aucun style homogène.

Il y a bien des contrôles officiels mais ils n'ont quand même pas de thème natif.

À ce jour je ne connais pas encore beaucoup d'application en QML pour Linux mais je cache pas une légère angoisse si on commençait à en faire en masse avec chacune ayant son propre style.

git is great because linus did it, mercurial is better because he didn't

Justement, j'ai du mal à comprendre cette pétition. Quand j'utilise GNOME je sens une harmonie parfaite dans toutes les applications qui ont exactement le même style (merci HIG, une chose qu'ils font strictement bien).

Je change rarement de thème, parfois je mets Arc et tout l'ensemble est toujours homogène. Bon faut dire que je passe aussi la plupart de mon temps en terminal alors peut-être que je ne vois pas tous les détails…

Plus d'exemple de « cassage » à cause de thèmes m'aideraient (applications non GNOME mais en Gtk alors).

git is great because linus did it, mercurial is better because he didn't

Personnellement j'ai toujours un peu de mal avec les forks dits un peu « simples ». C'est à dire n'apporter que peu de valeur ajouté si ce n'est une simplicité d'installation. Par exemple la distribution korora à mes yeux n'a pas beaucoup d'intérêt car il s'agit simplement d'une fedora avec des dépôts par défauts en plus et quelques paquets.

À contrario, les distributions comme Ubuntu sont bien plus qu'un fork à Debian car c'est toute une politique différentes, des paquets différents (globalement), etc.

Edit : ah ben korora est abandonnée aussi. CQFD.

Pour moi, les gens qui aiment Arch devraient simplement utiliser Arch.

git is great because linus did it, mercurial is better because he didn't

Il parait que system76 n'est pas très coopératif par contre. Il y avait un développeur chez RedHat qui s'en plaignait.

https://blogs.gnome.org/hughsie/2018/05/09/system76-and-the-lvfs/

Je ne sais pas comment ça a évolué depuis par contre.

git is great because linus did it, mercurial is better because he didn't

Je ne sais pas, j'ai essayé tuxguitar qui est en Java (et utilise Gtk2 à priori) du coup c'est comme gimp. Utilisable mais un peu petit.

git is great because linus did it, mercurial is better because he didn't

Le QHD sur un écran 14", c'est rien d'autre que de l'enfumage marketing. Pire, à l'usage, c'est même carrément contre-productif : tu passes ton temps à te battre avec la gestion du HiDPI. Quand tu crois avoir trouvé la bonne configuration pour une appli donnée, tu en lances une autre et bam, rebelotte, rien ne va plus à nouveau !

Pas vraiment, GNOME sur Wayland fait tout auto (y compris les différentes mise à l'échelle vu que mon écran 4k externe a encore un DPI différent). Personnellement la seule application qui me pose problème aujourd'hui c'est GIMP étant toujours et encore en Gtk 2.

git is great because linus did it, mercurial is better because he didn't

J'ai un thinkpad x1 carbon actuellement. Il me plaît mais c'est vrai que j'ai aussi songé à partir dans du 100% libre.

Le librem 13 et les « clevo » que tu montres n'ont que du full hd en résolution. Je trouve ça dommage en 2019. Perso j'ai un WQHD sur mon x1 et un écran 4k en externe, je pourrais pas revenir en arrière tellement c'est agréable à l'utilisation. Par ailleurs, ils sont plutôt épais et lourds pour des 13". Mon x1 ne fait que 1,1kg et c'est un 14".

git is great because linus did it, mercurial is better because he didn't

Et en quoi c'est mal, avec de réels arguments autre que Windows ou macOS font pareils ?

Le modèle des distributions classiques a fait son temps, il présente de gros défauts structurels que personne ne souhaite corriger. Un utilisateur veut pouvoir installer facilement plusieurs versions d'une application en parallèle, ou installer un logiciel qui n'est pas dans les dépôts ou dans une version différente (souvent plus récente mais pas que). Or, mettre en place cela pour l'utilisateur actuellement c'est une vraie plaie, même si tu es expérimenté.

J'en ai donné :

• intégrité fonctionnelle (déjà dit)
• versions (quand tu installes une debian, tu sais que tu n'auras que des bug fixes). quand tu installes un produit flatpak, tu fais du rolling release
• tu laisses la porte ouverte à l'upstream, s'il souhaite te mettre un trojan à la dernière minute il peut (cf eslint-scope de npm) alors que le packager d'une distribution s'assure de l'intégrité et sécurité des paquets
• légereté, j'ose pas imaginer les appliances et autres embarqués avec flatpak
• mélange paquets systèmes / flatpak, bonjour le bordel

git is great because linus did it, mercurial is better because he didn't

Attention ce qui suit est sujet à troll / débats.

Étant libriste depuis plus de 15 ans et ayant utilisé d'autres systèmes que GNU/Linux (notamment FreeBSD et NetBSD en bureau) j'ai parfois envie de dire que Red Hat est aussi entrain de tuer l'écosystème.

Pipewire

Comme vous le savez tous, PulseAudio était connu pour être particulièrement populaire pour ces plantages incessants lors de ses débuts. C'était d'ailleurs le cas sur les autres systèmes que Linux, ce qui a accentué sa mauvaise image pendant pas mal d'années. Honnêtement, maintenant ça fonctionne bien et j'avoue que c'est plutôt facile pour moi de passer d'un profile bluetooth / dock / jack sur mon thinkpad.
Pipewire est récent et à priori par encore utilisé tant que ça (corrigez moi si je me trompe) donc son intégration va à nouveau être longue et semée d'embuches. D'autant plus que si ça souhaite intégrer l'audio, on va de nouveau avoir des problèmes de support dans les boites à outils (Qt, Gtk, SDL, Firefox ?). J'aimerais en savoir plus, mais à vue de nez ça m'inquiète.

Flatpak

Alors franchement, flatpak est clairement la technologie qui m'agace le plus ces derniers temps. Je n'aime pas le concept, je n'aime pas son implémentation et encore moins son utilisation. À mon avis, flatpak est entrain de Windowiser les distributions. Bientôt, on va pouvoir se rendre sur telecharger.com et double clicker sur un paquet pour installer nos applications favorites. Les développeurs de distributions font en sorte que tout l'écosystème d'une distribution soit pur et cohérent. Avec flatpak on installe directement les outils et applications depuis le projet. Et un développeur d'une application ne connaît pas forcément tous les rudiments du packaging et ses spécificités. Ainsi on laisse openbar notre système.

Fedora

Fedora était de loin ma distribution préférée dès mes débuts. Mais plus j'ai avancé dans les versions avec, plus je me suis rendu compte à quel point c'est instable.

https://bugzilla.redhat.com/show_bug.cgi?id=1029213
https://bugzilla.redhat.com/show_bug.cgi?id=1416310
https://bugzilla.redhat.com/show_bug.cgi?id=1585276

J'ai donc progressivement quitté Fedora pour des distributions minimaliste où j'ai supprimé tout les Red Hat'ware.

git is great because linus did it, mercurial is better because he didn't

N'utilisant pas Windows je me demande comment fonctionne la couche de compatibilité pour faire tourner bash notamment.

Je comprends bien que Windows fournit une couche de compatibilité au niveau des appels noyau Linux (par exemple epoll). D'ailleurs c'est ce que FreeBSD propose aussi. Mais techniquement comment ça fonctionne ?

Si je prends un binaire /bin/bash compilé sur une debian 9 ça se lance donc directement sous cette « émulation » faite par Microsoft ou il y a d'autre manipulations à faire ? Est-ce que le noyau Windows détecte que c'est un exécutable Linux et se charge du reste ?

D'ailleurs qu'en est-il des bibliothèques externes ? Car les syscalls c'est quelque chose, mais il y a tout le reste (glibc/musl, libstdc++/libc++, SDL, X11, wayland, etc, etc).

git is great because linus did it, mercurial is better because he didn't

Et on fait comment si on a pas de smartphone ou qu'on a pas envie d'installer une application non libre ?

Personnellement ça m'agace assez. Surtout que dans mon entreprise on m'a forcé à installer une application sur mon téléphone personnel pour faire de l'authentification double. J'ai l'impression que les gens ont tendance à croire qu'un smartphone est maintenant un prérequis dans la vie.

git is great because linus did it, mercurial is better because he didn't

On expliquera un jour à tous les techos se disant anglophones que la traduction de library c'est pas libraire ? (-:

Au début je le faisais, mais j'ai vite arrêté.

git is great because linus did it, mercurial is better because he didn't

C'est systemd, tout comme ftpd, httpd, dhcpcd, etc.

Chez OpenBSD Theo de Raadt est aussi connu pour des prises de positions radicales et un comportement parfois offensif. C'est d'ailleurs une des raisons de son éviction du projet NetBSD.

En bref, l'herbe n'est pas toujours plus verte ailleurs.

git is great because linus did it, mercurial is better because he didn't

Moi c'est plutôt l'inverse. Certes en tant que pur utilisateur Linux tu n'as que faire du comportement de Torvalds mais lorsque tu contribues à plusieurs projets libres tu es bien content quand la communauté est vivable et conviviale. Linux est probablement un des projets opensource les plus influents du marché ayant une palanquée de contributions journalières alors forcément avoir un Godzilla en porte d'entrée ça peut vite devenir toxique. Personnellement, si à chaque projet où j'ai contribué on m'aurait insulté ou dit des choses comme « tu devrais être rétroactivement avorté ou mort en bébé en ne trouvant pas le sein de ta mère » je serais vite parti et aurait laissé tomber mes contributions.

(https://en.wikiquote.org/wiki/Linus_Torvalds#2012, je ne trouve plus le mail sur la LKML peut-être a-t-il été supprimé.)

git is great because linus did it, mercurial is better because he didn't

C'est pas parce que c'est racheté que ça va forcément devenir propriétaire. VirtualBox est toujours opensource par exemple. Au pire il y aura un fork au moment divergent.

git is great because linus did it, mercurial is better because he didn't

Tout va bien.

Donc si on fait quelques additions / soustractions, Microsoft va-t-il revendre mes données à des organismes de crédit dans le cas où mon total est négatif ?

git is great because linus did it, mercurial is better because he didn't

Je suis entrain de commencer ma propre distribution que je créé à partir de LFS. C'est vraiment très éducatif car bien qu'étant expérimenté sous Linux depuis 16 ans, je ne pensais pas que concevoir son toolchains en plusieurs étapes était aussi complexe.

En tout cas je recommande pour ceux qui souhaitent vraiment comprendre le principe de bootstrap et les différentes passes de la recompilation du toolchain.

git is great because linus did it, mercurial is better because he didn't

Je te rassure je n'ai rien compris non plus.

git is great because linus did it, mercurial is better because he didn't

J'aime bien les couleurs et la police. Je préfère également la version sans bulle. Après j'avoue avoir du mal avec ce flat design émergeant ces temps ci.

git is great because linus did it, mercurial is better because he didn't