totof2000 a écrit 2049 commentaires

je suis sûr (je n'ai même pas besoin d'essayer) que si je demande à une IA type Claude ou autre d'analyse le dépôt, de me lister les incohérences ou les redondances de ce type et de me proposer des correctifs, elle le fera sans problème.

Je suis sûr que les propositions qu'elle te feravont introduire d'aitres incohérences … Et tu vas tourner en boucle comme ça presque indéfiniment

Pour être honnête, je suis même étonné que ça n’existe pas encore !

Moi je suis juste étonné que PHP existe encore …

Il n'y a pas de sujet. Je ne VEUX PAS lire ce genre de document généré par IA : j'en trouve assez dans mon boulot au quotidien. Et pour ma part, lorsque je me fais aider par l'IA pour en générer un, je m'arrange par respect pour mes lecteurs de faire en sorte qu'elle ait le moins l'air possible d'être généré par IA.

Parce que non, je ne suis pas anti-IA. Je l'utilise au quotidien, que ce soit pour mon boulot ou pour des trucs plus perso, mais JAMAIS je ne la laisse rédiger un texte sans rester maître de ce qui est écrit.

Parce que l'IA c'est un style "Harlequin" : des phrases mises bout a bout qui ont l'air bien mais qui donnent un texte creux, qui ne veut rien dire, avec des phrases du style 'pas machin' à répétition ou alors 'ceci, pas celà" qui est un style à gerber (ça c'est surtout Claude, mais Chatgpt le fait peut-être maintenant) avec des phrases qui se contredisent …

Utiliser l'IA pour aider à formuler certaines idées, faire une correction grammaticale ou orthographique, ou pour reformuler certains morceaux de textes, pourquoi pas, tant que son utilisation clarifie ou améliore le texte généré. Mais pitié, arrêtez de l'utiliser pour générer un texte complet, que ce soit de la doc, des spécifications, etc …. Bien souvent le texte généré est illisible, pénible à comprendre, contradictoire, et on décroche avant même d'avoir fini. Et on ne s'intéresse plus au sujet PARCE QUE la présentation de celui-ci est merdique.

A la première lecture je pensais que tu parlais d'un outil de build automatisé sous git.

Ca a l'air généré par Claude

Formats ouverts, mais pas exclusivement

Pas uniquement Word + Excel + PowerPoint

Pas parce que le logiciel est "terminé".

Et pas non plus parce que je pense avoir trouvé le remplaçant de LibreOffice, Microsoft Office ou Google Docs.

Le genre de tournure que je déteste dans les textes générés par IA.

Mais c'est sûr qu'ils trouveront ça pénible.

Ma fille a utilisé Linux pendant des années sans trouver ça pénible. Je ne vois pas pourquoi ça le serait d'ailleurs.

Elle a demandé un windows quand elle est arrivée en université juste pour se familiariser avec mais elle a gardé Linux comme système prncipal.

Ouais enfin, un exemple foireux reste un exemple foireux hein. Et les choix politiques du même acabit que ceux cités en exemple se trouvent plutôt dans les couches hautes du système (là ou on est à la limite entre système d'exploitation en lui même et la couche applicative, même si elle est aujourd'hui intégré à ce qu'on appelle "système d'exploitation").

Euh … Les exemples cités sont vraiment foireux : ils n'ont rien à faire dans le noyau et les couches systèmes basses ….

J'entends bien les arguments sur SNAP et le flou par rapport à l'IA, mais il y a un autre argument qui me fait tiquer :

la lenteur des correctifs : TUXEDO pointe également du doigt des délais de déploiement parfois trop longs pour certaines mises à jour de sécurité critiques au sein des dépôts d’Ubuntu.

Combien paye TUXEDO pour avoir une distribution sécurisée rapidement ? Peut-être le font-ils, je ne sais pas, mais ils devraient peut-être verser un peu plus pour avoir ces mises à jour rapidement non ? Parfois j'entends certains râler pour les délais e correction de failles de sécurité sur des logiciels libres et dispo gratuitment, mais ces gens se plaignent alors qu'ils ne paient même pas, d'ou mon interrogation à propos de Tuxedo.

2 ans pour les moins chers ( parfois obsolète s à peine achetés)

bienvenue dans le sectarisme moderne qui malheureusement n'épargne pas linuxfr.

1/ Pour apprendre à faire une mise à jour plus tard :D ?

2/ Peut-être pour éviter d'essuyer les plâtres sur une distrib trop récente ? (perso je laissee toujours au moins 3 mois avant de faire les MAJ LTS chez moi).

3/ Parce qu'il ne savait pas ? (la réponse la plus probable à mon avis).

Je rencontre tellement de gens, y compris professionnellement, qui sont incapable de debugger es problèmes de perf sur des systèmes containerisés, qui copient/collent des lignes dans des dockerfiles sans savoir ce qu'il font.

Je ne peux malheresement que constater la même chose. Et l'expérience que j'ai avec les IA me montre qu'elle fait souvent la même chose ( je l'ai constaté avec Claude qui souvent part en boucle dans des tentatives de réslution en cascade en essayant des trucs à la con alors que pour résoudre le probème il suffit de s'arreter, et de chercher à comprendre - en lisant la doc - comment fonctionne le truc).

Par exemple pf moi la syntaxe me rentre pas dans la tête. Je sais que le but c'est que ça ressemble à du langage naturel, mais je sais pas si c'est que mon niveau en anglais est pourri ou si c'est une sorte de vallée de l'étrange.

Ben je ne sais pas pourquoi tu n'accroches pas mais honnetement, j'ai essayé IPFilter (puis Packet Filter plus tard), et honnetement je ne reviendrai jamais à IPTable ou dérivés. Mais comme tu le dis c'est peut-être un problème avec l'anglais … D'ailleurs un exemple pour s'en convaincre.

Le code Packet Filter :

# Macros
int_if="rl0"
ports_ouverts_pour_tous="{ http https }"
ports_ouverts_pour_lequipe="{ ssh 21 60000:60100 }"

# Tables
table <ip_de_lequipe> { XYZ.XYZ.XYZ.XYZ, XYZ.XYZ.XYZ.XYZ, XYZ.XYZ.XYZ.XYZ }

# Normalisation du trafic
scrub in no-df

# NAT
nat on egress -> (egress)

# Règles de filtrage
block in
pass out keep state
pass in on egress proto tcp from <ip_de_lequipe> to port $ports_ouverts_pour_lequipe
pass in on egress proto tcp to port $ports_ouverts_pour_tous
block in quick on $int_if proto tcp from $int_if:network to port 4662
pass quick on !egress

La même chose en iptable (issu de chatgpt donc à prendre avec des pincettes) :

#!/bin/sh
set -eu

int_if="rl0"
egress_if="eth0"
int_net="192.168.1.0/24"

ip1="XYZ.XYZ.XYZ.XYZ"
ip2="XYZ.XYZ.XYZ.XYZ"
ip3="XYZ.XYZ.XYZ.XYZ"

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

# Différence avec "scrub in no-df" : iptables n'a pas d'équivalent direct ; TCPMSS ne traite que le MSS TCP sur les paquets SYN routés.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables -t nat -A POSTROUTING -o "$egress_if" -j MASQUERADE

iptables -A INPUT -i "$int_if" -s "$int_net" -p tcp --dport 4662 -j DROP
iptables -A FORWARD -i "$int_if" -s "$int_net" -p tcp --dport 4662 -j DROP

iptables -A INPUT -i "$int_if" -j ACCEPT
iptables -A FORWARD -i "$int_if" -j ACCEPT

iptables -A INPUT -i "$egress_if" -p tcp -s "$ip1" -m multiport --dports 22,21,60000:60100 -j ACCEPT
iptables -A INPUT -i "$egress_if" -p tcp -s "$ip2" -m multiport --dports 22,21,60000:60100 -j ACCEPT
iptables -A INPUT -i "$egress_if" -p tcp -s "$ip3" -m multiport --dports 22,21,60000:60100 -j ACCEPT

iptables -A INPUT -i "$egress_if" -p tcp -m multiport --dports 80,443 -j ACCEPT

Avec nftables (toujours issu de chatgpt pour être transparent) :

#!/usr/sbin/nft -f

flush ruleset

define int_if = "rl0"
define egress_if = "eth0"
define int_net = 192.168.1.0/24

table inet firewall {
    set ip_de_lequipe {
        type ipv4_addr
        elements = { 198.51.100.10, 198.51.100.11, 198.51.100.12 }
    }

    set ports_ouverts_pour_tous {
        type inet_service
        elements = { 80, 443 }
    }

    set ports_ouverts_pour_lequipe {
        type inet_service
        flags interval
        elements = { 22, 21, 60000-60100 }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        ct state established,related accept
        iifname "lo" accept

        iifname $int_if ip saddr $int_net tcp dport 4662 drop
        iifname != $egress_if accept

        iifname $egress_if ip saddr @ip_de_lequipe tcp dport @ports_ouverts_pour_lequipe accept
        iifname $egress_if tcp dport @ports_ouverts_pour_tous accept
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        ct state established,related accept

        iifname $int_if ip saddr $int_net tcp dport 4662 drop
        iifname != $egress_if accept

        iifname $egress_if ip saddr @ip_de_lequipe tcp dport @ports_ouverts_pour_lequipe accept
        iifname $egress_if tcp dport @ports_ouverts_pour_tous accept
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        oifname $egress_if masquerade
    }
}

table inet mangle {
    chain forward {
        type filter hook forward priority mangle; policy accept;

        # Différence avec "scrub in no-df" : nftables n'a pas d'équivalent direct complet ; cette règle ne traite que l'ajustement MSS TCP, pas la normalisation PF ni le retrait global du bit DF.
        tcp flags syn tcp option maxseg size set rt mtu
    }
}

Pour ma part je trouve que Packet Filter reste bien plus lisible et compréhensible que IPTable ou NFtable.

D'ailleurs c'est vraiment un truc à savoir en passant de linux à BSD, c'est que les perfs vont morfler.

t'as pas un peu l'impression d'exagérer là ? :)

En terme de perf, FreeBSD n'a pas forcément grand chose à envier à Linux en général. Il y a certainement des usages ou effectivement il sera en dessous, mais dire que "les perfs vont morfler", mis à part cas précis et besoins spécifique, je pense que c'est vraiment exagérer.

Par contre pour NetBSD et OpenBSD, sans aller jusqu'à dire que "les perfs vont morfler", je dirais que les perfs ne sont pas la priorité pour ces deux derniers : l'un favorise la portabilité (NetBSD - on trouve un tas de machines/CPU sur lequel tourne ce système), l'autre la sécurité (Openbsd), parfois effectivement au détriment des perfs. Mais pour la plupart des usages (hors jeux ) il n'y aura pas de différences perceptibles.

Il faut avoir joué avec IPFilter ou Packet Filter pour se rendre ompte à quel point gérer des règles de firewall est bien plus facile sous xBSD que sous Linux par exemple …

Le règles iptables sont à gerber ….

Loin d'être inutile, au contraire. J'adore ce genre d'analogie.

Faudrait apprendre un peu à contextualiser quand vous voyez des mots dans un phrase, plutôt que de jouer les chiens de Pavlov et de passer votre temps à vouloir censurer tout et tout le monde juste pour donner plus d'importance que vous en avez.

Bah, comme on dit, "l'argent n'a pas d'odeur" …. Linux était un cancer tant qu'ils ne pouvaient pas se faire d'argent avec. Aujourd'hui, ils ont trouvé un modèle économique pour faire payer leurs clients, donc pour eux c'est bon.

Nul doute que si un jour, ils trouvent moyen de développer une distribution Linux qui leur rapportera beaucoup beaucoup d'argent, ils le feront.

Internet a été justement conçu pour résister à ce type d'attaques. Quand je luis que "Les conséquences militaires et stratégiques d’une coupure des câbles pourraient être plus graves encore. Les armées dépendent de communications sécurisées sur de longues distances et d’une coordination en temps réel." … Ca me fait bien rire. Au pire on aura un ralentissement global, on ne ourra peut-être pas lire des flux venus des US en 4k, mais rien ne sera bloqué si l'Iran coupe des cables ….

… Pour financer les dépenses des entreprises en jetons IA, il suffira de licencier les employés.

Si tu lui demandes "remplace les printf par des cout dans ce code C++", il ne va pas te demander "est-ce que je remplace aussi les sprintf?", puis "est-ce que je remplace aussi les fprintf?", puis "est-ce que tu veux que je remplace aussi les printf(stderr, …) par cerr?", etc. C'est un coup à devenir dingue, tu vas finir par écrire "ARRETE DE POSER DES QUESTIONS ET REMPLACE TOUS CES P*** DE PRINTF".

Ben justement : pour ma part je m'attends à ce que l'IA me pose ces questions plutôt que de prendre l'initiative et d'extrapoler. Je perds beaucoup plus de temps à corriger les extrapolations erronées de l'IA, et à lui rappeler de ne pas supposer qu'à confirmer les questions qu'elle pourrait me poser.

Le message qui est passz (en tout cas celui que j'ai perçu), c'est "A cause de Microsoft, des tas de PC sont morts et enterrés" … Le message sous-jacent "SVP Mr Microsoft, veuillez faire quelque chose pour éviter ça" … Et du coup, ma perception est que l'APRIL s'associe à cette demande. Pas très cohérent. Message brouillé.

A la limite l'April aurait pu intervenir dans la mise en scène (en cosplay manchot qui ressucite les PC morts et enterrés pour y installer un Linux par exemple). Mais là c'est pas terrible je trouve.

OK il faut RTFM mais si tu dois t'attendre à ce que la documentation réinvente les définitions des mots ça reste problématique.

Bienvenue dans le XXIeme siècle ou tout le monde réinvente sa propre définition des mots.

Alors, si. L'appel simple devrait retourner une erreur si le volume est utilisé. Et une option dans l'appel pour "forcer". C'est ce que fait l'API AWS de mémoire ; voire même, la deuxième option n'existe pas : il faut détacher le volume avant de le supprimer.

Effectivement, s'il s'agit d'un volume attaché à une VM, l'appel ne devrait pas aboutir. Mais dans ce cas précis, je ne suis pas convaincu que ça aurait changé grand chose …

Et il y a aussi des services cloud qui proposent de "locker" une ressource : tu dois faire un "unlock" avant de faire un "delete". Cela permet de pas se foirer lors d'un appel en masse.

La aussi, ça n'aurait pas changé grand chose, car l'IA semblait avoir récupéré un token qui lui aurait permis de faire tout ça …. Ca se serait fait en plus d'appels API.

Et aussi, le plus sûr, quand tu delete, ça delete pas tout de suite. Et tu as 24h pour ouvrir un ticket pour qu'on se sauve tes données.

C'est peut-être la seule mesure qui aurait permis de récupérer rapidement les données.