En termes de parts de marché, MS Office est très largement dominant sur le marché.
Mon impression personnelle est que le numéro 2, c'est le couple OOo/LO, le reste est marginal sinon carrément négligeable.
Du coup je me demande bien qui sont ces concurrents très nombreux qui préfèrent optimiser l'interopérabilité avec OOXML plutôt que ODF, histoire de dormir moins con ce soir…
Déjà on commence par boucher les trous de sécurité, et c'est pas parce que la tâche est titanesque qu'il ne faut jamais la commencer.
Ensuite, on peut leur faire comprendre à quel point on est content de ça en interrompant immédiatement tout programme d'échange d'information jusqu'à ce que clarification soit faite de ce qu'ils accumulent et ce qu'ils en font.
On peut même exiger l'accès à leurs bases de données pour avoir une idée de l'étendue du désastre.
On peut commencer à interdire l'utilisation de matériel et logiciel d'origine anglo-saxonne ou simplement extra-européenne (hors R.U.) partout où c'est possible dans les administrations et en particulier les administrations qui gèrent des données sensibles.
On peut instaurer une loi qui veut que si un constructeur/développeur fournit en Europe un appareil dont on prouve qu'il est utilisé pour récupérer des données par des puissances étrangères: une bonne grosse amende, l'interdiction immédiate de vendre en Europe, plus une obligation de remboursement de tout citoyen qui voudrait se débarrasser du mouchard, au prix du neuf, ça va de soi.
La Chine a déjà carrément posé les pieds dans le plat, et (ironie du sort!) a fait preuve de moins d'hypocrisie que l'U.E. en demandant carrément les accès aux backdoors des appareils américain vendus en Chine.
Si on veut bouger, on peut faire plus que gueuler. Mais vu que jusqu'à maintenant on n'a rien vu d'autre que des indignations de quelques jours et beaucoup de résignation "c'est mal, mais on peut rien faire tu comprends?", je ne vois aucune raison pour les Américains et leurs potes Britanniques de réduire la voilure.
Ouai, moi je parierai qu'on ne trouve tout simplement pas 2 ordinateurs qui auraient exactement les mêmes signatures, même pris sur une même chaîne d'assemblage.
Tout ça doit prendre un certain réglage fin.
Cela dit, une fois que la technique est appliquée, il doit y avoir un moyen de faire de l'auto-étalonnage si le volume de données traitées est suffisamment grand.
Effectivement: aucune des personnes qui râle contre systemd ne paie le moindre centime aux dévs de udev pour qu'il maintienne une version systemd, nous sommes bien d'accord.
Figure toi que oui, ça a râlé quand Gtk a proposé de dépendre de certaines parties de Gnome.
Oui, et je me souviens que pragmatiquement, le projet Xfce aurait pu dépendre (dépend? je ne me souviens plus de l'issue) de certaines libs de Gnome, et la vie a continué.
Je ne me souviens pas en revanche d'avoir un journal par semaine et des flots d'insultes contre les dévs.
Mais ! Il ne dit pas ça ! Il dit que systemd ne remplacera pas l'init et les outils de base sur les HPC de son boulot avant longtemps.
Il fait quand même de gros sous-entendus, hein:
Mais c'est vrai que c'est pas grave hein c'est pas comme si c'etait important linux sur du HPC…
et dans le commentaire suivant, il parait que Zenitram ne comprend pas le problème, qui est:
Systemd est en train de devenir obligatoire
Alors soit il veut dire que systemd a un impact négatif sur la présence de Linux sur HPC, soit il balance des phrases hors contextes et hors sujet, et c'est sa santé mentale à lui qui m'inquiète.
Il est interdit de faire de grand changement dans l'univers Linux parce que les gens qui font du HPC n'aiment pas ça?
Quand ils sautent N versions de noyau, tu vas me dire qu'il n'y a que quelques changements mineurs à suivre?
Avec la phrase qui suit, j'en comprends que les admins qui gèrent ces HPC n'y sont pas favorables, probablement parce que le changement implique de faire confiance à une techno jeune qui leur est encore inconnue et qui nécessiterait un travail important d'apprentissage avant d'être prêt à se lancer en prod. Ce qui est plutôt compréhensible vu l'infrastructure et les conséquences potentielles d'une panne…
Ton explication est tout-à-fait légitime, mais je ne comprends pas la même chose, moi. Quand on me dit que le problème est que "systemd va devenir obligatoire", et "les HPC c'est important", je suppose que je dois lire un lien logique entre les 2.
Linux bouge mais les changements sont nettement moins radicaux qu'un passage à systemd. De plus avec le LTS, tu as tout le temps pour préparer ta migration, rester sur une version agée n'impacte que très peu le fonctionnement, surtout si le matériel n'évolue pas.
Vraiment? Ce sont eux qui le disent avec arguments à l'appui après avoir consciencieusement étudié systemd, ou c'est une affirmation gratuite?
Si Debian arrête de maintenir Debian/kFreeBSD parce qu'ils n'auront pas que ça à foutre, est-ce que ça va te faire dire que Linux est vraiment trop envahissant?
Les mainteneurs de ta distro font des choix. Je n'ai jamais lu personne hurler que GNU te force à utiliser un vaste panel d'outils GNU si envahissants que les mainteneurs de distros ne gardent pas des alternatives complètes à côté.
Dans quelques années, les nouveaux apprendront le "Linux de base" avec GNU et systemd, ce sera presque comme à nos débuts à tous: on n'a pas questionné l'obligation d'utiliser les outils GNU en arrivant, et ils ne comprendront pas tout ce vacarme.
Je n'ai rien contre systemd en particulier, mais je comprends que ça peut rendre certains nerveux: contrairement à GNOME, ou si tu n'es pas content tu ne peux pas aller voir vers KDE, il n'y a pas d'alternative complète.
Si on élimine la partie init de systemd (qui reste donc très gros, et de plus en plus gros même), et pour laquelle les alternatives existent, sinon ce débat n'aurai pas lieu, il me reste une question:
Quelles étaient les alternatives avant qui ont été abandonnées par leur développeurs à cause de systemd?
udev n'a pas été abandonné. Il n'est pas plus abandonné qu'un projet Gtk qui devient projet Gnome utilisant les bibliothèques Gnome, ou un projet Qt devenant projet KDE.
Donc si un projet Gtk devient un projet Gnome, ou si un projet Qt devient un projet KDE, on doit s'attendre à voir le même foin que pour udev dans systemd?
Les téléphone Android seront les plus vendus encore un bon petit moment.
Le temps que les autres sortent de l'ombre et MS sera fin prêt à leur tomber dessus à coups de brevets également.
Le protocole permet de faire tourner des serveurs hors fédération donc il est pourri?
Un bon protocole, c'est un protocole qui intègre des clauses interdisant de fermer son réseau? Ça c'est un problème de licence, pas de protocole. Excuse-moi de considérer que c'est totalement hors-sujet.
Quant aux XEP qui partent dans tous les sens, quelques messages plus haut, on reproche à XMPP de n'être "pas fini", et là, tu lui reproches d'en faire trop?
Pour moi au contraire, LE reproche qu'on devrait faire à XMPP, c'est la lenteur exaspérante de son procédé de standardisation, qui va toujours moins vite que le reste du monde (y'a qu'à voir la voix/vidéo, ou d'actualité, le microblogage).
Le fait de préciser «somme toute» montre bien qu'en fait, ce n'est pas vraiment le succès espéré. Ça reste une niche.
C'est un demi-échec qui a été utilisé par Google et qui est, à ma connaissance, toujours utilisé par Facebook.
On a vu pires, comme références.
Le "somme toute" tempère ces succès par le fait que Google l'a laché et que FB ne participe pas à la fédération.
Ça fait à peu près 15 ans que XMPP (ou son ancêtre Jabber) existe. S'il reste des choses à faire, c'est qu'à un moment donné, il y a quelque chose qui ne tourne pas rond.
On pourrait parler des moyens qui y sont consacrés par rapport à d'autres, de la lenteur du processus de standardisation, ou tout simplement se dire que Linux existe depuis plus longtemps et je n'ai pas l'impression qu'il ne reste rien à faire.
Il y a 15ans, la visioconf, c'était pas un requis, par exemple.
Est-on condamné à devoir utiliser XMPP parce que c'est libre ou alors est-ce qu'on peut inventer d'autres protocoles de 0 et qui seront tout aussi libre et qui ont des chances d'avoir plus de succès que XMPP ? Les défauts de XMPP sont connus et rien ne change pour les corriger, au contraire, on dirait presque des features maintenant. J'aurais été à leur place, j'aurais fait exactement pareil.
Sur un marché économique, on sait qu'une solution techniquement meilleure qui arrive un peu plus tard peut mourir simplement en raison de son retard sur le marché, pas de ses qualités techniques. Dans le Libre, ça peut simplement prendre plus de temps.
Encore une fois, je ne dis pas que Matrix est mal ou que c'est une mauvaise idée, je déplore qu'on invente un énième protocole.
Les défauts de XMPP sont connus et ce qu'on change pour les corriger c'est pondre un nouveau protocole qui aura lui aussi des défauts de jeunesse et qui aura besoin d'un bon bout de temps avant d'avoir un écosystème autour de lui.
Imaginons qu'ils aient voulu implémenter leur protocole par dessus XMPP. Déjà il faut se farcir toutes les XEP pour voir s'il y a des choses qu'on peut réutiliser. Ensuite, il faut écrire sa propre XEP. Ensuite, si on est sérieux, il faut l'implémenter et donc se farcir toutes les couches basses de XMPP. Quel gain là dedans ? Quasiment aucun.
J'ai du mal à croire que "se farcir toutes les XEP" soit plus long et compliqué que réécrire tout ce dont on a besoin de 0. Surtout qu'on parle ici d'un protocole qui pourrait utilisé des briques éprouvées plutôt que des nouvelles. Un bogue dans un protocole, ça me semble autrement plus chiant que dans une implémentation particulière.
Encore une fois: XMPP a ici l'avantage de son ancienneté.
De même, "se farcir toutes les couches basses de XMPP" est-il vraiment un chemin de plus grande résistance que d'inventer et implémenter de nouvelles couches basses?
Enfin, plus bas, il est écrit que Matrix est plutôt complémentaire que concurrent à XMPP, et que les 2 seront interopérables.
On verra bien, donc.
Aujourd'hui, XMPP est somme toute un succès. Malgré cette assertion, il reste encore beaucoup à faire: transformer l'essai sur les réseaux sociaux, convaincre les acteurs propriétaires d'ouvrir les communications entre serveurs, etc.
Bref, il reste encore beaucoup de boulot.
Là, on nous annonce un nouveau protocole qu'il va tout déchirer. Et je me dis que même s'il est vraiment bon, il n'arrive pas au bon moment: XMPP n'est pas encore assez obsolète pour qu'on lui cherche un remplaçant, et pas encore assez solide sur le marché pour ne pas souffrir de la concurrence d'un autre protocole ouvert dans l'écosystème du Libre.
Du coup quand je lis que Matrix fait des choses qu'il aurait été impossible de faire dans XMPP sans modif majeure, je me demande si les modifs auraient été plus majeures que:
Écrire un nouveau protocole depuis 0
Faire utiliser le protocole par une large audience afin qu'il ait une utilité quelconque.
Les protocoles, ce n'est pas comme les applis: 120 applis qui utilisent le même protocole contribuent plus ou moins dans la même direction.
Chaque nouveau protocole Libre réduit les chances d'adoption en masse d'un protocole Libre.
C'est vrai, quand tu fais une recherche sur systemd, les premiers résultats sont le plus souvent de longues déclarations haineuses qui mentionnent vaguement le problème rencontré et pas la solution, au milieu des complots et le reste.
À la fin, ton problème n'est pas résolu, mais au moins tu as appris que Lennart est un extra-terrestre envoyé par la planète GJtnghht pour détruire l'humanité, tout comme Bill Gates et Rebecca Black.
Je suis sûr que si c'était possible, d'autres râleraient en disant que systemd autorise à démarrer avec des partitions critiques pas disponibles sur une simple question.
[^] # Re: Assis / debout
Posté par Maclag . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 10.
Heureusement, une solution existe qui répond à toutes ces problématiques:
http://mistupid.com/pictures/page097.htm
(j'ai eu du mal à retrouver cette photo!)
# "La plupart des suites bureautiques concurrentes"
Posté par Maclag . En réponse au journal ODF a t-il définitivement perdu la guerre face à OOXML ?. Évalué à 5.
En termes de parts de marché, MS Office est très largement dominant sur le marché.
Mon impression personnelle est que le numéro 2, c'est le couple OOo/LO, le reste est marginal sinon carrément négligeable.
Du coup je me demande bien qui sont ces concurrents très nombreux qui préfèrent optimiser l'interopérabilité avec OOXML plutôt que ODF, histoire de dormir moins con ce soir…
# Aidons-les à trouver les mots-clés juste
Posté par Maclag . En réponse au journal Effacer le téléchargement d'Internet, Total Wipes a essayé. Évalué à 6.
Je propose:
"piracy"
pour éliminer les pirates
"illegal copy"
pour éliminer les copies illégales
"copying is stealing"
pour éliminer ceux qui le font!
si avec ça on est pas un peu plus tranquilles…
[^] # Re: Gemalto n'est pas la France
Posté par Maclag . En réponse au journal J'ai écrit à mon ministre des affaires étrangères. Évalué à 10.
Déjà on commence par boucher les trous de sécurité, et c'est pas parce que la tâche est titanesque qu'il ne faut jamais la commencer.
Ensuite, on peut leur faire comprendre à quel point on est content de ça en interrompant immédiatement tout programme d'échange d'information jusqu'à ce que clarification soit faite de ce qu'ils accumulent et ce qu'ils en font.
On peut même exiger l'accès à leurs bases de données pour avoir une idée de l'étendue du désastre.
On peut commencer à interdire l'utilisation de matériel et logiciel d'origine anglo-saxonne ou simplement extra-européenne (hors R.U.) partout où c'est possible dans les administrations et en particulier les administrations qui gèrent des données sensibles.
On peut instaurer une loi qui veut que si un constructeur/développeur fournit en Europe un appareil dont on prouve qu'il est utilisé pour récupérer des données par des puissances étrangères: une bonne grosse amende, l'interdiction immédiate de vendre en Europe, plus une obligation de remboursement de tout citoyen qui voudrait se débarrasser du mouchard, au prix du neuf, ça va de soi.
La Chine a déjà carrément posé les pieds dans le plat, et (ironie du sort!) a fait preuve de moins d'hypocrisie que l'U.E. en demandant carrément les accès aux backdoors des appareils américain vendus en Chine.
Si on veut bouger, on peut faire plus que gueuler. Mais vu que jusqu'à maintenant on n'a rien vu d'autre que des indignations de quelques jours et beaucoup de résignation "c'est mal, mais on peut rien faire tu comprends?", je ne vois aucune raison pour les Américains et leurs potes Britanniques de réduire la voilure.
[^] # Re: virus qui comuniquent sans réseau
Posté par Maclag . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 3.
Reste que ça me semble un peu juste pour envoyer des infos un petit peu lourde.
De toute façon les gens du réseau ont déjà mis un modem dans ton alim, alors inutile de fantasmer sur ton haut-parleur.
[^] # Re: vous reprendrez bien des chips
Posté par Maclag . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 7.
Maintenant qu'on a ton digicodes, est-ce que tu peux nous donner les quasiment toutes pareilles (ton) adresse?
---------> [ ]
[^] # Re: Les condensateurs vibrent....
Posté par Maclag . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 5.
Ouai, moi je parierai qu'on ne trouve tout simplement pas 2 ordinateurs qui auraient exactement les mêmes signatures, même pris sur une même chaîne d'assemblage.
Tout ça doit prendre un certain réglage fin.
Cela dit, une fois que la technique est appliquée, il doit y avoir un moyen de faire de l'auto-étalonnage si le volume de données traitées est suffisamment grand.
[^] # Re: guerre perdu d'avance
Posté par Maclag . En réponse à la dépêche Quand la cybernétique hiberne l'éthique. Évalué à 10.
On a de toute évidence déjà perdu la guerre de l'orthographe à l'école, le reste ne fait que suivre…
[^] # Re: j'adore
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5.
Ok, au temps pour moi, tu ne l'as pas dit.
Il n'y a donc absolument aucun souci avec systemd et le HPC sinon le logique temps de migration plus long que pour les systèmes de bureau ou autres.
Pourquoi avons-nous cet échange?
[^] # Re: Du bon et du mauvais
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 4.
Effectivement: aucune des personnes qui râle contre systemd ne paie le moindre centime aux dévs de udev pour qu'il maintienne une version systemd, nous sommes bien d'accord.
Oui, et je me souviens que pragmatiquement, le projet Xfce aurait pu dépendre (dépend? je ne me souviens plus de l'issue) de certaines libs de Gnome, et la vie a continué.
Je ne me souviens pas en revanche d'avoir un journal par semaine et des flots d'insultes contre les dévs.
[^] # Re: j'adore
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 1.
Il fait quand même de gros sous-entendus, hein:
et dans le commentaire suivant, il parait que Zenitram ne comprend pas le problème, qui est:
Alors soit il veut dire que systemd a un impact négatif sur la présence de Linux sur HPC, soit il balance des phrases hors contextes et hors sujet, et c'est sa santé mentale à lui qui m'inquiète.
Il est interdit de faire de grand changement dans l'univers Linux parce que les gens qui font du HPC n'aiment pas ça?
Quand ils sautent N versions de noyau, tu vas me dire qu'il n'y a que quelques changements mineurs à suivre?
Ton explication est tout-à-fait légitime, mais je ne comprends pas la même chose, moi. Quand on me dit que le problème est que "systemd va devenir obligatoire", et "les HPC c'est important", je suppose que je dois lire un lien logique entre les 2.
Vraiment? Ce sont eux qui le disent avec arguments à l'appui après avoir consciencieusement étudié systemd, ou c'est une affirmation gratuite?
[^] # Re: j'adore
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5.
Si Debian arrête de maintenir Debian/kFreeBSD parce qu'ils n'auront pas que ça à foutre, est-ce que ça va te faire dire que Linux est vraiment trop envahissant?
Les mainteneurs de ta distro font des choix. Je n'ai jamais lu personne hurler que GNU te force à utiliser un vaste panel d'outils GNU si envahissants que les mainteneurs de distros ne gardent pas des alternatives complètes à côté.
Dans quelques années, les nouveaux apprendront le "Linux de base" avec GNU et systemd, ce sera presque comme à nos débuts à tous: on n'a pas questionné l'obligation d'utiliser les outils GNU en arrivant, et ils ne comprendront pas tout ce vacarme.
[^] # Re: Du bon et du mauvais
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5.
Si on élimine la partie init de systemd (qui reste donc très gros, et de plus en plus gros même), et pour laquelle les alternatives existent, sinon ce débat n'aurai pas lieu, il me reste une question:
Quelles étaient les alternatives avant qui ont été abandonnées par leur développeurs à cause de systemd?
udev n'a pas été abandonné. Il n'est pas plus abandonné qu'un projet Gtk qui devient projet Gnome utilisant les bibliothèques Gnome, ou un projet Qt devenant projet KDE.
[^] # Re: Du bon et du mauvais
Posté par Maclag . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 6.
Donc si un projet Gtk devient un projet Gnome, ou si un projet Qt devient un projet KDE, on doit s'attendre à voir le même foin que pour udev dans systemd?
Au fait, qui paie les dévs de udev?
[^] # Re: Un peu trop tard ?
Posté par Maclag . En réponse au journal Microsoft utiliserait le chantage des brevets Android pour forcer Samsung à diffuser des spywares. Évalué à 4.
Non, ce n'est pas trop tard.
Les téléphone Android seront les plus vendus encore un bon petit moment.
Le temps que les autres sortent de l'ombre et MS sera fin prêt à leur tomber dessus à coups de brevets également.
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Maclag . En réponse au journal Pas seul dans la matrice. Évalué à 3.
Le protocole permet de faire tourner des serveurs hors fédération donc il est pourri?
Un bon protocole, c'est un protocole qui intègre des clauses interdisant de fermer son réseau? Ça c'est un problème de licence, pas de protocole. Excuse-moi de considérer que c'est totalement hors-sujet.
Quant aux XEP qui partent dans tous les sens, quelques messages plus haut, on reproche à XMPP de n'être "pas fini", et là, tu lui reproches d'en faire trop?
Pour moi au contraire, LE reproche qu'on devrait faire à XMPP, c'est la lenteur exaspérante de son procédé de standardisation, qui va toujours moins vite que le reste du monde (y'a qu'à voir la voix/vidéo, ou d'actualité, le microblogage).
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Maclag . En réponse au journal Pas seul dans la matrice. Évalué à 6.
C'est un demi-échec qui a été utilisé par Google et qui est, à ma connaissance, toujours utilisé par Facebook.
On a vu pires, comme références.
Le "somme toute" tempère ces succès par le fait que Google l'a laché et que FB ne participe pas à la fédération.
On pourrait parler des moyens qui y sont consacrés par rapport à d'autres, de la lenteur du processus de standardisation, ou tout simplement se dire que Linux existe depuis plus longtemps et je n'ai pas l'impression qu'il ne reste rien à faire.
Il y a 15ans, la visioconf, c'était pas un requis, par exemple.
Sur un marché économique, on sait qu'une solution techniquement meilleure qui arrive un peu plus tard peut mourir simplement en raison de son retard sur le marché, pas de ses qualités techniques. Dans le Libre, ça peut simplement prendre plus de temps.
Encore une fois, je ne dis pas que Matrix est mal ou que c'est une mauvaise idée, je déplore qu'on invente un énième protocole.
Les défauts de XMPP sont connus et ce qu'on change pour les corriger c'est pondre un nouveau protocole qui aura lui aussi des défauts de jeunesse et qui aura besoin d'un bon bout de temps avant d'avoir un écosystème autour de lui.
J'ai du mal à croire que "se farcir toutes les XEP" soit plus long et compliqué que réécrire tout ce dont on a besoin de 0. Surtout qu'on parle ici d'un protocole qui pourrait utilisé des briques éprouvées plutôt que des nouvelles. Un bogue dans un protocole, ça me semble autrement plus chiant que dans une implémentation particulière.
Encore une fois: XMPP a ici l'avantage de son ancienneté.
De même, "se farcir toutes les couches basses de XMPP" est-il vraiment un chemin de plus grande résistance que d'inventer et implémenter de nouvelles couches basses?
Enfin, plus bas, il est écrit que Matrix est plutôt complémentaire que concurrent à XMPP, et que les 2 seront interopérables.
On verra bien, donc.
# Le Libre, c'est le choix, mais...
Posté par Maclag . En réponse au journal Pas seul dans la matrice. Évalué à 10.
Aujourd'hui, XMPP est somme toute un succès. Malgré cette assertion, il reste encore beaucoup à faire: transformer l'essai sur les réseaux sociaux, convaincre les acteurs propriétaires d'ouvrir les communications entre serveurs, etc.
Bref, il reste encore beaucoup de boulot.
Là, on nous annonce un nouveau protocole qu'il va tout déchirer. Et je me dis que même s'il est vraiment bon, il n'arrive pas au bon moment: XMPP n'est pas encore assez obsolète pour qu'on lui cherche un remplaçant, et pas encore assez solide sur le marché pour ne pas souffrir de la concurrence d'un autre protocole ouvert dans l'écosystème du Libre.
Du coup quand je lis que Matrix fait des choses qu'il aurait été impossible de faire dans XMPP sans modif majeure, je me demande si les modifs auraient été plus majeures que:
Les protocoles, ce n'est pas comme les applis: 120 applis qui utilisent le même protocole contribuent plus ou moins dans la même direction.
Chaque nouveau protocole Libre réduit les chances d'adoption en masse d'un protocole Libre.
[^] # Re: distrib
Posté par Maclag . En réponse au journal Au moins 30% des serveurs hébergés sur Microsoft Azure sont sous Linux !. Évalué à 10.
Devuan.
Microsoft rejette en bloc systemd, ils trouvent ça trop contraire à l'esprit Unix. Et pis d'abord, ils aiment pas Lennart!
[^] # Re: ...
Posté par Maclag . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 10.
Ben sur Debian ça va aller encore plus vite vu que les mainteneurs des autres init se barrent pour faire une autre distro…
-----------> [ ]
[^] # Re: .
Posté par Maclag . En réponse au journal systemd: je me lance. Évalué à 10.
C'est vrai, quand tu fais une recherche sur systemd, les premiers résultats sont le plus souvent de longues déclarations haineuses qui mentionnent vaguement le problème rencontré et pas la solution, au milieu des complots et le reste.
À la fin, ton problème n'est pas résolu, mais au moins tu as appris que Lennart est un extra-terrestre envoyé par la planète GJtnghht pour détruire l'humanité, tout comme Bill Gates et Rebecca Black.
[^] # Re: .
Posté par Maclag . En réponse au journal systemd: je me lance. Évalué à 10.
Je suis sûr que si c'était possible, d'autres râleraient en disant que systemd autorise à démarrer avec des partitions critiques pas disponibles sur une simple question.
[^] # Re: Déception
Posté par Maclag . En réponse au journal ArchLinux : serait-il venu le temps de passer à autre chose ?. Évalué à 6.
Moi entre la petite, ma femme et le trollage sur linuxfr, je n'ai pas le temps d'installer des distros qui cassent.
C'est pour ça que j'utilise exclusivement Debian!
Debian: prenez le temps d'être velu!
[^] # Re: Déception
Posté par Maclag . En réponse au journal ArchLinux : serait-il venu le temps de passer à autre chose ?. Évalué à 3.
C'est qu'en on lit cela
Là je vais être obligé de me demander si tu as été chanceux au point de ne jamais avoir connu cet environnement plein d'enfants qu'on appelle l'école…
[^] # Re: Déception
Posté par Maclag . En réponse au journal ArchLinux : serait-il venu le temps de passer à autre chose ?. Évalué à 6.
Ben il l'a déjà trouvée, mais si un jour quelqu'un veut documenter la résolution de problème sur le wiki…
En cas de problème sur Arch du type "j'en ai marre: je ne devrais pas passer autant de temps à m'occuper du système", allez directement ici:
https://www.debian.org/distrib/
Mais j'aurais franchement préféré qu'on en parle vendredi!