reno a écrit 3886 commentaires

Ouh, la mon poste était là pour rappeler que libre n'implique pas sécurisé.

Et non avoir Capsicum dans FreeBSD n'est pas suffisant pour être plus sécurisé car il faut ensuite le support des applications (ce qu'ils ont commencé à faire).
Les dev de Capsicum ont commencé a travailler sur le support Linux, mais bon d'ici à ce que cela soit intégré, ça peut être long..

En ce qui concerne openSSL, ce n'est pas parce que tout le monde a mis la tête dans le sable pendant des années que tu dois généraliser.

C'est vrai, il y a plein d'autres raisons pour généraliser!
En vrac:

• la conception d'X ou chaques applications peut "sniffer" tout ce qui se passe.

• X lui même qui tourne root dans beaucoup de cas.

• ceux qui s'intéresse fortement à la sécurité critiquent régulièrement la gestion de la sécurité dans Linux..

D'ailleurs les dev de Capsicum (un des projets que je trouve le + intéressant pour la sécurité) ont commencé par bosser sur FreeBSD pas par Linux.

[JDN] Comment se repérer dans la jungle des licences open source

Même pas mention de LGPL, Boost.

Description de la GPL comme 'contaminante', une contamination c'est INVOLONTAIRE, l'utilisation (ou pas) de code GPL c'est toujours volontaire, donc 'contraignante' est beaucoup plus juste.

Note qu'il y a eu une reprise des ventes de PC à peu près au moment ou XP n'a plus eu de MAJ de sécurité (13 ans d'age quand même) donc effectivement ne pas changer est courant (et parfaitement raisonnable si tu as du support).

Et avoir des évolutions à apporter sur une application quand on change d'OS, ce n'est pas de la merde, juste de la logique…

Ça, ça dépend de la philosophie de ceux qui font l'OS..
Avec Microsoft, la compatibilité des nouvelles version de Windows avec l'existant est traité de manière assez sérieuse (enfin c'est TRÈS loin d'être parfait mais ils essayent), dans le monde des OS a base de Linux (mis à part pour Linux lui-même ironiquement) la compatibilité est très aléatoire..

Donc non ce n'est pas de la "logique".

Et je pense que les applications qui utilisent le GPU sont principalement les jeux, qui sont souvent en plein écran et dans ce cas là le desktop ne devrait plus jouer.
Après pour les jeux en fenetres..

Je crois qu'il y a des algorithmes plus intelligent que mémoriser les serveurs pour tout les clients, par exemple commencer par faire un algorithme qui fait un hash des informations du client et qui s'il tombe sur un serveur indisponible (planté ou plein) va appliquer une deuxième étape.

Il y a aussi le problème lié a l'augmentation du nombre de serveur a gérer si possible de manière transparente.

D’autre part, je trouve que ça correspond bien à la volonté de rendre toujours tout plus simple et plus clair

Sauf que plus simple visuellement != plus simple d'utilisation, c'est le problème majeur du flat, donc on en reviendra..

Pour un hobby? Python me parait bien adapté..

Et si je suis d'accord avec toi que Scala me parait mieux adapté pour programmer des gros programmes, comme premier langage Python a des avantages.

Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..

Explique alors que je préfère la lisibilité de la version Scala/Perl/Ruby et toi celle de la version Python/Rust?

La lisibilité est principalement subjective dans beaucoup de cas..

Comme je le disais, la lisibilité c'est subjectif, bien que n'utilisant pas Scala je trouve ça plus lisible que la version Python, alors?
Alors ça ne veut RIEN dire, la lisibilité c'est plus une question d'habitude qu'autre chose.

Par contre la maintenabilité ça c'est moins arbitraire, et je pense que mes arguments sur le manque de maintenabilité de {} en Python ou la verbosité des place holders obligatoires sont plus objectif.

Ça permet de passer toutes les variables dans un dictionnaire, sans forcément les connaître à l'avance.

Ce qui est rarement utile.. Rendre moins lisible et moins maintenable la syntaxe la plus utilisée pour une possibilité rarement utilisée, bof!

De plus, elle permet un formatage supplémentaire grâce aux indications (nombre de chiffres, remplissage avec des espaces, …).

Et alors? Avoir des formats strings lisibles n’empêche pas d'avoir des formatages supplémentaire..
En Scala, ça donne ça: println(f"$name%s is $height%2.2f meters tall")

J'ai l'impression qu'il y en a pas mal qui se disent, c'est comme ça que c'est fait en Python donc c'est forcément bien!
Désolé mais si la lisibilité est subjective, la maintenable ne l'est pas elle et
1) mettre les variables séparément des chaines ("foo {} faa {}",var1,var2) est moins maintenable que ("foo $var1 faa $var2")
2) en utilisant les places holders nommés tu peux récupérer la maintenabilité ("foo {u} faa {v}",u = var1, v = var2) MAIS c'est au prix d'une verbosité et d'une redondance supplémentaire par rapport à ("foo $var1 faa $var2") (si le nom des variable est trop moche pour mettre directement dans la format string c'est un problème entre la chaise et le clavier, pas un problème de langage).

Alors OK, les places holder nommés permettent quelques trucs supplémentaires utile dans 1% des cas, mais ça reste une syntaxe pas terrible pour le cas par défaut.

De mon point de vue, les concepteurs de Python ont merdé sur ce point là, ça arrive et après c'est difficile de changer donc ils sont coincés OK, mais que les dev de Rust copient Python sans améliorer la syntaxe par défaut là..

Puissante, puissante.. Ça se discute.
Je ne vois pas trop en quoi c'est plus puissant que l'équivalent en Scala (la même chose existe en Perl, Ruby):
tata="tutu"
"toto ${tata}"
mis à part que la syntaxe Python/Rust viole la règle DRY (ne pas se répéter)..

Si tu as une variable avec un nom bien clair alors "toto ${ma_variable}" est court et bien lisible mais la syntaxe Python/Rust impose d'ajouter un renommage supplémentaire même dans ce cas ("toto {foo}",foo=ma_variable)..

Tu peux expliquer/détailler par un exemple concret?
En Scala par exemple..

Ah? Ça ne me gène pas beaucoup personnellement..
Et les conséquences d'une faute d’orthographe me paraissent bien plus anecdotique que les conséquences d'un mauvais ordonnancement des variables, ce qui est très classique avec ce type de format string: modifier la chaine sans modifier la liste des variables en conséquence ou vice versa..

La plupart des langages?
Ça ne me parait pas un argument valide pour un nouveau langage, il devrait autant que possible reprendre le meilleur des langages existants!

Ah, j'imagine que certains trouvent la comparaison de Rust avec Perl ou Ruby biaisée car ces derniers sont interprétés, mais avec Scala la syntaxe est similaire..

Qui préfère lire
println!("texte {}", variable) ou println!("texte {v}, v = variable); (Rust)
a
println(s"texte $variable") ou println(s"texte ${variable}") (Scala)
?

Quand le nombre de variables augmente, je trouve la version Scala/Perl/Ruby bien plus lisible..

En fait la chaîne est passée à la fonction fmt qui ne connait bien sûr pas les variables déclarées,

Note que ce n'est pas une fonction, c'est une macro donc comme c'est a la compilation, je pense qu'on peut extraire le nom de la variable de la chaine et c'est le compilateur qui hurle plus tard si la variable n'est pas déclarée..
En D, un mixin doit pouvoir faire ça.

Pouvoir faire ça, ok ça peut être intéressant, mais ne pouvoir faire QUE ça, c'est ça qui me choque, pourquoi je ne peut pas faire println!("plop: {ma_variable}");
au lieu de devoir faire println!("plop: {u}", u = ma_variable);

Euh, il me semble que tout ce que tu dis, on peut le faire en Perl avec en plus l'avantage que tu as une syntaxe lisible pour les programmes tout simple ou tu n'as pas l'internationalisation..

De plus je ne vois pas l'avantage de faire printf!("{u}, u = v); par rapport à
my $u = $v;
print("$u");

et je trouve franchement dommage qu'un nouveau langage utilise une syntaxe si peu lisible..

L'équivalent de println!("{}", foo); ça serait en Perl print("$foo");
ou avec des {} si on veut clairement délimiter les variables du texte print("${foo}"); en Ruby pareil mais avec un # au lieu d'un $.

Dans les deux cas en Perl ou en Ruby, quand on lit le programme pas besoin de faire des aller-retour entre le texte et les variables contrairement à Rust ou au C: qui ne s'est jamais trompé en C dans ses chaine de formats en utilisant la mauvaise variable?
Pas moi!

En Rust, on peut faire  println!("{u}", u = foo);, c’est un peu moins moche mais je ne comprends pas l'intérêt par rapport à un (hypothétique) println!("{foo}"); ??

Il y a du concept, ça couvre la plupart de mes points bloquants avec la Fantasy…

Vu la liste de tes points, je t'invite a lire la série du trône de fer.
Enfin si tu as beaucoup de temps devant toi.. C'est tellement prenant que c'est très chronophage, genre tiens je vais lire jusqu'à 22h et à 2h du matin, bon il faut que j’arrête là!
Le seul inconvénient de lire cette saga, c'est que toutes les autres paraissent mièvres à coté..

Mmm, je t'ai plusser puis j'ai réfléchi: l’intérêt principal des conteneur est d'être 'autonome' ce qui évite les problèmes de compatibilités, mais à chaque fois que tu utilise la solution que tu décris, tu réintroduit le problème de compatibilité, non?

Ne vaudrait-il pas mieux automatiser la création de conteneur pour garder a la fois l'autonomie et une certaine 'facilité de mise à jour'?
Bon, réinstaller N conteneurs c'est moins simple qu'un seul, mais bon si c'est automatisé..

Desole pour le doublon.
Ce que je voulais dire: si la decoration de la fenetre est geree cote client, est ce que le compositeur sait qu'un clic a un endroit correspond a une iconification?

Avec Windows, c'est aussi quand tu iconifie une fenêtre.
Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..

Avec Windows, c'est aussi quand tu iconifie une fenêtre.
Pour la fermeture d'une application, là c'est différent et indépendant du gestionnaire de fenêtres:quand tu force la fermeture d'une application, tu risque de perdre des données..