Posté par barmic 🦦 le 12 décembre 2020 à 13:20. En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  3. Dernière modification le 12 décembre 2020 à 13:22.
En réalité, à la base RH n'avait pas la marque CentOS.
C'est pas "en réalité", mais "par le passé". Ils ont pas volée la marque ils l'ont acheté. Ensuite si le principe qui veut qu'une entreprise fournisse sont produit payant et la copie identique gratuite ne paraît pas fragile, c'est assez naïf. Ils ont profité jusque ici, maintenant on va voir comment les choses se passent. Est-ce que RockyLinux va pouvoir se démarquer et en combien de temps ? Est-ce que les gens vont raquer pour avoir une vraie RHEL ?
Ce n'est pas à toi que je vais expliquer que le travail a un coût et que RH investie énormément dans tout l'écosystème linux (et dans le bureau linux ce qui ne rapporte pas des masses). Oui ça fait mal de se faire couper le robinet quand tu en profitais gratuitement, oui ils auraient pu être moins violent, mais il s'agit là d'épiphénomènes au concept de base : si tu veux une RHEL, achètes-en une. Ils font un travail suffisamment conséquent pour que ce ne soit pas du vol.
C'est un coup pourri (autant de RH que de ceux qui ont filé le nom à RH) qu'il ne faudra pas oublier dans le futur, pour bien faire attention à s'en protéger.
Tu parle d'oublier, mais ça n'est pas la première fois que RH fait ce genre de choses. Par exemple pour leur kubernetes managé, je sais plus si c'est le passage de la version 2 à 3 ou 3 à 4, ils ont laissé quelques semaines à leur clients pour faire le changement ! Et là c'est leurs clients à qui ils ont dit qu'ils devaient être passé à la nouvelle plateforme en moins de 2 mois.
A chacun de juger de la solidité de ce qu'il utilise. Le principe de faire des choix pas très solide (comme continuer à utiliser une distribution dont l'objectif ne semble pas en accord avec son possesseur) et se dire que si on gueule assez ça tiendra me fatigue un peu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par barmic 🦦 le 12 décembre 2020 à 09:03. En réponse au journal Linux ne m'intéresse plus. Évalué à  4.
Ben bravo on comprend pourquoi t'a tant de processus ! Je ne te félicite pas ! Alors que tu vois, tu pourrais utiliser l'option -c de grep et économiser un processus !
Blague à part, je ne suis pas convaincu de la pertinence de la métrique du nombre de processus. Oui ça prend plus de mémoire, mais ça permet au noyau d'avoir des informations plus spécifiques sur chaque tâche pour l'ordonnancement. Ça permet aussi d'utiliser d'améliorer la sécurité.
Posté par barmic 🦦 le 12 décembre 2020 à 01:26. En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  5.
si quelqu'un n'est pas content, libre Ă lui de forker
Ça n'est pas si simple. CentOS c'est une marque. C'est la seule distribution qui soit acceptée par les services de support qui certifie RHEL. C'est en ça que c'est un sabordage. On prend une marque qui gène et on casse son image. Pour revenir au même point il faut non seulement faire le travail de fork, mais aussi gérer l'image de ta distribution (avoir suffisamment de visibilité) pour qu'elle soit de nouveau acceptée.
Mais oui Red Hat gère ses marques et ses projets comme elle l'entends. Ça n'est pas un projet communautaire.
Posté par barmic 🦦 le 12 décembre 2020 à 01:17. En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  9.
Donc si CentOS, n'est plus 100% équivalent de RedHat, ben autant te dire qu'il sera remplacé. Soit par l'achat de licences RedHat soit par un équivalent. CentOS sera tellement proche de Red Hat de manière générale que si c'est pour une question de compatibilité cela ne sera pas un vrai problème en fait.
Donc si CentOS, n'est plus 100% équivalent de RedHat, ben autant te dire qu'il sera remplacé. Soit par l'achat de licences RedHat soit par un équivalent.
CentOS sera tellement proche de Red Hat de manière générale que si c'est pour une question de compatibilité cela ne sera pas un vrai problème en fait.
C'est pas une question de compatibilité. Sincèrement OSEF de ça. C'est une question de support. La plupart des services de support qui certifie avec RHEL acceptent CentOS. C'est une confiance qui prend du temps à acquérir. Prendre la marque CentOS pour en changer le contenu ça peut très bien mettre à mal cette confiance quelque soit la réalité et d'autant plus si pour une raison ou une autre il y a un problème dans l'une des premières versions.
Je comprends que Red Hat veuille vendre ses licences. Se faire payer son travail ce n'est pas sale.
Posté par barmic 🦦 le 11 décembre 2020 à 14:48. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3.
J'ai 35 ans de programmation derrière moi J'ai toujours du mal avec le joker "cv". A côtoyer des devs d'âge et d'expérience pro divers, ce n'est sans doute pas le critère le plus pertinent.
J'ai 35 ans de programmation derrière moi
J'ai toujours du mal avec le joker "cv". A côtoyer des devs d'âge et d'expérience pro divers, ce n'est sans doute pas le critère le plus pertinent.
C'est toi qui a lancé l'appel au CV :
je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages
Si l'expérience n'est pas un argument ne t'en sert pas toi non plus. Sinon évidement que les gens vont répondre en contextualisant avec leur expérience, tu leur demande.
Y'a une juste valeur a avoir. Par exemple, je laisserais des langages comme Haskell, Prolog, Ada dans le cadre "académique" : on apprend des concepts qu'on va pouvoir réutiliser dans des langages plus orienté "concret".
Haskell et prolog, je ne sais pas, mais il n'y a pas plus industriel qu'Ada. « Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité. » Ada a carrément employé dans des endroits où l'apparition d'une erreur coûte des milliers d'euros (et oui l'histoire retiens que le langage ne fait pas tout).
Après je comprends toujours pas pourquoi reprocher à des langages que tu n'utilisent pas de choisir leurs évolutions.
Posté par barmic 🦦 le 11 décembre 2020 à 00:19. En réponse au journal Linux ne m'intéresse plus. Évalué à  3.
Tu t'emportes pour rien
Quand tu dit que ceux qui ne sont pas d'accord sont des noobs, ça fait réagir ceux qui ne sont pas d'accord avec toi.
Mais au final, pourquoi Evince (un lecteur pdf), Simple Scan (un scanner) ne marche pas correctement en environnement non GNOME/systemd ???
Parce que c'est des appli qui ont étaient écrite avec comme dépendance GNOME/systemd. soit les développeurs n'ont pas conscience d'avoir cette dépendance aussi forte, soit ils assument et c'est leur choix. Mais vu ce que tu en a dit je présume que tu a juste ragé, le libre c'est être juste utilisateurs de logiciels et préférer s'énerver et dire du mal de logiciel s'en chercher à se renseigner ? (communauté tout ça, tout ça)
Posté par barmic 🦦 le 10 décembre 2020 à 15:00. En réponse au journal Linux ne m'intéresse plus. Évalué à  4.
Défi : explique moi où est le problème dans ce script, et comment le corriger, c’est pour savoir si tu sais de quoi tu parles quand tu parles de shell : while read file do otherscript "${file}" done
Défi : explique moi où est le problème dans ce script, et comment le corriger, c’est pour savoir si tu sais de quoi tu parles quand tu parles de shell :
while read file do otherscript "${file}" done
Je serait intéressé de savoir ce que tu avais en tête ? Limiter la taille lue ou choisir un délimiteur ? Ou c'est un tricks avec backslash ?
En tout cas même si c'est une de ses raisons je n'aurais pas trouvé sans qu'on me mette le doigt dessus.
Posté par barmic 🦦 le 10 décembre 2020 à 14:27. En réponse au journal Linux ne m'intéresse plus. Évalué à  6.
Parfois un script de service doit vérifier plusieurs choses pour se lancer comme la présence de répertoire, trouver un fichier de configuration, initialiser une base de données.
C'est précisément pour cette raison qu'un script shell ne me semble pas une bonne idée. Ça peut devenir compliqué de rester idempotent pour ce genre de choses. Je trouve que c'est la même problématique que celles que gère les gestionnaires de configuration. Tu souhaite que ton système possède un état donné pour que le service se lance correctement. Pour ça une description déclarative, bien que potentiellement plus verbeuse et moins intuitive, sera bien plus solide.
Posté par barmic 🦦 le 10 décembre 2020 à 11:29. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  9.
Ça donnait quoi, la concurrence à l'époque?
multics évidement le prédécesseur le plus direct d'unix, celui qui a inventé les fichiers, les arborescence et tout un tas de trucs repris par unix. Si linuxfr existait à l'époque, on aurait expliqué à Ken Thomson que ça sert à rien d'essayer de recréer un multics from scratch qu'en plus se lancer dans un nouveau langage alors qu'il y a déjà l'embarra du choix avec PL/1 (et ses alternatives), Fortran, lisp, COBOL,…
Après il y avait GECOS, IBSYS et un tas d'autres OS. C'est difficile de comparer 50 ans après, l'UNIX de l'époque n'était pas ce qu'on connaît aujourd'hui et je n'ai jamais vu tourner multics (mais son code a était libéré dernièrement).
Posté par barmic 🦦 le 10 décembre 2020 à 11:13. En réponse au lien La CNIL inflige des amendes à Google et Amazon pour non-respect de la législation sur les cookies. Évalué à  4.
Ça met un peu en perspective le journal : Je viens de déposer plainte à la CNIL : mon retour d'expérience et sa section « Remarque générale sur l'état du web et le respect du consentement de l'internaute par les sites » qui indiquait que la CNIL acceptait les pratiques de Google.
Posté par barmic 🦦 le 08 décembre 2020 à 23:28. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  6.
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Unix a était conçu avec un langage adhoc (tout neuf, non standardisé, une seule implémentation faite pour le projet lui-même).
Comme quoi ça peut chémar.
Posté par barmic 🦦 le 08 décembre 2020 à 13:59. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  5. Dernière modification le 08 décembre 2020 à 14:01.
Dans toutes les définitions usuelles de « système d’exploitation », on trouve l’idée que l’OS sert d’« intermédiaire entre le matériel et les logiciels », « gère les ressources matérielles », ou plus généralement « permet l’utilisation d’un ordinateur »…
Et c'est de plus en plus faux, il y a une couche de plus en plus présente sous l'OS est-ce que tu pense que ça les dénatures ? C'est un logiciel qui permet d'exploiter une machine, le fait que cette machine soit virtuelle ne me semble pas changer la nature du problème.
Posté par barmic 🦦 le 08 décembre 2020 à 12:08. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  4.
J'aime bien Rust, mais justement, quand on écrit un OS, on tape pas souvent le unsafe ?
Pas autant qu'on ne pourrait l'imaginer je pense. Ça va concerner les drivers, le bootstrap du noyaux, quelques interfaçages pas niveau (pour les IRQ j'imagine), mais il reste un tas de choses à faire comme le scheduling, le mappage mémoire, la pile IP,…
Posté par barmic 🦦 le 08 décembre 2020 à 07:16. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  2.
C'est pas faux. J'entends souvent ça pour la résilience, mais c'est vrai. Par contre j'ai pas encore tout lu sur le sujet mais le tout est URL fait plutôt peur pour la sécurité.
Posté par barmic 🦦 le 08 décembre 2020 à 00:30. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  8.
GNU a passé 7 ans à reconstruire un userland de 83 à 90 et en 90 ils se sont attaqué au dernier morceau qui leur manqué pour avoir un OS. La démarche est largement moins éparpillée. 30 ans après on peut les juger, mais avoir des concepts novateurs n'est pas déconnant pour se démarquer. L'équipe limité dont tu parle a commit des petites choses tel que qu'emacs ou gcc. Ils n'ont pas démarré de but en blanc tout un OS en commençant par les parties les plus compliquées.
Redox ne s attaque pas à Linux mais a OpenBSD ils ne cherchent pas a avoir tous les pilotes mais a avoir un os sécurisé.
Ça n'est pas mis en avant. A part si on fait du rust signifie ça ce qui n'est évidement pas le cas. C'est dis dans leurs objectifs, mais il y ai aussi dis qu'ils veulent être une alternative à linux. Ce qui est dommage je trouve dans cet optique, c'est que :
Posté par barmic 🦦 le 07 décembre 2020 à 23:33. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  4.
Mais je suis vraiment curieux de voir ce que ça donne, si on voit réellement rejaillir les avantages annoncés du langage sur le produit fini.
Tu peux regarder la liste des CVE liées à des buffers overflows. Hors unsafe ça fait parti des classes d'erreurs qui sont impossibles (avec d'autres comme les races conditions, les danglings pointers,…).
unsafe
Posté par barmic 🦦 le 07 décembre 2020 à 23:17. En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  10.
Ça me fait toujours très peur de voir des projets s'attaquer à un projet complexe et trouver le moyen de s'éparpiller sur un paquet de sujets. Pour des projets comme Haiku ça s'explique car c'est un écosystème qui existait déjà et qu'ils cherchent à maintenir. De plus l'ambition n'est pas de remplacer linux.
Il faut combien de temps pour stabiliser btrfs ou zfs ? Se lancer dans un autre FS, c'est s'acheter des soucis. Je n'ai aucun doute que c'est fait avec toute la bonne volonté du monde, qu'avec un couplage de dingue ils peuvent faire un truc super efficace, mais rester un peu concentré sur avoir un noyau me paraît de loin plus important.
Posté par barmic 🦦 le 06 décembre 2020 à 23:41. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2. Dernière modification le 06 décembre 2020 à 23:41.
Alors je ne jouerai pas avec ton script par flemme de lister pleins d'url. Par contre je viens de vérifier et asyncio et single core donc pour utiliser tout la puissance de ta machine il faut effectivement toi même créer un thread pour chaque cpu et chacun lance des requêtes. Ça devrait être mieux.
Posté par barmic 🦦 le 06 décembre 2020 à 23:14. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Pour java le terme inférence me semble un peu galvaudé. C'est plus comme ne pas déclarer 2 fois le type d'une variable. Si une variable est initialisée à sa déclaration, il est possible d'utiliser le mot var à la place du type pour choisir le type de la partie droite.
var
Posté par barmic 🦦 le 06 décembre 2020 à 23:08. En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à  3.
Jusqu'à présent, la plupart des banques proposent un boîtier qui sert de second moyen d'authentification.
Juste un token RSA ? Ça ne me semble pas compatible avec DSP2.
Posté par barmic 🦦 le 06 décembre 2020 à 20:11. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Je te rejoins. Je n'ai pas le temps de tester le code, mais j'ajoueterais :
J'ai vite fais trouvé un bench qui fait exactement ce test mais sur qui montre plus l'évolution en fonction du nombre de requêtes, jusqu'à 10 url les threads sont meilleurs (contrairement à toi il utilise un pool de threads pour ne pas exploser son CPU et éviter de payer de trop le coût de création des threads). Tu peux trouver le lien ici : A better way for asynchronous programming: asyncio over multi-threading.
est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?
C'est précisément ce que fait go par exemple.
Posté par barmic 🦦 le 06 décembre 2020 à 18:01. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2. Dernière modification le 06 décembre 2020 à 18:01.
Mais tu pars du postulat qu'il n'y a pas de context switching dans les green thread ce qui me semble tout à fait erroné.
Je n'ai pas était très précis, quand je parle de context switch, j'entends celui qui est le plus classique, qui s'appuie sur une interruption, implique de vider le core du CPU ainsi que d'autres choses comme le TLB. Les greens threads sont coopératifs, ils impliquent beaucoup moins de choses, on en nettoie pas le core (seuls quelques registres sont changé), ni le noyau1, ce qui en fait une opération drastiquement plus performante.
évidement cela se fait au détriment de la sécurité, mais on reste au sein d'une même application. C'est pour ça que ce n'est pas une bonne idée pour Firefox qui exécute du code qui n'est pas maitrisé, utiliser des threads systèmes c'est nécessaire (mais pas suffisant) pour ce genre de pratiques) ↩
Posté par barmic 🦦 le 06 décembre 2020 à 11:11. En réponse au journal Extension Google Direct pour Firefox. Évalué à  2.
Bref, l'utilisation de l'e-mail comme identifiant soit-disant indispensable est très galvaudé, normalement on aurait juste à le mettre à jour auprès de nos contacts qu'on connaît, et un nombre limité d'institutions — comme on faisait avant quand on changeait d'adresse physique… — et ça irait très bien.
Tu t'intéresse à ce qui pourrait être alors que je m’efforce de décrire l'existant. On a une fonctionnalité d'internet acentrée, mais l'usage en fait quelque chose de plutôt centralisé et laisse la porte ouvertes à des problèmes liés aux monopoles. Ce n'est pas la faute de l'email, on ne va pas interdire email, mais il y a tout de même le problème.
Alors comme avec fearan au-dessus, je pense que tu as mal compris (ou j'ai mal expliqué) mon point de vue : certaines choses se prêtent naturellement au monopole, et ne peuvent qu'y mener. Je pense que c'est le cas avec la « recherche » au sens d'outil utilisé par l'humanité pour répondre à toute question généraliste. Il ne peut pas exister de « concurrence » de l'oracle universel.
Tout usage se prête naturellement au monopole. Quand tu n'a pas l'expertise et que tu n'a pas d'intérêt particulier, tu es facilement enclin à aider un monopole. Comme le montre l'e-mail, c'est l'usage qui crée le monopole (ou la situation de quasi-monopole) ce n'est pas intrinsèque.
Mais dans le domaine dont on parle, ça n'a pas vraiment de sens.
C'est quasiment la définition des GAFAM. Si ça n'a pas de sens ici, je ne vois pas où ça aurait du sens.
C'est ce que tu affirme, mais ça n'est pas établi. Peut-être faudrait-il que j'étoffe mon argumentaire, mais j'y réfléchis et j'ai débattu depuis plusieurs années (pas en grand comité, certes), et je n'ai jamais vu de contre-argument réellement pertinent. Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ? Le but ça n'est pas d'interdire les tentatives de choses plus « éthiques », c'est de dire que de toutes façons, elles sont vouées à l'échec. Le but c'est d'interdire Google ou tout autre qui pourra le remplacer (mais je pense qu'au niveau où ils sont, c'est in-rattrapable ; cf. déjà l'analyse d'Assange d'il y a 10 ans déjà ).
C'est ce que tu affirme, mais ça n'est pas établi.
Peut-être faudrait-il que j'étoffe mon argumentaire, mais j'y réfléchis et j'ai débattu depuis plusieurs années (pas en grand comité, certes), et je n'ai jamais vu de contre-argument réellement pertinent.
Il existe plusieurs tentatives de créer des moteurs de recherches généralistes fédérés. Pourquoi les interdire ?
Le but ça n'est pas d'interdire les tentatives de choses plus « éthiques », c'est de dire que de toutes façons, elles sont vouées à l'échec. Le but c'est d'interdire Google ou tout autre qui pourra le remplacer (mais je pense qu'au niveau où ils sont, c'est in-rattrapable ; cf. déjà l'analyse d'Assange d'il y a 10 ans déjà ).
Je ne comprends pas le but n'est pas d'interdire, mais comme il vont se planter, interdisons les (parce qu'interdire les moteurs de recherche ça interdit de fait YaCy ou seeks) ? Avant la création de wikipedia il y a eu plusieurs tentatives qui fur des échecs, quels sont les arguments qui permettent de dire que ce sera toujours un échec ? Tu base se savoir sur quelque chose de solide ou juste sur la volonté de détruire google ?
Google peut très bien se faire tronçonner comme ce fut le cas d'AT&T.
Mais en plus de ça, c'est très dommageable d'interdire l'échec. C'est en expérimentant qu'on découvre.
Je ne sais pas trop quels biais tu évoques, mais oui parfois c'est fait « par réflexe », sans penser aux inconvénients différents que ça va amener.
En soit on s'inquiète des centralisations qui ont du succès sans se rendre compte que ce qui est décentralisé peine à avoir du succès (il tend vers une centralisation). C'est plus simple à l'usage et les utilisateurs adorent ça, c'est normal d'ailleurs. Si on avait yahoo, bing, google, baidu et yandex qui avaient chacun 20% requêtes de recherche, tu ne pourrais pas dire les moteurs de recherche c'est nécessairement mal.
Posté par barmic 🦦 le 06 décembre 2020 à 00:27. En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à  4.
Apparemment si Why are new versions of Manjaro being released?
Posté par barmic 🦦 le 06 décembre 2020 à 00:12. En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.
Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.
Je ne vois pas en quoi ça améliore le context switching.
Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.
D'après https://en.wikipedia.org/wiki/Green_threads#Performance, c'est même l'inverse et ça me parait logique vu que c'est une couche d’abstraction en plus et que ça ne tiens pas en compte du matériel (mono CPU et pas de prise en compte du multi-threading physique)
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés… C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.
Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.
Après, entre la définition (d'ailleurs chaque langage a un peu son nom a lui), l'implémentation (pareil, très fluctuent) et ce que ça fait réellement.
A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.
[^] # Re: pourquoi ?
Posté par barmic 🦦 . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  3. Dernière modification le 12 décembre 2020 à 13:22.
C'est pas "en réalité", mais "par le passé". Ils ont pas volée la marque ils l'ont acheté. Ensuite si le principe qui veut qu'une entreprise fournisse sont produit payant et la copie identique gratuite ne paraît pas fragile, c'est assez naïf. Ils ont profité jusque ici, maintenant on va voir comment les choses se passent. Est-ce que RockyLinux va pouvoir se démarquer et en combien de temps ? Est-ce que les gens vont raquer pour avoir une vraie RHEL ?
Ce n'est pas à toi que je vais expliquer que le travail a un coût et que RH investie énormément dans tout l'écosystème linux (et dans le bureau linux ce qui ne rapporte pas des masses). Oui ça fait mal de se faire couper le robinet quand tu en profitais gratuitement, oui ils auraient pu être moins violent, mais il s'agit là d'épiphénomènes au concept de base : si tu veux une RHEL, achètes-en une. Ils font un travail suffisamment conséquent pour que ce ne soit pas du vol.
Tu parle d'oublier, mais ça n'est pas la première fois que RH fait ce genre de choses. Par exemple pour leur kubernetes managé, je sais plus si c'est le passage de la version 2 à 3 ou 3 à 4, ils ont laissé quelques semaines à leur clients pour faire le changement ! Et là c'est leurs clients à qui ils ont dit qu'ils devaient être passé à la nouvelle plateforme en moins de 2 mois.
A chacun de juger de la solidité de ce qu'il utilise. Le principe de faire des choix pas très solide (comme continuer à utiliser une distribution dont l'objectif ne semble pas en accord avec son possesseur) et se dire que si on gueule assez ça tiendra me fatigue un peu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: moi c'est l'inverse
Posté par barmic 🦦 . En réponse au journal Linux ne m'intéresse plus. Évalué à  4.
Ben bravo on comprend pourquoi t'a tant de processus ! Je ne te félicite pas ! Alors que tu vois, tu pourrais utiliser l'option -c de grep et économiser un processus !
Blague à part, je ne suis pas convaincu de la pertinence de la métrique du nombre de processus. Oui ça prend plus de mémoire, mais ça permet au noyau d'avoir des informations plus spécifiques sur chaque tâche pour l'ordonnancement. Ça permet aussi d'utiliser d'améliorer la sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par barmic 🦦 . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  5.
Ça n'est pas si simple. CentOS c'est une marque. C'est la seule distribution qui soit acceptée par les services de support qui certifie RHEL. C'est en ça que c'est un sabordage. On prend une marque qui gène et on casse son image. Pour revenir au même point il faut non seulement faire le travail de fork, mais aussi gérer l'image de ta distribution (avoir suffisamment de visibilité) pour qu'elle soit de nouveau acceptée.
Mais oui Red Hat gère ses marques et ses projets comme elle l'entends. Ça n'est pas un projet communautaire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: À voir en vrai
Posté par barmic 🦦 . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à  9.
C'est pas une question de compatibilité. Sincèrement OSEF de ça. C'est une question de support. La plupart des services de support qui certifie avec RHEL acceptent CentOS. C'est une confiance qui prend du temps à acquérir. Prendre la marque CentOS pour en changer le contenu ça peut très bien mettre à mal cette confiance quelque soit la réalité et d'autant plus si pour une raison ou une autre il y a un problème dans l'une des premières versions.
Je comprends que Red Hat veuille vendre ses licences. Se faire payer son travail ce n'est pas sale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  3.
C'est toi qui a lancé l'appel au CV :
Si l'expérience n'est pas un argument ne t'en sert pas toi non plus. Sinon évidement que les gens vont répondre en contextualisant avec leur expérience, tu leur demande.
Haskell et prolog, je ne sais pas, mais il n'y a pas plus industriel qu'Ada. « Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité. » Ada a carrément employé dans des endroits où l'apparition d'une erreur coûte des milliers d'euros (et oui l'histoire retiens que le langage ne fait pas tout).
Après je comprends toujours pas pourquoi reprocher à des langages que tu n'utilisent pas de choisir leurs évolutions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: moi c'est l'inverse
Posté par barmic 🦦 . En réponse au journal Linux ne m'intéresse plus. Évalué à  3.
Quand tu dit que ceux qui ne sont pas d'accord sont des noobs, ça fait réagir ceux qui ne sont pas d'accord avec toi.
Parce que c'est des appli qui ont étaient écrite avec comme dépendance GNOME/systemd. soit les développeurs n'ont pas conscience d'avoir cette dépendance aussi forte, soit ils assument et c'est leur choix. Mais vu ce que tu en a dit je présume que tu a juste ragé, le libre c'est être juste utilisateurs de logiciels et préférer s'énerver et dire du mal de logiciel s'en chercher à se renseigner ? (communauté tout ça, tout ça)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: moi c'est l'inverse
Posté par barmic 🦦 . En réponse au journal Linux ne m'intéresse plus. Évalué à  4.
Je serait intéressé de savoir ce que tu avais en tête ? Limiter la taille lue ou choisir un délimiteur ? Ou c'est un tricks avec backslash ?
En tout cas même si c'est une de ses raisons je n'aurais pas trouvé sans qu'on me mette le doigt dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: moi c'est l'inverse
Posté par barmic 🦦 . En réponse au journal Linux ne m'intéresse plus. Évalué à  6.
C'est précisément pour cette raison qu'un script shell ne me semble pas une bonne idée. Ça peut devenir compliqué de rester idempotent pour ce genre de choses. Je trouve que c'est la même problématique que celles que gère les gestionnaires de configuration. Tu souhaite que ton système possède un état donné pour que le service se lance correctement. Pour ça une description déclarative, bien que potentiellement plus verbeuse et moins intuitive, sera bien plus solide.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  9.
multics évidement le prédécesseur le plus direct d'unix, celui qui a inventé les fichiers, les arborescence et tout un tas de trucs repris par unix. Si linuxfr existait à l'époque, on aurait expliqué à Ken Thomson que ça sert à rien d'essayer de recréer un multics from scratch qu'en plus se lancer dans un nouveau langage alors qu'il y a déjà l'embarra du choix avec PL/1 (et ses alternatives), Fortran, lisp, COBOL,…
Après il y avait GECOS, IBSYS et un tas d'autres OS. C'est difficile de comparer 50 ans après, l'UNIX de l'époque n'était pas ce qu'on connaît aujourd'hui et je n'ai jamais vu tourner multics (mais son code a était libéré dernièrement).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Contrebalancer un peu le FUD
Posté par barmic 🦦 . En réponse au lien La CNIL inflige des amendes à Google et Amazon pour non-respect de la législation sur les cookies. Évalué à  4.
Ça met un peu en perspective le journal : Je viens de déposer plainte à la CNIL : mon retour d'expérience et sa section « Remarque générale sur l'état du web et le respect du consentement de l'internaute par les sites » qui indiquait que la CNIL acceptait les pratiques de Google.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  6.
Unix a était conçu avec un langage adhoc (tout neuf, non standardisé, une seule implémentation faite pour le projet lui-même).
Comme quoi ça peut chémar.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas de pilotes...
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  5. Dernière modification le 08 décembre 2020 à 14:01.
Et c'est de plus en plus faux, il y a une couche de plus en plus présente sous l'OS est-ce que tu pense que ça les dénatures ? C'est un logiciel qui permet d'exploiter une machine, le fait que cette machine soit virtuelle ne me semble pas changer la nature du problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  4.
Pas autant qu'on ne pourrait l'imaginer je pense. Ça va concerner les drivers, le bootstrap du noyaux, quelques interfaçages pas niveau (pour les IRQ j'imagine), mais il reste un tas de choses à faire comme le scheduling, le mappage mémoire, la pile IP,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  2.
C'est pas faux. J'entends souvent ça pour la résilience, mais c'est vrai. Par contre j'ai pas encore tout lu sur le sujet mais le tout est URL fait plutôt peur pour la sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  8.
GNU a passé 7 ans à reconstruire un userland de 83 à 90 et en 90 ils se sont attaqué au dernier morceau qui leur manqué pour avoir un OS. La démarche est largement moins éparpillée. 30 ans après on peut les juger, mais avoir des concepts novateurs n'est pas déconnant pour se démarquer. L'équipe limité dont tu parle a commit des petites choses tel que qu'emacs ou gcc. Ils n'ont pas démarré de but en blanc tout un OS en commençant par les parties les plus compliquées.
Ça n'est pas mis en avant. A part si on fait du rust signifie ça ce qui n'est évidement pas le cas. C'est dis dans leurs objectifs, mais il y ai aussi dis qu'ils veulent être une alternative à linux. Ce qui est dommage je trouve dans cet optique, c'est que :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  4.
Tu peux regarder la liste des CVE liées à des buffers overflows. Hors
unsafeça fait parti des classes d'erreurs qui sont impossibles (avec d'autres comme les races conditions, les danglings pointers,…).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à  10.
Ça me fait toujours très peur de voir des projets s'attaquer à un projet complexe et trouver le moyen de s'éparpiller sur un paquet de sujets. Pour des projets comme Haiku ça s'explique car c'est un écosystème qui existait déjà et qu'ils cherchent à maintenir. De plus l'ambition n'est pas de remplacer linux.
Il faut combien de temps pour stabiliser btrfs ou zfs ? Se lancer dans un autre FS, c'est s'acheter des soucis. Je n'ai aucun doute que c'est fait avec toute la bonne volonté du monde, qu'avec un couplage de dingue ils peuvent faire un truc super efficace, mais rester un peu concentré sur avoir un noyau me paraît de loin plus important.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2. Dernière modification le 06 décembre 2020 à 23:41.
Alors je ne jouerai pas avec ton script par flemme de lister pleins d'url. Par contre je viens de vérifier et asyncio et single core donc pour utiliser tout la puissance de ta machine il faut effectivement toi même créer un thread pour chaque cpu et chacun lance des requêtes. Ça devrait être mieux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Pour java le terme inférence me semble un peu galvaudé. C'est plus comme ne pas déclarer 2 fois le type d'une variable. Si une variable est initialisée à sa déclaration, il est possible d'utiliser le mot
varĂ la place du type pour choisir le type de la partie droite.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi ?
Posté par barmic 🦦 . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à  3.
Juste un token RSA ? Ça ne me semble pas compatible avec DSP2.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Je te rejoins. Je n'ai pas le temps de tester le code, mais j'ajoueterais :
J'ai vite fais trouvé un bench qui fait exactement ce test mais sur qui montre plus l'évolution en fonction du nombre de requêtes, jusqu'à 10 url les threads sont meilleurs (contrairement à toi il utilise un pool de threads pour ne pas exploser son CPU et éviter de payer de trop le coût de création des threads). Tu peux trouver le lien ici : A better way for asynchronous programming: asyncio over multi-threading.
C'est précisément ce que fait go par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2. Dernière modification le 06 décembre 2020 à 18:01.
Je n'ai pas était très précis, quand je parle de context switch, j'entends celui qui est le plus classique, qui s'appuie sur une interruption, implique de vider le core du CPU ainsi que d'autres choses comme le TLB. Les greens threads sont coopératifs, ils impliquent beaucoup moins de choses, on en nettoie pas le core (seuls quelques registres sont changé), ni le noyau1, ce qui en fait une opération drastiquement plus performante.
évidement cela se fait au détriment de la sécurité, mais on reste au sein d'une même application. C'est pour ça que ce n'est pas une bonne idée pour Firefox qui exécute du code qui n'est pas maitrisé, utiliser des threads systèmes c'est nécessaire (mais pas suffisant) pour ce genre de pratiques) ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par barmic 🦦 . En réponse au journal Extension Google Direct pour Firefox. Évalué à  2.
Tu t'intéresse à ce qui pourrait être alors que je m’efforce de décrire l'existant. On a une fonctionnalité d'internet acentrée, mais l'usage en fait quelque chose de plutôt centralisé et laisse la porte ouvertes à des problèmes liés aux monopoles. Ce n'est pas la faute de l'email, on ne va pas interdire email, mais il y a tout de même le problème.
Tout usage se prête naturellement au monopole. Quand tu n'a pas l'expertise et que tu n'a pas d'intérêt particulier, tu es facilement enclin à aider un monopole. Comme le montre l'e-mail, c'est l'usage qui crée le monopole (ou la situation de quasi-monopole) ce n'est pas intrinsèque.
C'est quasiment la définition des GAFAM. Si ça n'a pas de sens ici, je ne vois pas où ça aurait du sens.
Je ne comprends pas le but n'est pas d'interdire, mais comme il vont se planter, interdisons les (parce qu'interdire les moteurs de recherche ça interdit de fait YaCy ou seeks) ? Avant la création de wikipedia il y a eu plusieurs tentatives qui fur des échecs, quels sont les arguments qui permettent de dire que ce sera toujours un échec ? Tu base se savoir sur quelque chose de solide ou juste sur la volonté de détruire google ?
Google peut très bien se faire tronçonner comme ce fut le cas d'AT&T.
Mais en plus de ça, c'est très dommageable d'interdire l'échec. C'est en expérimentant qu'on découvre.
En soit on s'inquiète des centralisations qui ont du succès sans se rendre compte que ce qui est décentralisé peine à avoir du succès (il tend vers une centralisation). C'est plus simple à l'usage et les utilisateurs adorent ça, c'est normal d'ailleurs. Si on avait yahoo, bing, google, baidu et yandex qui avaient chacun 20% requêtes de recherche, tu ne pourrais pas dire les moteurs de recherche c'est nécessairement mal.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les mots ont un sens
Posté par barmic 🦦 . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à  4.
Apparemment si Why are new versions of Manjaro being released?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à  2.
Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.
Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés… C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.
Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.
A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll