abriotde a écrit 982 commentaires

Il faudrait ajouter les bonnes raisons de choisir la licences Mit et celles de choisir la Gpl.

• MIT rassure les entreprises privées car avec la GPL elles ont peur de la contagion. A savoir qu'elles ont peur de devoir mettre tous leur soft en GPL s'il y a un bout de GPL dedans. C'est faux mais le lobby anti-open-source joue dessus et les PME n'ont pas les moyens d'étudier plus la question. Résultat, si tu est en MIT, tu devrait avoir plus de contributions d'entreprises privé qui veulent intégrer leurs spécificités.

• GPL à l'inverse rassure effectivement l'auteur car cela empêche une entreprises de partir du software et de le faire évoluer bien plus vite que l'auteur avec de gros moyens privé. Cela c'est vu dans les années 2000 mais aujourd'hui le risque est très limité car la communauté open-source est très reactive. On le voit dans l'IA.

La meilleure illustration de ceci est BSD vs Linux. Bsd est type MIT et on voit qu'il est soutenu par des entreprises très puissantes mais beaucoup plus discrètes que Linux.

A l'origine, on écrivait le code sur papier. Il était ensuite saisi dans l'ordinateur par un/une secrétaire. en fait on réfléchissait sur papier et essayait de tout corriger avant la saisie. C'était long et complexe de saisir dans l'ordinateur. Au tout début il fallait parfois le coder sur le ruban en binaire à la main…

Merci Free. Sans lui nous l'aurions.

comment trouves-tu en 2024

Bien sûr tu n'en trouves pas. Mais tu sais que si tu installe un vieux compilo sur un PC tu pourra compiler ton programme comme on le fait avec n'importe quel programme C/C++ ou autre programme compilé. C'est inhérent aux langages compilés. Généralement ils ont un mode de rétro-compatibilité (-c89 pour comilé un programme C de la norme 1989) et sinon tu peux installer le binaire de 1989 sur un PC récent et le recompilé. Le compilateur n'a pas (ou très difficilement) des failles de sécurité.
Alors que trouver un compilo Java qui te produit un binaire compatible JVM8 pour un programme Java aux normes de 1990, c'est une autre paire de manche. Je me trompe peut-être mais ça n'existe pas à ma connaissance.

PS : c'est pire avec un langage interprété comme Python. Il est totalement impossible de faire tourner un programme Python1 sur un Python3.

Bref, l'idée est de dire que la compatibilité binaire d'un programme compilé, n'est généralement pas un problème.

En fait le vrai problème, existe : La compatibilité binaire des librairies Rust pour des programme C (l'inverse est moins vrai). Actuellement c'est un point noir pour lequel Google à donné 1 million de dollars mais il sera résolu.
Mais c'est pire en Java, c'est impossible à ma connaissance: appeler un binaire Java avec un programme C qui a prévu d'appeler un librairie C (Même en le voulant dans le code C, ça doit être bien galère). Et se problème se pose juste parce que l'on veut remplacer C au plus vite morceau par morceau. Ce n'est pas un problème Rust à la base.

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.

D'accord mais à algorithme équivalent Rust l'emporte. Et un développeur veut que son programme tourne le plus vite possible sans passer trop de temps à l'optimiser. S'il faut 3 jours de dev en Python pour faire l'équivalent en Rust en 1 jours. Et il y a autre chose, dans un pilote, rajouter une JVM n'est pas envisageable. Et si c'est possible sur un serveur, c'est de la maintenance en plus, d’où la préférence de Go pour sa maintenance simplifié.

T'inquiètes, je pense que des experts se penchent sur chaque détails de chaque langages pour les optimiser avec les dernières techno de pointe. Python, PHP, Java, C, Rust améliorent chaque jours leurs perfs. Si la HashMap avec l'algorithme de hashage par défaut de Rust est très lente ça ne durera pas.

Non :

• Go, Swift : Bah c'est comme du Java (Avec garbage-collector) : Performant mais pas autant que C et beaucoup plus lourd binairement parlant et beaucoup plus consommateur de RAM. C'est bien pour des application serveurs mais pas poour de l'embarqué, ou de la haute performances : Carte graphique : Jeux vidéos, IA, pilotes, calculs hautes perfs aux ressources limités…
• D, Nim, Crystal, Zig, Pascal, Objective C : Ce sont des concurent de C, mais ils ne sont pas mémory-safe comme Rust.
• Ada : Oui top, mais moins productif encore que Rust. Ca n'est nécessaire que quand le plantage logiciel ou même la simple erreur de programme met en jeu des vies humaines (Ou des milliards): Aéronautique, spatial, et parfois dans le transport…

PS : 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. Ce n'est pas parce que c'est hype. C'est parce qu'il y a dans Rust quelques chose de plus qu'il n'y a pas dans les autres concurrents.

PS2 : Alors oui, il se développe quelques langage qui reprennent les concepts Rust et qui sont aussi bien… mais Rust est maintenant le leader, alors je doute qu'il percent réellement sans killer feature.

Java n'est pas si stable binairement en tout cas beaucoup moins que C. C est stable sur 30 ans au minimum alors que va faire tourner un programme compilé en Java 3 sur une JVM Java 8… Ca marchera pas car il n'est pas stable (surtout les libs).

C'est aussi un autre problème de Java: Il est dépendant d'une JVM à la bonne version et avec les bonnes lib (Peut-être peut-on les compiler en statique en Java?).
En Rust, c'est la config du compilo qui décide de l'OS sur lequel il va tourner. et pour les libs tu peux les compiler en statique.
Le problème fondamental c'est qu'un programme C ou Rust écris il y a 20/50 ans peut tourner tel quel sur une machine moderne juste en étant recompilé. En Java, il faut soit installer une vielle JVM (Avec les lib) et toutes leurs failles non maintenus soit, migrer le code dans la dernière version de Java.

C'est le même problème que tous les langages interprété à la différence que la JVM reste plus stable binairement que Python, PHP et consorts (Car ils sont interprété et donc sensible au moindre changement de syntaxe).

Pour cette raison entre autre, je préfère encore le Go au Java (Pour plus de productivité que Rust).

C'est s'arrêter proprement. Peut être pas volontairement pour le programmeur. Java fait pareil. Mais ils ne corrompent pas la mémoire autour pour autant.

Par contre en Rust pour générer un pannic! il faut normalement faire un ".unwrap()" ou quelque chose de cet ordre. Autrement dis explicitement dire "bah tu t'arrête". Autrement dis c'est clairement que volontairement tu a voulu ne pas géré le plantage. En Java, tu n'a rien qui te préviens et tu ne peux pas t'ammuser à tester chaque pointeur. Et même si tu le fais, tu va en oublier…

Mais l'avantage de Rust sur Java, c'est surtout sa vitesse d'exécution. Autrement dis : "Rust gère mieux la mémoire et surtout va beaucoup plus rapidement pour une productivité similaire"… Evidemment, encore une fois, tout est compromis entre productivité et vitesse d'exécution en langage informatique.

Aucun programme dans un OS de ses 30 dernières années pourrait corrompre la mémoire comme ça

Bien sûr que si. La seul chose c'est qu'effectivement l'OS limite le phénomène et généralement la corruption est limité au programme qui tourne et arrive très rarement aux autres programmes/drivers et exceptionnellement à l'OS.

Non quelque soit le langage si l'OOM killer veut ta peau il l'aura

Bien sûr que Rust consomme de la mémoire, mais en quantité plus limité surtout il évite en grande majorité ce que l'on appel la fuite mémoire. La fuite mémoire c'est quand tu alloue de la mémoire en boucle sans jamais la libéré. Or en Java comme tu sais que tu ne peux pas "oublier" de libérer la mémoire gâce au garbage collector, naturellement, tu fais moins attention. En Rust, cette fuite est possible mais bien moins courante car il le programme doit prévoir de libérer sa mémoire par conception. Mais évidemment si tu fait un appel récursif infini (Ou trop important..) par exemple, fatalement, dans un cas comme dans l'autre tu crash.
PS : l'OOM killer, est une "option" sous Linux (par défaut sur la plupart des distribs) mais pas toujours présente. Il est une sécurité pour éviter de crasher l'OS faute de mémoire.

Null-pointer-exception

Oui bien sûr qu'un accès null-pointer en C est bien plus grave en C qu'en Java, reste que c'est un plantage dû à la mémoire indésirable quelques soit le programme.
En Java en gros on quitte "Proprement", sans corrompre la mémoire contrairement à C. Mais en Rust, on a une exception que l'on est censé traité. Evidemment si on la traite pas on est comme en Java. Mais la différence n'est pas négligeable.

J'ai aucune idée de ce que signifie s'arrêter proprement particulièrement quand on ne gère pas.

C'est simple, quand un programme crash il fait n'importe quoi autrement dis il peut faire du dégât comme en C ou il peut aller ailleurs dans la mémoire et écraser tout et n'importe quoi. Mais pire, il peut ne pas planter, et continuer avec des donner qu'il a totalement pourri. Souvent d'ailleurs le crash réel intervient longtemps après.
En Rust et en Java on a une exception. La mémoire n'est pas corrompu et si on gère "l'exception" on peut utiliser les données car elles restent bonnes (Elles n'ont pas été altérées par le programme).
Evidemment, en Rust comme en Java, tu peux par bug, faire entrer le programme dans un comportement impossible et corrompu malgré tout (Par exemple mettre 400° dans un angle censé être entre 0 et 360). Ada est le langage ultime pour ça mais il est encore bien moins productif…

Je ne vois pas l'intérêt de continuer Open-Office en plus de Libre-Office. Les 2 applications ont exactement la même cible (Il y en a pas un orienté cloud ou light ou…).

On peut dire qu'Oracle à gagné. Il a racheté Open-Office pour ralentir au maximum son développement. Une fois quasi-stoppé, la communauté s'est révolté et a forké vers Libre-Office. Et quand c'est devenu trop flagrant qu'Open-Office était à la ramasse, ils l'ont donné à la fondation Appache… Résultat 2 projets très similaires mais aux codes suffisamment différents pour ne pas pouvoir être mergé… Et une bataille d'égo au sein de l'open-source. Clairement, maintenant que partout c'est Libre-Office qui à remplacé Open-Office, il faut le lâcher… C'est du développement pour rien.

Pourtant Rust n'a pas de concurrent sérieux. Il est plus sécurisé que le C et aussi rapide soit plus rapide que le C++ alors forcément plus que le Java et infiniment plus que Python et consort…

En contrepartie évidemment, il est plus complexe et moins productif que les langages interprété. Mais avec un peu d'entrainement, il est même plus productif que C et autant que C++. Autrement dit, il est mieux que C et C++, Java… mais pas concurrent de Python, Go, PHP, etc…

Après évidemment pour un vieux projet en C, C++ ou Java cela ne vaut peut-être pas le coup de tout réécrire.

Tout langage à garbage collector / interprété est mémory-safe mais ce n'est pas le problème. Le problème c'est qu'ils sont lent. Et en plus Rust apporte un peu plus que ça. Il évite plus que Rust le "Out-of-memory" et surtout "Null-pointer-exception" qui est très commun en Java.

En gros Java crash sans corrompre la mémoire là ou Rust ne crash pas (ou quasiment pas) il s'arrête "proprement" sur une erreur consciemment non gérée.

Enfin je pense que c'est avant tout pour le fun. Ensuite, c'est un projet qui peut tout à fait être utile pour sécuriser un endroit sensible. Une entreprise "sensible" par exemple.

PS: les états ont toujours les moyens de développer bien mieux et plus pervers.

Par exemple pour certaines personnes discuter des effets secondaires de la pilule et des risques de cancer éventuel ce serait promouvoir le retrait

Ah mais c'est clair qu'aujourd'hui si tu nuance un tant soit peu un propos tu est matchiste, complotiste, terroriste, wokiste ou xénophobe. Le débat n'est plus possible en France. Pourtant la vérité n'est jamais blanc ou noir…

En gros on se préoccupe plus des résultats obtenus par les athlètes que de leur santé.

Et aussi on se preaucupe beaucoup plus de rassurer pour vendre un médicament que du reste. Probablement que ces études sont aussi plus pipées…

Oui, dans la mesure où le sperm peut se conserver 7 jours… ça n'indique pas un haut degré de fertilité non plus.

Je ne sais pas quoi en penser.

Ah, c'est simple et connu, le psychique joue beaucoup. Il est fort probable que le stress et la dopamine lors de l'effort synchronisent les choses. Après il n'y a pas de mécanisme clair pour prédire quoique ce soit sur le psychique de la femme.

Pour informations. Je les aient eu en visio. Ils ont un super produit qui pourrait bien me donner un sacré coup de main mais il y a un mais. Disons qu'ils ont un outils qui, techniquement, pourrait répondre à tous mes besoins mais en étant hébergé chez eux. Pour moi c'est un non sens. Cela leur coûte cher et je n'ai pas les moyens. En plus je suis rentré un peu dans leur code et c'est du PHP5… ce qui à un coût serveur/maintenance assez important (PHP5 est gourmand en ressources et en plus il est complexe de maintenir une vielles techno non maintenue) et en plus cela m’empêche de le faire tourner sur mon serveur mutualisé. Alors j'envisage d'upgrader leurs système en PHP7… mais c'est complexe, seront-ils partant? Leurs moyens sont limités.

En plus il y a autre chose : Mon système pur HTML est ultra light (Une parti du trafic n'arrive même pas jusqu'à mon serveur et est servi par les caches du réseau). Or 95% de mon besoin est statique (Que de la consultation). J'envisage une croissance idéalement importante de mon trafic, je n'ai pas envie de payer cher en hébergement.

Ils ont poussé loin la pub :D .
Ca leur donne une image cool et assez ouvert. Je trouve l'idée de soutenir un tel projet tellement plus intelligents que tout ceux qui condamne le hack de leur objets sous prétexte de problème de sécurité…
Après j'imagine que cela ne va pas les faire râler s'il y en a qui hack leur tondeuse pour la réparer. Mais un pas est fait au moins.

Merci.

C'est pas mal vu :D

A peine plus loin :

vagrant@d0535e79e3d6:/build$ fdroid checkupdates --allow-dirty openproduct
2024-02-26 22:19:11,756 INFO: Processing openproduct
2024-02-26 22:19:15,951 ERROR: …checkupdate failed for openproduct : No tags found

Ce n'est pas simple. J'en suis à l'étape de build dans un docker :

vagrant@642a7549e0bb:/$ cd build/
vagrant@642a7549e0bb:/build$ fdroid readmeta
2024-02-26 21:35:09,544 CRITICAL: Unknown exception found!
Traceback (most recent call last):
File "/home/vagrant/fdroidserver/fdroid", line 22, in
fdroidserver.main.main()
File "/home/vagrant/fdroidserver/fdroidserver/main.py", line 222, in main
raise e
File "/home/vagrant/fdroidserver/fdroidserver/main.py", line 203, in main
mod.main()
File "/home/vagrant/fdroidserver/fdroidserver/readmeta.py", line 34, in main
metadata.read_metadata()
File "/home/vagrant/fdroidserver/fdroidserver/metadata.py", line 567, in read_metadata
read_srclibs()
File "/home/vagrant/fdroidserver/fdroidserver/metadata.py", line 548, in read_srclibs
srcdir.mkdir(exist_ok=True)
File "/usr/lib/python3.9/pathlib.py", line 1312, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: 'srclibs'

J'avais trouvé man_made=works mais c'est trop indstriel dans l'ensemble. Par contre craft est intéressant. A creuser.

C'est effectivement à creuser.