L'argument comme quoi "Grâce à l’intelligence artificielle, les attaquants disposent désormais d’outils de détection de vulnérabilités d’une puissance inédite." est totalement ridicule.
1. Cela a toujours été le cas.
2. L'avantage du logiciel Open-Source est justement que beaucoup plus de relecteurs (IA ou pas) peuvent trouver les failles avant les personnes malveillantes.
3. On sait très bien trouver les failles d'un logiciels sans en disposer du code source. Décompilation, fuzzing… et avec l'IA cette étape est aussi simplifiée.
En fait avec l'IA on peut tout faire plus vite et rapidement. Mais fondamentalement cela ne change rien au niveau sécurité.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
C'est surtout qu'avec l'IA on peut tout justifier j'ai l'impression.
Je veux passer mon code open-source en code fermé : c'est à cause de l'IA !
Je n'ai plus les moyens d'embaucher car mon projet ne marche pas terrible : je vais raconter que l'IA marche tellement bien que je ne recrute plus !
Posté par Maderios .
Évalué à 5 (+3/-0).
Dernière modification le 18 avril 2026 à 15:29.
Une perle:
« Distribuer du code open source, c’est un peu comme donner les plans d’un coffre-fort », affirme-t-il (Bailey Pumfleet). « Et maintenant, on a cent fois plus de pirates informatiques qui les étudient. »
C'est comme si interdisait la vente du bois de menuiserie ou/et de plastoc sous prétexte que les voleurs vont fracturer les portes construites avec ces matériaux.
Une autre : « According to Hex Security, Open-Source Software is 5-10x more exploitable than closed source. […] Going closed source doesn’t make us impossible to hack, it reduces that risk by up to 10 times.» Et la source de stat 5-10x c'est une toute jeune startup de YC qui vend du "continuous AI penetration testing". Ça n'est pas mon domaine mais j'ai très souvent lu ici même que la sécurité par l'obscurité était une mauvaise idée… C'est sûrement plus facile de trouver un exploit si tu as le code, mais du coup c'est aussi plus facile de le patcher. Là avec cette affirmation j'ai l'impression que le CEO s'est mis une cible sur le dos.
En gros : Vikunja est en AGPL, n'a pas de CLA et n'a pas d'investisseurs, et même s'ils ferment leur code un jour quelqu'un pourra toujours le forker. Ce n'est pas hypothétique, disent-ils : c'est ce qui s'est passé quand Redis a fermé son code et que son fork Valkey a pris le dessus.
Attention que le bon vieux ncal (apparu dans FreeBSD 2.2.6, donc après novembre 1994, et fourni via les paquetages bsdmainutils ou ncal sous Debian) est plus jeune que le bon vieux cal (apparu dans la Version 5 AT&T UNIX, donc vers novembre 1971, et présent dans le paquetage util-linux) qui est dans le standard POSIX (Optional (XSI)). Tout comme gcal et tcal entre autres (dont calcol, lvsk btw, carl une nouvelle Rustplémentation, ainsi que module éponyme Py≥2.5 ou…), ce sont des commandes d’affichage de calendrier grégorien1…
Initialement, du fait de l’origine culturelle de ces commandes, c’est le calendrier grégorien strict. Mais rapidement la chose a été étendue au calendrier grégorien proleptique d’une part, et il existe des commandes pour d’autres systèmes calendaires (chinois, hébraïque, hégirien, jalali±, discordien, etc.) d’autre part. ↩
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je voyais pas trop non plus comment on en serait arrivé à changer la licence de bsdmainutils. Le lien est derrière un paywall donc j'ai aucune idée de quoi il s'agit mais j'ai pas l'impression de perdre grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Ridicule
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
L'argument comme quoi "Grâce à l’intelligence artificielle, les attaquants disposent désormais d’outils de détection de vulnérabilités d’une puissance inédite." est totalement ridicule.
1. Cela a toujours été le cas.
2. L'avantage du logiciel Open-Source est justement que beaucoup plus de relecteurs (IA ou pas) peuvent trouver les failles avant les personnes malveillantes.
3. On sait très bien trouver les failles d'un logiciels sans en disposer du code source. Décompilation, fuzzing… et avec l'IA cette étape est aussi simplifiée.
En fait avec l'IA on peut tout faire plus vite et rapidement. Mais fondamentalement cela ne change rien au niveau sécurité.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Ridicule
Posté par alkino . Évalué à 8 (+6/-0).
C'est surtout qu'avec l'IA on peut tout justifier j'ai l'impression.
Je veux passer mon code open-source en code fermé : c'est à cause de l'IA !
Je n'ai plus les moyens d'embaucher car mon projet ne marche pas terrible : je vais raconter que l'IA marche tellement bien que je ne recrute plus !
[^] # Re: Ridicule
Posté par Voltairine . Évalué à 7 (+5/-0).
Bah oui, il suffit de demander à l'IA une justification argumentée.
[^] # Re: Ridicule
Posté par Maderios . Évalué à 5 (+3/-0). Dernière modification le 18 avril 2026 à 15:29.
Une perle:
C'est comme si interdisait la vente du bois de menuiserie ou/et de plastoc sous prétexte que les voleurs vont fracturer les portes construites avec ces matériaux.
[^] # Re: Ridicule
Posté par Faya . Évalué à 6 (+4/-0).
Une autre :
« According to Hex Security, Open-Source Software is 5-10x more exploitable than closed source. […] Going closed source doesn’t make us impossible to hack, it reduces that risk by up to 10 times.» Et la source de stat 5-10x c'est une toute jeune startup de YC qui vend du "continuous AI penetration testing". Ça n'est pas mon domaine mais j'ai très souvent lu ici même que la sécurité par l'obscurité était une mauvaise idée… C'est sûrement plus facile de trouver un exploit si tu as le code, mais du coup c'est aussi plus facile de le patcher. Là avec cette affirmation j'ai l'impression que le CEO s'est mis une cible sur le dos.
# La réponse de Vikunja
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 7 (+5/-0). Dernière modification le 18 avril 2026 à 11:42.
"On Cal.com, AI security reports, and why Vikunja can't easily close"
En gros : Vikunja est en AGPL, n'a pas de CLA et n'a pas d'investisseurs, et même s'ils ferment leur code un jour quelqu'un pourra toujours le forker. Ce n'est pas hypothétique, disent-ils : c'est ce qui s'est passé quand Redis a fermé son code et que son fork Valkey a pris le dessus.
[^] # Re: La réponse de Vikunja
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Comment tu vois ça ?
Sur le docker hub redis reste encore bien au dessus de valkey, google trend place encore redis devant, popcon place redis devant valkey
Valkey est en progression mais je n'ai pas l'impression qu'il est pris le dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La réponse de Vikunja
Posté par aiolos . Évalué à 3 (+1/-0).
C’est ce qu’ils disent dans l’article cité, et qui justifierait le retour de Redis à l’AGPL.
[^] # Re: La réponse de Vikunja
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C'est un peu du téléphone arabe…
On passe de Salvatore Sanfillipo a réussi à dire que sur le long terme le libre a de la valeur qui devient valkey a pris le dessus.
Les données temporelles que j'ai donné ne corroborent pas du tout que valkey ai pu devenir une source d'inquiétude pour redis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La réponse de Vikunja
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C'est un peu du téléphone arabe…
On passe de Salvatore Sanfillipo a réussi à dire que sur le long terme le libre a de la valeur qui devient valkey a pris le dessus.
Les données temporelles que j'ai donné ne corroborent pas du tout que valkey ai pu devenir une source d'inquiétude pour redis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La réponse de Vikunja
Posté par steph1978 . Évalué à 3 (+1/-0).
C'est parce que valkey prenait le dessus que redis a fait machine arrière. En redevenant open source, ils ont évité de dégringoler.
# plus de peur que de ncal
Posté par bistouille . Évalué à 10 (+8/-0).
J'ai vraiment pensé une seconde qu'on parlait de /usr/bin/cal mais non, ouf ce n'est pas notre bon vieux ncal :-)
[^] # Re: plus de peur que de ncal
Posté par zurvan . Évalué à 2 (+0/-0).
ouaip !
heu… même pas vrai (j'utilise le calendrier de nextcloud et ça me va bien)
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: plus de peur que de ncal
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Attention que le bon vieux
ncal(apparu dans FreeBSD 2.2.6, donc après novembre 1994, et fourni via les paquetagesbsdmainutilsouncalsous Debian) est plus jeune que le bon vieuxcal(apparu dans la Version 5 AT&T UNIX, donc vers novembre 1971, et présent dans le paquetageutil-linux) qui est dans le standard POSIX (Optional (XSI)). Tout commegcalettcalentre autres (dontcalcol,lvskbtw,carlune nouvelle Rustplémentation, ainsi que module éponyme Py≥2.5 ou…), ce sont des commandes d’affichage de calendrier grégorien1…Une application de planification par contre permet de gérer électroniquement un agenda (c’est pourquoi je préfère l’appellation planner en anglais.)
En interface textuelle (TUI), il y a beaucoup de candidats : Enhanced Cal de Alex Matulich (paquet et commande
ccaldans Ubuntu la dernière fois que j’ai regardé),pal,khal,calcurse,calcure,when(qui est un peu le pendant de todo.txt),remind(qui est un cousin deatetcronavec un format textuel simple et épatant, auquel on peut adjoindre un frontal commewyrdoutkremindpar exemple), Calendar.vim (à ne pas confondre avec l’afficheur synonyme, ni avec le journal par wiki, c’est un frontal à Google C…) etgcalcli,taskwarrior(dans une certaine mesure),timemap, Emacs calfw avec OrgMode, etc.En interface graphique (GUI), la plupart des bureaux (DE) fournissent leur appli et il y a pas mal d’autres choix pour que l’on ne s’inquiète pas trop qu’un ferme la porte …tant qu’on utilise les formats ouverts. En vrac, qui semblent pérennes : KOrganizer, Evolution, Osmo, Gnome Calendar, etc.
Initialement, du fait de l’origine culturelle de ces commandes, c’est le calendrier grégorien strict. Mais rapidement la chose a été étendue au calendrier grégorien proleptique d’une part, et il existe des commandes pour d’autres systèmes calendaires (chinois, hébraïque, hégirien, jalali±, discordien, etc.) d’autre part. ↩
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: plus de peur que de ncal
Posté par bistouille . Évalué à 2 (+0/-0).
Merci pour les précisions.
Je ne connaissais pas tous ces "planners" en mode texte, je vais regarder ça de plus près.
[^] # Re: plus de peur que de ncal
Posté par Krunch (courriel, site web personnel) . Évalué à 5 (+3/-0).
Je voyais pas trop non plus comment on en serait arrivé à changer la licence de bsdmainutils. Le lien est derrière un paywall donc j'ai aucune idée de quoi il s'agit mais j'ai pas l'impression de perdre grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.