abriotde a écrit 989 commentaires

Normal vu qu'ils sont sélectionner sur ce critère.

Non, les modèles sont sélectionner sur leur capacité à être scientifiquement cohérents avec les faits.

On a ensuite parmi tous ces modèle tracés plusieurs scénarios possibles pour le futur en fonction des modèles, des incertitudes scientifiques et des incertitudes sur la réaction humaine.
On avait des scénarii "pessismiste" avec un réchauffement important et des scénarii "optimiste" ou le réchauffement était maîtrisé. Là, ce qui inquiète les scientifique, c'est que le réchauffement constaté, est au delà des scénarii pessimistes. Le réchauffement s'emballe plus que prévu et plus fort, pire l'homme limite moins que prévu sa consommation de pétrole. Alors on essaye de ressortir les scénarii mis de côté car trop pessimistes (Faisant trop peur à l'époque), car au final, ils pourraient bien avoir raisons.

L'homme à une propention incroyable à croire que le pire n'est pas possible (Il faut dire, qu'au delà de la mort, il n'y a pas vraiment pire pour lui). Mais si, la Corée du Nord existe et peut-être encore pour longtemps, mais si la Russie communiste à tué des millions de russes pour rien mais si l'Allemagne Nazi à créé des camps de concentration et si, l'Allemagne Nazi aurait pu gagner la guerre.
Aujourd'hui l'homme veut croire qu'il s'aura s'adapter au réchauffement climatique. Et comment dire, oui sûrement mais à quels prix? Au prix de milliards de morts, au prix de milliard d'exclus au prix de ruine économique, au prix d'un retour de l'obscurantisme, de régions plus inhospitalières qu'aujourd'hui? Probablement.

On notera aussi que de nombreux utilisateurs voulaient aussi des changement car le fonctionnement des paquets traditionnel a aussi ses limites, ne t'en déplaise cela ne convient pas toujours.

Tu en dis trop ou pas assez. Le problème avec le système traditionnel tel les paquets deb, ce sont les conflits. Typiquement, la liste de journaux sur les environnements Python, est le coeur de cible. On a des soft qui tournent en Python2 et d'autres en Python3, des soft qui ont besoin de la lib XXX en version < 0.12.3 et d'autres qui la veulent en version > 1.23. Avec les paquets, on est obliger d'arbitrer puisqu'elles seront disponibles pour tous.
Avec Snap, on s'en fiche, il intègre tout dans son paquet. En plus, l'application sera fans un environnement plus ou moins contrôlé, à savoir avec des droits limités puisque derrière c'est un Docker. L'utilisateur hésite donc moins à l'installer.
Autant effectivement, cela permet d'intégrer tout et n'importe quoi. Autant cela présente à mes yeux 2 inconvénients majeurs :
1) L'installation des paquets est bien plus lourde à tous les niveau. Elle est plus lourde puisqu'elle duplique sa version des librairies, elle est donc plus lente à lancer puisqu'elle est isolé, elle est aussi plus lente à tourner et demande plus de RAM car il faut avoir plusieurs instance des même librairies de bases.
2) Comme les développeurs n'ont plus vraiment la pression de mettre à jours leurs dépendances pour faire tourner leur application sur Linux, ils le font moins (Du moins certains). Et puis ce n'est pas vraiment grave que la librairie comporte des failles de sécurité car elle est en environnement isolé…

Autrement dis, c'est un truc de fainéant, et le problème c'est que comme ça marche pas trop mal, ça n’incite pas à faire les choses plus proprement. De l'autres côté, comme ça simplifie la vie des mainteneurs, cela arrange tout le monde…

Donc tu préfères corriger des bugs sur un OS non libre : Windows 7 :D . Bon je suppose que c'est quand même très exceptionnel.

Mais plutôt que Windows 7, je mettrai bien ReactOS. Il n'est peut-être pas dénuées de bug, il est un clone libre de Windows XP qui est encore plus ancien. Mais il est maintenu et libre. Déplus je ne serais pas étonné que la communauté Windows XP soit encore supérieure à celle 7…

PS: pour l'armée, il sortiront un serveur Azure d'hébergement de la suite Microsoft au sein de l'environnement sécurisé de l'état. Un serveur avec un lien très discret vers ma NSA et truffé de logiciels espions.

D’ailleurs, Microsoft a indiqué que d’ici 2030, voire 2027, il n’y aura plus que des logiciels sous forme de SaaS

Je prends le pari que ça ne sera pas le cas

Je prends le pari que ça sera le cas, peut-être même avant au pire en retard.
Aujourd'hui avec Starlink le 100Mb est partout sur terre. Et puis si tu n'a pas les moyens d'avoir ce "luxe" tu fais parti des 0.01% que Microsoft laisse à LibreOffice. Pour Microsoft, il n'a plus de problème de piratage, c'est bien plus rentable (entendez cher pour le client). Le client est content car il n'a pas de problème de backup ni pour du partage en édition.
Hélas la raison l'emporte rarement dans ces cas, sinon Apple n'existerait plus et Linux dominerait…

D'accord on doute que les navigateurs fassent une version européenne juste pour avoir leur moteur de rendu.

Mais cela ouvre peut-être une porte aux développeurs d'application pour contourner la taxe Apple. Je sais que le moteur de rendu bloque une voie de contournement.

Sans doute parce que comme tu dis, il doit explorer un grand arbre : la perf dépends pour parti du réseau. Pire, il ne peut pas récupérer tout en une fois il ne peut descendre que d'une génération à chaque passe.

Pour un peu plus de détail, Julia est un langage "interprété" mais conçu pour être compilé en ASM. Il compile au départ tout le code en assembleur (Ou une grosse partie je pense). Une fonction non typé est considéré comme du template C++ et elle peut donc donné naissance à plusieurs version ASM suivant le besoin du programme et l'inférence de type.

Python est dans les pires langages point de vue perf on lui adjoint du code C/C++/Rust pour avoir de meilleur perf mais cela complique tout.

C'est pourquoi je préfère Julia qui fait le choix de "compiler en live", ce n'est pas parfait, notamment au lancement, mais je trouve le langage plus cohérent rapport perf/simplicité. Il offre le meilleur des deux monde (un bon compromis en fait) c'est pourquoi sa cible n°1 ce sont les data-scientiste. Ce n'est pas demain qu'il aura un aussi bon écosystème que Python, c'est pourquoi Julia utilise beaucoup de biding Python…

C'est ça le problème, c'est qu'à la base un langage interprété est peu performant mais plus simple à développé et tourne plus facilement sur du multi-plateforme (Pas à s'embêter avec les appels systèmes spécifiques). Mais au final ce n'est pas si simple d'en faire du multi-plateforme (Sauf à limiter la complexité) mais en plus comme Python est dans les pires langages point de vue perf on lui adjoint du code C/C++/Rust avec pour conséquence de bousiller le multi-plateforme.

C'est pourquoi je préfère Julia qui fait le choix de "compiler en live", ce n'est pas parfait, notamment au lancement, mais je trouve le langage plus cohérent. Il offre le meilleur des deux monde (un bon compromis en fait) c'est pourquoi sa cible n°1 ce sont les data-scientiste.

Oui et non. Rust n'est peut-être pas directement à l'origine des bonnes perfs mais cela debunk deux choses:
* Rust est utilisable pour un ordonanceur sécurisé. C'est juste un langage mais il impose tellement de contraintes sécuritaire qu'il y a parfois des gens à dire que c'est trop complexe pour une tel utilisation.
* Rust est performant. car même en changeant d'algo, c'est impossible d'améliorer les perfs de Linux avec un code non performant. Javascript ou Java ne peuvent rien faire.

C'est peut-être enfoncé des portes ouvertes car Rust commence à avoir fait ses preuves mais bon.

Bah s'il y a une faille sur l'hôte, on y a accès. Enfin évidemment ça ne veut pas dire que demain tous les PC, tous les serveurs et tout vont être infectés par un vers par cette faille. Mais il est aussi évident que c'est possible au moins si l'on est sur le même réseau. Et les majors du hacking n'ont elles pas déjà des virus installés un peu partout?

Le soucis, ce n'est pas Cobol dans Git. C'est Cobol.
Il existe 100 fois mieux comme langage pour programmer efficacement. Le problème c'est que migrer un code Cobol vers un autre langage, cela demande du temps et de l'argent… Par contre, migrer de SVN à Git me semble assez simple.

C'est à dire que tant que SVN conserve un avantage sur Git, il devrait continuer. En l'occurrence je ne vois que ne pas copier tout le repo. Mais bon Git à les sous-repo. L'intérêt reste limité. Reste surtout les bases de code non migrées. En informatique on à le cas Cobol.

Pour le coup, je ne comprends pas que l'on note la pliure comme un défaut majeur. Franchement, de ce que j'ai vu c'est invisible. Après 1 ans ou 2 d'utilisation peut-être moins, je suis curieux.
Pour le coup, avoir un grand écran et un petit téléphone, c'est top (l'avenir, mais évidemment un peu de trop cher pour le moment.)

Même les prises VGA n'ont pas disparut. Ca c'est assez incroyable mais même les écrans modernes, ont pour beaucoup encore du VGA… Enfin ça se remplace un peu par de l'HDMI…

J'ai même une voiture neuve de conception récente (Dacia Spring) équipé de port USB-A pour brancher une clé pour écouter de la musique.
Tu me dira, mais maintenant on utilise le téléphone avec Deezer…
Ouais ben non. On a encore le droit de faire autrement non? La péremption c'est au bout de 20 ans minimum.

Leur police est super chouette en tous cas.

Ca m'intéresse autant que ta couleur de cheveux :D

Ancien non : Atom ou VSCode datent de 2014/2015 alors que par exemple PHPStorm date de 2009.
Par contre avec moins de fonctionnalités avancées, sans doute quoiqu' Atom/VSCode aient pléthore de fonctionnalités alors je ne suis pas si sûr que cela.

Disons que les IDE JetBrain sont plus "pré-maché".

Mon principale reproche à VSCode et surtout Atom (Qui est plus open-source) c'est surtout leur lenteurs (Consommation CPU/RAM). JetBrain est sans doute meilleur sur ce plan.

Mais pour le C/C++ QtCreator est tout à fait performant.

Leur faute ou celle de developpez.com ?

La faute aux 2 qui font du partenariat qui ressemble plus a du bourrage de crane lourd dingue qu'autre chose.
En fait généralement, ce genre de pratique éveille chez moi un gros warning : S'il y a autant de pub pour lui c'est qu'il y a sans doute de l'arnaque derrière.
Cela ressemble aux pratiques des sites porno (Surtout années 2000 sur internet) ou aux pratique d'appel téléphonique pour de l'isolation gratuite…
J'exagère un peu, et JetBrain n'est certainement pas aussi mal intentionné. Mais tout de même, ils sont sur une mauvaise pente. Et je n'ai pas envie d'installer un soft proprio (Dont je n'ai pas confiance de ce qu'il fait) qui plus et va me demander toutes les 5 minutes d'acheter la version payante avec une super remise… Je comprends la position de JetBrain mais je trouve qu'il y a suffisamment de développeurs qui développent des solutions open-sources, parfois payé par Google/microsoft (Même si du fait de la dispersion elle sont moins "puissantes")

sauf que les IDE Jetbrains ne sont ni open-source ni disponibles gratuitement mais par contre t'innondent de pub partout (developpez.com en tête).
Alors Jetbrains c'est le mal.
Je préfère encore VSCodium ou Atom… Ou Éclipse, Netbeans ou QtCreator pour les plus "lourd"

Moi du full remote depuis mon bled français en indépendant ça me va. Cela permet de fait d'économiser des frais et temps (fatigue) de trajets et des cotisations. Alors un salaire de Madrid correct c'est déjà pas mal. Mon logement ne vaut pas plus qu'un logement dans Madrid.

Sachant qu'en plus après ça peut progresser et que je préfère travailler pour une entreprise qui fait de l'open-source plutôt que des missiles…

La part du "Soutien des activités économiques" est gigantesque, cela devrait-être minime, 11% c'est trop. Alors au moins, il faudrait détaillé. Le transport, cela peut se justifié si ce sont les infrastructures (Rails, routes, ponts…), un peu quelques lignes isolé de bus/train mais pas le reste.

Dans "Protection sociale", c'est un gros fourre-tout :
- Le "Chômage" ne devrait pas être là, il est censé être auto-financé par les cotisation qui, si elles sont pour la plupart (Mais de moins en moins) centralisées par un organisme public, sont censées être autonomes (Donc non payé par les impôt généraux). Sauf cas exceptionnel de crise ou cela peut ce justifié.
- Ou est la "retraite"? Est-elle considéré autonome ou inclus dans le fourre-tout "vieillesse"? Mais on sait qu'il est déficitaire, et pour cause on sort des cotisants et on paye les retraites des autres avec ceux qui restent.
- Ou est la part de dépense qui sert a gérer le prélèvement de l’impôt et sa redistribution autrement dis la perte par frottement. C'est un sujet très important il me semble. Si pour avoir 1 000 euros de dépense il faut 1 500 euros de prélèvement, ce n'est pas la même chose que si c'est 1 010 euros. Cela inclus les contrôle fiscaux, mais aussi les contrôle de fraudes aux prestations, le "SAV", la bureaucratie…
- Ou est le fonctionnement des institution : Elysée, parlement, députés, votes, présidents… C'est sans doute inclus dans les "Services généraux" mais cela mériterait plus de détails.

Je ne sais pas, mais globalement on peut estimer que les vieilles version ont moins de bug que les nouvelles. S'ils maintiennenteux même les mises à jour de sécurité cela pourrait être plus fiable.
Mais on Fedora est pour moi la distribution la plus "bêta testeur" pourquoi ne pas avoir choisi une Debian ou autres qui attendent un peu plus avant de déployer les nouveautés…