David Delassus a écrit 749 commentaires

Created VSCode and made it the best and open-source IDE that everyone would jump to first.

Et moi qui utilise encore Visual Studio Community 2019 pour C#/Unity, Sublime Text sous Linux pour éditer vite fait des fichiers par-ci par-là (le startup time est juste incomparable, mais sous Windows je me contente de notepad qui fait le taf). Sur des serveurs je continue d'utiliser le très vénérable arbre mojo vim (où vi quand je peux pas l'installer).

Oui bon ok, j'utilise VS Code pour tout le reste.

Après, histoire de pinailler. Le seul IDE dans le lot que j'ai cité, c'est Visual Studio 2019. Le reste c'est des éditeurs de texte (oui parce que j'utilise pas le débugger de VSCode, ni sont système de build/tâches). En fait, c'est ptet le terminal avec bash (ou git bash sous Windows) mon IDE, tout simplement.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Je crois qu'emacs reste toujours le meilleur IDE OS open-source.

Voilà, c'est corrigé :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Je me suis foiré dans le copy/paste. Il y a 4 espaces en trop dans la ligne ~~~~~~~~~~~^^^^^ ce qui aligne pas correctement l'erreur.

Si vous pouvez corriger, ça serait chou <3

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.

Le "business development" qui comprend l'acquisition de client, l'entretien de la relation client, éventuellement du marketing, etc… Ca coûte de l'argent. Plus t'en as a investir dedans, plus tu sera efficace.

"sans argent" ça insinue que Gérard dans son garage peut le faire et peut en vivre. C'est faux.

Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent.

Oui c'est pour ça que j'ai dit :

C'est pas pour rien que les plus gros contributeurs à l'écosystème libre c'est les GAFAM, les Red Hat, etc… qui ont d'autres revenus conséquent qui leur permet d'investir dans le libre.

Donc on est bien d'accord.

Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.

Sauf que si tu es éditeur de logiciel libre, tu consacre une grosse partie de ton budget (payer les ingénieurs, le marketing, l'avant vente, etc…) sur quelque chose qui ne rapportera pas (car ce n'est pas le logiciel que tu vends). Que cela soit un moyen ou un finalité, c'est un investissement qui est plus facile a faire quand tu as d'autres revenus.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

A noter toutefois que pour "Amazon qui forke ElasticSearch" tout est libre la dedans

C'était justement pour appuyer mon point que si on a les moyens financier d'Amazon, on peut se permettre de faire du libre sans se soucier de la compétition.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Bizarrement je ne vois pas votre empathie quand c'est les GAFAM qui font exactement pareil pour exactement la même raison.
2 poids, 2 mesures.

Pour ma part, à partir du moment ou l'auteur est une compagnie privée, faire du non-libre, c'est fair game.

Amazon qui forke ElasticSearch ? Fair game.

Google qui garde jalousement ses algos privés et qui après bien les avoir exploité en sort une version avec moins de fonctionnalités (BigTable, Kubernetes, …) ? Fair game.

Une PME comme Sentry qui fait du proprio et libère après 3 ans ? Fair game.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Le terme exact quand c'était libre dès le début et que cela ne l'est plus c'est "devient", pas "redevient".

La ça sous-entend une girouette "on a fait du proprio, on a essayé le libre, et en fait nan".

De plus, comme d'autres commentaires l'ont déjà dit, la phase propriétaire est temporaire. Et je trouve que cela est une excellente idée pour continuer de contribuer à l'opensource et garder un certain avantage en tant que business, un parfait juste milieu.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'aime bien la BSL.

Parce que au bout d'un moment, il faut être réaliste.

T'es un business, ton but c'est d'être viable, de générer du revenu, de payer tes employers, de payer ta direction. Bref, le but d'un business c'est de faire de la thune.

Avec le temps, je me suis rendu compte pour faire de l'argent avec du libre, il faut…. de l'argent, beaucoup d'argent.

C'est pas pour rien que les plus gros contributeurs à l'écosystème libre c'est les GAFAM, les Red Hat, etc… qui ont d'autres revenus conséquent qui leur permet d'investir dans le libre.

Mais quand t'es un trou du cul avec ta petite PME, t'as pas assez d'argent pour faire du libre efficacement.

Le business a peut être commencé avec des techos qui aiment réellement le libre, qui se sont rendus compte tristement dans une grande désillusion qu'ils ne sont ni Google, ni Amazon, et qu'ils doivent manger, et ont décidé à contre cœur une des options suivantes :

• faire du proprio
• faire de l'opencore
• faire du dual-licensing
• faire du faux libre (comme avec la BSL)

Cela a été le choix d'ElasticSearch, de MongoDB, de Qt, de Sentry, et de bien d'autres.

J'aimerais bien moi faire du libre 100% du temps, et avoir de quoi payer mon loyer et ma bouffe, et mettre même un peu de côté pourquoi pas ?

le libre c'est bien tant que les autres n'utilisent pas les libertés du libre, la compétition à armes égales c'est chiant en fait.

Bref, c'est vrai, mais c'est extrêmement réducteur et manque d'empathie.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Pourquoi? Tu aimes coder pour du proprio?

La vrai question c'est : es-tu prêt a ignorer la majorité des utilisateurs potentiels de ton appli ?

Il me semble que les Linux et *BSD c'est même pas 5% des parts de marché.

C'est bien d'être libriste, mais à un moment il faut être réaliste.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

En Lua tu as des tables. L'opérateur # retourne le nombre d'éléments dans la table. Une table ne peut pas contenir nil (et donc assigner nil a un élément de la table le supprime de la table). Les clés d'une tables peuvent être des nombres, des strings, des fonctions (oui oui), etc…

Lorsque l'on créé une table sans préciser les clés, c'est comme si on utiliser des nombres en partant de 1:

local l1 = {"a", "b", "c"}
local l2 = {[1] = "a", [2] = "b", [3] = "c"}

Pour parcourir une table on utilise:

for key, value in ipairs(l1) do
  print(key, value)
end

Lua n'a donc pas vraiment de "liste" / "tableau". Que des dictionnaires, donc utiliser les indices pour parcourir une table n'est vraiment pas la bonne pratique.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Héhé ça fait plaisir de voir ce commentaire :)

En plus en ce moment ça avance pas mal, de grosse news arrivent au moins avant la fin d'année !

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

leur tableaux commençant a l'index 1

Je ne classerai pas ça comme une boulette (ni grosse ni petite).

C'est un choix subversif certes, mais rappelons que du point de vue des maths (point de vue que prend Julia), c'est l'index 0 qui est bizarre.

Aussi, l'argument souvent avancé pour l'index 1 vs l'index 0 c'est le "off by one error" qui est censé ne pas arriver avec l'index 0.

• mais il y a une librairie qui permet de faire des tableaux avec des index de début arbitraire
• leur système de typage ne permet pas de différencier les 2 types de tableaux
• il y a des librairies qui hardcode l'index commençant à 1 et ce qui veut dire qu'elles ne fonctionnent pas avec les tableaux avec index arbitraire :-(

Oui bon la je peux plus les défendre…

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

1/4 du code du kernel sera dans un bloc unsafe.

Avec ce 1/4 bien encapsulé dans une API safe, on a donc 3/4 du code qui est garanti safe par le compilateur.

Aussi : https://os.phil-opp.com/

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

C# et Java sont vraiment de bons langages, en constante évolution.

Je vois le C# beaucoup utilisé comme "scripting engine" dans le GameDev, qui se prête bien à la POO que proposent ces langages.

Je suis pas sûr d'ou viendrait une motivation à les enterrer, vu ce qu'ils apportent (CassandraDB est en Java).

Faut pas oublier que la JVM est hautement paramétrable, et que GraalVM va encore plus loin.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.

Après plus d'un an à écrire du Rust, je me suis rendu compte d'une chose :

Rust n'est pas un langage "general purpose".

Il vise la programmation système, de bas niveau (en utilisant des concepts de haut niveau le plus possible), la ou on a un besoin d'un contrôle précis sur les performances, les allocations, etc… (osdev, gamedev, real time systems, etc…).

A cause de ça, le language reste un langage de niche. On est très très loin des API CRUD faite en autre chose que Java, Python et/ou Go (qui est un langage safe aussi, mais avec d'autres tradeoffs).

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Vous savez que Rust n'a rien inventé ?

Vous savez qu'il existe de nombreux outils pour s'assurer que le code est safe, comme :

• https://github.com/NASA-SW-VnV/ikos/
• http://splint.org/
• … (voir https://github.com/analysis-tools-dev/static-analysis )

vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?

Toutes les applications ne sont pas critiques. Le C est un important language a avoir dans sa besace, et il reste invaincu en termes de performance, il reste le language le plus proche qui soit de la machine, il reste le seul langage aussi portable sur tant d'architectures complètement différentes (car il n'y a pas que x86 dans la vie), etc…

Bref, merci de la leçon de morale, j'aurais pu m'en passer.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

une liste doublement chaînée, en Rust, sans unsafe

Avec RefCell<T> c'est facile.

Un structure récursive aussi c'est difficile à implémenter, tu passes un temps fou à te battre avec le compilateur pour qu'il accepte ce que tu lui décris

Soit tu choisis la facilité avec Box<T>, soit tu gères correctement les lifetimes avec &T, soit tu utilises RefCell<T>, … il existe plein de manière différente de faire ça.

Ne pas oublier aussi std::mem::replace qui est un très bon ami dans ce genre de situation.

Avec un peu d'expérience en Rust, et un peu de googling skill, ça devient tout de suite plus facile.

Je recommande aussi ##rust sur le IRC liberachat. Ils sont actifs, et ont très souvent la réponse a toutes questions que tu pourrais avoir.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Pourquoi faire simple quand on peut faire compliquer ?

Je dirais même que vu que malloc et free font éventuellement des appels systèmes, on devrait appeler :

Kernel Programming Interface ==> KPI

De quoi rendre confus les managers :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

La majorité en anglais… pas du tout le même public

Les sous titres ça existe.

tout comme Lê que tu ne cites même pas

Parmi les milliers de chaîne youtube qui existe, il y en a beaucoup que je ne cites même pas, c'est à ça que les … servent en général.

Oh! et les autres aussi disent des conneries.

Personne a dit le contraire.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'aimais bien e-penser fut un temps, mais c'est un peu une drama queen (un drama king?) et il n'a jamais su garder une roadmap (avec ses "on en parlera une autre fois"). Il y a tellement d'autres chaînes de vulgarisation de meilleure qualité, même si la plupart sont en anglais :

• https://www.youtube.com/c/ArvinAsh (physique - anglais)
• https://www.youtube.com/c/pbsspacetime (physique - anglais)
• https://www.youtube.com/c/pbsinfiniteseries (math - anglais)
• https://www.youtube.com/c/UpandAtom (physique - anglais)
• https://www.youtube.com/c/3blue1brown (math - anglais)
• https://www.youtube.com/c/Fouloscopie (sciences sociale? - français)
• https://www.youtube.com/c/Micmaths (math - français)
• https://www.youtube.com/c/PrimerLearning (math/algorithmie - anglais)
• https://www.youtube.com/c/Reducible (computer science - anglais)
• https://www.youtube.com/c/ScienceClic (physique/math - français)
• https://www.youtube.com/c/ScienceEtonnante (physique/math/… - français)
• https://www.youtube.com/c/StuffMadeHere (ingénierie - anglais) NB: ce mec pourrait être Iron Man
• …

EDIT: J'hésitais a mentionner DirtyBiology à cause des récents événements, mais séparons l'oeuvre de l'artiste. Nombreuse de ses vidéos sont très intéressantes.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ça coutait trop cher de récupérer les données des 3 milliards restant ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

A chaque fois que je vois un sujet sur les mails, je repense à Google Inbox.

Ce joli produit à l'interface simple, et puissante, qui était le seul client mail ou je ne laissais pas ma boite mail devenir un tas de merde non trié, impossible à exploiter.

Un des rares produits google à avoir une bonne UX, alors que d'habitude c'est un désastre (coucou GCP, GMail, etc…).

Nostalgique de l'époque avant que Inbox ne rejoigne le cimetière google, je fais une petite recherche et tombe sur Shortwave !

Haaaa, en 5min ma boite mail est de nouveau exploitable.

Merci pour ton journal que je n'ai pas lu. J'ai pu retrouver une belle techno.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Les pierres de la faim sont des pierres sur lesquelles sont gravées des messages du type "Si tu me vois, pleure".

Ces roches sont normalement au fond des rivières, et le fait de les voir indique que le niveau de la rivière est très bas due à une sécheresse qui précède une famine.

Je suis triste de vivre dans un monde ou un "mur de cookie" est une mauvaise chose :(

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

// C
typedef struct
{
  int a;
  struct 
  {
    double x;
  } bar;
} Foo;

// C3
struct Foo
{
  int a;
  struct bar 
  {
    double x;
  }
}

Ok alors, en C c'est parfaitement clair :

• struct y {} est un type
• struct {} y est une variable dont le type est une structure anonyme

Mais en C3:

• struct Foo {} est un type
• struct bar {} est une variable dont le type est une structure anonyme

Apparemment, les "structures sont toujours nommées" sauf :

• quand c'est nested
• quand c'est passé en argument

Pourquoi complexifier autant la syntaxe ? Ce qu'on avait initialement en C était déjà parfaitement clair.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Tout le monde sait qu'il faut travailler des machines des processeurs un tant soit peu puissants, avec un minimum de ram et des disques potables avec java. Et là, on commence à parler :-)

L'intérêt de Java et de la JVM c'est pas write once, run everywhere ?

L'argument est douteux, si tu configure proprement ta JVM, et optimise correctement ton appli, Java va très bien tourner même sur un grille pain.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg