Letho a écrit 344 commentaires

parce que tu ne peux pas livrer un exécutable docker à des utilisateurs

Non. Mais une image à instancier, disponible sur un registry, régulièrement mise à jour et testée en amont via un système d'intégration continue, si.

parceque je préfèrerais déployer et livrer un exécutable sans une nouvelle couche technologique qui a besoin de temps pour lire la doc, se former, mettre en place la pipeline, mettre à jour l'image docker, pour réparer les bugs pas liés à ton soft, qui a des problèmes de sécurité, etc, etc, etc

Cela demande, comme n'importe quelle techno, un investissement en temps. Et ce temps, on ne l'a pas toujours, effectivement. Ceci dit, cela peut également en faire gagner de façon non négligeable une fois le tout en place.
Pour ce qui est des bugs liés à l'environnement contenu dans l'image, ça nous est arrivé une fois. Je suppose que des outils comme Nix peuvent aider pour avoir des environnements facilement reproductibles, mais je suis loin d'être un spécialiste dans ce domaine.

Certains languages te construisent un exécutable prêt à l'emploi. Point barre.

Tout à fait. Je partageais juste un retour d'expérience sur un point : nous ne maîtrisons pas l'environnement dans lequel notre client déploie nos applications. Docker s'est révélé un bon compromis pour avoir un livrable tout en un en faisant abstraction des technologies utilisées, sans aucune autre dépendance que Docker lui-même.

Après, je conviens volontiers que ce n'est pas adapté à toutes les situations.

Pourquoi ne pas utiliser Docker ?
Nous avons eu le même problème avec une application Node, cela s'est révélé une très bonne solution.
Et c'est parfaitement intégrable avec un système de CI/CD (coucou Gitlab :) )

Je n'ai pas vu la pub, et ne peux pas la regarder maintenant. Et puis j'ai de la barbe, de toute façon. Et puis je peux me tromper, aussi. Mais sur cette simple phrase, « some », ça veut bien dire quelques uns ?
Parce que sans généraliser à la totalité, on parlerait donc bien du « reste », soit une grosse majorité, non ?

Oui… et non. J'adore Vim. Mais dans IDE, il y a le I de « integrated ». Et l'intégration entre Vim et un ensemble disparate de plugins ne sera jamais aussi bonne que dans un IntelliJ IDEA, par exemple.

Ou directement return (nombre_à_tester & 1 == 0) ?

Regarde peut-être du côté du Xiaomi Redmi Note 5 ?

Ben justement… Non ;)

Je ne sais pas pour C ou C++, mais c'est au contraire très facile d'avoir plusieurs versions de Rust. Il est officiellement recommandé d'installer Rust via RustUp qui te permet justement de gérer tes toolchains. Tu détermine ensuite par projet celle que tu souhaites utiliser.

# Installer la toolchain nightly
rustup install nightly
# Aller dans le répertoire du projet
cd mon_super_projet
# Le projet utilise maintenant Rust nightly
rust override set nightly

https://www.rust-lang.org/fr-FR/install.html
https://rustup.rs/

Idem pour les bibliothèques, tout est géré au niveau du projet, via le fichier Cargo.toml.
Je ne sais pas si c'est la question que tu posais, mais il n'y a aucun souci à avoir deux projets différents qui utilisent deux versions distinctes d'une même bibliothèque.

En aparté, l'icone est quasiment identique à celle de Boost, un client Reddit pour Android.
À ce point, c'est… surprenant.

http://boostforreddit.com/

C'est ce que je fais également, mais j'en vois les limites, principalement au boulot : certains mots de passe que je veux garder en sécurité ne sont pas liés à mon utilisation du web, par exemple ceux de comptes mails utilisés par nos applications.

GSConnect est une implémentation du protocole KDE Connect. Comme le dit amdg, Il n'y a rien venant de KDE à installer sur ton ordinateur. En fait, il n'y a strictement rien d'autre que l'extension à installer.
Pour le téléphone, il faut juste installer le logiciel client.

Après, effectivement, ce n'est pas un projet officiel GNOME. Mais il en utilise les technologies, et fonctionne tout de même fichtrement bien.

Tu veux dire un truc comme GSConnect ?

« This extension is a complete KDE Connect protocol implementation written in GJS that integrates with Gnome Shell, Nautilus and Chrome or Firefox. »

https://extensions.gnome.org/extension/1319/gsconnect/

;)

Hors-sujet, mais je viens grâce à toi de découvrir un superbe texte, et je t'en remercie :)

Un ami change sa date d'anniversaire tous les mois sur Facebook.
Ma consomation de pop-corn a littéralement explosé.

Effectivement, tu peux gérer tes masques indépendamment des modules, via l'outil « Gestion des masques », à gauche dans la chambre noire :)

Idem, Ctrl+L Ctrl+Z. Mais j'admets que c'est moins intuitif.

Moi je veux un logiciel qui fonctionne et qui fait seulement ce que je lui demande!!

Et donc, en clair, de façon concrète, en quoi Firefox ne fonctionne-t-il pas pour toi ?

Mais bon, visiblement, vous êtes tous trop bouffis d'orgueil pour regarder la vérité en face.

Ah oui, d'accord. Don't feed the troll, toussa.

si tu ne veut pas compiler pour les différentes architectures, ne fourni que les sources, éventuellement les sources au format adapté pour debian et pour redhat mais pas ce genre de choses.

J'ajouterai, éventuellement, en plus des sources, distribuer l'application via Flatpak, qui tendra (je l'espère) à devenir un standard en termes d'installation d'application tierces, sans avoir à se soucier de la distribution Linux utilisée.

Me gourre-je ?

Oui. C'est « me gourré-je », me semble-t-il ;)

Il me semble au contraire qu'il a été parfaitement respectueux dans sa réponse.
Il a également pris le temps de répondre à chacun des points que tu soulevais, de manière argumenté, et non pas passionnée comme tu semble le présenter.

Je ne sais pour toi, mais perso, je trouve ça un peu facile de demander à ce qu'il n'y ait pas de réponse à tes propos, sauf si cette réponse a un but constructif et/ou comparatif (sic), et te faire dans le même temps le seul juge de ces qualités, d'autant plus quand la réponse ne semble pas aller dans ton sens. Et je ne compte même pas l'ad hominem dès la première phrase.

Je serais un peu moins brut de décoffrage, mais je ne peux que plussoyer à titre personnel en tant que développeur : Gnome est pour moi un vrai plaisir au quotidien, et ce sans extensions. Le fait de pouvoir utiliser le shell au clavier joue beaucoup. Idem pour mes stagiaires :)

Je confirme, marche parfaitement bien sur un Redmi 3S sous LineageOS 13.
Et ça permet aussi de jouer à Mario Run ;)

Ah, les ADT… je crois bien que c'est ce qui me manque le plus en Java depuis que j'ai goûté à Rust. Ça, et le pattern-matching.

Sinon, merci pour ce journal, qui à mon sens n'aurait pas démérité en tant que dépêche :)

Fedora a également le numlock actif par défaut depuis la dernière version. Mais j'avoue ne pas comprendre pourquoi il a fallu si longtemps :)

Ils en parlent sur le Bugzilla de Gnome : https://bugzilla.gnome.org/show_bug.cgi?id=741224
(edit : grillé !)

Une appli flatpack, si j'ai bien compris (?), peut très bien intégrer sa propre version de la lib ssl et ne pas la mettre à jour et on va se retrouver avec une appli certes jouant seule dans son bac à sable mais dont les données utilisateur ne sont pas sécurisées.

Oui et non. Une application Flatpak pourrait n'avoir accès qu'à ce à quoi tu lui donne accès. Maintenant, tu as raison, si une bibliothèque embarquée doit être mise à jour, cela relève de la responsabilité du développeur. Les bibliothèques les plus courantes devraient faire partie des runtimes, qui eux sont mis à jour pour toutes les applications les utilisant. J'avoue que je ne sais pas du tout si la libssl fait partie du runtime Freedesktop ou de celui de Gnome.

Après, tu y gagne énormément en confort d'utilisation pour l'utilisateur, ET pour le développeur qui souhaite distribuer son application. Soyons honnêtes : je suis vraiment très heureux sous Fedora, mais l'installation d'applications tierces est une véritable plaie. Et je ne parle même pas du souci du packaging pour les X distributions existantes. Flatpak offre ça, plus le sandboxing. Ça demande de sacrifier - et encore, de façon relative - un peu de ce qu'offrent actuellement les gestionnaires de paquets. Mais les avantages dépassent à mon sens largement les inconvénients.