Depuis quand ? J'ai toujours cru que son usage était plus près des 5% que des 40%.
Du coup, je vais voir l'article original dans Stack Overflow, et je vois que c'est basé sur un sondage annuel de Stack Overflow (et donc majoritairement des développeurs, j'imagine), et sur un panel de 71,503 responses.
Bref, j'imagine que c'est de l'humour.
Mais bon, il y a une réelle progression de linux dans cette population au cours des ans (ou alors plus de linuxiens qui répondent au sondage annuel ?)
En tout cas, c'est ainsi que je le prends sans que cela rende totalement inintéressant d'observer la progression de Linux dans cette catégorie de personnes.
Il prend aussi en compte l'usage des VMs linux de manière indirecte via WSL2, docker desktop (et outils similaires). Voilà comment il aboutit aux 40%.
Je ne pense pas. De ce que je comprends c'est 40% + ceux qui l'utilisent de manière indirecte.
Posté par Psychofox (Mastodon) .
Évalué à 2.
Dernière modification le 27 décembre 2022 à 11:14.
Bref, j'imagine que c'est de l'humour.
En tout cas, c'est ainsi que je le prends sans que cela rende totalement inintéressant d'observer la progression de Linux dans cette catégorie de personnes.
Je ne vois pas bien en quoi ce serait de l'humour. Au niveau des équipes de developpement c'est aussi une tendance que j'ai pu observer ces 10 dernières années. De plus en plus de boites te laissent le choix du materiel ou de l'OS, c'est même souvent vendu comme un des avantages proposés dans les offres d'emplois. Je vois souvent les product managers qui touchent peu ou pas du tout de code sous Mac et Windows, les devs en général bien plus répartis entre mac, windows et linux. Beaucoup de DEV commençant avec Windows se rendent compte des perfs deplorables de git sous NTFS, du bricolage qu'est le WSL et de l'impact des politiques de l'IT sur les perfs de leur pc sous windows et switchent rapidement sous Linux.
De toute manière avec office 365 t'as accès maintenant à tout Office sous linux via le web, les IDE stars que sont vscode et ceux basés sous jetbrains tournet dessus et tous les autres outils de developpements sont soit basés web, soit sous conteneurs natif linux soit sous cli. Certe tu peux presque tout faire tourner sous WSL…mais avec la surcharge d'avoir deux OS et deux noyaux qui tournent sous la même machine. Quel intérêt? Du coup oui il y a pas mal de devs en entreprise qui utilisent linux par défaut.
Je ne vois pas bien en quoi ce serait de l'humour.
Ça n'en serait pas si le titre avait été Amongst the devs, 2022 was the year of Linux on the Desktop
Tel quel, ou c'est un titre putaclic, ou c'est une référence à ce qui est devenu une vieille blague du type de la sortie de Hurd stable. Je préfère croire que la deuxième interprétation est la bonne.
Et je suis bien d'accord que de toute façon, la tendance est intéressante, un doublement des linux chez les devs et autres pro de l'informatique en quelques années n'est pas insignifiant (bon, pour faire une analyse sérieuse, il faudrait aller comparer les différents panels ayant servi de base pour chaque année).
Allez, j'ai résisté lors du premier message à mettre l'image conventionnelle, pas lors du second :-)
Personnellement je n'ai jamais compris comment on pouvait utiliser Windows pour travailler (hors bureautique bien sûr et peut être pour développer sous Windows). Windows c'est bien pour jouer, mais pour travailler, notamment sur de l'infra, c'est loin d'être la panacée, du moins, sans l'installation d'un tas d'outils tiers qui ne sont pas fournis avec la distribution (il faut se taper 50 000 sites webs pour télécharger des trucs qui peuvent aider à travailler).
Personnellement je n'ai jamais compris comment on pouvait utiliser Windows pour travailler
[…]
il faut se taper 50 000 sites webs pour télécharger des trucs qui peuvent aider à travailler
Git Bash
MSYS2 (avec pacman)
Chocolatey ou winget
PowerShell
…
NodeJS, Python, Ruby, GCC (mingw), Clang, CMake, vcpkg, Rust, Go, et bien d'autres langages/toolchains tournent sous windows très bien.
Tout les IDE les plus populaires tournent aussi sous Windows pour au final aucune différence de comportement.
Après bien sûr, pour comprendre il faut d'abord faire un peu de recherche ou voir même essayer. Mais c'est plus facile de suivre la tradition de "bouh windows c'est nul pour dev"
…Sur le poste windows fourni par ma boite (censé être une machine de développeur), je ne peux rien installer de tout ça, sauf en mode "portable". On pourrait dire que c'est pas de la faute à windows mais de la faute aux gestionnaires de poste de travail, sauf que les gestionnaires de poste de travail font ainsi car pendant des années, Windows n'a pas d'équivalent de repo centralisé comme ceux des distributions Linux. Du coup, pour être utilisable il faut installer plein de trucs qu'on trouve à droite à gauche sans forcément être sur de ce que l'on installe. Si j'etais admin windows, je restreindrais aussi la possibilité d'installer n'importe quoi sur une machine windows. A l'opposé, les distributions Linux intègrent une majorité d'outils, que l'on peut centraliser sur un repo dédié, à partir duquel on peut installer pas mal d'outils de façon relativement sûre. Là ou les admins doivent faire un travail de sélection d'outils "surs" issus de plein de sources différentes pour Windows, et gérer les mises à jour, on trouve des distributins Linux qui font ça pour l'utilisateur. Mettre à disposition tous ces paquets via une copie d'un repo officiel d'une distribution, ou via un proxy est si simple que s'en priver serait une grosse erreur.
Il me semble que ce n'est pas un repository de binaires et / où sources de logiciel, mais juste un index centralisé des liens de téléchargement de chaque logiciel.
En plus du lien, il y a un script PowerShell pour "automatiser" les cliques des installateurs fournis upstream.
Si je ne me trompe pas, la situation ne s'améliore pas, car tu continues à devoir télécharger sur chaque site le binaire, mais en plus tu dois faire confiance aux scripts PowerShell de la communauté chocolatey.
Il me semble que ce n'est pas un repository de binaires et / où sources de logiciel, mais juste un index centralisé des liens de téléchargement de chaque logiciel.
Pour l'utilisateur final, cela ne change rien, c'est juste un détail d'implémentation. Et ce n'est valable que pour chocolatey, msys2 lui repose sur pacman (de archlinux).
Si je ne me trompe pas, la situation ne s'améliore pas
Ben si justement, on a maintenant des outils pour optimiser l'installation de logiciel alors qu'avant non. En quoi cela ne serait pas une amélioration de la situation ?
tu dois faire confiance aux scripts PowerShell de la communauté chocolatey.
Sous n'importe quel système de gestion de paquet (npm, pip, cargo, apt, pacman, …) tu dois faire confiance aux mainteneurs du dépôt ou du paquet.
Si c'est un argument contre Windows, c'est aussi un argument contre Linux.
Avec Debian, par exemple, tu mets ta confiance uniquement dans les mainteneurs et pour moi c'est une très grande différence: le mainteneur fournit la recette pour compiler les sources et installer le binaire généré.
Il maitrise donc vraiment ce qui se passe et peut éviter, par exemple, que le binaire d'installation ajoute des logiciels tiers indésirables (télémétrie, adware, extensions de navigateurs…).
Par exemple, si tu utilises Chocolatey pour installer VS Code, alors tu auras toute la télémétrie Microsoft installée avec.
Avec Debian, la charte impose la distribution de logiciel redistribuable et donc, si un paquet VS Code existait, il serait produit avec la version open source "codium" et donc sans la télémétrie propriétaire de Microsoft ni leur marché d'extension (car inaccessible pour les binaires non fournis par Microsoft).
Avec Debian, par exemple, tu mets ta confiance uniquement dans les mainteneurs
Il y a beaucoup trop de mainteneurs pour que l'argument tienne. Et c'est en plus faux, tu mets ta confiance dans :
le développeur upstream
le mainteneur du paquet
les mainteneurs du dépôt
Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :
le développeur upstream
le mainteneur du paquet
les mainteneurs de l'index
Et, au risque de me répéter, c'est strictement la même chose pour tout les gestionnaires paquets existant. Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.
De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.
Avec Debian, la charte impose la distribution de logiciel redistribuable et donc, si un paquet VS Code existait, il serait produit avec la version open source "codium" et donc sans la télémétrie propriétaire de Microsoft ni leur marché d'extension (car inaccessible pour les binaires non fournis par Microsoft).
Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?
Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :
Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.
Et l'exemple de VS Code montre justement que c'est un problème: l'upstream crée uniquement des binaires privateurs qui ajoutent des outils indésirables sur un logiciel pourtant opensource.
Chocolatey n'a aucune maitrise sur les binaires produits par Microsoft.
Alors que Debian, avec sa charte signée par tous les mainteneurs, ne fournira que ce qui est disponible en opensource. C'est pourquoi ils doivent compiler eux-mêmes les binaires pour VS Code.
Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.
De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.
C'est pour cette raison que je ne parlais uniquement des dépôts Debian et de ce que fournis Debian de base.
S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.
Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.
Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?
C'est un index de liens, il n'y a pas de code source hebergé et de binaires générés par Chocolatey.
Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.
Tu crois que les mainteneurs ont le temps de review le code des 25.000 logiciels qui sont livrés dans les dépôt officiels ? Certainement pas, donc tu fais confiance au code source upstream dans tout les cas, que le binaire soit build par l'upstream ou par le système de build de Debian, cela ne change pas grand chose à ou tu place ta confiance.
S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.
Dans la pratique, ce qui est fait c'est soit fournir un .deb pré-compilé, soit carrément un dépôt à ajouter au sources.list.
J'ai donné l'exemple de NodeJS et MongoDB qui font ça, et ce sont loin d'être les seuls.
Ils ne sont pas tenu de respecter la charte de Debian.
Quelle différence entre télécharger un binaire upstream, et un .deb/repo apt upstream ?
Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.
Libre à toi d'utiliser MSYS2 avec Pacman qui dispose donc de cette infrastructure.
Tu crois que les mainteneurs ont le temps de review le code des 25.000 logiciels qui sont livrés dans les dépôt officiels ?
Ils ont des outils qui permettent de vérifier leurs sources ou binaire et de détecter plein de choses. Des qu'une faille est repérée, (par eux, ou par quelqu'un d'autre), ils mettent à jour leur code, rebuildent, et mettent à dispo de leurs utilisateurs une nouvelle version. Si t'es dans une entreprise, tu mets a jour ton mirroir et tu as un paquet corrigé. Côté Windows, je ne sais pas comment c'est géré par les produits que tu cites, mais ça n'a rien à voir avec un gestionnaire de paquets et tous le processus mis en place par les distrib.
Côté Windows, je ne sais pas comment c'est géré par les produits que tu cites, mais ça n'a rien à voir avec un gestionnaire de paquets et tous le processus mis en place par les distrib.
Sur le poste windows fourni par ma boite (censé être une machine de développeur), je ne peux rien installer de tout ça
En 10 ans de carrière, j'ai jamais rencontré une seule entreprise qui t'empêchait d'installer tes outils de devs sur ta machine de dev.
Je suppose que tu entends « ta machine de dev » comme une machine perso…? Parce-que je rencontre encore, au bout de près d’un quart de siècle en entreprises, beaucoup de boîtes qui ne laissent pas installer ce qu’on veut et ont des « masters » et une liste blanche de programmes installables sur les postes (de dev ou pas).
Je répète :
Ça n’en fait pas pour autant la vérité absolue : ce ne sont pas des solutions intégrées et les usagers des postes en question ne peuvent pas les installer.
En te lisant, j’ai l’impression que toutes les sociétés où je suis passé, dont la moitié sont au CAC40, ne sont que des exceptions. Pourtant, en échangeant avec d’autres personnes dans d’autres entreprises où l’on gère un parc W, je n’ai pas l’impression que les exceptions ne soient qu’à mon niveau. Ai-je loupé quelque chose ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je suppose que tu entends « ta machine de dev » comme une machine perso…?
Fourni par l'employeur mais oui.
Ça n’en fait pas pour autant la vérité absolue : ce ne sont pas des solutions intégrées
Le propos était "il n'existe pas de gestionnaire de paquet sous Windows", c'est juste faux que cela soit intégré ou non.
Preuve en est, sous Linux, on peut avoir en parallèle plusieurs gestionnaires de paquets: apt, flatpak, snap, …
En te lisant, j’ai l’impression que toutes les sociétés où je suis passé, dont la moitié sont au CAC40, ne sont que des exceptions.
C'est qu'une impression alors, j'ai bien précisé "mon expérience", a aucun moment j'ai sous-entendu que j'étais passé par les millions d'entreprises existante.
Quand bien même, si l'entreprise m'embauche pour faire du développement Python et qu'elle m'interdit d'installer Python, ou pip. Il y a un problème. En théorie, l'ordinateur qui t'es fournit devrait avoir tout le nécessaire pour accomplir le boulot, pas besoin d'aller installer 40.000 paquets différents qui n'ont rien à voir avec ton travail. Si il manque un outil essentiel, la-dite entreprise est censé fournir un processus (faisant intervenir des humains surement) pour intégrer l'outil au catalogue autorisé.
Dans une précédente entreprise, on avait l'autonomie sur l'ordinateur, il y avait juste PulseSecure (VPN) d'installé pour te faire passer par leur proxy, et dépôt Maven/PyPI géré par la-dite société (pas question d'utiliser les dépôts publique).
Pas besoin de passer par des millions d’entreprises… (je suis actuellement dans la troisième entreprise où j’ai l’autonomie sur l’ordinateur que j’utilise, donc je sais que cela existe mais cela me semble l’exception en vingt-quatre ans et quelque.)
Dans les cas que j’ai connu, l’entreprise qui t’embauche pour faire du développement Python te fournira un poste où ce sera déjà installé, et des gens sachant ce dont tu as besoin auront décidé par exemple que tu as le choix entre vscodium et notepad++ …Si alors t'estime que t’as besoin de pycharm, il te faudra faire un ticket qui sera fermé en t'indiquant d’utiliser ce qui est fourni et non ce que tu estimes essentiel.
PS : il y a quinze ans environ, j'avais des scripts pour automatiser l’installation des programmes sur mon poste W et que quelques autres. Est-ce à dire qu’il existait un gestionnaire de paquets ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Le propos était "il n'existe pas de gestionnaire de paquet sous Windows", c'est juste faux que cela soit intégré ou non.
Je comprendsq alors pourquoi tes arguments sont à côté, tu n'as pas compris le proiblème (mais je n'aiu peut-être pas été clair).
pourtant j'ai parlé de repository de la distrib, géré par la distrib … Et je ne parle pas seulement de distribution communautaire, j'avais entre autre en tête RedHat quand je parlais de ça.
Mais bon, pour info, le poste windows que j'ai aujourd'hui est un poste pro fourni par mon entreprise et je ne peux rien installer dessus. J'ai travaillé dans au moins une grosse banque récemment, et chez un des gros opérateurs télécom en France, je ne peux pas installer ce que je veux sur un poste windows. Par contre dans ces boites, il y a des repo (feu) centos, ubuntu et/ou redhat contenant les paquets dque l'on trouve sur toute distrib et qui permet de développer, la maintenance de ces paquets étant déléguée au fournisseur de distribution.
Pour windows à ma connaissance il n'y a pas de repo officiel fourni par microsoft, contenant tout ce qu'une distribution linux permet de faire. Pour installer un Python avec un minimum de maintenance , je dois passer par un fournisseur externe, style activestate. Et je dois prendre un fournisseur différent pour chaque brique de dev dont j'ai besoin … Alors peut-être que les outils que tu as cité facilitent (un peu) les choses, mais ça n'a rien à voir en terme d'utilisation et de maintenance avec un outil tel que e gestionnaire de paquet et les repo de la distrib.
J'ai l'impression que tu ne sais pas de quoi tu parles quand il s'agit de repo géré par la distribution.
Posté par totof2000 .
Évalué à 2.
Dernière modification le 29 décembre 2022 à 11:27.
Je te donne mon impression - et je l'ai bien indiqué, que ça te plaise ou non n'a aucune espece d'importance pour moi, et je continuerai à te dire ce que je pense en te lisant, toi ou n'importe qui d'ailleurs. Tes états d'ames à la réception ne m'importent pas. Celà dit ce n'est qu'une impression, je peux me tromper, et rien ne t'oblige à réagir de la sorte.
Non, c'est une attaque personnelle qui n'a rien à faire dans un débat sain.
que ça te plaise ou non n'a aucune espece d'importance pour moi, et je continuerai à te dire ce que je pense en te lisant, toi ou n'importe qui d'ailleurs.
Ce qui prouve que tu n'es pas la pour débattre sainement, et donc argumenter avec toi est une perte de temps pure et simple.
Tes états d'ames à la réception ne m'importent pas.
Il ne s'agit pas de mes états d'âmes, mais de toi qui fait un jugement de valeur sur mes compétences et mon expérience basée sur 3 pauvres commentaires. Tu ne me connais pas, je te connais pas, laissons l'individu en dehors du débat et faisons parler uniquement les arguments et les faits.
rien ne t'oblige à réagir de la sorte.
Rien ne t'oblige a faire une attaque personnelle dans un débat.
"Je n'ai plus d'argument donc je vais dire que tu y connais rien pour te décrédibiliser". C'est ce que tu as fait en gros. Et moi je dis non à ce genre "d'argumentation" fallacieuse.
Tu le prends comme tu veuux. mais je vais aarrêter là, parce que sinon tu sauras ce que c'est qu'une attaque personnelle, et tu comprendras la différence.
Ce qui prouve que tu n'es pas la pour débattre sainement, et donc argumenter avec toi est une perte de temps pure et simple.
L'art et la maniere de retourner la situation … au vu de tes autres réactions ça ne me surprend pas. Si tu es trop suceptible pour ne pas comprendre juste parce que j'ai l'impression que tu n'as pas compris quelque chose, c'est ton problème pas le mien. Il n'y a rien de mal à ne pas comprendre ce n'est pas une tare.
Il ne s'agit pas de mes états d'âmes, mais de toi qui fait un jugement de valeur sur mes compétences et mon expérience basée sur 3 pauvres commentaires.
Je te donne mon impression du moment, ce que je comprends à te lire. je ne t'ai pas dit un truc du genre "pauvre con, tu ne comprends rien", mais là vu ta réaction, c'est ce que j'ai envie de te dire.
Pas d'attaque personnelle, juste mon impression, un doute que tu peux lever sans réagir aussi vivement. Apres … l'écrit te donne peut etre l'impression que c'est une attaque personnelle, mais c'en est pas une.
"Je n'ai plus d'argument donc je vais dire que tu y connais rien pour te décrédibiliser". C'est ce que tu as fait en gros. Et moi je dis non à ce genre "d'argumentation" fallacieuse.
C'est ton interprétation, elle t'appartient. Ce n'est pas le sens de mes propos initiaux. Cela dit vu comment dans les autres fils tu détourne le sens de ce que disent tes interlocuteurs, je ne suis plus surpris de ta réaction.
Si je n'avais plus d'argument, j'aurais cessé de répondre tout simplement. Je vais arrêter là de toute façon, ça ne sert à rien de continuer. Je continue de penser que tu n'as pas pleinement compris le système de paquets d'une distribution, le rôle des mainteneurs, et d'autre choses (même si techniquement tu as compris ce que ça fait). Mais je n'irai pas plus loin, c'est inutile.
L'analogie est assez incorrecte vu que Linux n'est qu'un noyau et debian un OS.
Je dirais que MSYS2 ou chocolatey sont à windows ce que pkgsrc ou les gestionnaires de paquets guix ou nix sont à des distributions linux comme debian.
Pour le cas de chocolatey on peut dire que c'est bien qu'il existe, mais l'expérience utilisateur est assez affreuse en faite comparé à des gestionnaires de paquets comme pacman utilisé par MSYS2.
c'est aussi ce que je pense. A l'époque ou je faisais du solaris, il me semble que Sun mettait à disposition des binaires libres compilés pour leur OS. Il y avait aussi des trucs qui étaient faits pour AIX par IBM il me semble, ou par Bull. Microsoft ne fait rien de ça (a moins qu'ils le fassent maintenant sur leur app store ?). Je pense que si ils le faisaient, on pourrait facilement avoir un poste windows utilisable pour le dev : les admins auraient je pense moins de gène à accepter l'installation d'un soft venant de chez Microsoft que de chez un éditeur/packageur tiers qu'ils ne connaissent pas (avec comme idée en tête "on bloque les downloads de sourceforge ou de clubic, c'est pas pour les autoriser via un outil issu de je ne sais ou" ).
Effectivement, c'est une meilleure analogie, merci.
Le point que je voulais avancer c'était que le fait qu'un système soit indépendant de l'OS n'enlève rien à sa qualité.
Et on est aussi d'accord, chocolatey face à un MSYS2 ne fait pas le poids d'un point de vue expérience utilisateur.
Dans tout les cas, aujourd'hui sous Windows, l'époque des "je vais chercher mes logiciels sur 50.000 sites différents" est révolue, tu as soit :
l'autorisation par ton entreprise d'utiliser chocolatey/MSYS2
un dépôt central fournit par ton entreprise qui contient les logiciels autorisés (donc un seul site à consulter)
une machine fournie par ton entreprise avec les logiciels autorisés pré-installés
une entreprise qu'il faut que tu quittes
Je pars du principe que si tu as une machine Windows personnelle chez toi, tu es libre de faire ce que tu veux dessus.
Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
Posté par Psychofox (Mastodon) .
Évalué à 4.
Dernière modification le 30 décembre 2022 à 11:47.
Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
Dans les faits avec la mode des installations à base de curl | bash et allez chercher ma dernière release sur github, c'est le cas quelque soit l'OS.
Exemple tout con, les outils pour kubernetes. Bien que le projet soit libre, le fait que kubectl supporte les versions de kubernetes n-1 à n+1 et que le projet kubernetes sort environ 4 nouvelles versions par an rend difficile le suivi pour une distro ayant un cycle de sortie de 6 mois ou plus. Résumé la majorité des distros ne proposent pas les kubectl/kubeadm dans les repos principaux, ou alors dans une version particulière ou via un type de packaging différent (snap chez ubuntu) car il est compliqué de maintenir x versions différentes à la fois. Supposément des distros comme nix résoudraient ce problème mais dans les faits ce n'est pas le cas car les mainteneurs downstream ne suivent pas forcément le rythme.
Du coup dès qu'on gère de la prod on se retrouve généralement à installer les binaires kubectl à la main, des containers ou à utiliser des projets de gestions de version comme asdf pour avoir les versions de kubectl qui convient au cluster utilisé.
Idem pour tous les languages de programmation ou fleurissent les gestionnaires de versions pour maintenir n versions à la fois dans son homedir comme nvm pour le monde javascript, sdk pour le monde apache/java, rvm pour ruby, les gestionnaires d'environnemnets et de versions de python etc etc.
La gestion des paquets et la maintenance downstream fonctionne assez bien pour l'utilisateur final, mais quelque soit l'OS, un developpeur va toujours installer des trucs à la main, utiliser des projets de gestions d'environnements/versions et/ou des containers pour gérer plus finement et de manière plus agile ses environnement des développement. Sous linux il n'y a peut-être que les devs C/C++ qui se contentent de ce qui est fourni par une distro linux.
Ma remarque initiale n'était pas qu'on ne peut pas developper sous windows, mais que si on termine par avoir un kernel linux qui tourne dans des VMs et qu'on finit par n'installer que des outils dispos sous linux, faire tourner ça sous windows n'ajoute qu'un overhead et des complexités inutiles, un environnement de bureau hostile (je n'ai pas testé le 11, mais l'ergonomie, la gestion du clavier et des fenêtres sous windows jusqu'à 10 est proprement horrible), une gestion des fin de lignes/retour chariot différent selon les outils utilisé, des possibles pertes de performances dues aux outils déployés par les IT Exemple tout bête le windows 10 fournit par ma boite contient un outil vpn cisco qui fait sauter toutes les connections de WSL, des VMs et impose de passer une commande powershell en admin à chaque occurence pour changer la priorité des interfaces et retrouver le réseau sur celles-ci…ce qui arrive à minima à chaque fois que je déconnecte/connecte le laptop au dock usb-c si j'ai un câble ethernet branché à celui-ci. Du coup de plus en plus de gens, dont je fais partie n'utilisent plus le windows et bootent directement sous linux car à quoi bon garder la couche windows si elle ne sert que comme socle d'hyperviseur pour un environnement linux?
Haha! Le meilleur exemple qui soit. go get ou wget / curl|bash.
Sans parler de helm ou kustomize pour déployer des trucs ad-hoc sans réelle gestion de dépendance (et non, argocd/fluxcd ne résolvent pas le problème).
J'ai rédigé un draft de spec pour développer un gestionnaire de paquet avec dépôt centralisé basé sur kapp (de la team carvel), mais par manque de temps et de motivation, je m'y suis jamais attaqué.
le projet [xxx] sort environ 4 nouvelles versions par an rend difficile le suivi pour une distro ayant un cycle de sortie de 6 mois ou plus.
Le cycle de sortie de la distro ne signifie pas qu'il n'y a pas de mises à jours entre temps… Si le suivi est difficile c'est souvent pour d'autres raisons (par exemple, pas de samever, chose que tu pointes indirectement)
P.S. Bienvenue dans l'univers merveilleux où W et les outils de l'IT cassent les c…ll.s mais tout le monde va te répéter ici que ça marche très bien cet environnement de bureau.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Idem. À l'époque où j'ai arrêté d'utiliser widows, il y a avait surtout ce problème de devoir télécharger moult outils de sources plus ou moins douteuses pour au final se retrouver rapidement avec une machine inutilisable. Pas vraiment la faute de mirosoft, mais celle de l'utilisateur et d'un éco-système déficient dès avant la conception. Ensuite j'ai compris que les bonnes sources étaient libres. Alors pourquoi s'embêter avec un OS fermé qui réclame pléthore de protections quand en quelques clics on peut directement avoir accès au valhalla (tous le nécessaire empaqueté par la distribution de son choix) ?
Depuis, si j'ai bien compris, windos a bien empiré. Apparemment le menu démarrer serait devenu par défaut un panneau publicitaire clignotant géant, l'OS aurait été rempli de traceurs et de fuites volontaires — de mon temps on incriminait uniquement des failles. Comme de plus tout citoyen avec un minimum de conscience politique s’interdirait l'usage d'un tel système…
Du coup, non que ce soit infaisable ou même difficile mais parce qu'à la fois immoral et dénué d'intérêt autre que l'attitude du mouton de Panurge, je ne comprend vraiment pas comment quiconque peut affirmer sans honte utiliser widows.
Posté par sebas .
Évalué à 8.
Dernière modification le 28 décembre 2022 à 10:05.
Mais pour ça il faut au minimum suivre le lien proposé avant de sauter sotement sur la fonction commentaires pour y dégueuler sa haine.
Qu'est-ce qui ne va pas chez toi ? Ta femme t'a quitté ? Ta banque a saisi ta bagnole ? Vous vous êtes mis sur la gueule entre cousins autour de la bûche aux marrons ? Où as-tu vu de la haine de ma part ??? Alors que j'attribue en toutes lettres et par deux fois la motivation du gars à de l'humour.
De plus, j'ai suivi non seulement le lien proposé, mais également le lien cité dans le lien proposé, duquel j'extrais d'ailleurs des données citées dans mon commentaire. Il faut au minimum lire les commentaires "avant de sauter sottement sur la fonction commentaires pour y dégueuler sa haine".
C'est littéralement écris en gros sur la bannière en tête du titre: 2022 Developer Survey.
Ça n'est écrit ni dans le lien, ni dans le titre de l'article. Effectivement il y a un gros logo "Develelpper Survey, mais bon, un titre d'article, c'est fait pour quoi, alors ?
Je cite les deux premières phrase :
Thanks to the 2022 StackOverflow developer survey we can finally say 2022 was the year of Linux on the Desktop!
Linux as a primary operating system had been steadily climbing for the past 5 years. 2018 through 2021 saw steady growth with 23.2% , 25.6% , 26.6% , 25.3% , and finally in 2022 the usage was 40.23%. Linux usage was more than macOS in 2021, but only by a small margin. 2022 it is now 9% more than macOS.
Grâce au sondage chez les devs, on sait que Linux est utilisé à 40% (aucun terme de phrase ne limite la portée de cette affirmation).
Désolé, mais l'article dit clairement par trois fois (et sans compter le lien lui-même) que linux est adopté massivement. Point.
Posté par Zenitram (site web personnel) .
Évalué à 3.
Dernière modification le 27 décembre 2022 à 13:39.
Je ne vois pas bien en quoi ce serait de l'humour.
Me considérer comme "desktop Linux" parce que je lance un terminal WSL mais sinon suit dans l'écosystème Windows pour tout le reste, je ne vois pas bien en quoi ça ne serait pas de l'humour.
Beaucoup de DEV commençant avec Windows se rendent compte des perfs deplorables de git sous NTFS, du bricolage qu'est le WSL et de l'impact des politiques de l'IT sur les perfs de leur pc sous windows et switchent rapidement sous Linux.
Tient, encore de l'humour.
Du coup oui il y a pas mal de devs en entreprise qui utilisent linux par défaut.
Tient, encore de l'humour.
Mais bizarre comme humour.
J'ai jeté un œil sur les nombres, je n'y comprend rien, en plus d'être limité aux répondants SO (donc très loin d'être représentatif, cf l'image juste au dessus quo est bien démonstration de la réalité), la somme pour "principal" est largement supérieur à 100%, j'ai du mal à comprendre combien en vrai on Linux en principal même permis les répondants SO, si quelqu'un peut éclairer ma lanterne… aux dernières nouvelles pour le monde entier comme indiqué dans la généralisation c'est 2-5% (source plus credible).
Tu veux que je te sorte les bench entre docker sur mon laptop pro sous linux en bare-metal versus sur WSL2 ou docker dekstop avec le win10 géré par l'IT de ma boite?
Hey rien que MS Teams plante régulièrement en réunion chez les ceux qui utilisent windows.
Du coup oui il y a pas mal de devs en entreprise qui utilisent linux par défaut.
Tient, encore de l'humour.
Mais bizarre comme humour.
Depuis ta petite PME tu crois savoir mieux ce qui se passe dans des centaines de multinationales que ceux qui y travaillent?
Posté par xcomcmdr .
Évalué à 1.
Dernière modification le 27 décembre 2022 à 17:04.
Beaucoup de DEV commençant avec Windows se rendent compte des perfs deplorables de git sous NTFS,
10 ans que j'utilise git, les perfs n'ont rien à voir avec le FS…
Git est rapide quel que soit le FS. Il n'est pas dépendant du FS.
Faudrait se mettre à la page ?
du bricolage qu'est le WSL
WSL2 c'est un vrai kernel Linux, et fonctionne très bien. Il est utilisé par défaut depuis des années.
Faudrait se mettre à la page ?
Quel intérêt?
Quand tu veux utiliser Linux sans VM (chiant) et sans multiboot (encore plus chiant). Mais faut être dév pour comprendre que Visual Studio sous Linux est un doux rêve.
et de l'impact des politiques de l'IT sur les perfs de leur pc sous windows et switchent rapidement sous Linux
Rien à voir avec Windows. Les politiques IT peuvent tout niquer quel que soit l'OS.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Depuis quand le WSL et Docker compte comme usage "desktop" ? A ce rythme la, faut aussi compter Android, les VMs, certains grille-pains ou frigo, etc…
Non ça n'a rien à voir. Sémantiquement c'est correct. Si ton linux tourne sur le pc que tu pose sur ton bureau (admettons que beaucoup de laptops ont maintenant l'usage desktop)…ben il tourne dessus quoi, au même titre que toute autre appli.
Remarque que la phrase n'est pas Linux as the desktop OS.
Le terme "Linux Desktop" ca veut dire "Un système d'exploitation basé sur Linux pour une utilisation bureautique". Le terme bureautique a aussi une signification particulière, et "je l'ai posé sur un bureau en bois" n'est pas la définition.
Mon ordinateur est posé sur une petite table en bois et pas un bureau, du coup je suis pas inclus dans les chiffres ?
Une VM, un conteneur Docker, le WSL, ce n'est pas de la bureautique, je vois pas comment cela peut être sujet à débat.
Remarque que la phrase n'est pas Linux as the desktop OS.
Merci, mais ta mauvaise foi tu peux te la garder.
Ou alors dans ce cas laisse moi surenchérir, Mac OS est un système FOSS car je peux installer GIMP dessus ?
Le terme "Linux Desktop" ca veut dire "Un système d'exploitation basé sur Linux pour une utilisation bureautique". Le terme bureautique a aussi une signification particulière, et "je l'ai posé sur un bureau en bois" n'est pas la définition.
Justement on ne parle pas de Linux Desktop (Bureau Linux) mais de Linux on the desktop (Linux sur le bureau).
Une VM, un conteneur Docker, le WSL, ce n'est pas de la bureautique, je vois pas comment cela peut être sujet à débat.
Ce qu'on entend par desktop en anglais ne se traduit pas directement par la bureautique. Par exemple quand on parles des desktop environnements, on ne parle pas des suites type "office".
Et ici on parle de contexte de developpeur, ça n'a rien à voir avec de la bureautique, vu qu'un développeur fait pas ou très peu de bureautique. Le bureau, c'est son environnement de travail, de developpement. Et oui les VM, les containers, le WSL ce sont des outils du bureau de developpement. Donc ça a du sens de dire que Linux fait partie des outils de bureau de developpements chez de nombreux DEVs, y compris utilisant Mac ou Windows. À minima ceux utilisants les systèmes de containerisation linux.
Ou alors dans ce cas laisse moi surenchérir, Mac OS est un système FOSS car je peux installer GIMP dessus ?
Ben non sémantiquement ça ne marche pas.
Si le sujet ce sont les logiciels libres, oui ceux tournant sur des systèmes propriétaires comme MacOS ne deviennent pas moins libres.
Tu tortilles les phrases et les mots pour leur donner des sens qui n'existent pas et après tu prétends que c'est moi qui soit de mauvaise foi.
# Euh, oui, mais non
Posté par sebas . Évalué à 3.
Depuis quand ? J'ai toujours cru que son usage était plus près des 5% que des 40%.
Du coup, je vais voir l'article original dans Stack Overflow, et je vois que c'est basé sur un sondage annuel de Stack Overflow (et donc majoritairement des développeurs, j'imagine), et sur un panel de 71,503 responses.
Bref, j'imagine que c'est de l'humour.
Mais bon, il y a une réelle progression de linux dans cette population au cours des ans (ou alors plus de linuxiens qui répondent au sondage annuel ?)
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 26 décembre 2022 à 23:53.
Il prend aussi en compte l'usage des VMs linux de manière indirecte via WSL2, docker desktop (et outils similaires). Voilà comment il aboutit aux 40%.
[^] # Re: Euh, oui, mais non
Posté par tisaac (Mastodon) . Évalué à 4.
En tout cas, c'est ainsi que je le prends sans que cela rende totalement inintéressant d'observer la progression de Linux dans cette catégorie de personnes.
Je ne pense pas. De ce que je comprends c'est 40% + ceux qui l'utilisent de manière indirecte.
Le rapportde stackoverflow.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 27 décembre 2022 à 11:14.
Je ne vois pas bien en quoi ce serait de l'humour. Au niveau des équipes de developpement c'est aussi une tendance que j'ai pu observer ces 10 dernières années. De plus en plus de boites te laissent le choix du materiel ou de l'OS, c'est même souvent vendu comme un des avantages proposés dans les offres d'emplois. Je vois souvent les product managers qui touchent peu ou pas du tout de code sous Mac et Windows, les devs en général bien plus répartis entre mac, windows et linux. Beaucoup de DEV commençant avec Windows se rendent compte des perfs deplorables de git sous NTFS, du bricolage qu'est le WSL et de l'impact des politiques de l'IT sur les perfs de leur pc sous windows et switchent rapidement sous Linux.
De toute manière avec office 365 t'as accès maintenant à tout Office sous linux via le web, les IDE stars que sont vscode et ceux basés sous jetbrains tournet dessus et tous les autres outils de developpements sont soit basés web, soit sous conteneurs natif linux soit sous cli. Certe tu peux presque tout faire tourner sous WSL…mais avec la surcharge d'avoir deux OS et deux noyaux qui tournent sous la même machine. Quel intérêt? Du coup oui il y a pas mal de devs en entreprise qui utilisent linux par défaut.
[^] # Re: Euh, oui, mais non
Posté par sebas . Évalué à 8.
Ça n'en serait pas si le titre avait été Amongst the devs, 2022 was the year of Linux on the Desktop
Tel quel, ou c'est un titre putaclic, ou c'est une référence à ce qui est devenu une vieille blague du type de la sortie de Hurd stable. Je préfère croire que la deuxième interprétation est la bonne.
Et je suis bien d'accord que de toute façon, la tendance est intéressante, un doublement des linux chez les devs et autres pro de l'informatique en quelques années n'est pas insignifiant (bon, pour faire une analyse sérieuse, il faudrait aller comparer les différents panels ayant servi de base pour chaque année).
Allez, j'ai résisté lors du premier message à mettre l'image conventionnelle, pas lors du second :-)
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 3.
Personnellement je n'ai jamais compris comment on pouvait utiliser Windows pour travailler (hors bureautique bien sûr et peut être pour développer sous Windows). Windows c'est bien pour jouer, mais pour travailler, notamment sur de l'infra, c'est loin d'être la panacée, du moins, sans l'installation d'un tas d'outils tiers qui ne sont pas fournis avec la distribution (il faut se taper 50 000 sites webs pour télécharger des trucs qui peuvent aider à travailler).
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 1.
NodeJS, Python, Ruby, GCC (mingw), Clang, CMake, vcpkg, Rust, Go, et bien d'autres langages/toolchains tournent sous windows très bien.
Tout les IDE les plus populaires tournent aussi sous Windows pour au final aucune différence de comportement.
Après bien sûr, pour comprendre il faut d'abord faire un peu de recherche ou voir même essayer. Mais c'est plus facile de suivre la tradition de "bouh windows c'est nul pour dev"
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 2.
…Sur le poste windows fourni par ma boite (censé être une machine de développeur), je ne peux rien installer de tout ça, sauf en mode "portable". On pourrait dire que c'est pas de la faute à windows mais de la faute aux gestionnaires de poste de travail, sauf que les gestionnaires de poste de travail font ainsi car pendant des années, Windows n'a pas d'équivalent de repo centralisé comme ceux des distributions Linux. Du coup, pour être utilisable il faut installer plein de trucs qu'on trouve à droite à gauche sans forcément être sur de ce que l'on installe. Si j'etais admin windows, je restreindrais aussi la possibilité d'installer n'importe quoi sur une machine windows. A l'opposé, les distributions Linux intègrent une majorité d'outils, que l'on peut centraliser sur un repo dédié, à partir duquel on peut installer pas mal d'outils de façon relativement sûre. Là ou les admins doivent faire un travail de sélection d'outils "surs" issus de plein de sources différentes pour Windows, et gérer les mises à jour, on trouve des distributins Linux qui font ça pour l'utilisateur. Mettre à disposition tous ces paquets via une copie d'un repo officiel d'une distribution, ou via un proxy est si simple que s'en priver serait une grosse erreur.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 4.
En 10 ans de carrière, j'ai jamais rencontré une seule entreprise qui t'empêchait d'installer tes outils de devs sur ta machine de dev.
Je répète :
cf point précédent.
En fait, le reste de ton commentaire: cf point précédent. Tout ce que tu dis était vrai, il y a 10 ans. Ce n'est plus le cas.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Il me semble que ce n'est pas un repository de binaires et / où sources de logiciel, mais juste un index centralisé des liens de téléchargement de chaque logiciel.
En plus du lien, il y a un script PowerShell pour "automatiser" les cliques des installateurs fournis upstream.
Si je ne me trompe pas, la situation ne s'améliore pas, car tu continues à devoir télécharger sur chaque site le binaire, mais en plus tu dois faire confiance aux scripts PowerShell de la communauté chocolatey.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 4. Dernière modification le 28 décembre 2022 à 13:48.
Pour l'utilisateur final, cela ne change rien, c'est juste un détail d'implémentation. Et ce n'est valable que pour chocolatey, msys2 lui repose sur pacman (de archlinux).
Ben si justement, on a maintenant des outils pour optimiser l'installation de logiciel alors qu'avant non. En quoi cela ne serait pas une amélioration de la situation ?
Sous n'importe quel système de gestion de paquet (npm, pip, cargo, apt, pacman, …) tu dois faire confiance aux mainteneurs du dépôt ou du paquet.
Si c'est un argument contre Windows, c'est aussi un argument contre Linux.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Avec Debian, par exemple, tu mets ta confiance uniquement dans les mainteneurs et pour moi c'est une très grande différence: le mainteneur fournit la recette pour compiler les sources et installer le binaire généré.
Il maitrise donc vraiment ce qui se passe et peut éviter, par exemple, que le binaire d'installation ajoute des logiciels tiers indésirables (télémétrie, adware, extensions de navigateurs…).
Par exemple, si tu utilises Chocolatey pour installer VS Code, alors tu auras toute la télémétrie Microsoft installée avec.
Avec Debian, la charte impose la distribution de logiciel redistribuable et donc, si un paquet VS Code existait, il serait produit avec la version open source "codium" et donc sans la télémétrie propriétaire de Microsoft ni leur marché d'extension (car inaccessible pour les binaires non fournis par Microsoft).
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
Il y a beaucoup trop de mainteneurs pour que l'argument tienne. Et c'est en plus faux, tu mets ta confiance dans :
Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :
Et, au risque de me répéter, c'est strictement la même chose pour tout les gestionnaires paquets existant. Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.
De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.
Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?
Cela existe déjà en plus : https://community.chocolatey.org/packages/vscodium
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.
Et l'exemple de VS Code montre justement que c'est un problème: l'upstream crée uniquement des binaires privateurs qui ajoutent des outils indésirables sur un logiciel pourtant opensource.
Chocolatey n'a aucune maitrise sur les binaires produits par Microsoft.
Alors que Debian, avec sa charte signée par tous les mainteneurs, ne fournira que ce qui est disponible en opensource. C'est pourquoi ils doivent compiler eux-mêmes les binaires pour VS Code.
C'est pour cette raison que je ne parlais uniquement des dépôts Debian et de ce que fournis Debian de base.
S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.
Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.
C'est un index de liens, il n'y a pas de code source hebergé et de binaires générés par Chocolatey.
Mais c'est le projet vscodium qui fourni les binaires et non pas Chocolatey, n'est-ce pas ? Si oui, le problème est toujours là.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
Tu crois que les mainteneurs ont le temps de review le code des 25.000 logiciels qui sont livrés dans les dépôt officiels ? Certainement pas, donc tu fais confiance au code source upstream dans tout les cas, que le binaire soit build par l'upstream ou par le système de build de Debian, cela ne change pas grand chose à ou tu place ta confiance.
Dans la pratique, ce qui est fait c'est soit fournir un .deb pré-compilé, soit carrément un dépôt à ajouter au sources.list.
J'ai donné l'exemple de NodeJS et MongoDB qui font ça, et ce sont loin d'être les seuls.
Ils ne sont pas tenu de respecter la charte de Debian.
Quelle différence entre télécharger un binaire upstream, et un .deb/repo apt upstream ?
Libre à toi d'utiliser MSYS2 avec Pacman qui dispose donc de cette infrastructure.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 2.
Ils ont des outils qui permettent de vérifier leurs sources ou binaire et de détecter plein de choses. Des qu'une faille est repérée, (par eux, ou par quelqu'un d'autre), ils mettent à jour leur code, rebuildent, et mettent à dispo de leurs utilisateurs une nouvelle version. Si t'es dans une entreprise, tu mets a jour ton mirroir et tu as un paquet corrigé. Côté Windows, je ne sais pas comment c'est géré par les produits que tu cites, mais ça n'a rien à voir avec un gestionnaire de paquets et tous le processus mis en place par les distrib.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
MSYS2 c'est littéralement pacman…
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 2.
Ok, merci pour l'info et les liens, je regarderai. J'ai au moins appris quelque chose, merci.
[^] # Re: Euh, oui, mais non
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Je suppose que tu entends « ta machine de dev » comme une machine perso…? Parce-que je rencontre encore, au bout de près d’un quart de siècle en entreprises, beaucoup de boîtes qui ne laissent pas installer ce qu’on veut et ont des « masters » et une liste blanche de programmes installables sur les postes (de dev ou pas).
Ça n’en fait pas pour autant la vérité absolue : ce ne sont pas des solutions intégrées et les usagers des postes en question ne peuvent pas les installer.
En te lisant, j’ai l’impression que toutes les sociétés où je suis passé, dont la moitié sont au CAC40, ne sont que des exceptions. Pourtant, en échangeant avec d’autres personnes dans d’autres entreprises où l’on gère un parc W, je n’ai pas l’impression que les exceptions ne soient qu’à mon niveau. Ai-je loupé quelque chose ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 1.
Fourni par l'employeur mais oui.
Le propos était "il n'existe pas de gestionnaire de paquet sous Windows", c'est juste faux que cela soit intégré ou non.
Preuve en est, sous Linux, on peut avoir en parallèle plusieurs gestionnaires de paquets: apt, flatpak, snap, …
C'est qu'une impression alors, j'ai bien précisé "mon expérience", a aucun moment j'ai sous-entendu que j'étais passé par les millions d'entreprises existante.
Quand bien même, si l'entreprise m'embauche pour faire du développement Python et qu'elle m'interdit d'installer Python, ou pip. Il y a un problème. En théorie, l'ordinateur qui t'es fournit devrait avoir tout le nécessaire pour accomplir le boulot, pas besoin d'aller installer 40.000 paquets différents qui n'ont rien à voir avec ton travail. Si il manque un outil essentiel, la-dite entreprise est censé fournir un processus (faisant intervenir des humains surement) pour intégrer l'outil au catalogue autorisé.
Dans une précédente entreprise, on avait l'autonomie sur l'ordinateur, il y avait juste PulseSecure (VPN) d'installé pour te faire passer par leur proxy, et dépôt Maven/PyPI géré par la-dite société (pas question d'utiliser les dépôts publique).
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Pas besoin de passer par des millions d’entreprises… (je suis actuellement dans la troisième entreprise où j’ai l’autonomie sur l’ordinateur que j’utilise, donc je sais que cela existe mais cela me semble l’exception en vingt-quatre ans et quelque.)
Dans les cas que j’ai connu, l’entreprise qui t’embauche pour faire du développement Python te fournira un poste où ce sera déjà installé, et des gens sachant ce dont tu as besoin auront décidé par exemple que tu as le choix entre vscodium et notepad++ …Si alors t'estime que t’as besoin de pycharm, il te faudra faire un ticket qui sera fermé en t'indiquant d’utiliser ce qui est fourni et non ce que tu estimes essentiel.
PS : il y a quinze ans environ, j'avais des scripts pour automatiser l’installation des programmes sur mon poste W et que quelques autres. Est-ce à dire qu’il existait un gestionnaire de paquets ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 1.
Je comprendsq alors pourquoi tes arguments sont à côté, tu n'as pas compris le proiblème (mais je n'aiu peut-être pas été clair).
pourtant j'ai parlé de repository de la distrib, géré par la distrib … Et je ne parle pas seulement de distribution communautaire, j'avais entre autre en tête RedHat quand je parlais de ça.
Mais bon, pour info, le poste windows que j'ai aujourd'hui est un poste pro fourni par mon entreprise et je ne peux rien installer dessus. J'ai travaillé dans au moins une grosse banque récemment, et chez un des gros opérateurs télécom en France, je ne peux pas installer ce que je veux sur un poste windows. Par contre dans ces boites, il y a des repo (feu) centos, ubuntu et/ou redhat contenant les paquets dque l'on trouve sur toute distrib et qui permet de développer, la maintenance de ces paquets étant déléguée au fournisseur de distribution.
Pour windows à ma connaissance il n'y a pas de repo officiel fourni par microsoft, contenant tout ce qu'une distribution linux permet de faire. Pour installer un Python avec un minimum de maintenance , je dois passer par un fournisseur externe, style activestate. Et je dois prendre un fournisseur différent pour chaque brique de dev dont j'ai besoin … Alors peut-être que les outils que tu as cité facilitent (un peu) les choses, mais ça n'a rien à voir en terme d'utilisation et de maintenance avec un outil tel que e gestionnaire de paquet et les repo de la distrib.
J'ai l'impression que tu ne sais pas de quoi tu parles quand il s'agit de repo géré par la distribution.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à -2.
Ce genre de commentaire à la con tu te les mets ou je pense.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 2. Dernière modification le 29 décembre 2022 à 11:27.
Je te donne mon impression - et je l'ai bien indiqué, que ça te plaise ou non n'a aucune espece d'importance pour moi, et je continuerai à te dire ce que je pense en te lisant, toi ou n'importe qui d'ailleurs. Tes états d'ames à la réception ne m'importent pas. Celà dit ce n'est qu'une impression, je peux me tromper, et rien ne t'oblige à réagir de la sorte.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
Non, c'est une attaque personnelle qui n'a rien à faire dans un débat sain.
Ce qui prouve que tu n'es pas la pour débattre sainement, et donc argumenter avec toi est une perte de temps pure et simple.
Il ne s'agit pas de mes états d'âmes, mais de toi qui fait un jugement de valeur sur mes compétences et mon expérience basée sur 3 pauvres commentaires. Tu ne me connais pas, je te connais pas, laissons l'individu en dehors du débat et faisons parler uniquement les arguments et les faits.
Rien ne t'oblige a faire une attaque personnelle dans un débat.
"Je n'ai plus d'argument donc je vais dire que tu y connais rien pour te décrédibiliser". C'est ce que tu as fait en gros. Et moi je dis non à ce genre "d'argumentation" fallacieuse.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 2.
L'art et la maniere de retourner la situation … au vu de tes autres réactions ça ne me surprend pas. Si tu es trop suceptible pour ne pas comprendre juste parce que j'ai l'impression que tu n'as pas compris quelque chose, c'est ton problème pas le mien. Il n'y a rien de mal à ne pas comprendre ce n'est pas une tare.
Je te donne mon impression du moment, ce que je comprends à te lire. je ne t'ai pas dit un truc du genre "pauvre con, tu ne comprends rien", mais là vu ta réaction, c'est ce que j'ai envie de te dire.
Pas d'attaque personnelle, juste mon impression, un doute que tu peux lever sans réagir aussi vivement. Apres … l'écrit te donne peut etre l'impression que c'est une attaque personnelle, mais c'en est pas une.
C'est ton interprétation, elle t'appartient. Ce n'est pas le sens de mes propos initiaux. Cela dit vu comment dans les autres fils tu détourne le sens de ce que disent tes interlocuteurs, je ne suis plus surpris de ta réaction.
Si je n'avais plus d'argument, j'aurais cessé de répondre tout simplement. Je vais arrêter là de toute façon, ça ne sert à rien de continuer. Je continue de penser que tu n'as pas pleinement compris le système de paquets d'une distribution, le rôle des mainteneurs, et d'autre choses (même si techniquement tu as compris ce que ça fait). Mais je n'irai pas plus loin, c'est inutile.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 0.
Debian est à Linux ce que MSYS2 ou chocolatey est à Windows.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 6.
L'analogie est assez incorrecte vu que Linux n'est qu'un noyau et debian un OS.
Je dirais que MSYS2 ou chocolatey sont à windows ce que pkgsrc ou les gestionnaires de paquets guix ou nix sont à des distributions linux comme debian.
Pour le cas de chocolatey on peut dire que c'est bien qu'il existe, mais l'expérience utilisateur est assez affreuse en faite comparé à des gestionnaires de paquets comme pacman utilisé par MSYS2.
[^] # Re: Euh, oui, mais non
Posté par totof2000 . Évalué à 3.
c'est aussi ce que je pense. A l'époque ou je faisais du solaris, il me semble que Sun mettait à disposition des binaires libres compilés pour leur OS. Il y avait aussi des trucs qui étaient faits pour AIX par IBM il me semble, ou par Bull. Microsoft ne fait rien de ça (a moins qu'ils le fassent maintenant sur leur app store ?). Je pense que si ils le faisaient, on pourrait facilement avoir un poste windows utilisable pour le dev : les admins auraient je pense moins de gène à accepter l'installation d'un soft venant de chez Microsoft que de chez un éditeur/packageur tiers qu'ils ne connaissent pas (avec comme idée en tête "on bloque les downloads de sourceforge ou de clubic, c'est pas pour les autoriser via un outil issu de je ne sais ou" ).
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
Effectivement, c'est une meilleure analogie, merci.
Le point que je voulais avancer c'était que le fait qu'un système soit indépendant de l'OS n'enlève rien à sa qualité.
Et on est aussi d'accord, chocolatey face à un MSYS2 ne fait pas le poids d'un point de vue expérience utilisateur.
Dans tout les cas, aujourd'hui sous Windows, l'époque des "je vais chercher mes logiciels sur 50.000 sites différents" est révolue, tu as soit :
Je pars du principe que si tu as une machine Windows personnelle chez toi, tu es libre de faire ce que tu veux dessus.
Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 30 décembre 2022 à 11:47.
Dans les faits avec la mode des installations à base de curl | bash et allez chercher ma dernière release sur github, c'est le cas quelque soit l'OS.
Exemple tout con, les outils pour kubernetes. Bien que le projet soit libre, le fait que kubectl supporte les versions de kubernetes n-1 à n+1 et que le projet kubernetes sort environ 4 nouvelles versions par an rend difficile le suivi pour une distro ayant un cycle de sortie de 6 mois ou plus. Résumé la majorité des distros ne proposent pas les kubectl/kubeadm dans les repos principaux, ou alors dans une version particulière ou via un type de packaging différent (snap chez ubuntu) car il est compliqué de maintenir x versions différentes à la fois. Supposément des distros comme nix résoudraient ce problème mais dans les faits ce n'est pas le cas car les mainteneurs downstream ne suivent pas forcément le rythme.
Du coup dès qu'on gère de la prod on se retrouve généralement à installer les binaires kubectl à la main, des containers ou à utiliser des projets de gestions de version comme asdf pour avoir les versions de kubectl qui convient au cluster utilisé.
Idem pour tous les languages de programmation ou fleurissent les gestionnaires de versions pour maintenir n versions à la fois dans son homedir comme nvm pour le monde javascript, sdk pour le monde apache/java, rvm pour ruby, les gestionnaires d'environnemnets et de versions de python etc etc.
La gestion des paquets et la maintenance downstream fonctionne assez bien pour l'utilisateur final, mais quelque soit l'OS, un developpeur va toujours installer des trucs à la main, utiliser des projets de gestions d'environnements/versions et/ou des containers pour gérer plus finement et de manière plus agile ses environnement des développement. Sous linux il n'y a peut-être que les devs C/C++ qui se contentent de ce qui est fourni par une distro linux.
Ma remarque initiale n'était pas qu'on ne peut pas developper sous windows, mais que si on termine par avoir un kernel linux qui tourne dans des VMs et qu'on finit par n'installer que des outils dispos sous linux, faire tourner ça sous windows n'ajoute qu'un overhead et des complexités inutiles, un environnement de bureau hostile (je n'ai pas testé le 11, mais l'ergonomie, la gestion du clavier et des fenêtres sous windows jusqu'à 10 est proprement horrible), une gestion des fin de lignes/retour chariot différent selon les outils utilisé, des possibles pertes de performances dues aux outils déployés par les IT Exemple tout bête le windows 10 fournit par ma boite contient un outil vpn cisco qui fait sauter toutes les connections de WSL, des VMs et impose de passer une commande powershell en admin à chaque occurence pour changer la priorité des interfaces et retrouver le réseau sur celles-ci…ce qui arrive à minima à chaque fois que je déconnecte/connecte le laptop au dock usb-c si j'ai un câble ethernet branché à celui-ci. Du coup de plus en plus de gens, dont je fais partie n'utilisent plus le windows et bootent directement sous linux car à quoi bon garder la couche windows si elle ne sert que comme socle d'hyperviseur pour un environnement linux?
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . Évalué à 3.
Haha! Le meilleur exemple qui soit.
go getouwget/curl|bash.Sans parler de helm ou kustomize pour déployer des trucs ad-hoc sans réelle gestion de dépendance (et non, argocd/fluxcd ne résolvent pas le problème).
J'ai rédigé un draft de spec pour développer un gestionnaire de paquet avec dépôt centralisé basé sur kapp (de la team carvel), mais par manque de temps et de motivation, je m'y suis jamais attaqué.
https://link-society.com - https://kubirds.com
[^] # Re: Euh, oui, mais non
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Attention
Le cycle de sortie de la distro ne signifie pas qu'il n'y a pas de mises à jours entre temps… Si le suivi est difficile c'est souvent pour d'autres raisons (par exemple, pas de samever, chose que tu pointes indirectement)
P.S. Bienvenue dans l'univers merveilleux où W et les outils de l'IT cassent les c…ll.s mais tout le monde va te répéter ici que ça marche très bien cet environnement de bureau.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 3.
En l'occurence kubernetes utilise le semantic versionning. Ça ne change rien au problème.
[^] # Re: Euh, oui, mais non
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Idem. À l'époque où j'ai arrêté d'utiliser widows, il y a avait surtout ce problème de devoir télécharger moult outils de sources plus ou moins douteuses pour au final se retrouver rapidement avec une machine inutilisable. Pas vraiment la faute de mirosoft, mais celle de l'utilisateur et d'un éco-système déficient dès avant la conception. Ensuite j'ai compris que les bonnes sources étaient libres. Alors pourquoi s'embêter avec un OS fermé qui réclame pléthore de protections quand en quelques clics on peut directement avoir accès au valhalla (tous le nécessaire empaqueté par la distribution de son choix) ?
Depuis, si j'ai bien compris, windos a bien empiré. Apparemment le menu démarrer serait devenu par défaut un panneau publicitaire clignotant géant, l'OS aurait été rempli de traceurs et de fuites volontaires — de mon temps on incriminait uniquement des failles. Comme de plus tout citoyen avec un minimum de conscience politique s’interdirait l'usage d'un tel système…
Du coup, non que ce soit infaisable ou même difficile mais parce qu'à la fois immoral et dénué d'intérêt autre que l'attitude du mouton de Panurge, je ne comprend vraiment pas comment quiconque peut affirmer sans honte utiliser widows.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à -3.
C'est littéralement écris en gros sur la bannière en tête du titre: 2022 Developer Survey.
Mais pour ça il faut au minimum suivre le lien proposé avant de sauter sotement sur la fonction commentaires pour y dégueuler sa haine.
[^] # Re: Mauvaise digestion ?
Posté par sebas . Évalué à 8. Dernière modification le 28 décembre 2022 à 10:05.
Qu'est-ce qui ne va pas chez toi ? Ta femme t'a quitté ? Ta banque a saisi ta bagnole ? Vous vous êtes mis sur la gueule entre cousins autour de la bûche aux marrons ? Où as-tu vu de la haine de ma part ??? Alors que j'attribue en toutes lettres et par deux fois la motivation du gars à de l'humour.
De plus, j'ai suivi non seulement le lien proposé, mais également le lien cité dans le lien proposé, duquel j'extrais d'ailleurs des données citées dans mon commentaire. Il faut au minimum lire les commentaires "avant de sauter sottement sur la fonction commentaires pour y dégueuler sa haine".
Ça n'est écrit ni dans le lien, ni dans le titre de l'article. Effectivement il y a un gros logo "Develelpper Survey, mais bon, un titre d'article, c'est fait pour quoi, alors ?
Je cite les deux premières phrase :
Grâce au sondage chez les devs, on sait que Linux est utilisé à 40% (aucun terme de phrase ne limite la portée de cette affirmation).
Désolé, mais l'article dit clairement par trois fois (et sans compter le lien lui-même) que linux est adopté massivement. Point.
[^] # Re: Euh, oui, mais non
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 27 décembre 2022 à 13:39.
Me considérer comme "desktop Linux" parce que je lance un terminal WSL mais sinon suit dans l'écosystème Windows pour tout le reste, je ne vois pas bien en quoi ça ne serait pas de l'humour.
Tient, encore de l'humour.
Tient, encore de l'humour.
Mais bizarre comme humour.
J'ai jeté un œil sur les nombres, je n'y comprend rien, en plus d'être limité aux répondants SO (donc très loin d'être représentatif, cf l'image juste au dessus quo est bien démonstration de la réalité), la somme pour "principal" est largement supérieur à 100%, j'ai du mal à comprendre combien en vrai on Linux en principal même permis les répondants SO, si quelqu'un peut éclairer ma lanterne… aux dernières nouvelles pour le monde entier comme indiqué dans la généralisation c'est 2-5% (source plus credible).
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . Évalué à 4.
Tu veux que je te sorte les bench entre docker sur mon laptop pro sous linux en bare-metal versus sur WSL2 ou docker dekstop avec le win10 géré par l'IT de ma boite?
Hey rien que MS Teams plante régulièrement en réunion chez les ceux qui utilisent windows.
Depuis ta petite PME tu crois savoir mieux ce qui se passe dans des centaines de multinationales que ceux qui y travaillent?
[^] # Re: Euh, oui, mais non
Posté par xcomcmdr . Évalué à 1. Dernière modification le 27 décembre 2022 à 17:04.
10 ans que j'utilise git, les perfs n'ont rien à voir avec le FS…
Git est rapide quel que soit le FS. Il n'est pas dépendant du FS.
Faudrait se mettre à la page ?
WSL2 c'est un vrai kernel Linux, et fonctionne très bien. Il est utilisé par défaut depuis des années.
Faudrait se mettre à la page ?
Quand tu veux utiliser Linux sans VM (chiant) et sans multiboot (encore plus chiant). Mais faut être dév pour comprendre que Visual Studio sous Linux est un doux rêve.
Rien à voir avec Windows. Les politiques IT peuvent tout niquer quel que soit l'OS.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Euh, oui, mais non
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Un peu quand même.
# Hahaha
Posté par David Delassus (site web personnel) . Évalué à 6. Dernière modification le 27 décembre 2022 à 16:35.
Ou:
Depuis quand le WSL et Docker compte comme usage "desktop" ? A ce rythme la, faut aussi compter Android, les VMs, certains grille-pains ou frigo, etc…
"C'est l'année du bureau Linux, regarde, c'est utilisé partout sauf sur le bureau."
Merci de la tranche de rire et bonnes fêtes de fin d'année ! :)
https://link-society.com - https://kubirds.com
[^] # Re: Hahaha
Posté par Psychofox (Mastodon) . Évalué à 1.
Non ça n'a rien à voir. Sémantiquement c'est correct. Si ton linux tourne sur le pc que tu pose sur ton bureau (admettons que beaucoup de laptops ont maintenant l'usage desktop)…ben il tourne dessus quoi, au même titre que toute autre appli.
Remarque que la phrase n'est pas Linux as the desktop OS.
[^] # Re: Hahaha
Posté par David Delassus (site web personnel) . Évalué à -1. Dernière modification le 28 décembre 2022 à 10:21.
Le terme "Linux Desktop" ca veut dire "Un système d'exploitation basé sur Linux pour une utilisation bureautique". Le terme bureautique a aussi une signification particulière, et "je l'ai posé sur un bureau en bois" n'est pas la définition.
Mon ordinateur est posé sur une petite table en bois et pas un bureau, du coup je suis pas inclus dans les chiffres ?
Une VM, un conteneur Docker, le WSL, ce n'est pas de la bureautique, je vois pas comment cela peut être sujet à débat.
Merci, mais ta mauvaise foi tu peux te la garder.
Ou alors dans ce cas laisse moi surenchérir, Mac OS est un système FOSS car je peux installer GIMP dessus ?
https://link-society.com - https://kubirds.com
[^] # Re: Hahaha
Posté par Psychofox (Mastodon) . Évalué à 2.
Justement on ne parle pas de Linux Desktop (Bureau Linux) mais de Linux on the desktop (Linux sur le bureau).
Ce qu'on entend par desktop en anglais ne se traduit pas directement par la bureautique. Par exemple quand on parles des desktop environnements, on ne parle pas des suites type "office".
Et ici on parle de contexte de developpeur, ça n'a rien à voir avec de la bureautique, vu qu'un développeur fait pas ou très peu de bureautique. Le bureau, c'est son environnement de travail, de developpement. Et oui les VM, les containers, le WSL ce sont des outils du bureau de developpement. Donc ça a du sens de dire que Linux fait partie des outils de bureau de developpements chez de nombreux DEVs, y compris utilisant Mac ou Windows. À minima ceux utilisants les systèmes de containerisation linux.
Ben non sémantiquement ça ne marche pas.
Si le sujet ce sont les logiciels libres, oui ceux tournant sur des systèmes propriétaires comme MacOS ne deviennent pas moins libres.
Tu tortilles les phrases et les mots pour leur donner des sens qui n'existent pas et après tu prétends que c'est moi qui soit de mauvaise foi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.