Ruminant a écrit 108 commentaires

C’est vrai :) Malheureusement… j’ai encore eu des problèmes avec et j’ai abandonné après trois jours de recherche, pour retourner sur ces horribles IDE RAM-ovores :D

Non et puis un gros frein c’est aussi de devoir réapprendre beaucoup trop de bindings pour être efficace. Venant de Vim, c’est chronophage.

Non mais je suis complètement d’accord, mais, déjà, avant d’avoir des retours sur le support linux, il faut que certains s’y cassent les dents.

Mon Lenovo E480 ainsi que la machine du boulot (un HP je sais plus quoi) ont eu les mêmes problèmes de pilote de la puce vidéo intégrée Intel. Il a fallu attendre le kernel 5.4 pour corriger le souci de freeze récurrent.

Enfin, je ne parle pas seulement du matériel (surtout qu’à ce compte là, Windows n’est pas forcément mieux logé) mais aussi du software.

Loin de moi l’idée de cracher dans la soupe, je suis bien content de pouvoir faire 90% de ce que je veux sur linux (les 10% restant c’est les jeux vidéo et éventuellement tester un soft pourri de visioconférence) et en plus d’avoir la liberté de choisir i3 comme gestionnaire de fenêtre.

Seulement bon, il aura toujours fallu que je bidouille pour faire taire un message récalcitrant sur un rapport de plantage, une conf réseau qui refuse de se faire oublier, un gestionnaire de login qui plante…

En ce qui me concerne j’accepte ces problèmes parce que je sais les contourner et que le bénéfice que je tire à configurer proprement les choses me permet à la fin d’avoir ce que je veux.

Mais avant d’en arriver là, il a fallu que j’investisse quelques années de boulot. Clairement pas ce que souhaite faire la plupart des utilisateurs/trices.

Bon mais de toute façon, chaque OS a son lot de problèmes.

Malheureusement rien n’est absolument parfait non plus ^{^}

À aucun moment je n’ai dit l’inverse. Est-ce que ça intéresse la plupart des utilisateurs, c’est ça la question.

Et puis c'est toujours sympa de considérer que l'intégralité des utilisateurs de macos sont des « bobos des centre ville ».

Tout le monde n'est pas au fait de comment fonctionnent nos machines et la plupart veut juste que ça fonctionne.

Bientôt 15 ans sous Linux, ça ne m'est jamais arrivé d'avoir quelque chose qui « juste marche ».

Du coup ouais, je pense que certaines personnent savent ce qu'elles veulent : un truc qui marche sans avoir à penser à rien.

Paraît qu'il faut quand même faire un pacte avec Chtuluh et disposer de minimum 20 ans devant sois pour configurer proprement le bousin.

Bof, pour ma part je suis plutôt circonspect de l’absence de temps ainsi que de précision.

Le double sens semble possible tant il est nécessaire de faire travailler son imagination pour comprendre avec précision ce dont il est question.

Quant à l’étymologie, (Science qui a pour objet la recherche de l'origine des mots d'une langue donnée, et la reconstitution de l'ascendance de ces mots. selon le Larousse), semble être une science créer pour comprendre les langues déjà créées et dont on a, en quelque sorte, perdu l’étiquette de traçabilité. Ce qui n’est pas le cas avec une langue construite, à partir du moment où l’histoire de celle-ci est conservée et ne se perd pas en route :D

Après, une langue s’inscrit aussi dans un contexte et les "usages", la vie quoi, feront que l’on va ajouter du vocabulaire à mesure qu’il devient nécessaire d’être précis et éventuellement concis.

Il existe bel et bien des langues "non construites" sans notion de numération, car le concept et le besoin même de dénombrer avec précision des objets n’existe pas et n’est pas nécessaire.

Source : https://www.personal.psu.edu/ejp10/blogs/thinking/2008/07/the-language-without-numbers.html

En ce qui me concerne je trouve cette langue (Toki Pona) « rigolote » et je ne pense pas que l’on puisse extrapoler quoi que ce soit avec. Ça peut avoir son intérêt pour certaines personnes sans pour autant réduire « l’expression humaine à 120 mots ». D’ailleurs, c’est quoi, l’expression humaine ?

Une phrase du journal le dit très bien : « Même si la langue est complètement inutile pour faire de la documentation technique ou de la diplomatie car pas assez précise, il peut faire une excellente langue universelle de base pour survivre à l'étranger. Pis sinon, son apprentissage occupe pendant les jours de pluies et permet de faire un peu de gymnastique cérébrale. »

J’aime assez l’idée d’avoir à disposition un langage minimal sur lequel on pourrait se reposer de façon universelle. Ça serait encore plus marrant de voir ce qui pourrait en ressortir. Peut-être que toutes les langues du monde, exposées au tourismes et échanges internationaux en général, finiraient par avoir du Toki Pona en usage courant !

Bon aujourd’hui c’est l’anglais semble-t-il. Ou plutôt le "Globish" comment l’appellent certains élitistes.

Ce n’est pas déjà une pièce de musée ?

N’oublions pas pour autant que le projet accepte les donations.

Loin de moi l’idée de faire la morale, je pense tout simplement que s’il est possible de donner quelque chose aux outil qu’on utilise, c’est toujours ça de gagné pour le libre et ça permet de pérenniser les projets qu’on aime :)

https://inkscape.org/support-us/donate/

Il y a sway qui reprend le fonctionnement et la configuration de i3 et utilise wayland.

Je pense que tu connais, mais pour les éventuels curieux qui passeraient par là :)

Je prenais ce logiciel comme j’aurais pu prendre un autre, c’était pour illustrer :)

Mais effectivement je n’ai pas eu de freeze depuis un moment avec lui.

On peut quand même essayer de limiter la casse : par exemple, nautilus ne devrait pas (à mon avis, hein) complètement freezer dès qu’il essaye d’accéder à un partage réseau en berne.

On devrait quand même être capable de le fermer, ou simplement de naviguer dans d’autres dossiers etc.

Il est inutile et effectivement illusoire de vouloir rendre tout "parfait", on peut au moins éviter de galérer comme des ânes et rendre les choses plus fluides. Vu que les utilisateurs sont humains, on peut se permettre quelques dizaines de millisecondes de freeze par-ci par-là, en quelque sorte :)

Ou alors ils n’ecrivent pas les accents, parce que ce n’est pas franchement necessaire, dans le fond : sur ce meme site nous avons eu droit a quelques journaux et commentaires ecrits sans accents, car la personne utilisait alors une disposition qwerty. Ca n’a pas empeche la communication.

Ici il s’agit d’un langage qui oblige a utiliser un caractere specifique, particulierement difficile d’acces, alors qu’il y a beaucoup d'autres caracteres immediatement disponibles et qui feront aussi bien l’affaire.

Bienvenue dans la realite, ou le plus grand nombre choisira autre chose parce, vu que ce qui est propose par defaut n’est pas accessible, en plus de ne proposer aucun avantage par rapport aux produits existants.

Ou même la commande cargo fmt, qui utilise rustfmt bien entendu, mais qui a l’avantage de passer sur tout le projet d’un coup.

En quoi utiliser un séparateur ou un autre - et offrir la possibilité d'en changer -, a une incidence sur le clavier ?

Doit-on vraiment reparler de ce o barré qu’il m’est impossible d’écrire sans devoir changer de disposition ?

Personnellement, j'en serais très heureux si ça pouvait être le cas.

On ne doit pas vivre dans la même réalité.

La problématique n’à rien à voir avec "TOML" vs "JSON", qui sont deux formats aux possibilités très différentes.

Là, quelque soit le séparateur, les fonctionnalités sont les mêmes : c’est comme si la configuration de Redis, selon la compilation, pouvait avoir des commentaire avec # par défaut, mais avec | dans d’autres cas, tout ça parce que la personne veut des | parce que c’est plus simple à écrire dans son cas…

Si on commence à devoir changer de disposition clavier pour pouvoir écrire sa conf on est pas sorti d’affaire.

J’ai l’impression que le propos n’a pas été compris.

Mettons qu’un script ai été écrit avec ce o barré, et utilisé sous une version du logiciel utilisant ce même o barré, tout va bien.

Mais dès lors que le script est utilisé par une autre version compilée avec, disons, >, boum, le script ne fonctionne plus.

Donc oui, ça ne va rien changer dans le logiciel, mais dès qu’on voudra l’utiliser on se retrouvera avec des incompatibilités stupides…

Quel souci ? Je suis perdu :)

Je ne suggérais pas d’utiliser urxvt pour pouvoir taper et lire des caractères "bizarres", mais à un moment faudrait peut-être aussi en finir avec l’ISO, non ?

Pourquoi ne pas utiliser urxvt ?

https://fr.wikipedia.org/wiki/%C3%98#Repr%C3%A9sentations_informatiques

Je reste convaincu que c’est une mauvaise idée d’utiliser ce caractère par défaut.

L’accessibilité/utilisabilité, c’est important.

Je ne suis pas sûr d’avoir compris ton message.

Si tu veux parler de comment la mémoire est gérée dans Redis, je n’en sais rien. J’imagine cependant qu’il doit y avoir à minima un système de "bucket" en fonction du temps d’expiration des clefs, pour pouvoir les nettoyer plus rapidement.

Pour le reste je n’en sais rien, et je parlais uniquement des objets imbriqués.

J’invite à la clémence, c’est ma contribution à la communauté… :)

Pas de souci :)

c’est un projet entièrement francophone

En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.

Robert se veut être un logiciel utilisable par le plus grand nombre

En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.

Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.

De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.

Le projet ne dépend d’aucune « caisse » (module) externe, volontairement, afin d’éviter le serpent des dépendances, qui rend complexe la maintenance

Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.

Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.

Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)

La base est constituée de « canaux »

Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?

Une valeur peut être […] un objet qui lui‑même est un dictionnaire de paires clé‑valeur. Il est donc possible de faire des « chemins » amenant à une valeur particulière dans l’arbre du canal.

Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?

En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.

En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.

Peux-tu m’éclairer à ce sujet ?

Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité : ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.

En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de HashMap provenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.

Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.

Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.

Ben quoi ?

Aurait-on franchi un nouveau niveau de marketing ?

En dehors de ce troll et sans même faire de Java, je suis un peu jaloux de ces annotations, surtout quand je regarde mon code en Go.

Personne n’a parlé de passer sur un BSD :

• opendoas est un portage sur linux
• sudo est disponible et largement utilisé sur les BSD, il est pertinent d’annoncer que sur ces plateformes, on peut utiliser d’autres outils.

Ensuite c’est sûr, les outils alternatifs ont peut-être d’autres failles. Pour le cas de opendoas, le programme est tellement petit en comparaison de sudo que le nombre de bugs possibles s’en trouve pratiquement automatiquement réduit.

Le programme parfait est un programme sans aucune instructions ;)