David Delassus a écrit 747 commentaires

Perso, si personne d'autre n'a ramené de tire bouchon, j'accueille cette personne avec le sourire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

the development of the project is not open source

Grosse différence.

je trouve ça dommage, puisque c’est se priver de nombreuses contributions externes potentielles

Peut être qu'ils ne font pas de l'open source pour avoir des contributions externes. Peut être qu'ils n'ont pas les resources, le temps, l'énergie, l'envie, de traiter avec des inconnus qui ne partagent pas forcément la même vision de l'avenir du projet.

Je comprends parfaitement l'envie de se fermer aux contributions externes.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'avais rapidement l'impression de faire du lisp

Mais, c'est bien le Lisp pourtant !

https://xkcd.com/297/

---

PS: Oui Ysabeau, j'ai le droit de hotlink cette image, le site de xkcd fournit même le lien pour le faire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Cela me fait penser à la gouvernance du projet Lua :

On vous file les sources lors d'une release, mais tout le reste, ça se passe en privé, entre nous.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

CONTRIBUTING.md pre PR

Note: by contributing code to the Redis project in any form, including sending a pull request via GitHub, a code fragment or patch via private email or public discussion groups, you agree to release your code under the terms of the Redis license that you can find in the COPYING file included in the Redis source distribution.

---

Note: En contribuant du code au projet Redis sous n'importe quelle forme, incluant l'envoi d'une Pull Request via Github, un fragment de code ou un patch via email privé ou groupes de discussion publics, vous acceptez de diffuser votre code sous les termes de la licence Redis que vous pouvez trouver dans le fichier COPYING inclus dans les sources du projet Redis.

La licence c'était donc du BSD-3 : COPYING pre PR

Qui autorise donc la redistribution du code sous une autre licence.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

import typing

try:
    from yaml import CSafeLoader as SafeLoader

    if typing.TYPE_CHECKING:
        from yaml import SafeLoader as _SafeLoader
        SafeLoader = typing.cast(type[_SafeLoader], SafeLoader)

except ImportError:
    from yaml import SafeLoader

Le if typing.TYPE_CHECKING n'est entré que lors du (roulement de tambours) type-checking par mypy.

C'est aussi utile pour les imports circulaires (quand on a des classes définies dans plusieurs modules qui se référencent mutuellement via les annotations).

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Complètement d'accord.

Plus je l'utilise, plus je suis contre.

Il faut noter que mypy est un très mauvais outil, il abandonne très vite lorsqu'il s'agit d'inférer des types complexes. Pyright (qui est développé en typescript et inclus de base avec VS Code) est mieux, mais on a toujours pas un type-checker qui soit solide.

Le système de type que Python propose est de plus peu expressif et ne fonctionne tout simplement pas dans des cas pourtant simple, par exemple :

type Request = Union[
  tuple[Literal["action_a"], PayloadA],
  tuple[Literal["action_b"], PayloadB],
]

match request:
    case ("action_a", payload_a):
        pass

    case ("action_b", payload_b):
        pass

Dans cet exemple, mypy ne sait pas inférer le type de payload_a ou payload_b.

Et il sera impossible d'exprimer un type Response dont les variants dépendent du variant de Request :

type Response = Union[
    ResponseA,
    ResponseB,
]

Comment exprimer que quand j'ai une PayloadA je reçois une ResponseA ? En Python c'est pas possible.

De plus, Python est un langage qui est de nature purement dynamique. Aucun type-checker ne pourra vérifier la magie noire que l'on peut faire avec de la magie noire à base de subclasshook. Et pourtant ce sont des choses bien utiles parfois lorsqu'il est question de génération de code au runtime.

Au final, je deviens de l'avis suivant :

Si tu veux un système de type, tu veux un autre langage, alors utilise un autre langage.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

18/20, on a le droit de faire des arrondis quand même ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Il n'y a qu'a voir pourquoi Linus Torwald, la maison Blanche, Google (Qui avait développé son concurrent Go) ne jurent maintenant que par Rust.

Linus Torvalds qui persiste et signe quand il dit que le noyau Linux restera écrit en C, et que le C reste le meilleur langage pour du développement d'OS ne jure que par Rust ? T'as des sources ?

Les politiciens de la maison blanche, on s'en cogne un peu.

Google ne jure pas que par Rust, ils continuent de maintenir Go et ils ont même démarré Carbon en plus.

[phrase retirée par la modération]

NdM: commentaire édité par la modération

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.

Bah si, ça durera. Car c'est l'idée même de cette fonction de hashage, être cryptographiquement solide, cela veut donc dire exécution en temps constant (pour ne pas leak des infos sur la données en fonction du temps d'exécution). Elle ne sera donc jamais pus performante qu'un dict Python, car la team de Rust préfère fournir quelque chose de sécurisé par défaut.

La performance ça ne fait pas tout. Surtout quand tu es dans du IO bound et non du CPU bound (aka: tu passes plus de temps à attendre une réponse de la base de données qu'à faire des calculs).

C'est d'ailleurs pourquoi Java, Python, et Go sont très présents.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

S'arrêter proprement c'est relâcher les resources que l'on a acquise (file descriptor, socket, …) avant l'arrêt effectif. Ou plus communément appelé : "graceful shutdown".

Si ton serveur derrière le socket s'attend à ce que tu lui envoie goodbye avant de fermer le socket, c'est pas l'OS qui va le faire pour toi.

Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre.

Oue, il faudrait avoir fait un peu de Rust en fait avant de parler de Rust.

La fonction .unwrap() existe pour les types Result<T, E> et Option<T>. Elle génère effectivement un panic! si le Result<T, E> contient Err(E), ou si le Option<T> contient None.

De la même manière, Result<T, E> a une fonction .unwrap_err() qui génère un panic! si le Result<T, E> contient Ok(T).

C'est pas inné au langage, c'est un design d'API. Un autre design c'est que toutes les allocations faites par la stdlib génèrent un panic! si l'allocation échoue, à savoir notamment :

• Box::new(...)
• Vec::push(...)
• etc…

Note qu'il existe aussi Box::try_new(...) qui au lieu de générer un panic! va retourner un Result<T, E> avec Ok(Box<T>) ou Err(OutOfMemory). Et bien sûr, équivalent pour toutes fonctions allouant de la mémoire.

Mais tout ça, c'est au delà de ce que je disais, à savoir :

Il n'y a aucune différence entre panic! et :

void *p = malloc(size);
if (p == NULL) {
  abort(...);
}

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Rust ne crash pas (ou quasiment pas) il s'arrête "proprement" sur une erreur consciemment non gérée.

Depuis quand un panic! lors d'un Box::new(...) ou Vec::push(...) c'est s'arrêter proprement ?

C'est l'équivalent de :

void *p = malloc(size);
if (p == NULL) {
  abort(...);
}

Faut arrêter un peu les fantasmes sur le Rust.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

"Sécurisé" ça veut tout et rien dire.

Rust a 2 types de sécurités :

• "Memory safe" : tout les langages avec GC sont memory safe, Python, C#, Javascript, D, Go, etc…
• "Type safe" : tout les langages avec un système de type statique et strict sont type safe, Haskell, Standard ML, Java, etc…

Pour ce qui est des performances, cela va dépendre des algos, du développeur, et des choix fait par les designers du langage et de la librairie standard.

Par exemple, c'est bien connu que la HashMap avec l'algorithme de hashage par défaut de Rust est très lente.

"Pas de concurrent sérieux" c'est juste une ineptie totale.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

https://www.cairn.info/revue-legicom-1998-1-page-119.htm

https://www.profession-audiovisuel.com/droit-courte-citation-instant-pro/

https://braun-avocat.com/le-droit-de-citation-en-matiere-audiovisuelle-a-lepreuve-du-droit-a-limage/

Les sources la dessus sont contradictoires. Ni toi, ni moi, ni ces sites ne sont des avocats.

Je maintiens que je suis parfaitement dans mon droit d'utiliser ces images, que LinuxFR n'est pas sujet à litige quand ces images sont en plus externes.

Le pire des cas, c'est que vous recevez une demande de suppression des ayants droits (qui se traduirait par un procès en cas de refus). Toutes actions prises avant ça prennent source dans une paranoïa et sont du zèle.

Explique moi en quoi littéralement tout les sites journalistiques existant ont le droit d'héberger et de distribuer ces images, mais moi je n'ai pas le droit de faire du hotlinking.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Rien que sur ce post https://linuxfr.org/news/sortie-de-luneos-eiskaffee

Il ne semble pas que les assets graphiques soient libres de droit, donc le logo n'est pas soumis à la licence CC-By-SA, et l'auteur du post n'en possède pas les droits.

Et cela ne pose pas problème justement grace au hotlinking et au droit de citation que tu cites :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Il y a des images compatibles avec un contenu CC By-Sa sur https://fr.wikipedia.org/wiki/Akira_Toriyama et les pages dédiées aux œuvres concernées, que tu aurais pu utiliser.

Ce qui est sous licence CC-By-SA, c'est ce que j'ai écrit. Donc quand j'écris :

![alt][external link]

L'image pointée n'est pas soumise à la licence CC-By-SA. Sinon tout les articles de ce site qui diffuse le logo de Chrome, Firefox, Android, etc… sont des violations. C'est le principe du hotlinking.

on remplit les trois conditions : tu savais, tu l'as écrit ici, et LinuxFr.org est au courant

Les images que j'ai lié n'enfreignent pas le droit d'auteur. Ces images elles même étaient hébergées par des sites journalistiques qui n'ont pas en leur possession de licence d'utilisation provenant de la Toei, c'est le droit de citation qui est exercé ici.

on les bloque au besoin

Ici, je réfute le besoin de les bloquer. C'est pour moi du zèle, voir même irrespectueux de l'hommage que je voulais faire. En fait, c'est de la parano rien de plus.

et ceux qui disent « ça n'arrive jamais » ne sont pas les gens qui gèrent les problèmes

Bien belle phrase pour se dédouaner qui montre encore votre paranoïa. Le droit de citation existe, le hotlinking n'est pas une infraction du droit d'auteur. Non, je vous garanti bien que la Toei ne va pas vous mettre un procès dans la tronche pour l'utilisation de 3 images qui citent la source. Ou alors il faut faire fermer tout les sites journalistiques, reddit, youtube, etc…

Votre position sur le sujet est juste ridicule.

La chose à faire ici, qui serait respectueuse, vu qu'aucune infraction n'a été commise (ou alors, merci de me le prouver), serait de restaurer les-dites images.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Le hotlinking (utiliser une balise <img/> dont le src pointe vers une resource externe) n'est pas une violation de copyright.

Le contenu que j'ai soumis n'enfreint aucun copyright, je comprend pas pourquoi il s'est fait éditer… Surtout quand le-dit contenu cite la source/l'auteur original. Vous avez tant peur que ça d'un procès de la Toei que l'on ne peut plus rendre hommage à un artiste ?

Si LinuxFR parse le markdown et va wget les images pour les copier sur leur serveurs, c'est une autre histoire, et c'est très bizarre de faire ça.

Vous avez vérifié que toutes les images diffusées sur le site (logos de projets même libre, photo de profil de tout les utilisateurs, …) n'enfreignent aucun copyright ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

A ce que je sache, LinuxFR n'héberge pas les images, elles sont toujours hébergées par les sites qui les ont originellement publié.

En tout cas, les liens que j'ai mis sont externes.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Fun fact, les ExceptionGroup de Python 3.11 c'est inspiré par le travail de njsmith (l'auteur initial de trio) sur trio (les MultiError initialement).

Beaucoup d'améliorations de asyncio sont également inspirées de trio.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Mais moi je suis un gentil, je publie des friends links qui vous permettent de pas avoir de pub et l'article complet <3

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Tu dois avoir une extension dans ton navigateur qui fait ça automatiquement.

Ces sites (scribe.rip, …) c'est de la dobe, ils mettent pas l'article complet.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Es-ce que tu passe par dev.to ou quelque chose du genre ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

ElementaryOS utilise Flatpak comme gestionnaire de paquet par défaut.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

En plus, le tgz c'est déjà un paquet pour Slackware !

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Bah du coup on est d'accord. Tu répètes ce que j'ai dit.

En tant que développeur d'application qui n'a pas la popularité d'un Firefox ou vim, et donc personne d'autre que moi ne prendra le temps de faire les paquets, je vais pas me faire chier à distribuer sur 50 plateformes différentes et faire un tgz.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg