Linux? - Page 268

Godzil (./8009) :
133MMX? C’est rare de l’Isa sur ces machines

Ah non, à l'époque c'était encore courant (en plus des ports PCI bien sûr, pas en remplacement).

Je n’ai pas souvenir d’avoir eu du pentium avec isa, mais bon ça date.

L'ISA est resté disponible longtemps après l'arrivée du PCI et de l'AGP, pour la compatibilité avec des périphériques comme les cartes son, pour lesquels la faible bande passante de l'ISA n'était pas un vrai goulot d'étranglement. Même sur des MBs PIII avec AGP, des slots ISA sont disponibles de façon non exceptionnelle: https://www.vogonswiki.com/index.php/List_of_Socket_370_motherboards . C'était également assez fréquent sur les MBs Super Socket 7 pour K6*, et cela semble plus rare pour les K7 avec AGP mais ça a également existé au moins jusqu'au socket A: https://www.vogonswiki.com/index.php/List_of_Socket_A_motherboards .

Je ne connais pas de MB qui ait ISA, PCI, AGP et PCIe, en revanche. Les 3 premiers, ce n'est pas rare, et j'ai trouvé des ASRock 4CoreDual-SATA2, qui ont les 3 derniers (et aussi des slots DDR et des slots DDR2 d'ailleurs, ces MBs sont des doubles hybrides de transition entre les époques...), dans une poubelle. Et j'ai appris aujourd'hui qu'il y a des MBs ISA, PCI et PCIe, comme https://www.ebay.fr/itm/387991583838 (industrielle socket 775, donc déjà après un certain temps dans la génération P4).

Under the hood, Azure Linux 4.0 is based on Fedora Linux

J'en connais un qui doit avoir les oreilles qui sifflent

Haaa WSL. plus je doit l'utiliser et plus j'ai envie de vomir.

Car marche Okay jusqu'a ce que ca ne marche plus et te force a completement redemarer la VM, et encore des fois ca ne suffit pas il faut rebooter windows.

Vous vous souvenez peut-être du membre du conseil d'administration de GNOME qui s'était fait bannir il y a quelques années, officiellement pour une violation du code-of-conduct, sauf que personne ne voulait dire ce qui s'était concrètement passé ?

Il vient de poster sa version des faits (source), et ça donne un éclairage différent à l'incident. Quelques extraits :

Rob assured and insisted to Tobias and I that the Foundation would make an effective fiscal sponsor for the 1M€ STF grant. We knew that under Rob’s (long) presidency and directorship it was dysfunctional but we chose to trust them rather than looking for another fiscal host or creating a new entity because we hoped it would bring the community together.

Later; I get an email from a partner saying that not only the past few monthly invoices were never paid but that they did not receive a reply from the person in charge of it at the Foundation.
I sent a letter demanding the executive committee to start addressing the structural and operational failures (some of which may breach California nonprofit law and hold board members accountable) or I would have no other choice than to resign and inform the GNOME community and partners.

The initial response was positive, we started working on a path forward until during a meeting with Rob, he had the audacity to blame the STF team for the unpaid invoices. I lost my temper.
I apologized to all parties immediately after but that didn’t stop the 3rd participant of that meeting to file a complain against me.

This led Federico to send a letter to the board of directors demanding to ban me permanently with accusations of “Intimidation”, “Disruption of discussions” and “Influencing or encouraging inappropriate behavior”.
I don’t know how we got there. What I do know is that I was never contacted by anyone with concerns about my behavior or my directorship. It’s also worth noting the CoC committee back then was composed of 4 people including Federico, the person who filed the complain and past (at the time current) staff members.

The meeting we had planned to inform the full board about the operational failures got canceled. I was informed that the board followed the CoC recommendation to ban me. The board at the time was largely disengaged, one director challenged both the procedure and its content but to no effect.

Rob escalated with an offer to sign a non disparagement agreement (aka gag procedure) which would expose me to a fine should I criticize any of the foundation staff or directors. If I refused, a defamatory statement about me would be published. Since the defamatory statement had no ground I chose not to sign the agreement.

Je ne trouve pas ces posts, ils ont été supprimés depuis ?

[Edit] Ah non c'es Discourse qui permet pas au navigateur de chercher un texte qui n'est pas sur l'écran :/ quelle plaie.

Le lien direct vers le post :

Arch Linux utilise un gestionnaire de packages appelé « pacman ». Judd Vinet voulait quelque chose de plus rapide qu'apt et rpm.
Problème : ce format de package est très souvent ignoré, parce que faire une version Debian-based et Red Hat-based, c'est suffisamment brasse-brouilles comme ça (d'où la volonté d'Ubuntu d'imposer snap alors que FlatHub et les AppImages existent).

D'où l'AUR qui est un repository permettant de récupérer le code source des programmes et autres drivers afin de les compiler pour le système Arch-based. N'importe quoi avec un peu de volonté peut créer un package pour le publier sur l'AUR. La communauté open-source étant ce qu'elle est, parfois les paquets maintenus ne le sont plus parce que soit le mainteneur a disparu de la surface de la planète, soit parce que le paquet est de facto obsolète.

Des gens s'en sont aperçus et ont injecté un malware dans la plupart des paquets ainsi orphelins. On en est à 1621.
Le comportement du malware est expliqué ici :

Une vidéo avec un type dans sa chaise qui bouge :


Comment savoir si on a un paquet AUR affecté ?
Un terminal normal :
bash <(curl -s https://cscs.pastes.sh/raw/aurvulntest20260611.sh)
fish, le terminal de CachyOS :
bash <(curl -s https://cscs.pastes.sh/raw/aurvulntest20260611.sh | psub)
Pour le moment, tant qu'on n'a pas tout nettoyé, interdiction de lancer la commande « yay -Syu ».

Vous vous rappelez des gens (*) qui disaient que l'écosystème Linux était plus sûr parce que la nature Open Source du code permettait de détecter les actes malicieux quasi-immédiatement ?

(*) dont KelKun, et je sais que tu vas réagir dans le FlashChat alors que ça fait une douzaine d'années que t'es banni d'ici ; ferme ta putain de gueule, je veux pas te lire

Pas besoin d’aller aussi loin. Arch n’est pas la distro la plus utilisée, donc on peu se dire ok, ça peux passer inaperçu.


Heart Bleed est la preuve meme que aussi utile soit l’open source ce n’est pas non plus la panacée. OpenSSL était (et est toujours) largement plus utilisé qu’Arch, pourtant cette faille est passé inaperçue pendant des années.

Kevin n'utilise pas ArschLinux voyons c'est obsolète.

Ça fait longtemps qu'on sait que le côté open-source n'est pas une garantie de sécurité (heart bleed est en effet un bon exemple), et il manque plein de sécurités sur l'espace utilisateur (par exemple n'importe quel programme lancé par l'utilisateur peut accéder à toutes les données de l'utilisateur).
Pour autant, ça amène des garanties intéressantes sur le long terme, en étant *moins* lié à un éditeur qui décide de changer de licence ou d'arrêter ses ventes.

il manque plein de sécurités sur l'espace utilisateur (par exemple n'importe quel programme lancé par l'utilisateur peut accéder à toutes les données de l'utilisateur).

Ouais. Du moins, sans sandboxing, mais la plupart des usages restent non sandboxés.
Il manque également beaucoup de sécurités dans les divers kernels ouverts et fermés... un nombre croissant de techniques d'anti-exploitation est développé depuis 25 ans environ (PaX / grsecurity, évidemment), mais les kernels utilisés par l'écrasante majorité des utilisateurs ne disposent pas de ces techniques d'anti-exploitation.

D'ailleurs les trucs de sandbox comme snap justement c'est pas censé résoudre une partie du problème ?

Je n'ai pas l'impression que snap permette de limiter les droits sur les données de l'utilisateur qui lance le programme (mais je connais mal).

Ouais ça m'a l'air d'être plutôt du sandboxing pour aider au packaging et la désinstallation éventuellement. Mais je connais mal. Sinon que ça fout déjà pas mal la merde avec certaines applis classiques.

Flatpak et Snap ont un peu de sandboxing, mais représentent des systèmes de packaging non intégrés aux systèmes de packaging historiques des distributions Linux, voire des systèmes fermés. Hors de ces trucs, il y a des choses comme Firejail et Bubblewrap.
J'ai vu ces 4 technos-là elles-mêmes apparaître sur les flux de vulnérabilités...