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).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
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'
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Elle y est… mais en fait c'est casse pied ces histoires : Il y a du scroll et il faut scroller. Ce n'est pas volontaire, loin de là. J'ai mis genre 90% de hauteur, il faudrait un peu moins ou plutôt 100%-Xp/em.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
En fait je ne sais pas comment alimenter le Wiki en automatique à partir de la carte. Le wiki est donc un peu de côté actuellement. Il est plus là, pour susciter des idées et ouvrir les portes.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Moi, je dirais que c'est toujours vrai. Néanmoins il y a après le principe de réalité. Autrement dit, "plus simple, c'est mieux mais encore faut-il pouvoir/vouloir."
C'est un peu ce que fait Elon Musk quand il dit : "Best part is no part". Autrement, dit, la meilleur pièce est sans la pièce. Pour autant, il fait des voitures et des fusées, autant dire qu'il y a beaucoup de pièces. Comment il fait pour supprimer des pièces : Il demande une vision globale. C'est à dire qu'en gros le cheminement est : "Cette pièce, ok, elle sert à ça. Mais ça on en a besoin à cause de ça, si on intervient donc en amont on peut supprimer tout ça"
En informatique c'est un peu pareil. Beaucoup d'informaticiens manquent de vision globale du projet surtout au niveau des chefs. Et plus on monte, pire c'est. Ils vont dire, "Ca marche, ça me va". Ca marche mais à quel prix?
Parlons concret : XML, est langage qui peut tout faire mais il est très lourd à parser, très sensible aux erreurs de balises et pas si lisible que ça par l'humain… Il a fallut du temps mais heureusement aujourd'hui il disparait au profit du JSON. JSON, n'est pas parfait, mais au combien moins verbeux (Moins lourd) et plus simple à parser. Parfois le CSV, est tout simplement le plus adapté. CSV c'est génial : C'est simple, ça se lit dans un LibreOffice (Excel) très bien, la part du poids des méta-données est négligeable (Simplement le séparateur) et c'est hyper efficace à parser. En plus CSV peut-être traité ligne par ligne, sans avoir à charger tout le fichier. Ca ne veut pas dire que le XML soit à jeter (Quoique).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et en plus
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à -1.
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).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et en plus
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à -4.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et en plus
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à -6. Dernière modification le 17 mars 2024 à 21:12.
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.
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.
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.
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…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Abondonner au profit de Libre-Office
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien OpenOffice 4.1.15 est là (la version 4.2 toujours en attente) [correction de bugs divers]. Évalué à 5.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et en plus
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à -2.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et en plus
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien Java is becoming more like Rust, and I am here for it!. Évalué à -4.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Un outil très versatile...
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien OpenGFW, implémentation open-source de GFW, le grand firewall chinois. Évalué à 1. Dernière modification le 11 mars 2024 à 02:21.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Dérégulation réglementée.
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Des cycles, des applis et des données. Évalué à 2.
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…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Dérégulation réglementée.
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Des cycles, des applis et des données. Évalué à 2. Dernière modification le 09 mars 2024 à 09:03.
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…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Periodical
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Des cycles, des applis et des données. Évalué à 2.
Oui, dans la mesure où le sperm peut se conserver 7 jours… ça n'indique pas un haut degré de fertilité non plus.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Dérégulation réglementée.
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Des cycles, des applis et des données. Évalué à 1.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Près de Chez Nous
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 3.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# C'est intelligent
Posté par abriotde (site web personnel, Mastodon) . En réponse au journal Doom et jardinage. Évalué à 5.
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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Partagé sur le Slack de OpenFoodFacts
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
Merci.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Logo
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
C'est pas mal vu :D
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Appli sur FDroid
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
A peine plus loin :
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Appli sur FDroid
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
Ce n'est pas simple. J'en suis à l'étape de build dans un docker :
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: OSM Key:craft
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
J'avais trouvé man_made=works mais c'est trop indstriel dans l'ensemble. Par contre craft est intéressant. A creuser.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Et les AMAP ?
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 4.
C'est effectivement à creuser.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Près de Chez Nous
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 4.
Je vais les contacter.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Attribution OpenStreetMap
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 3. Dernière modification le 26 février 2024 à 00:52.
Elle y est… mais en fait c'est casse pied ces histoires : Il y a du scroll et il faut scroller. Ce n'est pas volontaire, loin de là. J'ai mis genre 90% de hauteur, il faudrait un peu moins ou plutôt 100%-Xp/em.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Appli sur FDroid
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
Surement, je le remonte dans mon TODO. Je te dirais quand ce sera fait.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: pistes subventions
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2.
Pourquoi pas. C'est un peu un modèle pour moi. J'apprécie leur façon de voir les choses.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beau projet
Posté par abriotde (site web personnel, Mastodon) . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 1.
En fait je ne sais pas comment alimenter le Wiki en automatique à partir de la carte. Le wiki est donc un peu de côté actuellement. Il est plus là, pour susciter des idées et ouvrir les portes.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Des idées intéressantes, mais simplistes
Posté par abriotde (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à -1. Dernière modification le 24 février 2024 à 23:01.
« plus simple = mieux »
Moi, je dirais que c'est toujours vrai. Néanmoins il y a après le principe de réalité. Autrement dit, "plus simple, c'est mieux mais encore faut-il pouvoir/vouloir."
C'est un peu ce que fait Elon Musk quand il dit : "Best part is no part". Autrement, dit, la meilleur pièce est sans la pièce. Pour autant, il fait des voitures et des fusées, autant dire qu'il y a beaucoup de pièces. Comment il fait pour supprimer des pièces : Il demande une vision globale. C'est à dire qu'en gros le cheminement est : "Cette pièce, ok, elle sert à ça. Mais ça on en a besoin à cause de ça, si on intervient donc en amont on peut supprimer tout ça"
En informatique c'est un peu pareil. Beaucoup d'informaticiens manquent de vision globale du projet surtout au niveau des chefs. Et plus on monte, pire c'est. Ils vont dire, "Ca marche, ça me va". Ca marche mais à quel prix?
Parlons concret : XML, est langage qui peut tout faire mais il est très lourd à parser, très sensible aux erreurs de balises et pas si lisible que ça par l'humain… Il a fallut du temps mais heureusement aujourd'hui il disparait au profit du JSON. JSON, n'est pas parfait, mais au combien moins verbeux (Moins lourd) et plus simple à parser. Parfois le CSV, est tout simplement le plus adapté. CSV c'est génial : C'est simple, ça se lit dans un LibreOffice (Excel) très bien, la part du poids des méta-données est négligeable (Simplement le séparateur) et c'est hyper efficace à parser. En plus CSV peut-être traité ligne par ligne, sans avoir à charger tout le fichier. Ca ne veut pas dire que le XML soit à jeter (Quoique).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.