ff9097 a écrit 745 commentaires

Quand je reçois une contribution à un de mes projets, je l'oublie pas

C'est pas bête, je me demande si quelqu'un y a pensé avant.

Si je comprends bien, pour restaurer l'image il faudra toujours brancher 2 clés : la bootable avec redorescue et celle contenant l'image sauvegardé pour restorer. Il y a un moyen simple pour avoir les deux sur la même clé ?

Noto est relativement récent

Si je ne me trompe pas, actuellement c'est DejaVu + Noto car DejaVu ne couvre pas toutes les langues. En basculant sur Noto pour toutes les langues, on enlève DejaVu de l'installeur

Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.

Je vois pas le rapport entre LDAP et les logs

CI c'est le minimum en effet. Après le delivery a chaque push je dirais que ça dépends.

Tu crois que ça n'est pas utilisé sur GitHub ni SO mais que ça serait très utilisé ailleurs ? Non c'est (quasiment) pas utilisé parce que c'est (quasiment) inutile.

Il n'y a aucun rapport entre des API taggés obsolètes et une soit-disant envie de pousser Kotlin puisque c'est la même API Android et que Kotlin est 100% compatible avec Java.
Franchement AsyncTask plus personne n'utilise cette horreur depuis des années

Android Studio n'est pas tout léger c'est clair mais ça fonctionne très bien. Hormis du matériel limité c'est un gros apport.

Go a été conçu pour ça. Rust non

Il faut vite un noyau alternatif pour être plus hétérogène !

C’est dur d’estimer quel genre de traffic ils prennent, mais une autre façon de voir les choses c’est que chaque serveur génère plus de 650k euros de chiffre d’affaire par an.
C’est assez incongru comme métrique aussi, mais vu sous cet angle, ça devient moins stupide.

Ça fait moins de 1800 balles / jour / serveur c'est très faible je trouve

Bof ça pourrait être plus haut niveau pour plus de facilité et plus de contributeurs.

Depuis quand Windows est personnalisable ? Même Android ne l'est pas énormément

Pour moi le langage doit décider des règles sur le nombre de tabulations et autres formatage de manière à ce que ça soit le plus homogène possible partout. Avec possibilité simple d'activer ou désactiver des règles si l'on veut

Tu confonds typage faible et dynamique. On va s'arrêter là.

Des micro-package c'est normal mais 1 ligne sérieusement....

J'espère qu'il y a les packages isEven, isOdd, isTrue et isFalse faudrait quand même pas devoir les implémenter moi même.

Pas de stdlib, bourrés d'incohérences, typage faible... C'est drôle tu défends JavaScript en nous parlant de Typescript.

Bah... pas forcément... En quoi le code qui copie/colle 3 lignes serait plus beau que le code qui fait un require?

Quand on préfère ajouter bêtement une dépendance au lieu d'implémenter 1 ligne pour quelque chose qui n'évoluera jamais c'est qu'on ne réfléchis pas beaucoup à ce qu'on fait. Ce qui laisse à penser qu'on a pas beaucoup réfléchi au reste.

Si je ne me trompe pas on écrit toujours en JavaScript avec ces frameworks

Une version unique de dépendance comme on fait ailleurs c'est déjà beaucoup mieux.
Je trouve hallucinant les dépendances qui comportent à peine quelques lignes de code (voir une seule comme dans l'exemple !) et que des gens l'utilisent au lieu de l'implémenter eux-mêmes. Le code derrière qui utilise ça ne doit pas être bien beau....
Javascript est immonde et devrait arrêter d'être écrit et simplement généré à partir d'autre chose. Voir à long-terme complètement remplacer mais même Google y a renoncé.

C’est la principale raison pour laquelle je n’aime pas trop les projets en nodejs. Ça et l’utopie de croire que tout exécuter avec un seul proc/cœur, y’a qu’à scaler si on veut gérer de la concurrence, s’avère bien plus compliqué qu’il n’y parait au premier abord.

Quel rapport avec le reste ?

On compare un système très mature comme le système de paquets mais où aucun format ni gestionnaire de paquets s'est imposé. On se retrouve donc aujourd'hui avec plusieurs formats qui sont tous un peu les mêmes en différents et pareil pour les gestionnaire de paquets. On est tous habitué au deb/rpm et apt/yum/... et ça continue par inertie.

Et de l'autre on a un système quasi-unique (je compte pas snap qui n'est poussé et n'est pris en charge que sur ubuntu) qui est encore très récent et dont pas mal de défauts mentionnés sont des choix qui peuvent être remis en cause facilement comme l'attribution de certaines permissions par défaut où le but était de ne pas trop changer les habitudes des utilisateurs.

Sur la sécurité c'est risible, actuellement c'est open-bar. Les applications ont tout les droits sur $HOME et même l'accés en lecture à /. Avec flatpak je retire les droits sans soucis si j'ai envie et sans bidouilles.

Je pense qu'en effet certaines distros iront vers une généralisation du flatpak sur ce qui est graphique. Et d'autres resteront sur le modèle actuel. Au moins ça donnera de vrais différences entre chacunes et ça simplifiera le choix parce qu'aujourd'hui pas mal de distribs sont un peu toutes les mêmes.

Oui continuons à être open-bar et à donner absolument tout les droits à ce qu'on exécute !

Le langage est complexe donc lent a compiler. Pareil pour C++.
C est simple donc rapide a compiler. Rien ne bien étonnant donc

Tu as peut être une garantie de délai maximum avant rétablissement en cas de coupure de service. Même si en fait ça paraît pas assez cher pour ça