ff9097 a écrit 725 commentaires

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

Linux 88% Windows 28% tout est dit !

Quand on bosse pas à plein temps dedans c'est vrai que ça à tendance à bouger un peu trop. Quand je déploie une application web et que j'y reviens 6 mois après, tout à changé. Tu as désormais 4/5 versions de retard sur le framework sur lequel tu te base. Tout fonctionne encore mais bon tu te dis qu'il faudrait mieux upgrader aujourd'hui que d'attente encore. Et forcément il y a pas mal de choses à adapter pour éviter tout ces warnings de dépréciation dans tout les sens…. Et ça te prends au moins 3 jours….

Ça permet de séparer le contrôle de la vue. Si jamais la vue ne me va pas, je ne touche pas le code…

Jamais été convaincu par cet argument. On arrive très vite à devoir toucher au code si on change de widget. Et puis ton XML c'est tout autant du code que le python.

Le vrai souci, c’est plutôt le manque de contributeurs. De ce côté, l’obstination inutile d’Apache n’aide pas vraiment à clarifier la situation.

Manque de quel type de contributeurs ? LO m'a l'air très actif niveau développement.

En même temps ça m'a l'air un peu complexe. Comment ça se passe ? Admettons que je suis développeur indépendant et un bounty m'intéresse. Je suis payé à quel moment ? Dès que je m'engage simplement à y consacrer 1 semaine ? Ou il y a une obligation de résultat derrière et je ne suis payé que si le ticket associé est clôturé ?

L’est-il ? S’il l’était, qu’est-ce que ça changerait s’il l’était moins ? La base du code est énorme et chaque module, je crois, utilise un peu de tout dans cette base. Ce n’est que du partage de code.
Le vrai souci, c’est plutôt le manque de contributeurs. De ce côté, l’obstination inutile d’Apache n’aide pas vraiment à clarifier la situation.

Si tu peux facilement identifier a quel module appartient un bug, et si il est possible de le reproduire le problème, le corriger et tester sans recompiler la totalité alors ça simplifie pas mal la chose.

C'est là que l'idée des développeurs qui travailleraient bénévolement pendant leur temps libre est assez loin de la réalité pour des projets de cette taille.
Le problème n'est-il pas que LO est trop monolithique ?

Ce qui ne répond pas vraiment à ma question. Est-ce que c'est upstream qui patch ? (notamment les anciennes versions). Plus simplement, est-ce la version de sudo dans debian est toujours maintenu par upstream ?

Est-ce que chaque patch est écrit dans l'urgence par les distributions ou on attend upstream ?

Le client doit laisser un minimum de place pour manipuler la fenêtre, de mémoire sous Gnome ça ne m'a jamais posé problème. Quant au focus, c'est un style différent à appliquer. Tout ça est un peu léger pour justifier cette barre de titre.

Pour moi le concept de diplôme est dépassé (sauf en médecine) puisque je considère que de recruter sur ça l'est tout autant.
Ce qui compte c'est l'enseignement que l'étudiant a pu bénéficier et donc ce qu'il pourra en tirer dans le monde professionnel (et il n'y a pas que le code en effet).
Mettre sur ton CV que tu as passé X années à étudier le domaine Y à l'école Z est suffisant pour un recruteur. Le reste c'est l'entretien, le test de niveau, la période d'essai.

Mince, PHP et le shell sont (de loin) les deux langages que je pratique le plus…

Désolé pour toi…