J’utilisais Evernote, puis j’ai migré vers OneNote après une dégradation soudaine du service. Depuis, je me méfie des applications de prise de notes de petites entreprises. La politique d’Obsidian pourrait elle aussi changer du jour au lendemain.
C’est ce que je voulais dire en voyant ça.
Les fonctionnalités temps réel ont pu être maintenues pendant longtemps dans un projet séparé du noyau, et ceux qui en avaient besoin pouvaient les récupérer, les appliquer au noyau et les utiliser.
Je n’ai jamais développé côté Linux.
J’imagine donc que le wrapper Rust du pilote de périphérique a une structure qui ne peut pas être dissociée du noyau...
J’utilise moi aussi Rust, mais si du code Rust et du code C se retrouvent mélangés dans un projet open source, alors à moins d’avoir des règles extrêmement strictes sur jusqu’où l’on autorise le code Rust, cela me semble ingérable, ou du moins le coût de revue et de maintenance risque d’exploser ; je pense donc que le choix le plus judicieux est de faire un fork plutôt que d’ajouter ce code.
Je pense que cela veut dire que, parmi les différentes méthodes de marketing, le blog n’est pas forcément la meilleure option, mais les alternatives proposées sont d’aller faire sa promo avec une pancarte devant les bureaux des clients ou de lancer des polémiques sur X, donc bof.
Je ne m’y connais pas très bien en kernel, mais je me dis que ce serait bien si on pouvait traduire automatiquement du code C en Rust. Bien sûr, il y aura sans doute aussi des problèmes humains, pas seulement des problèmes de traduction de code.
Je me souviens que lorsqu’un backport vers la version stable était nécessaire et que je le contactais, il répondait bien même au milieu de son emploi du temps chargé.
Je connais des entreprises qui ont investi sur le long terme dans le SEO pour augmenter leur trafic organique et en tirer des revenus stables, donc je comprends l’idée, mais j’ai du mal à y adhérer spontanément.
Je ne sais pas très bien si vous avez de l’expérience en développement du kernel, donc je ne sais pas trop quoi vous répondre, mais
d’abord, appliquer le langage Rust ne signifie pas remplacer le kernel par Rust. On peut se dire qu’il suffirait sinon de séparer cela et de créer un autre kernel, mais
l’idée n’est pas de créer le kernel en Rust ; il s’agit plutôt de créer uniquement en Rust un wrapper pour l’interface destinée aux pilotes de périphériques dans le kernel, afin que seuls les pilotes de périphériques puissent être développés en Rust.
C’est pourquoi partir sur un nouveau projet n’a pas de sens.
Il faut un peu renoncer au fantasme de l’ingénierie globale..
Cela exige une optimisation extrême des processus, mais le développement en 3x8 sur une base locale unique est courant dans le jeu vidéo.
Les grands studios chinois, par exemple, développent en continu 24h/24 avec trois équipes.
Des entreprises du jeu où l’ingénierie globale est installée depuis longtemps, comme EA ou Ubisoft, travaillent selon leurs fuseaux horaires respectifs, donc un ralentissement dans la vitesse d’exécution est inévitable, mais elles fonctionnent avec l’idée que le coût de la vie moins élevé + les coûts salariaux compensent cela. (Je ne sais pas quelle est la situation aujourd’hui avec les licenciements massifs.)
C’est assez ironique de voir que la communauté Linux, qui a longtemps justifié son ton toxique au nom de la stabilité du kernel, considère maintenant que répondre « si ça ne te plaît pas, fais un fork » est une réponse raisonnable.
Obsidian est vraiment une excellente application. C’est une app de prise de notes que l’on peut recommander à presque tout le monde.
J’utilisais Evernote, puis j’ai migré vers OneNote après une dégradation soudaine du service. Depuis, je me méfie des applications de prise de notes de petites entreprises. La politique d’Obsidian pourrait elle aussi changer du jour au lendemain.
Je ne comprends absolument pas l'argument disant qu'il devrait forker et partir. Pourquoi diable Linus devrait-il forker Linux et s'en aller ?
C’est ce que je voulais dire en voyant ça.
Les fonctionnalités temps réel ont pu être maintenues pendant longtemps dans un projet séparé du noyau, et ceux qui en avaient besoin pouvaient les récupérer, les appliquer au noyau et les utiliser.
Je ne fais pas partie de la communauté Linux, mais...
Je n’ai jamais développé côté Linux.
J’imagine donc que le wrapper Rust du pilote de périphérique a une structure qui ne peut pas être dissociée du noyau...
Je pense qu’il ne faut pas considérer ces personnes et l’auteur de ce commentaire comme appartenant à la même communauté.
J’utilise moi aussi Rust, mais si du code Rust et du code C se retrouvent mélangés dans un projet open source, alors à moins d’avoir des règles extrêmement strictes sur jusqu’où l’on autorise le code Rust, cela me semble ingérable, ou du moins le coût de revue et de maintenance risque d’exploser ; je pense donc que le choix le plus judicieux est de faire un fork plutôt que d’ajouter ce code.
Je pense que cela veut dire que, parmi les différentes méthodes de marketing, le blog n’est pas forcément la meilleure option, mais les alternatives proposées sont d’aller faire sa promo avec une pancarte devant les bureaux des clients ou de lancer des polémiques sur X, donc bof.
Je ne m’y connais pas très bien en kernel, mais je me dis que ce serait bien si on pouvait traduire automatiquement du code C en Rust. Bien sûr, il y aura sans doute aussi des problèmes humains, pas seulement des problèmes de traduction de code.
J’avais voulu utiliser Obsidian au travail à titre personnel, mais j’y avais renoncé à cause de la licence. Je vais peut-être m’y remettre.
Sympa...
Je pensais que c’était une traduction libre.
Ah, j’étais abonné avec une licence commerciale, donc c’est une bonne nouvelle.
Je me souviens que lorsqu’un backport vers la version stable était nécessaire et que je le contactais, il répondait bien même au milieu de son emploi du temps chargé.
Je connais des entreprises qui ont investi sur le long terme dans le SEO pour augmenter leur trafic organique et en tirer des revenus stables, donc je comprends l’idée, mais j’ai du mal à y adhérer spontanément.
Je ne sais pas très bien si vous avez de l’expérience en développement du kernel, donc je ne sais pas trop quoi vous répondre, mais
d’abord, appliquer le langage Rust ne signifie pas remplacer le kernel par Rust. On peut se dire qu’il suffirait sinon de séparer cela et de créer un autre kernel, mais
l’idée n’est pas de créer le kernel en Rust ; il s’agit plutôt de créer uniquement en Rust un wrapper pour l’interface destinée aux pilotes de périphériques dans le kernel, afin que seuls les pilotes de périphériques puissent être développés en Rust.
C’est pourquoi partir sur un nouveau projet n’a pas de sens.
Il y a énormément de vidéos GOTO, de loin..
Il faut un peu renoncer au fantasme de l’ingénierie globale..
Cela exige une optimisation extrême des processus, mais le développement en 3x8 sur une base locale unique est courant dans le jeu vidéo.
Les grands studios chinois, par exemple, développent en continu 24h/24 avec trois équipes.
Des entreprises du jeu où l’ingénierie globale est installée depuis longtemps, comme EA ou Ubisoft, travaillent selon leurs fuseaux horaires respectifs, donc un ralentissement dans la vitesse d’exécution est inévitable, mais elles fonctionnent avec l’idée que le coût de la vie moins élevé + les coûts salariaux compensent cela. (Je ne sais pas quelle est la situation aujourd’hui avec les licenciements massifs.)
C’est assez ironique de voir que la communauté Linux, qui a longtemps justifié son ton toxique au nom de la stabilité du kernel, considère maintenant que répondre « si ça ne te plaît pas, fais un fork » est une réponse raisonnable.