ff9097 a écrit 637 commentaires

Et donc quel est le problème ? Beaucoup de distribution ne propose pas les dernières versions qui pourtant corrigent des bugs. Tant que la sécurité n'est pas compromise

Pour moi les problémes de sécurité sont uniquement avec des bibliothèques écritent en langage non safe (C/C++). Ce n'est pas le cas ?
Donc si j'ai plusieurs fois une même bibliothèque python installée sur mon système en différentes versions, on peut être attristé de l'espace disque perdu. Mais a part ça….

S'il n'y a pas de problème de sécurité je ne vois pas le soucis.

L'argument principal (unique) c'est que en cas de faille, chaque logiciel doit pousser une nouvelle version avec la lib patché. Mais c'est encore une fois un problème qu'avec C/C++ non ?

(ré-écrire Blender ou Gimp en Rust c'est une perte de temps ;

Il faudra y passer si on souhaite toujours attirer des contributeurs le jour où Rust aura pris une grosse place.
Je me vois bien contribuer un jour a un projet Rust mais le C hors de question.

Si tu fais du python, c'est que les performances n'est pas ta priorité. Ça ne veut pas dire qu'il ne faut pas la prendre en compte lorsqu'on a plusieurs choix mais il vaut mieux choisir ce qui est le plus clair.

Pourquoi ne pas juste rebuild l'image a chaque fois ? Avec le cache c'est rapide et ça évite les soucis de droits root lorsqu'on partage un volume

Je vois oui, merci pour l'explication

Go et Rust ne boxe pas dans la même catégorie. Go est un langage simple, un peu comme java. La généricité vient juste d être introduit.

Et donc c'est un problème ? Ça me parait plutôt un avantage.

Rust propose des securités du niveau d ocaml, et meme plus avec le borow checker qui permet de faire de la programation parralel beaucoup plus safe. Mais il est plus complexe.

Je sais que si les performances sont primordiales, Rust est au dessus. Mais c'est assez quand même assez rarement le cas.

Faudrait expliquer pourquoi ces deux langages n'ont rien en commun. Et pourquoi Go serait inutile (c'est un troll mais bon).

J'ai pris l'exemple de Go car ça compile en code machine directement, c'est performant, la concurrence est très simple et le langage en lui-même est simple a apprendre et à comprendre. Mais ça pourrait être un autre choix.

Golang ne serait-il pas plus adapté ? C'est également memory-safe, bien plus simple d'accès et très bien adapté à tout ce qui touche au réseau

Je ne suis pas certain que Konqueror incite Firefox a innover.
Pareil pour Calligra.
Le problème c'est que c'est difficile dans les domaines des navigateurs web & suites bureautiques de proposer des alternatives pertinentes. Le MVP est assez haut.
Est-ce leur rôle de proposer des alternatives à tout ce qui existe ?

On parle avec quelques applis lancées et toi tu nous sors la consommation nu ?

Une "killing feature" pour LibreOffice pourrait par exemple être des styles et une présentation générale plus belle que la compétition, avec une disponibilité (en ligne par exemple) plus grande (pas de barrière technique), une bonne intégration etc.

je n'appelle pas ça une killing feature justement, il faut "juste" pouvoir faire des trucs beaux facilement sans avoir besoin de feature de mise en page ou de customisation avancé

Franchement, dans un usage basique, c’est à dire l’usage le plus normal. Libre- et Micorsoft- Office font le taf mais je ne vois pas de killing feature à attribuer à Libre Office.

Les gens ne savent même pas utiliser les styles et tu pensent qu'ils attendent la killing feature pour switcher ? Sérieusement…

Je pense toujours qu'il maintiennent trop de choses et surtout trop de code. Beaucoup de monde ont toujours vanté la supposé supériorité des applis KDE sur les applis Gnome en terme de fonctionnalités.
Mais des fonctionnalités c'est bien, pouvoir les maintenir correctement c'est mieux. Beaucoup de critiques sur les fonctionnalités supprimées mais Gnome a su supprimer du code bugué non maintenu.
Le but de ces projets c'est fournir une base qui réponds à la plupart des besoins. Pour les power-user, il faut se tourner vers des projets spécialisés.

Au bout de 10 ans de forte activité pour LibreOffice et aucune de OpenOffice, le premier devrait commencer à être plus connu que le second

Ça a toujours fonctionné, il faut arrêter la mauvaise foi même si c'est ta spécialité

Mettre fin au "tout Web", au profit des applications natives.

Comme sur mobile quoi. Ça se plaint aussi sur mobile du tout applications

La solution a déjà été mentionné : flatpak

Disons que tu ne mets pas à jour pour mettre à jour. Ça fonctionne bien, il n'y a pas de problème particulier, tu retournes sur le projet pour ajouter une fonctionnalité et tu te dis qu'il vaut mieux mettre à jour tant que ça doit bien se passer plutôt que lorsque tu as plusieurs versions majeures de retard. Mais les 3 jours pour la mise à niveau c'est en plus du travail initialement prévu. Sur d'autres types de projets il n'y a rien à faire, juste upgrader les dépendances et tout roule.

Java n'a jamais, et ne remplacera jamais C/C++

Je n'ai pas creusé mais je pense que ça aurait mérité une version majeure (4.0) pour ce genre d'impact qui a peut-être été sous-estimé. Ça n'excuse pas les réactions

le problème de X11 est déjà réglé c'est Wayland

Wayland et Flatpak sont deux gros bonds en avant à ce sujet et c'est plutôt bien. Le problème de fond et qui pourra se résoudre à (très) long terme c'est l'abandon de langage non-sûr comme C/C++ pour les briques bas niveaux et remplacés par Rust. Ça arrive déjà et avec des mauvaises surprises