David Delassus a écrit 766 commentaires

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

Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.

Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.

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

Deux de mes choses favorites dans la vie, réunie en un seul miracle ?

Merci.

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

https://github.com/freetocompute/kebe

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

Vous commencez à casser les pieds avec votre discussion de sourd.

Personne ne contredit que le client est libre. Mais le système qui englobe le client et le serveur ne l'est pas, car le serveur ne l'est pas.

Oracle n'est pas libre, même si il existe des clients oracle libres.

Snap, qui inclus Snap Store n'est pas libre, même si il existe des clients pour le Snap Store qui sont libres.

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

Le premier arbre de commentaire est à propos de AppData, ProgramData, ProgramFiles, et le registre.

Je considère ces dossiers comme l'équivalent Windows des dossier XDG.

Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le $HOME.

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

Pardonne mon ignorance mais, comment font-ils pour gérer les dépendances dont les noms diffèrent ?

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