Alors personnellement, j'ai joué à tous les Fallout (1,2 et tactics). Vu à boy and his dog, La Jetée et Le Sang des héros.
Bah, c'est quand même un peu sympas le monde post-hiver nucléaire.
Bah ça me semble logique que Rust apporte plus, vu qu'il me semble que zig a pour but de rester un langage assez simple.
Donc moins de manière d'exprimer la même chose.
Rust, c'est cool, mais les code avec 8 itérateurs chainé, ce n'est pas ce qu'il y a de plus simple ni de plus reposant à lire.
Si je ne dis pas de connerie, GNU coreutils ne dépend que de libc + GNUlib.
GNUlib est static, et libc est aussi une dépendance des packages Rust. (Oui, elle est désactivable, mais généralement par défaut non)
Donc dans ce cas, la comparaison est plutôt équivalente.
De manière générale, les packages Rust, ont tendance à contenir beaucoup plus de dépendances que les packages C, principalement dû à la manière donc la gestion de dépendances marche en Rust, qui tire des dépendances, qui tire des dépendances… (mais par contre est facile)
En C, la gestion de dépendances, c'est chiant, mais vu que c'est chiant, bah, on évite d'en avoir trop, surtout quand ce sont des bibliothèques pas très rependues.
En C goto ne le permet pas, il faut passer par le couple setjmp/longjmp.
Ce qui est ultra casse-gueule, et mérite d'êtres expliqué si utilisé, mais a de rares use-case, tel que recoder des pseudo-exceptions en C. (et rendre fous qui voudrait déboguer ça).
Après les exceptions, c'est à peu près un goto, d'une fonction à une autre, mais avec des clean automatique, en plus. (et aussi forcent à sauter vers une fonction appelante, et pas le contraire).
Les generator function en js peuvent aussi s'apparenter à des goto, qui saute dans une autre function.
Bref oui, ce n'est pas ouf les goto entre des functions, mais au final la plupart des langages moderne en ont quelques utilités, si on n'a ni yield ni exeption, mais on en a l'utilité, ça reste aux dev de prendre soins de pas casser ça stack, et gérer ces ressources (et essayer de fuir le projet), mais peu encore être utils.
Alors en C utiliser goto, est une bonne pratique, car ça te permet les goto chaîne, et justement clean les choses que tu as allouées/ouvertes.
Si tu fais du C, sans goto, ni attribute((cleanup)) ton code est crade.
Et vérifier malloc, à part si tu codes sur machine à laver/arduino ou autre machin embarqué, ça ne sert à rien, malloc ne te retourneras pas NULL s'il manque de place. (bon bien sûr, l'embarqué reste des cibles potentielles de beaucoup de lib, donc ça reste un gros use-case).
Perso, je suis un peu con, mais en général, entre deux codes, un long et sans goto, et un plus court, mais avec goto, je prends celui avec goto, et généralement, je le trouve plus simple à lire, il y a moins de code.
Reste que C/go sont assez structurés pour en avoir rarement besoins, mais dans certains rares cas, qui arrive à peu près une fois toutes les 2k lignes de code, un goto, ça simplifie le code. (sauf si on est en C, pas GNU C, dans ce cas, c'est dans une fonction sur 2 pour les erreurs).
Et si on a élevé les dev à éviter goto, c'est je pense à cause des traumatisés de BASiC, sauf que les goto en C n'ont rien à voir.
Et personnellement, j'utilise les goto, quand ça me semble simplifier le code.
Par contre, quand on lit ce code, on se dit qu'on gagnerait bien en lisibilité avec un langage structuré, et c'est probablement contre ce genre de code que Dijkstra a écrit goto-considered-harmful.
Mais ça montre aussi que l'usage de goto tel qu'on peut trouver dans un code Kernel par exemples, n'a vraiment rien à voir, avec l'usage des goto de BASIC en 79.
Je suis le seul, qui me suis dit ça, en ouvrant le repos Github, espérant tomber sur le code du fork, mais juste une promesse de bientôt le mettre ?
Enfin, ils disent avoir plein de dev qui ont promis travailler dessus, mais je trouve que ce genre d'annonce sans au moins un code qui marchotte ça ne met pas en confiances.
Surtout que souvent les forks de ce genre qui marche montre très vite une base de code (mate, tenacity, PrismLauncher…)
Je suppose, que tu passes l'option "Ajouter un jeu non Steam à ma bibliothèque", puis dans le menu compatibilité, tu choisis quelle version de proton, tu veux utiliser.
C'est ça, on peut aussi rajouter qu'il pense que ça a été mi à 9.8, car c'est un interger overflow, que les gents ont vu interger overflow, et ont donc mis une grosse note.
Il a rajouté qu'il est contant qu'Ubuntu a pris le devant et ont marqué la CVE comme "non affectant".
Y'a 2h un pote me parlais des cochons de guerres, et me disaient que ça marche plus soue Windows, j'ai regarder soue protonDB, ça marche parfaitement.
Bon anecdote a part, mais de manière général, les jeux pas maintenue pre-windows 7, on autant de chances de marcher soue windows que linux.
En contre exemples j'ai Seven Kingdoms 2 qui est assez casse tête à faire marcher soue Arche Linux, mais a l'air de bien marcher soue Windows. (mais n'ayant que des Arch linux BTW ou dérivé, je n'ai pas tester)
sauf que un code qui marche avec -O3, mais pas sans ça, personnellement, j’appelle ça un code cassée.
Pas qu'il ne fasse jamais faire du récursive, mais s'appuyer sur l’hypothèse que le compilateur va optimiser ton code pour qu'il marche, font pleurer les heures que j'ai passer à utiliser/modifier tinycc.
Mais le truck, c'est que dans un code qui utilise un langages fonctionnel, tu risque de voir plus de récursion que de boucles.
Si quelqu'un viens te dire:
toute personne qui écrit une while ou un for à intérêt à l’accompagner d’un commentaire qui justifie pourquoi c’est une bonne idée de faire ça
Peu être que tu va te dire que c'est un peu abusé. (ceci dit ça m'étonnerais pas que des dev haskell aient déjà dit ce genre de choses)
Et je peu rejoindre que sur du C, justifier que l'on risque pas d'exploser la stack est une bonne choses. (et utiliser musttail je considère ça comme du self documentes code donc pas forcement besoins d'un autre commentaire)
Ce qui fait réagir, c'est de pas l'avoir dit dans le contexte d'un langage particulier.
Je connaissaient pas musttail, et je te remercie de ton commentaire, parce-que ça va contredire ce que je vais dire, mais dans les cas sans musttail même si les compilateur gére la récursion terminal, ça reste au bon vouloir des optimisation, et si on sait que l'on peu exploser ça stack avec un récursion, je l'utiliserais pas. surtout que avec un -O0, bah ça va pas optimiser, et -O0, ça reste bien pratique pour du debug.
Après pour moi le cas de la lisibilité, c'est vraiment un question de connaître les idiomes du code qu'on patch, et s'y adapter.
La on parle de récursions, mais ça peu s'adapter a n'importe quel code. C'est toujours embêtant d'expliquer à quelqu'un qui rentre dans un code libre et essaye de modifier le code pour qu'il lui convienne mieux en appliquant par exemple, ce qu'on lui a apprit a l'école au détriment du style déjà utilisé dans le projet, qu'il ferais mieux de juste imiter le coding style des autres fonctions du projets.
Mais la lisibilité, c'est énormément lier aux pratique utiliser dans un langages de programmations, et si t'a de la récursion dans toutes t'a lib standard (genre en ocaml), que la moitiés des idioms de ton languages utilise de la récursion, tu va justement plus rebuter les gents qui sont habituer à coder en fonctionnel, en leur imposant une boucle, la ou la plupart des dev auraient mit de la récursions.
en vrais je sais pas si un WM peu marcher sur XWayland, donc je pose ça pour savoir si c'est possible, et qu'est ce qui pourrait empêcher que ça marche dessus ?
Enfin il est pas très vivant pour autant, mais Sneedacity reste une situation assez différentes, ou c'est fait après plein de fork d'Audacity (Tenacity, Sneedacity et Audacium(qui il me semble avais reprit du code de Sneedacity)), et on savaient pas quel fork allais prendre le dessus.
plus le fait que le truck est partie de 4chan, avec un gros harcèlement contre les gets de tenacity, et un développement assez bordélique.
Je suis pas sur, mais il me semble que la GPL dit plus:
"On ne garantie pas le program, autant que la loi applicable ne le permet." donc si la loi vous oblige a garantir le program (genre ce que l'UE veut faire passer) bah on garantie ce que la loi nous oblige a garantir (mais je peu me tromper)
Ici on parle des license qui disent "vous ne devez pas utilisez ce program pour faire quelque choses d’illégal".
L'ipadic comme cité plus haut dit ca:
Each User may also freely distribute the Program, whether in its
original form or modified, to any third party or parties, PROVIDED
that the provisions of Section 3 ("NO WARRANTY") will ALWAYS appear
on, or be attached to, the Program, which is distributed substantially
in the same form as set out herein and that such intended
distribution, if actually made, will neither violate or otherwise
contravene any of the laws and regulations of the countries having
jurisdiction over the User or the intended distribution itself.
en google trad:
Chaque Utilisateur peut également distribuer librement le Programme, que ce soit dans son
forme originale ou modifiée, à un tiers ou à des tiers, À FOURNI
que les dispositions de la section 3 (" AUCUNE GARANTIE ") apparaîtront TOUJOURS
sur, ou être attaché à, le programme, qui est distribué substantiellement
sous la même forme que celle indiquée ici et que tel prévu
la distribution, si elle est effectivement effectuée, ne violera ni ne violera autrement
enfreindre les lois et réglementations des pays ayant
juridiction sur l'utilisateur ou la distribution prévue elle-même.
Qui peu être plus tricky, si par example tu utilise une lib avec une tel license et veut bug fix pour que ton client torrent marche mieux pour télécharger des truck illégal, bah t'a pas le droit de contribuer. (ou du moins de distribuer, t'a version patcher.)
1er question:
pourquoi ?
je veut dire, est-ce qu'une license qui utilise une tel clause a récemment fait parler d'elle ?
2ème question:
Pourquoi ?
Est-ce que ça étonne quelqu’un que "il faut respecter la loi", c'est ultra différent en function de ou est utiliser la licence? écrire ça en ayant en tête la loi de son pays, c'est au mieux faire preuve d'une grande naiveté ?
Bon j’hésitais a mettre un truck raciste des étasunien pour dire qu'ils ont du mal a imaginer le monde autrement que dans une vision très étasunienne, et ça peu expliquer ce genre d'article, mais je suis pas sur que ça soie bien venue ici.
[^] # Re: no future
Posté par uso (site web personnel) . En réponse au lien Enquête - Les jeunes, gros consommateurs d'alcool : « il faut boire pour s'intégrer ». Évalué à 2.
Alors personnellement, j'ai joué à tous les Fallout (1,2 et tactics). Vu à boy and his dog, La Jetée et Le Sang des héros.
Bah, c'est quand même un peu sympas le monde post-hiver nucléaire.
[^] # Re: bien mais pas top
Posté par uso (site web personnel) . En réponse à la dépêche De Zig et des zags. Évalué à 2.
Bah ça me semble logique que Rust apporte plus, vu qu'il me semble que zig a pour but de rester un langage assez simple.
Donc moins de manière d'exprimer la même chose.
Rust, c'est cool, mais les code avec 8 itérateurs chainé, ce n'est pas ce qu'il y a de plus simple ni de plus reposant à lire.
[^] # Re: taille de binaire
Posté par uso (site web personnel) . En réponse au lien exa is unmaintained…. Évalué à 3.
Si je ne dis pas de connerie, GNU coreutils ne dépend que de libc + GNUlib.
GNUlib est static, et libc est aussi une dépendance des packages Rust. (Oui, elle est désactivable, mais généralement par défaut non)
Donc dans ce cas, la comparaison est plutôt équivalente.
De manière générale, les packages Rust, ont tendance à contenir beaucoup plus de dépendances que les packages C, principalement dû à la manière donc la gestion de dépendances marche en Rust, qui tire des dépendances, qui tire des dépendances… (mais par contre est facile)
En C, la gestion de dépendances, c'est chiant, mais vu que c'est chiant, bah, on évite d'en avoir trop, surtout quand ce sont des bibliothèques pas très rependues.
# la suite
Posté par uso (site web personnel) . En réponse au lien [curl] CVE-2020-19909 is everything that is wrong with CVEs. Évalué à 3.
https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
[^] # Re: Si vous voulez comprendre la haine du goto,
Posté par uso (site web personnel) . En réponse au lien Portage du jeu Akalabeth, avec le listing basic (qui pourrait heurter les plus jeunes d'entre vous). Évalué à 4. Dernière modification le 05 septembre 2023 à 11:20.
En C goto ne le permet pas, il faut passer par le couple setjmp/longjmp.
Ce qui est ultra casse-gueule, et mérite d'êtres expliqué si utilisé, mais a de rares use-case, tel que recoder des pseudo-exceptions en C. (et rendre fous qui voudrait déboguer ça).
Après les exceptions, c'est à peu près un goto, d'une fonction à une autre, mais avec des clean automatique, en plus. (et aussi forcent à sauter vers une fonction appelante, et pas le contraire).
Les generator function en js peuvent aussi s'apparenter à des goto, qui saute dans une autre function.
Bref oui, ce n'est pas ouf les goto entre des functions, mais au final la plupart des langages moderne en ont quelques utilités, si on n'a ni yield ni exeption, mais on en a l'utilité, ça reste aux dev de prendre soins de pas casser ça stack, et gérer ces ressources (et essayer de fuir le projet), mais peu encore être utils.
[^] # Re: Si vous voulez comprendre la haine du goto,
Posté par uso (site web personnel) . En réponse au lien Portage du jeu Akalabeth, avec le listing basic (qui pourrait heurter les plus jeunes d'entre vous). Évalué à 2.
Âpres lua n'a pas de
continue(ou n'en avait pas en 5.3), donc legotoen lua est ultra-utile juste pour remplacer lescontinue.[^] # Re: Si vous voulez comprendre la haine du goto,
Posté par uso (site web personnel) . En réponse au lien Portage du jeu Akalabeth, avec le listing basic (qui pourrait heurter les plus jeunes d'entre vous). Évalué à 6.
Alors en C utiliser goto, est une bonne pratique, car ça te permet les goto chaîne, et justement clean les choses que tu as allouées/ouvertes.
Si tu fais du C, sans goto, ni attribute((cleanup)) ton code est crade.
Et vérifier malloc, à part si tu codes sur machine à laver/arduino ou autre machin embarqué, ça ne sert à rien, malloc ne te retourneras pas NULL s'il manque de place. (bon bien sûr, l'embarqué reste des cibles potentielles de beaucoup de lib, donc ça reste un gros use-case).
Perso, je suis un peu con, mais en général, entre deux codes, un long et sans goto, et un plus court, mais avec goto, je prends celui avec goto, et généralement, je le trouve plus simple à lire, il y a moins de code.
Reste que C/go sont assez structurés pour en avoir rarement besoins, mais dans certains rares cas, qui arrive à peu près une fois toutes les 2k lignes de code, un goto, ça simplifie le code. (sauf si on est en C, pas GNU C, dans ce cas, c'est dans une fonction sur 2 pour les erreurs).
Et si on a élevé les dev à éviter goto, c'est je pense à cause des traumatisés de BASiC, sauf que les goto en C n'ont rien à voir.
# Si vous voulez comprendre la haine du goto,
Posté par uso (site web personnel) . En réponse au lien Portage du jeu Akalabeth, avec le listing basic (qui pourrait heurter les plus jeunes d'entre vous). Évalué à 3. Dernière modification le 04 septembre 2023 à 10:43.
Vous pouvez jeter un coup d'œil au code.
Et personnellement, j'utilise les goto, quand ça me semble simplifier le code.
Par contre, quand on lit ce code, on se dit qu'on gagnerait bien en lisibilité avec un langage structuré, et c'est probablement contre ce genre de code que Dijkstra a écrit goto-considered-harmful.
Mais ça montre aussi que l'usage de goto tel qu'on peut trouver dans un code Kernel par exemples, n'a vraiment rien à voir, avec l'usage des goto de BASIC en 79.
# Talk is cheap. Show me the code.
Posté par uso (site web personnel) . En réponse au lien OpenTF annonce le fork de Terraform. Évalué à 1.
Je suis le seul, qui me suis dit ça, en ouvrant le repos Github, espérant tomber sur le code du fork, mais juste une promesse de bientôt le mettre ?
Enfin, ils disent avoir plein de dev qui ont promis travailler dessus, mais je trouve que ce genre d'annonce sans au moins un code qui marchotte ça ne met pas en confiances.
Surtout que souvent les forks de ce genre qui marche montre très vite une base de code (mate, tenacity, PrismLauncher…)
Enfin, j'espère que ça va marcher.
[^] # Re: steam-> battle net
Posté par uso (site web personnel) . En réponse au journal Même pour le jeu Windows n'est plus la panacée. Évalué à 1.
Je suppose, que tu passes l'option "Ajouter un jeu non Steam à ma bibliothèque", puis dans le menu compatibilité, tu choisis quelle version de proton, tu veux utiliser.
[^] # Re: Cette traduction et résumé auto montre tout ce qui ne va pas avec les modèles de langues
Posté par uso (site web personnel) . En réponse au lien [curl] CVE-2020-19909 is everything that is wrong with CVEs. Évalué à 6.
C'est ça, on peut aussi rajouter qu'il pense que ça a été mi à 9.8, car c'est un interger overflow, que les gents ont vu interger overflow, et ont donc mis une grosse note.
Il a rajouté qu'il est contant qu'Ubuntu a pris le devant et ont marqué la CVE comme "non affectant".
[^] # Re: anedocte
Posté par uso (site web personnel) . En réponse au journal Même pour le jeu Windows n'est plus la panacée. Évalué à 3.
Je l'ai installé, ça marche super bien, j'aurai dû le faire plus tôt, (surtout que je croie que l'on me l'avait déjà conseillé)
merci.
# Il y a 30 ans
Posté par uso (site web personnel) . En réponse au lien Happy 32nd Birthday, Linux!. Évalué à 2.
Linux était en C++:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/archive/+/refs/tags/v0.99-pl11
https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/archive/+/v0.99-pl13
[^] # Re: La vraie question
Posté par uso (site web personnel) . En réponse au journal Même pour le jeu Windows n'est plus la panacée. Évalué à 1.
C'est bon de vous revoir !
Parce-que "Notre quête est perdue d'avance…"
Même si dans le Baldur's Gate, il y a "Aventure, camaraderie, et acier sur acier, les ingrédients légendaires. Hein, Bouh ?"
# anedocte
Posté par uso (site web personnel) . En réponse au journal Même pour le jeu Windows n'est plus la panacée. Évalué à 7.
Y'a 2h un pote me parlais des cochons de guerres, et me disaient que ça marche plus soue Windows, j'ai regarder soue protonDB, ça marche parfaitement.
Bon anecdote a part, mais de manière général, les jeux pas maintenue pre-windows 7, on autant de chances de marcher soue windows que linux.
En contre exemples j'ai Seven Kingdoms 2 qui est assez casse tête à faire marcher soue Arche Linux, mais a l'air de bien marcher soue Windows. (mais n'ayant que des Arch linux BTW ou dérivé, je n'ai pas tester)
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 4.
sauf que un code qui marche avec -O3, mais pas sans ça, personnellement, j’appelle ça un code cassée.
Pas qu'il ne fasse jamais faire du récursive, mais s'appuyer sur l’hypothèse que le compilateur va optimiser ton code pour qu'il marche, font pleurer les heures que j'ai passer à utiliser/modifier tinycc.
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 2.
Mais le truck, c'est que dans un code qui utilise un langages fonctionnel, tu risque de voir plus de récursion que de boucles.
Si quelqu'un viens te dire:
Peu être que tu va te dire que c'est un peu abusé. (ceci dit ça m'étonnerais pas que des dev haskell aient déjà dit ce genre de choses)
Et je peu rejoindre que sur du C, justifier que l'on risque pas d'exploser la stack est une bonne choses. (et utiliser musttail je considère ça comme du self documentes code donc pas forcement besoins d'un autre commentaire)
Ce qui fait réagir, c'est de pas l'avoir dit dans le contexte d'un langage particulier.
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 2.
Je connaissaient pas musttail, et je te remercie de ton commentaire, parce-que ça va contredire ce que je vais dire, mais dans les cas sans musttail même si les compilateur gére la récursion terminal, ça reste au bon vouloir des optimisation, et si on sait que l'on peu exploser ça stack avec un récursion, je l'utiliserais pas. surtout que avec un -O0, bah ça va pas optimiser, et -O0, ça reste bien pratique pour du debug.
Après pour moi le cas de la lisibilité, c'est vraiment un question de connaître les idiomes du code qu'on patch, et s'y adapter.
La on parle de récursions, mais ça peu s'adapter a n'importe quel code. C'est toujours embêtant d'expliquer à quelqu'un qui rentre dans un code libre et essaye de modifier le code pour qu'il lui convienne mieux en appliquant par exemple, ce qu'on lui a apprit a l'école au détriment du style déjà utilisé dans le projet, qu'il ferais mieux de juste imiter le coding style des autres fonctions du projets.
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 4.
Mais la lisibilité, c'est énormément lier aux pratique utiliser dans un langages de programmations, et si t'a de la récursion dans toutes t'a lib standard (genre en ocaml), que la moitiés des idioms de ton languages utilise de la récursion, tu va justement plus rebuter les gents qui sont habituer à coder en fonctionnel, en leur imposant une boucle, la ou la plupart des dev auraient mit de la récursions.
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 2.
t'a jamais vu de code en OCaml/ask hell(Y'a une faute dans le nom ?)/lisp… ?
Certains langages assure que la récursion terminal, s'optimise pour pas justement casser la pile.
Mais oui, si on parle de C/java/Rust/python ou autre je suis d’accord.
[^] # Re: Loupé
Posté par uso (site web personnel) . En réponse au lien La récursivité sur linuxfr. Évalué à 2.
https://fr.wikipedia.org/wiki/Récursion_terminale
[^] # Re: Support de Wayland?
Posté par uso (site web personnel) . En réponse au lien Window Maker vient de sortir en version 0.96.0 . Évalué à 1.
XWayland ?
en vrais je sais pas si un WM peu marcher sur XWayland, donc je pose ça pour savoir si c'est possible, et qu'est ce qui pourrait empêcher que ça marche dessus ?
[^] # Re: Besoin d'un long commentaire ?
Posté par uso (site web personnel) . En réponse au lien Une nouvelle initiative pour forker/renommer GIMP. Évalué à 3.
https://github.com/Sneeds-Feed-and-Seed/sneedacity avec le bon lien :)
Enfin il est pas très vivant pour autant, mais Sneedacity reste une situation assez différentes, ou c'est fait après plein de fork d'Audacity (Tenacity, Sneedacity et Audacium(qui il me semble avais reprit du code de Sneedacity)), et on savaient pas quel fork allais prendre le dessus.
plus le fait que le truck est partie de 4chan, avec un gros harcèlement contre les gets de tenacity, et un développement assez bordélique.
[^] # Re: Garantie
Posté par uso (site web personnel) . En réponse au lien Just Obey The Law?. Évalué à 4.
Je suis pas sur, mais il me semble que la GPL dit plus:
"On ne garantie pas le program, autant que la loi applicable ne le permet." donc si la loi vous oblige a garantir le program (genre ce que l'UE veut faire passer) bah on garantie ce que la loi nous oblige a garantir (mais je peu me tromper)
Ici on parle des license qui disent "vous ne devez pas utilisez ce program pour faire quelque choses d’illégal".
L'ipadic comme cité plus haut dit ca:
en google trad:
Ici: https://packages.debian.org/changelogs/pool/non-free/i/ipadic/current/copyright
Qui peu être plus tricky, si par example tu utilise une lib avec une tel license et veut bug fix pour que ton client torrent marche mieux pour télécharger des truck illégal, bah t'a pas le droit de contribuer. (ou du moins de distribuer, t'a version patcher.)
# 2 questions:
Posté par uso (site web personnel) . En réponse au lien Just Obey The Law?. Évalué à 2.
1er question:
pourquoi ?
je veut dire, est-ce qu'une license qui utilise une tel clause a récemment fait parler d'elle ?
2ème question:
Pourquoi ?
Est-ce que ça étonne quelqu’un que "il faut respecter la loi", c'est ultra différent en function de ou est utiliser la licence? écrire ça en ayant en tête la loi de son pays, c'est au mieux faire preuve d'une grande naiveté ?
Bon j’hésitais a mettre un truck raciste des étasunien pour dire qu'ils ont du mal a imaginer le monde autrement que dans une vision très étasunienne, et ça peu expliquer ce genre d'article, mais je suis pas sur que ça soie bien venue ici.