Flock Selon Statcounter, la part de Linux dans les ordinateurs de bureau a atteint près de 4 % (3,82 %) en décembre 2023 sur StatCounter.com, relève GamingOnLinux.com.
La proportion du mois dernier représenterait « un record et une tendance claire au fil du temps », la part de Linux ayant franchi le cap de 1 % en 2013 puis celui de 1,5 % à partir de 2015, mais restant en deçà des 2 % de 2015 à début 2021.
Un taux qui n'a cela dit de cesse de progresser depuis la fin de 2022 et le franchissement de la barre des 3 % en juin 2023.
Des chiffres à prendre avec précaution : le taux d'OS Windows serait en effet étrangement passé de 69 à près de 73 % en décembre 2023, celui des Mac OS X de 21 à un peu plus de 16 %, et la part des Chrome OS de près de 4 à moins de 3 % dans le même temps.
Commentaires (59)
#1
#1.1
#1.2
#1.5
#1.6
#1.3
#1.4
Bon, ça risque d'être long par contre
#2
Ouaip chelou en effet une telle variation mensuelle!
Ceci dit, cela donne une idée ou tendance (à quel point juste ?) de la question que je posais dans le cadre de l’article sur Zorin OS : tant d’efforts pour combien d’utilisateurs.
#2.1
#2.2
#2.3
#2.4
Si Apple dans les années 90 était la marque d'ordinateurs préférée des créatifs (musique, video, presse, image), il faut bien reconnaître qu'Apple a envoyé une partie de ce monde se faire voire pendant les années 2000 et surtout 2010 ... Apple se veux imprévisible et capable de changements radicaux sur son offre sans prévenir et sans vision moyen terme pour ses utilisateurs, soit, mais ça a pour effet de régulièrement faire partir des utilisateurs.
Mention spéciale pour le "Mac Vador/Pro" qui a du jour au lendemain dit aux professionnels où ils pouvaient s'insérer leurs cartes PCIe ...
#2.5
De manière générale, Others est un mirroir quasi parfait de Windows
Historique des modifications :
Posté le 11/04/2024 à 11h19
Vu la gueule générale des courbes, c'est plutôt toute la période janvier 2023 à décembre 2023 qui est anormale. Une partie de la chute de Windows est passée dans Others mais a vite été corrigée, et le reste s'est retrouvé dans un plateau coté OSX avant d'être corrigée en décembre 2023.
De manière générale, Others est un mirroir quasi parfait de Windows
#3
#4
#4.1
#4.2
#5
En tout cas même si on lisse les courbes, il y a du progrès pour OS X et Linux et une baisse pour Windows. Possible que les délires de TPM et autres pour win11 n'y soient pas étrangers: Perso mon PC principal est un barebone de 10 ans et il fait encore le job, je comprends tout à fait que les gens cherchent des alternatives pour éviter de changer ce qui marche: En période très inflationniste, la volonté historique de Microsoft de pousser à changer de machines a de quoi gripper. Tant mieux.
#5.1
Sous Linux, l'empreinte est moins marquée.
Exemple: les chiffres Asie: moins de 3% début d'année, plus de 5% fin d'année.
L'évolution des prochaines années de l'informatique, c'est l'émergence de nouveaux marchés, de nouveaux produits, et une fracture culturelle à mon avis. Que l'on verra aussi dans le hard, les nouveaux marchés accueillant à bras ouvert l'ARM, notre marché étant réticent et très pro x64 par conservatisme.
#6
#6.1
#6.2
#6.3
C'était un test de QI et tu l'as loupé.
#7
#7.1
#7.2
J'avais parfaitement conscience de ce que ChromeOS implique en terme de tracking/vie privé mais pour des gens sans le moindre bagage informatique, c'est simple et ça marche. Ca offre juste ce dont ils avaient besoin (un navigateur web sur grand écran) et perso, j'ai jamais eu plus de "support" à gérer à distance que d'expliquer comment faire un copié/collé ou imprimer un doc (ne pas rire).
Ils avaient déjà des comptes gmail donc pour eux cela a été transparent.
J'avais testé de leur donner un ancien PC portable avec un linux (configuré au plus léger / simple / avec accès distant pour dépanner) mais ça me demandait quand même plus de support.
Donc pour revenir à ta question "quel public": un public qui a juste besoin d'un navigateur web et qui ne veut pas avoir à gérer quoi que ce soit ! ;-)
#7.3
Sauf erreur de ma part, lorsque tu installes une distribution classique en 20-25 min, tu as un navigateur par défaut qui permet de faire la même chose que sous ChromeOS.
@IfYouPlease, le chromeOS cible le très grand public et surtout il bénificie énormément de visibilité.
#7.4
C'es ce que tu écris en dessous, chromeOS est hyper grand public... un coté "dumb" ou tu ne pas toucher (et donc casser) grand chose :-)
#7.5
Et Ubuntu reste une distribution très grand public. Depuis quelques temps, certains conseillerait Mint.
De mon point de vue, malheureusement on cole encore bien souvent Linux de système compliqué alors qu'il existe des distributions très grands publics pour un usage classique commun, et tout cela sans utiliser de ligne de commande.
#8
#9
Et l'image de l'actu ...
#10
#10.1
#10.2
Après j'installe encore syslog pour la compatibilité de certains outil de monitoring.
#10.4
J'ai vu trop d'horreurs dans les scripts init dans des solutions commerciales et des solutions développées en interne pour accepter l'argument que la flexibilité d'init est un avantage...
flexible, ça veut trop souvent dire: on implémente le start, le stop, pas le status, le restart ou le reload, on laisse les codes de retour pour plus tard ou on renvoie les mauvais codes, on n'utilise évidemment pas de pidfile pour détecter un service mort, et on ne fait pas une gestion correcte de l'environnement et tant pis si le script marche pas via sudo ... et encore ça c'est quand c'est un script... j'ai aussi eu le coup du binaire dans /etc/init.d/, dans /etc/rc.d/rc3.d ... et puis il reste le classique du script "init" top feignasse qui n'est qu'un one-liner invoquant le binaire dans /usr/bin
#10.5
J'utilise pour ma part Devuan, dérivé Debian dont la raison d'être est simplement l'éviction de l'infection systemd.
Si vous désirez Debian sans systemd, c'est Devuan qu'il vous faut !
Et si vous êtes curieux de rentrer en contact avec les barbus derrière la proposition, il y a tout un tas de canaux, d'IRC au courriel, avec bien sûr la possibilité de contribuer via Git.
Dommage que certaines grandes distributions, notamment Debian, ait oublié leur raison d'être en y basculant.
Par conception, ce machin fourrant ses dépendances partout, le remplacer devient progressivement impossible, à mesure que le temps passe.
Il reste quelques Mohicans barbus permettant de faire tourner des fork plus confidentiel, mais sans retour à la raison d'une distribution majeure, l'avenir est bien sombre pour un PID 1 respectable.
L'exercice permet au moins d'illustrer la réalité de l'hydre, le fort couplage de tout un tas de mécanismes tiers à un machin qui veut à la fois être l'hyperviseur principal et le gestionnaire d'à peu près tout (et surtout n'importe quoi). Le tout codé avec l'arrière-train.
#10.7
A ce niveau, ta position s'éloigne de la philosophie pour relèver du dogmatisme.
Surtout que systemd respecte le principe d'unix. Eh oui, ce n'est pas un truc qui fait tout, ce sont des dizaines et des dizaines de binaire, chacun avec un rôle bien défini.
A croire que systemd, c'est le diable
Je suis allé faire un tour sur la distribution Gentoo, où il y a une page qui trace les paquets dépendant explicitement de systemd. J'en compte 9 (si on met de côté les paquets qui fournissent une application ou une bibliothèque dont le but premier est d'interagir avec systemd). 9 sur 19042 au moment où j'écris ces lignes. Effectivement, c'est partout.
Il est remarque aussi de voir à quel point l'ensemble des mainteneurs des grandes distributions sont des imbéciles qui ne comprennent rien et vendent leur âme au diable, pour avoir tous fait le même choix. Ces "imbéciles" n'ont donc absolument pas compris l'intérêt d'utiliser systemd (pourtant nombreux) et ne le fond que parce qu'ils ont "perdu la raison". Il est vrai que des démarrages plus rapides, une meilleure gestion des dépendances au démarrage, l'augmentation de la sécurité en facilitant grandement l'usage des cgroups et compagnie, et un système presque homogène d'une distribution à l'autre, c'est de la gnognote.
Je propose de ne pas revenir plus profondément sur le débat systemd/pas systemd, car ce n'est pas vraiment le sujet du brief. Surtout que généralement, ce n'est que de la résistance au changement de la part de personnes qui ne font que gueuler sans vraiment contribuer...
Qui es-tu pour te permettre de juger ainsi la qualité du travail des autres, sans même être aller jeter un oeil à leur travaux ? Montre moi ton code et tes contributions. J'ai envie de rigoler un peu...
#10.6
J'ai du autoriser ssh et nginx à faire des bind sur des adresses que le noyau n'avais pas encore pour qu'ils démarrent correctement à l'allumage de mes VM.
Quel progrès en effet.
Et puis pour arrêter, il ne sera plus possible de faire shutdown now car il faut passer par systemctl.
Pourquoi garder la commande que tout le monde maitrisait bien? Autant tout péter sans raison.
#10.8
Pareil pour shutdown now, ça marche très bien sur mes vm's ...
C'est quoi comme distro?
J'utilise systemd au quotidien sans avoir de problèmes du genre.
Donc oui le progrès, c'est bien, mais avec les distributions gnu/linux en général, il vaut mieux que les mainteneurs de la distribution aient fait le boulot correctement.
#10.10
Sur une « fresh install », cela fonctionne mieux mais je ne considère pas comme normal le fait de devoir réinstaller mon système à chaque nouvelle version majeure.
Dernier gag en date avec fail2ban qui ne fonctionne plus sous debian sans avoir à mettre les mains dans le camboui.
Pour ceux qui migrent depuis la 11, fail2ban ne sais plus où trouver les informations car il n'y a plus les informations de sshd dans le journal /var/log/auth.log et il faut migrer le jail.conf pour utiliser systemctl donc systemd.
Pour ceux qui migrent vers la 12 et même ceux qui installent une version 12 toute fraiche, fail2ban cherche à utiliser iptable au lieu de nftable et il faut aller dans fail.conf modifier les lignes banaction. Là, il s'agit d'un problème de cohérence dans la distribution.
Pour ceux que cela intéresse, il s'agit de remplacer:
par:
Pour revenir à mon problème de base, systemd fait de mauvais travail en lançant en vrac tous les services là où init.d permettait d'attendre la résolution des dépendances.
Avec d'utilisation de SLAAC ou DHCPv6, le réseau n'est prêt que quand tous ces processus sont terminés. Quand systemd lance SSHD ou nginx avant que le réseau soit totalement démarré, ils plantent car les adresses configurées dans leurs fichiers de configurations ne sont pas encore attribués.
Pire, la résolution de nom ne fonctionne pas à ce moment donc il faut tout configurer dans les fichiers /etc/hosts des VM. Cela va à l'encontre de la centralisation de la configuration.
Pour permettre à mes machines de démarrer, j'ai dû ajouter une configuration magique :
Devoir bidouiller pour rendre le système fonctionnel alors que mes besoins sont banals, c'est tout sauf acceptable.
#10.12
et que le problème c'est systemd, nftable, ...
Je pense que tu en demandes trop à Debian...
Les mains dans le cambouis, ça fait partie du contrat. Si on aime pas comprendre le système et ses évolutions, on ne prend aps de risque et on fait une installation "clean"
#10.13
Et pour ton conseil sur une installation clean, je t'ai donné justement un exemple qui montre qu'une installation clean de debian 12 ne fonctionne pas bien: fail2ban.
Mettre les mains dans le cambouis est une chose naturelle, surtout dans mon cas avec une netinstall, mais devoir faire une enquête puis aller patcher les 4 coins du systèmes pour trouver pourquoi ce qui fonctionnait très bien bloque totalement n'est pas normal.
D'une manière générique, il est normal de faire évoluer les programmes et les distributions mais il faudrait être en mesure de lister aux utilisateurs les adaptations à réaliser suite aux évolutions plutôt que de les mettre dans l'embarras. Et ce n'est pas la liste des changements de versions de paquets qui permet de savoir quoi modifier et où.
#10.3
#10.9
#10.11
#11
#11.1
Ceci dit meme dans ce cas, le navigateur utilisé est plutot celui de l'os hote ?
Mais la même question peut se poser pour les OS virtualisés, et voir comment ils sont remontés par rapport au host.
#11.2
Je n'arrive pas à retrouver d'article mentionnant la finalisation mais le boulot avait commencé il y a quelques années : https://next.ink/5126/wslg-comment-utiliser-applications-linux-sous-windows-10-avec-interface-graphique-et-gpu/
Edit : en ouvrant les yeux ça va mieux → https://next.ink/6004/108989-build-2020-wsl-2-gerera-gpu-et-interfaces-linux-terminal-1-0-winget-en-preview/
Et non, c'est bien un navigateur propre à l'install wsl, totalement indépendant d'un quelconque navigateur installé sur le système hôte. Concernant la remontée des stats, si je ne m'abuse c'est basé sur l'user agent envoyé par ton navigateur, donc il ne devrait pas y avoir de différence entre un navigateur dans un système donné et le même dans le même système virtualisé.
#12
#13
#13.1
#13.2
#13.3
A l'inverse, je n'ai jamais considéré cette supposée finalité de part de marché pour le noyau Linux. Contrairement à certaines des distributions qui l'intègre, ce n'est pas un produit commercial à proprement parler donc la notion de PDM sur l'intégration Desktop n'a pas vraiment d'incidence dessus. Le noyau jouit d'une grand popularité et est devenu un standard de fait dans l'IT pour de nombreux cas d'usage.
Pour rester chez Microsoft, Azure repose énormément dessus, au même titre que plusieurs distributions sont développées en interne (CBL Mariner qui porte la couche containerisation d'Azure App Services et peut être aussi utilisée pour AKS à la place d'Ubuntu, CBL-Delrige qui est la distrib derrière Azure Cloud Shell, basée Debian, ou encore Azure Cloud Switch qui est une distrib orientée network développée par MS).
Je ne vois donc pas trop de quel "grand jour" tu parles qui est censé arriver, étant donné que pour moi, l'usage d'un système basé Linux est une réalité quotidienne que ce soit sur le plan personnel et professionnel depuis vingt ans. Et pour les Cloud Providers aussi.
#13.4
#13.5
#13.6
#13.7
Considère que tu as eu le dernier mot si cela te fait plaisir. Je n'ai plus de temps à perdre avec ton agressivité inutile.
#14
#14.1