gaaaaaAab a écrit 1399 commentaires

"Enfin un maire qui a du plomb dans la tête"

ben oui, m'enfin

Je dirais que l'on doit s'attendre à une chute des contributions dans tous les projets FOSS sur lesquels RedHat était actif, et plus particulièrement sur tous les projets qui ne concernent pas directement les raisons pour lesquelles IBM a acheté RedHat.

Du coup, quelqu'un sait ce qu'IBM pense de systemd ?

heu … bon, imaginez que j'ai posté ça il y a 3 jours

--> []

Comme tu as pris ça pour une défense de MS, j'ai pris le temps de développer.

Le fait que le cliché que 'Microsoft ne soit pas bon techniquement' ne m'amuse pas n'indique rien de ce que je pense de Microsoft. Perso, je me souviens qu'ils étaient très impliqués pour faire adopter les brevets logiciels en Europe via la BSA, ils ont très salement forcé la standardisation de leur format de doc en parallèle de l'adoption d'odt, la façon dont ils ont imposé la migration vers windows 10 à tout un tas de gens qui n'en voulaient pas est indéfendable, ils ont toujours soutenus les DRMs. Ce que j'en pense, c'est qu'entre les intérêts de leurs partenaires industriels et ceux de leurs clients grand-public, MS semble très souvent choisir les premiers, ce qui me déplaît fortement. Je ne leur fais absolument pas confiance, et il faut surveiller de très près tout ce qu'ils feront, que ce soit au sein de la Linux Foundation, de l'OIN (cf journaux récents), de github, de linkedin, des institutions publiques de tous les pays et de n'importe quel truc où ils sont impliqués. Ils finiront peut-être par instaurer la confiance, mais ça va prendre plus que 5 ou 10 ans.

Je pense avoir pleins de bonnes raisons d'être critique de MS, mais si je ne dénonce pas celles qui ne tiennent pas la route, ça décrédibilise toutes les autres.

au fait les gars du dessus vous devriez taper "man humour" avant de prendre la derniere phrase du journal au premier degre…

Oh ben oui, "microsoft y sont nuls", c'est un trait d'esprit tellement brillant que c'est passé au dessus de mon pauvre esprit imperméable à l'humour. (man sarcasme)

Je suis d'accord avec ce morceau de phrase:

Le problème c'est qu'il est très difficile, même pour des programmeurs compétents, de faire un logiciel un tant soit peu ambitieux.

toutes choses étant égales par ailleurs

Oui, c'est sûr, si tu utilises un langage qui gère la mémoire, forcément, les bugs de gestion de la mémoire ne sont plus dans ton programme. Mais ils ne disparaissent pas pour autant. Si l'infrastructure de ton langage présente une faille de sécurité dans son gestionnaire de mémoire, d'un seul coup, ce sont tous les programmes écrits dans ce langage qui sont vulnérables. Alors c'est sûr que ça va arriver moins souvent, mais le jour où ça arrive, c'est la catastrophe. Quand tu utilises un langage qui rend les failles de sécurité plus difficiles à écrire, tu échanges un risque local contre un risque systémique. Je ne dis pas qu'il ne faut pas préférer un tel langage au C dans la plupart des cas, mais il ne faut pas non plus penser que le 1% de failles de sécurité potentiel du super langage ne peuvent pas avoir des conséquences catastrophiques.

Un effet Microsoft, qui l'a acheté et dont la transaction acquisition sera finie à la fin de l'année?

non

et la commande ?

xrandr --query |grep connect

ça serait étonnant le périphérique HDM apparaisse, mais autant vérifier. Sur ma machine, je n'arrive vraiment pas à voir dans quel fichier de log je peux tracer la connection/déconnection d'un cable HDMI.

Il y a quelques mois, j'avais des soucis lié à la détection des display (c'était un peu embêtant parce que c'était l'affichage principale de l'ordi portable qui n'était pas bien géré). J'ai du revenir sur une version antérieure du noyau (genre 4.15) pendant quelques mois et attendre la 4.18 pour que ça retombe en marche.

Vu que tu dis dans un autre message que ça a marché la semaine dernière. Est-ce que tu as fait une mise à jour du noyau depuis ?

que renvoie la commande suivante ?

xrandr  --listmonitors

ah oui, tiens. merci pour la correction. La lisibilité est un point tellement important pour moi que les retours à la ligne me paraissent nécessaires, même s'ils ne le sont techniquement pas.

ouais, ok, je n'avais pas correctement interprété le périmètre de "En tant que sysadmin" dans ton commentaire.

Je comprends qu'un sysadmin veuille un réseau plutôt homogène. Mais devoir administrer plusieurs distributions va à l'encontre de ce souhait d'homogénéité. La volonté de fonctionnement unifié pousserait plutôt vers l'utilisation d'une seule distrib, et dans ce cas, le système d'init n'a pas vraiment d'importance en terme d'homogénéité.

je n'aime pas quand chacun veut faire sa sauce et fonctionner comme il lui plait.

Ma question va sembler polémique, mais ce n'est pas le but. C'est juste que ce que je comprends m'étonne. Est-ce que permettre à chacun de faire ce qui lui plaît n'est pas l'essence du logiciel libre ?

je ne dis pas le contraire. Je dis juste que c'est difficile de faire la part des choses entre le gain éventuel de réactivité, l'augmentation de la complexité et l'augmentation des performances du matériel. Simplement dire que la réactivité est équivalente ou meilleure aujourd'hui avec l'augmentation de complexité n'est pas incompatible avec la possibilité que nos logiciels actuels soient "bloated".

Je ne dis pas que les systèmes modernes font "la même chose". Je dis juste que ça ne va pas de soi que le coût de l'augmentation de la complexité consomme une grande partie du gain de réactivité qu'on pourrait attendre de l'augmentation des performances du matériel.

Évidemment que Windows 10 est plus lent que Windows 95,

Ça n'a rien d'une évidence. On n'est pas à matériel constant. La loi de Moore sur 20 ans, c'est quand même une augmentation très significative de la performance brute.

il n'y a pas que des informaticiens qui lisent linuxfr. Et les plus jeunes informaticiens ne sont pas forcément encore au point en anglais.

En passant, si on pousse ton commentaire à sa conclusion logique, linuxfr n'a aucune raison d'exister …

Très intéressant, merci.

ouaip. J'ai pris un peu de temps pour la trad, ce que je fais rarement, mais je me disais que ça serait bien qu'il y a une version française dispo quelque part. Du coup, j'ai regardé, et il s'avère qu'il y en a déjà une :D

Si je puis me permettre : sans jamais essayé -> sans jamais essayer

j'en ai attrapée une poignée avant publication, mais celle là, je l'ai vu trop. Dans la même phrase, il y a aussi un "ou" qui traîne à la place d'un "où".

je me demande donc quelle est la différence entre les deux ?

c'est historique.

Après quelques recherches sur le web, j'ai retrouvé un article qui m'avait marqué sur le sujet: http://mobile.osnews.com/story.php/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

https://blog.w1r3.net/2018/01/06/rob-landley-about-usr-split.html propose une version amendée par l'auteur original, selon les dires de l'auteur de la note. Dans l'absolu, je ne sais pas évaluer la crédibilité, mais je ne vois pas bien quel serait l'intérêt de falsifier une telle mise à jour.

Pour les non-anglophones, voici un premier jet de traduction de la version amendée présentée dans le second lien:

--8<--
Vous savez que Ken Thompson et Dennis Ritchie ont créé Unix sur un PDP-7 en 1969 ? Et bien, vers 1971, ils sont passé à un PDP-11 et une paire de disques durs.

Quand leur système de fichier racine (root) est devenu trop gros pour tenir sur leur petit (un demi Mo) disque système, ils l'ont laissé déborder dans le pack disque RK-05, plus gros, mais plus lent. Le point de montage s'appelait /usr. parce que c'est dans ce disque que résidaient tous les répertoires home et utilisateurs. Ils ont répliqués tous les répertoires système dans le second disque (/bin, /sbin, /lib, /tmp, …) et enregistrés des fichiers dans ces nouveaux répertoires parce que leur premier disque était plein. Quand ils ont eu un second pack disque RK-05, ils l'ont monté sur /home et ont déplacé tous les répertoires utilisateurs sur ce troisième disque afin que leur OS utilise tout l'espace sur leurs deux premiers disques et croisse jusqu'à 3 Mo.

Bien sûr, ils ont établi des règles tel que "quand le système démarre, il doit pouvoir s'initialiser suffisamment pour pouvoir monter le second disque sur /usr, donc ne mettez pas des choses telles que la commande mount dans /usr/bin ou nous aurons un problème de l'oeuf et de la poule au démarrage du système". Le fait que leur petit disque système soit beaucoup plus rapide que le RK-05 a joué aussi: déplacer des fichiers de /bin vers /usr/bin avait un impact significatif sur les performances sur ce PDP-11 spécifique. Assez logique et aussi assez spécifique au matériel sur lequel Unix v6 a été développé il y a 40 ans. (NdT: à propos de la séparation /bin /usr/bin je pense)

La séparation entre /bin et /usr/bin (et toutes les autres) est un artefact de ce détail d'implémentation en 1970, qui a été reproduit pendant des décennies par des bureaucrates qui ne se sont jamais interrogé sur sa légitimité. Cette séparation a cessé d'avoir du sens bien avant la création de Linux, pour de multiples raisons:

1. les phases initiales du démarrage sont maintenant sous l'égide de initrd et initramfs, qui traitent des problèmes tels que "ce fichier est nécessaire avant celui ci". Nous avons aussi un système temporaire qui démarre le système principal.

2. les librairies partagées (introduites par les gens de Berkeley) interdisent la mise à jour indépendante de certains portions de /lib et /usr/bin. Ces deux partitions doivent être en concordance ou ça ne fonctionnera pas. Ce n'était pas le cas en 1974. À l'époque, il y avait une certain indépendance parce que tout était lié statiquement.

3. les disques durs pas chers du commerce ont dépassé les 100 Mo autour de 1990, et les logiciels de repartitionnement sont apparus à peu près à la même époque (partition magic 3.0 distribué en 1997). Bien sûr, cette séparation existante, certains ont inventé des nouvelles règles pour la justifier.

La racine (root) était pour les trucs système récupérés upstream et /usr pour les fichiers locaux. Ensuite, / était pour les trucs d'AT&T et /usr pour les trucs que ta distro, comme IBM AIX, Dec Ultrix ou SGI Irix, ajoutait, et /usr/local pour les fichiers spécifiques à ton installation. Plus tard, quelqu'un a décidé que /usr/local n'était pas un bon endroit pour installer des nouveaux paquets, donc ajoutons /opt ! Je m'attends encore à ce que /opt/local pointe son nez …

Bien sûr, depuis 30 ans, suite à cette séparation, d'intéressantes règles spécifiques à des distributions sont venues puis parties, telles que '/tmp est purgé à chaque redémarrage, mais pas /usr/tmp'. Sur Ubuntu, /usr/tmp n'existe pas, et sur Gentoo, /usr/tmp est un lien symbolique vers /var/tmp, que la règle est maintenant de ne pas purger au redémarrage.

Oui, tout ceci est antérieur à tmpfs. C'est lié à un système de fichier racine en lecture seule. /usr va toujours être en lecture seule dans ce cas, et l'espace en écriture se trouve dans /var. De plus, / est majoritairement en lecture seule, à l'exception de quelque parties de /etc, qu'ils ont essayé de déplacer vers /var, mais lier symboliquement /etc vers /var/etc arrive plus souvent qu'à son tour.

Les bureaucraties établissant des standards, telles que la Linux Foundation (qui a cannibalisé le Free Standard Group il y a des années dans son disque d'accrétion sans fin) a joyeusement documenté et ajouté ce type de complexité sans jamais essayé de comprendre d'ou ça venait au départ. "Ken et Dennis ont fait fuir leur OS sur l'équivalent de home parce que le disque racine de leur PDP-11 était trop petit" leur a filé au dessus de la tête.

--

J'essaye d'éviter toute dépendance externe (limiter le conky a son fichier conkyrc plus au pire l'image). Ceci afin d'éviter aux utilisateurs de devoir aller changer les PATH lors de l'installation.

admettons. L'écriture du script dans la ligne de commande avec des retours à la ligne reste possible (et plus lisible qu'une ligne de 10000 caractères :) ). Si ton éditeur de texte préféré fait de la coloration syntaxique pour sed, tu peux utiliser un fichier de script pour le dév, et recopier ton script dans la ligne de commande pour la version que tu distribues.

tu n'es pas obligé de piper tes sed dans des sed. Tu peux traiter des cibles différentes avec un seule invocation de sed. Exemple:

$ echo '1234\n5678' | sed -e '/1/{s/1/2/}
> /5/{s/5/6/}'
2234\n6678

Mais il faut des retours à la ligne pour séparer les différentes parties du script. Du coup, je te conseille de regrouper tous tes traitements sed dans fichier de script sed, que tu peux invoquer avec l'option -f de sed.

il est en vente chez gog. Je suis assez certain que la version windows qu'ils distribuent tourne sous un windows récent. Si je me souviens bien, ils le font tourner dans un dosbox. Du coup, je crois que j'ai réussi à le faire tourner avec dosbox sous Linux, mais il fallait que je modifie la résolution à la main (ou que je lance un second serveur X). Je ne souviens plus trop, c'était il y a un bon paquet de mois.

j'ai l'impression que dans ce fil, il y a confusion entre racisme et discrimination.

dans le contexte américain, le slogan "all lives matter" est une réponse à "black lives matter". Ça fait semblant de croire que "black lives matter" veut dire "only black lives matter" et que, les noirs n'ayant pas la vie plus dur que le reste de la population, il n'y a pas de raisons de les singulariser. Sauf que quand on regarde les statistiques, c'est très faux, surtout au regards des bavures policières. Alors évidemment, quand tu demandes aux gens, et qu'ils ne sont pas noirs, ils sont tous d'accord pour dire que toutes les vies comptes, et que dire que les noirs comptent, ça fait un peu communautaire. Mais au final, c'est encore une façon d'oppresser les noirs en niant la réalité du racisme structurel de la société américaine (je dis américaine parce que c'est le contexte, mais je crois qu'on peut élargir à un bon nombre de société européenne).

un petit bout de full frontal (en anglais). C'est une émission politiquement engagée, mais les micro trottoirs avec les participants à une convention américaine illustrent bien ça.

apparemment, il vaut mieux s'abstenir de tenter Overwatch avec Wine pour l'instant: https://tech.slashdot.org/story/18/09/14/2055209/some-linux-gamers-using-winedxvk-to-play-blizzards-overwatch-banned

l'article précise que ce n'est pas un choix de Blizzard, mais leur système anti-triche qui fait du zèle.

l’esclavage n’existe plus là bas

ça s'appelle système carcéral maintenant …

ou il y a peut-être une solution à base d'ACL, mais je ne m'en suis jamais servi. Je ne sais pas bien ce que ça peut faire. à creuser