Posté par mothsART .
En réponse au journal Zébulon.
Évalué à 3.
Merci de l'encouragement et pas mal l'idée.
A creuser : l'idée c'est qu'à chaque nouveau niveau, il y ai une nouveauté donc pourquoi pas mettre des bloques pour éviter dans le niveau 2 et rajouter cette évolution dans le niveau 3…
gspeech est pilotable en ligne de commande depuis la version 0.8 donc ça me parait tout à fait réalisable.
Je ne sais pas ce que vaux espeak actuellement comparé à picovox (plus robotique même configuré quand j'avais fait un tour d'horizon il y a quelques années).
A terme, je souhaite mettre en place une UI qui puisse passer par plusieurs moteurs mais dans l'immédiat c'est déjà améliorer l'existant pour prendre en charge les termes/expressions les plus courants.
Je vois depuis ce soir qu'un paquet AUR existe pour le projet et remercie par la présente son auteur. (j'ai du mal à croire au hasard)
Je précise que gSpeech tourne (pour le cadre de Primtux) bien sur de l'archi x86_64 mais également sur de l'i386 et de l'armhf (testé sur des rpi 3 et 4) !
Pour accéder aux sources : https://github.com/mothsart/gSpeech
Une version 0.11 est déjà dans les tuyaux avec exclusivement des améliorations de lecture : chiffres romains, prénoms les plus courants, quelques subtilités de langage etc.
Un exemple de bug à plusieurs millions dev en Ada. Rien de plus, rien de moins.
et sinon, une discussion honnête et bienveillante, ça te dit ?
Je pense qu'on a un peu épuisé le sujet et être lasse de devoir me justifier.
On se retrouvera sur d'autres thématiques sur linuxfr !
Je ne pense ni être malhonnête ni être malveillant.
J'ai exprimé simplement un coup de gueule et un avertissement (c'est ma première sur linuxfr) après avoir eu des expériences pro et associatives autours de trucs dev en PHP (et d'autres langages interprétés) qui me semble être plus du bricolage que du sérieux.
Je vais croire que t'es payé pour répondre pour les autres.
Si l'expérience n'est pas un argument ne t'en sert pas toi non plus.
Point pour toi.
Quand je pensais "expérience" je pensais plus "connaissance".
Si c'est juste des années au compteur, j'ai vu bcp de devs se complaire dans des taches assez répétitives et sortir peu de leur périmètre de confort.
et oui l'histoire retiens que le langage ne fait pas tout
J'ai jamais dit le contraire. C'est par parce que t'as une ceinture, l'abs et des airbags que tu peux faire le fou au volant… mais bon, quand ça te sauve la vie, t'es bien content.
J'ai toujours du mal avec le joker "cv". A côtoyer des devs d'âge et d'expérience pro divers, ce n'est sans doute pas le critère le plus pertinent.
PHP n'est pas sans défaut, mais de là à le mépriser à ta façon, c'est totalement débile.
Je ne le méprise pas mais ça reste un langage de "template" pour moi qu'on a voulu transformer en langage générique.
C'est comme si je disais qu'on va faire des applis entièrement en Jinja, Razor ou Twig (d'ailleurs, ce dernier quand on y pense c'est du template par dessus un langage de template).
Utilisons les choses pour ce qu'elles sont.
J'ai rien contre les twingo mais si on me dit qu'on va transformer les twingo pour en faire des ferrari, ben excuse moi d'être sceptique.
L'un n'empêche pas l'autre d'exister.
Ce que je reproche à PHP c'est de manquer d'identité.
Ca fait 10 ans que son évolution c'est de s'approcher de langage full POO et fortement typé et s'assoie sur ce qui a fait sa force au début.
Du coup, il ressemble à du Java/C# en mode dégradé.
La réponse magique a ça c'est de me dire que PHP est rétrocompatible.
D'une part, ce n'est pas entièrement vrai. (je sais de source sur que certaines boites ont investis énormément en temps et en énergie pour passer de PHP 5 à 7)
De l'autre, je trouve irresponsable de ne rien déprécier.
Critiquer un truc qu'on ne connaît pas bien, c'est fort quand même…
Ah bon, tu ne le fais jamais ?
Un politique va parler, tu vas jamais le critiquer ? Pourtant, t'as pas fait l'ENA.
Ton voisin va critiquer les mesures de confinement. Il n'est pas pour autant virologue.
On va pas se mentir, l'Homme même avec une discipline scientifique rigoureuse est en réalité très peu rationnel, soyons honnête.
On est tous soumis un jour ou l'autre à des dissonances cognitives.
Pour en revenir au sujet, je parle de l'écosystème (donc bien plus large que le langage) qui comprend bcp de choses (gestionnaire de dépendances, frameworks, libs, bonne pratiques) et qui demande souvent de l'expérimentation pour dire qu'on connait.
Mais bon, c'est des connaissances macros et ça n'empêche pas d'avoir un avis tout à fait objectives sans tout connaitre dans le détail.
C'est d'ailleurs le métier d'architectes logiciels : faire des choix techniques sans connaitre tout sur le bout des doigts.
En tout cas, ce snobisme sur tel ou tel langage parce qu'il serait plus "pure", ça me gonfle, car souvent prônés par des personnes qui sont en décalage avec la réalité du terrain
Y'a une juste valeur a avoir. Par exemple, je laisserais des langages comme Haskell, Prolog, Ada dans le cadre "académique" : on apprend des concepts qu'on va pouvoir réutiliser dans des langages plus orienté "concret".
Faut déjà définir "être en phase avec la réalité". Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité.
Quelques nouveautés qui vont devenir indispensables :
PEP 584 et PEP 616 : une paire de code boilerplate et imbuvable qui va être remplacé, j'ai hâte !
Moins intéressé par tout ce qui concerne le typage mais bon, il en faut pour tout le monde.
Ça se fait, pourtant, c'est justement une des charges utiles pour exploiter un buffer overflow.
Pour moi, c'est plus des instructions machines que t'injectes mais bon, je m'amuse pas a exploiter des buffers overflow tous les 4 matins donc j'ai sans doute des lacunes dans le domaine.
Un OS qui ne fournit aucun service réseau…
Je pense que la grande majorité des soucis (ou en tout cas des exploitations) DDOS ne sont pas lié à l'OS mais aux applicatifs, à leur mise en place et config.
Si c'est lié à l'OS, il faut déjà que l'attaque soit orienté vers ce dernier en particulier.
Comme dis, je ne suis pas vraiment légitime pour ce genre de sujet car le dev niveau OS ne m'est pas familier et j'oriente peu ma veille autours de la sécu.
Sur tes mesures, j'ai compris dans les grandes lignes comment tu as pu ressortir ces chiffres mais est-ce qu'ils ont réellement une pertinence ?
J'ai regardé en rapide une dizaine de lignes sur du Denial of service et quand on lit l'origine du soucis, on voit que c'est lié à un buffer overflow donc du coup, ça fausse sans doute pas mal ta conclusion.
Et leur kernel, il supporte les mécanismes de type ASLR? Parce que sinon, rust c'est safe… lol?
C'est pas parce qu'un langage protège de certaines failles qu'il protège de tout, on est bien dac.
La vrai question serait plutôt : est-ce que les garantis de sécurité de Rust qui ne sont pas disponible dans C sont suffisamment pertinentes pour le remplacer ?
Et leur kernel, il supporte les mécanismes de type ASLR
Je suis bien incapable de répondre à ça mais est-ce que c'est une priorité pour une version 0.5 ?
Dans celles-ci (les failles de buffer de 2020), je n'en vois aucune liée à linux
Oui, à priori ça permet de faire une appli graphique sans toolkit en C.
C'est cross-plateforme et ça s'appui sur https://github.com/jrmuizel/raqote
Dans la liste des GUI supportés en Rust https://www.areweguiyet.com/, t'en as quelques une qui sont en pure Rust : Azul et druid par exemple. Le reste c'est en effet des bindings C.
Au fait, j'ai un scoop: les failles de sécurité les plus faciles à exploiter… c'est pas les buffer overflows, ce sont les injections de code et les déni de service (un jeune de 16 ans peut exploiter ce type de failles).
L'injection de code sur du compilé, je demande à voir.
Le DDOS c'est une problématique réseau, je vois pas le parallèle avec un OS.
toutes les failles de sécurités ne sont pas liées à la mémoire
Je suis vraiment pas expert dans le domaine (surtout en matière de sécu au niveau OS) mais du peu que je vois passer, 95% des failles les plus faciles à exploiter s'appui sur des buffer overflow non ?
pour les bugs
En effet, c'est plus large mais Rust évite une paire de bugs de concurrence, de type et de conversion de type, de logique (pattern matching) etc.
Après, sur les aspects fonctionnels, métiers, les contournements logiciels pour des bugs matériels etc. y'a pas de magie en effet.
Pour ce qui est de Go et Swift, ils utilisent des Garbage collector. Ca ne rend pas la tâche impossible mais ça présente quand même un défaut de taille pour faire des OS un tant soit peu sérieux.
Pour les autres langages moins modernes, même si ils peuvent être pertinent, ils n'auront sans doute jamais la popularité pour être des candidats viables.
J'essai de suivre les avancé de Rust et y'a quand même beaucoup d'effort de fait pour éviter l'unsafe (plein d'api qui se stabilisent sur par exemple de la gestion fine de la mémoire) et donc de réduire le scope de code "dangereux".
Bien évidement, ça ne sera jamais parfait et des outils tel que Miri permettent de détecter un certain nombres de cas dans la partie unsafe.
Rust, malgré ses qualités peut avoir des soucis d'overflow et de bugs au runtime : la différence notable c'est que quand ça "panic", le programme s'arrête directement et il est donc plus délicat d'avoir des soucis de fuite de mémoire d'exploiter ces bugs (comme en C) pour un usage frauduleux.
Y'avait pas vraiment de but en soit à part peut-être de démontrer que entre la théorie et la pratique, certains concepts sont loin d'être aussi simple qu'ils n'y paraissent et que autant choisir une techno pour ses fonctionnalités est souvent pertinent, pour les perfs, ça peut être à double tranchant.
L'asynchronisme, jouer avec plusieurs langages, implémentations c'est toujours intéressant mais chronophage.
Comme souvent, quand on va dans ce genre de voie :
* la doc est difficile à trouver
* le vocabulaire n'est pas standardisé : on va parler de "green thread" dans Java mais ça sera plutôt des coroutines dans d'autres langage voir "green processes" en Erlang
* la doc pertinente sera souvent noyé par beaucoup de bruit
* faudra se tourner vers de l'anglais
Je passe pas mal de temps à lire le source de gros projets dans des langages que je maîtrise ou à regarder http://www.rosettacode.org/wiki/Rosetta_Code qui permet de comparer des langages sur des algos similaires.
Je pense que l'on a tendance (surtout les dev) a surestimé (moi le 1er) les diffs du software entre le matériel cible alors que dans certains domaines (la concurrence en fait partie), les perfs peuvent être très diff selon l'architecture employé et que des fois il vaut mieux se satisfaire d'une méthodologie éprouvé mais pas optimal plutôt que chercher le saint Graal et finalement se retrouver avec quelque chose de très productif dans un scope précis et improductif dans d'autres.
disons, les threads en espace utilisateur, je suis assez persuadé que les greens threads limités de Java il y a 20 ans n'étaient pas vraiment performants - ce n'était d'ailleurs pas vraiment leur objectif, leur objectif c'était il me semble surtout de ne pas trop dépendre des spécificités de chaque système d'exploitation pour avoir un mécanisme plus ou moins concurrent.
Tout à fait.
Java, leur slogan c'est "run everywhere" et faire des if (os == 'bsd') ça devait pas trop les enchanter.
Je ne vais plus continuer sur ce fil les échanges concernant l'asynchronisme car ça devient un peu ridicule.
Néanmoins, ça pourrait être intéressant d'avoir un dépôt de code (et de doc en markdown) avec des exemples sur le sujet :
- de la vulgarisation
- des liens vers des trucs pertinents
- des benchmarks idéalement dans plusieurs langages
- recommandations : utiliser tel truc dans tel cas
Si ça botte quelque uns, je pourrais initier le sujet.
En soit, c'est vrai que ça peut paraître un peu présomptueux surtout que y'a quand même une vague de fans de Rust qui ont tendance à vouloir réécrire le monde avec.
Rust est un des seuls langages (à ma connaissance) suffisamment mature (y'a D sans doute également, Zig et V mais ces 2 derniers sont trop jeunes) pour remplacer du C ou C++, obtenir des perfs équivalentes tout en donnant plus de sécurité (attention, c'est pas parfait, y'a tjs des blagues possibles au runtime) et permettant de faire des choses plus haut niveau notamment en terme de concurrence.
Le kernel linux commence à envisager des drivers en Rust, M# et Apple commencent à l'utiliser pour des parties critiques de leurs OS respectifs.
Bref, vu que le projet commence à se démarquer d'un simple POC et que l'essence de ces qualités proviennent en grande partie du langage choisi, je ne trouve pas ça déconnant.
En réalité, j'ai anticipé ces questions.
J'ai volontairement simplifié le script pour l'exemple. J'ai testé avec un nb d'urls bien plus conséquent et plus j'ai tendance à rajouter, plus l'écart se creuse en faveur des threads.
tu ne mesures pas vraiment green thread vs thread système
asyncio est la couche de concurrence de Python haut niveau et elle s'appuie sur les green thread par défaut. (mais on peut la config pour s'appuyer sur des threads ou des process : ça pourrait d'ailleurs valoir le coup de tester)
peut-être que l'asynchrone Python n'est pas très performant par exemple
Mais si d'autre veulent faire une impl dans un autre langage, je suis preneur
de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests
La, j'ai tout mis dans le même script mais en réalité j'ai effectué mes tests dans 2 fichiers distincts.
J'ai franchement joué le jeu en testant une autre liste d'url dans le sens inverse.
Pas une seul fois, (mais ça reste bien évidement possible, il suffit qu'un site soit plus lent temporairement) j'ai eu un résultat plus rapide avec asyncio.
Mais si l'on me démontre l'inverse, je m'inclinerais : je ne cherche pas à avoir raison.
Je peux bien sur pousser le truc plus loin, lancer des centaines de fois, faire des moyennes et des médianes et créer des graphiques… mais est-ce que le jeu en vaut la chandelle ?
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés… C'est assez logique.
Je ne dis pas le contraire. Ce qui se fait dans le scope d'un process reste vrai et vu qu'un thread (green ou non) est encapsulé dan un process, il sera forcément dépendant des interruptions/reprises de ce dernier.
Mais tu pars du postulat qu'il n'y a pas de context switching dans les green thread ce qui me semble tout à fait erroné.
Dès qu'il y a de la concurrence, c'est inévitable.
La seul différence c'est que c'est géré en espace utilisateur : c'est donc l'algo de ton langage qui s'occupe d'ordonnancer et non les routines de ton kernel.
(Ça permet sans doute d'uniformiser les comportements entre architectures physiques et OS mais bon ça reste du détail)
Comme tu le dis précédemment, le risque du context switching c'est que quand il n'y en a trop, ça devient plus long que du synchrone :
c'est pour ça que tu trouveras aussi bien dans les process, thread que green thread la possibilité de donner une limite d'opérations en simultannés.
Bref, rien n'est scalable à l'infini, tout à des limites physiques.
J'essai d'adapter mon langage selon mon public (ce qui est délicat dans ce contexte).
Si je dis à un gars qui a fait principalement du Haskell, OOCaml et qui s'intéresse à Python que ce dernier est typé fortement, il va vite déchanté et l'argument "dynamique" ne lui suffira sans doute pas et je le comprendrais.
Typage fort, je m'attend à ce que ça soit contraignant et sécure peut importe les petites lignes.
C'est un choix délibéré, peut-être un peu fort de café mais j'assume.
De toute façon, si il y a consensus et qu'on emploi un terme (le mieux serait sans doute de ne pas l'utiliser vu qu'il est nébuleux) c'est forcément qu'on a Sa définition.
Ex, en C#, tu écris une fonction, ça donne un truc du genre :
public int mafonction(MaSuperClass monobjet, string text, int num) { ... } Ou je dois préciser les types en entrée et en sortie.
A l'appel de la fonction, en effet, je n'aurais pas besoin de préciser tout ça car l'inférence fera son job.
La même chose en python :
def mafonction(monobjet, text, num):
... Tout ça pour dire que l'inférence c'est bien pour réduire du code rébarbatif mais ça simplifie pas tout et c'est pas non plus "magique".
Pour ma part, j'ai même tendance dans certains cas à préciser explicitement des types parce qu'avec l'inférence, c'est des fois complexe de comprendre à la lecture si on manipule des choux ou des carottes.
ben, si je veux faire un script rapide pour faire par exemple des regex et replace une fois (pas un truc réutilisable), je vais pas m'embêter avec un langage ultra typé. Je vais faire ça en python, pas forcément suivre les règles de pep à la lettre et ça "cassera" jusqu’à ce que ça passe une 1er fois.
Si la conversion est concluante, le script finira à la corbeille dans la foulée.
J'aurais le résultat de mon besoin sans grand efforts intellectuels ni temporels.
Foutaises. Le typage te dit « ton code est cassé », au moment ou tu l’écris, pas plus tard, quand tu le fais tourner.
sur des petits projets comme celui mentionné à titre d'ex, l'IDE fera amplement le job pour me prévenir de soucis éventuelles et le reste se terminera sans doute par quelques essais/erreurs à l'exec vite résolus.
Pour moi, pas besoin de sortir le bazooka pour tuer une mouche et j'encourage a au moins maîtriser un langage interprété pour bosser vite et un langage compiler et fortement typé pour bosser bien.
Si tu vois mes autres commentaires, tu remarqueras qu'une de mes critiques générales sur PHP c'est précisément d'être trop léger sur le typage (et de faire des vérifs au runtime) pour l'envisager sur de gros projets.
[^] # Re: c'est deja un beau résultat
Posté par mothsART . En réponse au journal Zébulon. Évalué à 3.
Merci de l'encouragement et pas mal l'idée.
A creuser : l'idée c'est qu'à chaque nouveau niveau, il y ai une nouveauté donc pourquoi pas mettre des bloques pour éviter dans le niveau 2 et rajouter cette évolution dans le niveau 3…
[^] # Re: paquet AUR
Posté par mothsART . En réponse à la dépêche gSpeech passe en 0.10. Évalué à 1.
gspeech est pilotable en ligne de commande depuis la version 0.8 donc ça me parait tout à fait réalisable.
Je ne sais pas ce que vaux espeak actuellement comparé à picovox (plus robotique même configuré quand j'avais fait un tour d'horizon il y a quelques années).
A terme, je souhaite mettre en place une UI qui puisse passer par plusieurs moteurs mais dans l'immédiat c'est déjà améliorer l'existant pour prendre en charge les termes/expressions les plus courants.
# paquet AUR
Posté par mothsART . En réponse à la dépêche gSpeech passe en 0.10. Évalué à 2.
Je vois depuis ce soir qu'un paquet AUR existe pour le projet et remercie par la présente son auteur. (j'ai du mal à croire au hasard)
Je précise que gSpeech tourne (pour le cadre de Primtux) bien sur de l'archi x86_64 mais également sur de l'i386 et de l'armhf (testé sur des rpi 3 et 4) !
[^] # Re: Prononciation
Posté par mothsART . En réponse à la dépêche gSpeech passe en 0.10. Évalué à 2.
Pas sur qu'il soit adapté x)
# accès github
Posté par mothsART . En réponse à la dépêche gSpeech passe en 0.10. Évalué à 2.
Pour accéder aux sources : https://github.com/mothsart/gSpeech
Une version 0.11 est déjà dans les tuyaux avec exclusivement des améliorations de lecture : chiffres romains, prénoms les plus courants, quelques subtilités de langage etc.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Un exemple de bug à plusieurs millions dev en Ada. Rien de plus, rien de moins.
Je pense qu'on a un peu épuisé le sujet et être lasse de devoir me justifier.
On se retrouvera sur d'autres thématiques sur linuxfr !
Je ne pense ni être malhonnête ni être malveillant.
J'ai exprimé simplement un coup de gueule et un avertissement (c'est ma première sur linuxfr) après avoir eu des expériences pro et associatives autours de trucs dev en PHP (et d'autres langages interprétés) qui me semble être plus du bricolage que du sérieux.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Je vais croire que t'es payé pour répondre pour les autres.
Point pour toi.
Quand je pensais "expérience" je pensais plus "connaissance".
Si c'est juste des années au compteur, j'ai vu bcp de devs se complaire dans des taches assez répétitives et sortir peu de leur périmètre de confort.
Pour Ada, je suis sur que tu penses à https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5
J'ai jamais dit le contraire. C'est par parce que t'as une ceinture, l'abs et des airbags que tu peux faire le fou au volant… mais bon, quand ça te sauve la vie, t'es bien content.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
J'ai toujours du mal avec le joker "cv". A côtoyer des devs d'âge et d'expérience pro divers, ce n'est sans doute pas le critère le plus pertinent.
Je ne le méprise pas mais ça reste un langage de "template" pour moi qu'on a voulu transformer en langage générique.
C'est comme si je disais qu'on va faire des applis entièrement en Jinja, Razor ou Twig (d'ailleurs, ce dernier quand on y pense c'est du template par dessus un langage de template).
Utilisons les choses pour ce qu'elles sont.
J'ai rien contre les twingo mais si on me dit qu'on va transformer les twingo pour en faire des ferrari, ben excuse moi d'être sceptique.
L'un n'empêche pas l'autre d'exister.
Ce que je reproche à PHP c'est de manquer d'identité.
Ca fait 10 ans que son évolution c'est de s'approcher de langage full POO et fortement typé et s'assoie sur ce qui a fait sa force au début.
Du coup, il ressemble à du Java/C# en mode dégradé.
La réponse magique a ça c'est de me dire que PHP est rétrocompatible.
D'une part, ce n'est pas entièrement vrai. (je sais de source sur que certaines boites ont investis énormément en temps et en énergie pour passer de PHP 5 à 7)
De l'autre, je trouve irresponsable de ne rien déprécier.
Ah bon, tu ne le fais jamais ?
Un politique va parler, tu vas jamais le critiquer ? Pourtant, t'as pas fait l'ENA.
Ton voisin va critiquer les mesures de confinement. Il n'est pas pour autant virologue.
On va pas se mentir, l'Homme même avec une discipline scientifique rigoureuse est en réalité très peu rationnel, soyons honnête.
On est tous soumis un jour ou l'autre à des dissonances cognitives.
Pour en revenir au sujet, je parle de l'écosystème (donc bien plus large que le langage) qui comprend bcp de choses (gestionnaire de dépendances, frameworks, libs, bonne pratiques) et qui demande souvent de l'expérimentation pour dire qu'on connait.
Mais bon, c'est des connaissances macros et ça n'empêche pas d'avoir un avis tout à fait objectives sans tout connaitre dans le détail.
C'est d'ailleurs le métier d'architectes logiciels : faire des choix techniques sans connaitre tout sur le bout des doigts.
Y'a une juste valeur a avoir. Par exemple, je laisserais des langages comme Haskell, Prolog, Ada dans le cadre "académique" : on apprend des concepts qu'on va pouvoir réutiliser dans des langages plus orienté "concret".
Faut déjà définir "être en phase avec la réalité". Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité.
# Version intéressante
Posté par mothsART . En réponse à la dépêche Python 3.9 est disponible. Évalué à 4.
Quelques nouveautés qui vont devenir indispensables :
PEP 584 et PEP 616 : une paire de code boilerplate et imbuvable qui va être remplacé, j'ai hâte !
Moins intéressé par tout ce qui concerne le typage mais bon, il en faut pour tout le monde.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2.
Pour moi, c'est plus des instructions machines que t'injectes mais bon, je m'amuse pas a exploiter des buffers overflow tous les 4 matins donc j'ai sans doute des lacunes dans le domaine.
Je pense que la grande majorité des soucis (ou en tout cas des exploitations) DDOS ne sont pas lié à l'OS mais aux applicatifs, à leur mise en place et config.
Si c'est lié à l'OS, il faut déjà que l'attaque soit orienté vers ce dernier en particulier.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2.
Comme dis, je ne suis pas vraiment légitime pour ce genre de sujet car le dev niveau OS ne m'est pas familier et j'oriente peu ma veille autours de la sécu.
Sur tes mesures, j'ai compris dans les grandes lignes comment tu as pu ressortir ces chiffres mais est-ce qu'ils ont réellement une pertinence ?
J'ai regardé en rapide une dizaine de lignes sur du Denial of service et quand on lit l'origine du soucis, on voit que c'est lié à un buffer overflow donc du coup, ça fausse sans doute pas mal ta conclusion.
C'est pas parce qu'un langage protège de certaines failles qu'il protège de tout, on est bien dac.
La vrai question serait plutôt : est-ce que les garantis de sécurité de Rust qui ne sont pas disponible dans C sont suffisamment pertinentes pour le remplacer ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4701, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8249 et https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28575
[^] # Re: Orbtk
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 3.
Oui, à priori ça permet de faire une appli graphique sans toolkit en C.
C'est cross-plateforme et ça s'appui sur https://github.com/jrmuizel/raqote
Dans la liste des GUI supportés en Rust https://www.areweguiyet.com/, t'en as quelques une qui sont en pure Rust : Azul et druid par exemple. Le reste c'est en effet des bindings C.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 6.
L'injection de code sur du compilé, je demande à voir.
Le DDOS c'est une problématique réseau, je vois pas le parallèle avec un OS.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2.
Oui, là tu parles de failles sur du web donc c'est pas vraiment comparable.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2.
Le langage D, j'en ai parlé car j'en entend souvent parlé mais j'ai si peu développé que je ne peut pas avoir d'avis objectif sur la question.
Rust peut s'interfacer avec C de plusieurs façon mais le plus courant est de créer des binding avec https://doc.rust-lang.org/std/ffi/index.html
Je suis vraiment pas expert dans le domaine (surtout en matière de sécu au niveau OS) mais du peu que je vois passer, 95% des failles les plus faciles à exploiter s'appui sur des buffer overflow non ?
En effet, c'est plus large mais Rust évite une paire de bugs de concurrence, de type et de conversion de type, de logique (pattern matching) etc.
Après, sur les aspects fonctionnels, métiers, les contournements logiciels pour des bugs matériels etc. y'a pas de magie en effet.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
héhé
Pour ce qui est de Go et Swift, ils utilisent des Garbage collector. Ca ne rend pas la tâche impossible mais ça présente quand même un défaut de taille pour faire des OS un tant soit peu sérieux.
Pour les autres langages moins modernes, même si ils peuvent être pertinent, ils n'auront sans doute jamais la popularité pour être des candidats viables.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
J'essai de suivre les avancé de Rust et y'a quand même beaucoup d'effort de fait pour éviter l'unsafe (plein d'api qui se stabilisent sur par exemple de la gestion fine de la mémoire) et donc de réduire le scope de code "dangereux".
Bien évidement, ça ne sera jamais parfait et des outils tel que Miri permettent de détecter un certain nombres de cas dans la partie unsafe.
Rust, malgré ses qualités peut avoir des soucis d'overflow et de bugs au runtime : la différence notable c'est que quand ça "panic", le programme s'arrête directement et il est donc plus délicat d'avoir des soucis de fuite de mémoire d'exploiter ces bugs (comme en C) pour un usage frauduleux.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Y'avait pas vraiment de but en soit à part peut-être de démontrer que entre la théorie et la pratique, certains concepts sont loin d'être aussi simple qu'ils n'y paraissent et que autant choisir une techno pour ses fonctionnalités est souvent pertinent, pour les perfs, ça peut être à double tranchant.
L'asynchronisme, jouer avec plusieurs langages, implémentations c'est toujours intéressant mais chronophage.
Comme souvent, quand on va dans ce genre de voie :
* la doc est difficile à trouver
* le vocabulaire n'est pas standardisé : on va parler de "green thread" dans Java mais ça sera plutôt des coroutines dans d'autres langage voir "green processes" en Erlang
* la doc pertinente sera souvent noyé par beaucoup de bruit
* faudra se tourner vers de l'anglais
Je passe pas mal de temps à lire le source de gros projets dans des langages que je maîtrise ou à regarder http://www.rosettacode.org/wiki/Rosetta_Code qui permet de comparer des langages sur des algos similaires.
Je pense que l'on a tendance (surtout les dev) a surestimé (moi le 1er) les diffs du software entre le matériel cible alors que dans certains domaines (la concurrence en fait partie), les perfs peuvent être très diff selon l'architecture employé et que des fois il vaut mieux se satisfaire d'une méthodologie éprouvé mais pas optimal plutôt que chercher le saint Graal et finalement se retrouver avec quelque chose de très productif dans un scope précis et improductif dans d'autres.
Tout à fait.
Java, leur slogan c'est "run everywhere" et faire des if (os == 'bsd') ça devait pas trop les enchanter.
Je ne vais plus continuer sur ce fil les échanges concernant l'asynchronisme car ça devient un peu ridicule.
Néanmoins, ça pourrait être intéressant d'avoir un dépôt de code (et de doc en markdown) avec des exemples sur le sujet :
- de la vulgarisation
- des liens vers des trucs pertinents
- des benchmarks idéalement dans plusieurs langages
- recommandations : utiliser tel truc dans tel cas
Si ça botte quelque uns, je pourrais initier le sujet.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 8.
En soit, c'est vrai que ça peut paraître un peu présomptueux surtout que y'a quand même une vague de fans de Rust qui ont tendance à vouloir réécrire le monde avec.
Rust est un des seuls langages (à ma connaissance) suffisamment mature (y'a D sans doute également, Zig et V mais ces 2 derniers sont trop jeunes) pour remplacer du C ou C++, obtenir des perfs équivalentes tout en donnant plus de sécurité (attention, c'est pas parfait, y'a tjs des blagues possibles au runtime) et permettant de faire des choses plus haut niveau notamment en terme de concurrence.
Le kernel linux commence à envisager des drivers en Rust, M# et Apple commencent à l'utiliser pour des parties critiques de leurs OS respectifs.
Bref, vu que le projet commence à se démarquer d'un simple POC et que l'essence de ces qualités proviennent en grande partie du langage choisi, je ne trouve pas ça déconnant.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0. Dernière modification le 06 décembre 2020 à 20:53.
En réalité, j'ai anticipé ces questions.
J'ai volontairement simplifié le script pour l'exemple. J'ai testé avec un nb d'urls bien plus conséquent et plus j'ai tendance à rajouter, plus l'écart se creuse en faveur des threads.
asyncio est la couche de concurrence de Python haut niveau et elle s'appuie sur les green thread par défaut. (mais on peut la config pour s'appuyer sur des threads ou des process : ça pourrait d'ailleurs valoir le coup de tester)
Mais si d'autre veulent faire une impl dans un autre langage, je suis preneur
La, j'ai tout mis dans le même script mais en réalité j'ai effectué mes tests dans 2 fichiers distincts.
J'ai franchement joué le jeu en testant une autre liste d'url dans le sens inverse.
Pas une seul fois, (mais ça reste bien évidement possible, il suffit qu'un site soit plus lent temporairement) j'ai eu un résultat plus rapide avec asyncio.
Mais si l'on me démontre l'inverse, je m'inclinerais : je ne cherche pas à avoir raison.
Je peux bien sur pousser le truc plus loin, lancer des centaines de fois, faire des moyennes et des médianes et créer des graphiques… mais est-ce que le jeu en vaut la chandelle ?
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Je me suis prêté à l'exercice rapide de comparatif : http://pastebin.fr/76926 (rien de mieux qu'un peu de pratique après de la théorie)
J'ai beau tourner le truc comme je veux, les threads sont plus rapides.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Je ne dis pas le contraire. Ce qui se fait dans le scope d'un process reste vrai et vu qu'un thread (green ou non) est encapsulé dan un process, il sera forcément dépendant des interruptions/reprises de ce dernier.
Mais tu pars du postulat qu'il n'y a pas de context switching dans les green thread ce qui me semble tout à fait erroné.
Dès qu'il y a de la concurrence, c'est inévitable.
La seul différence c'est que c'est géré en espace utilisateur : c'est donc l'algo de ton langage qui s'occupe d'ordonnancer et non les routines de ton kernel.
(Ça permet sans doute d'uniformiser les comportements entre architectures physiques et OS mais bon ça reste du détail)
Comme tu le dis précédemment, le risque du context switching c'est que quand il n'y en a trop, ça devient plus long que du synchrone :
c'est pour ça que tu trouveras aussi bien dans les process, thread que green thread la possibilité de donner une limite d'opérations en simultannés.
Bref, rien n'est scalable à l'infini, tout à des limites physiques.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
J'essai d'adapter mon langage selon mon public (ce qui est délicat dans ce contexte).
Si je dis à un gars qui a fait principalement du Haskell, OOCaml et qui s'intéresse à Python que ce dernier est typé fortement, il va vite déchanté et l'argument "dynamique" ne lui suffira sans doute pas et je le comprendrais.
Typage fort, je m'attend à ce que ça soit contraignant et sécure peut importe les petites lignes.
C'est un choix délibéré, peut-être un peu fort de café mais j'assume.
De toute façon, si il y a consensus et qu'on emploi un terme (le mieux serait sans doute de ne pas l'utiliser vu qu'il est nébuleux) c'est forcément qu'on a Sa définition.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Ex, en C#, tu écris une fonction, ça donne un truc du genre :
public int mafonction(MaSuperClass monobjet, string text, int num) { ... }
A l'appel de la fonction, en effet, je n'aurais pas besoin de préciser tout ça car l'inférence fera son job.
La même chose en python :
def mafonction(monobjet, text, num):
...
Pour ma part, j'ai même tendance dans certains cas à préciser explicitement des types parce qu'avec l'inférence, c'est des fois complexe de comprendre à la lecture si on manipule des choux ou des carottes.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
ben, si je veux faire un script rapide pour faire par exemple des regex et replace une fois (pas un truc réutilisable), je vais pas m'embêter avec un langage ultra typé. Je vais faire ça en python, pas forcément suivre les règles de pep à la lettre et ça "cassera" jusqu’à ce que ça passe une 1er fois.
Si la conversion est concluante, le script finira à la corbeille dans la foulée.
J'aurais le résultat de mon besoin sans grand efforts intellectuels ni temporels.
sur des petits projets comme celui mentionné à titre d'ex, l'IDE fera amplement le job pour me prévenir de soucis éventuelles et le reste se terminera sans doute par quelques essais/erreurs à l'exec vite résolus.
Pour moi, pas besoin de sortir le bazooka pour tuer une mouche et j'encourage a au moins maîtriser un langage interprété pour bosser vite et un langage compiler et fortement typé pour bosser bien.
Si tu vois mes autres commentaires, tu remarqueras qu'une de mes critiques générales sur PHP c'est précisément d'être trop léger sur le typage (et de faire des vérifs au runtime) pour l'envisager sur de gros projets.