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.
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 ?
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.
Il y a quelques années, la migration Gtk vers Qt de subsurface avait fait beaucoup de bruit. Le mainteneur principal avait tenu une conférence à ce sujet où il avait notamment constaté que GTK était développé dans les faits uniquement pour Gnome. Ça a peut être changé depuis mais ce que je lis au dessus ne m'étonne donc pas.
C'est un framework mobile à l'origine, ce qui peut expliquer certaines limitations bizarres. Le web avec flutter est toujours en beta. On peut imaginer que ça changera
Après il faut accepter la charge de travail pour la maintenance, backup, … Tu peux avoir des techniques pro open source mais encore il faudra rapidement quelqu'un de dédié à cette gestion.
J'avais testé plusieurs fois dans le passé le client de synchronisation Nextcloud pour expérimenter un éventuel déploiement professionnel : c'était tout simplement une catastrophe. Un peu de déplacement et de renommage de fichiers et il était rapidement perdu… Pas mal d'erreurs de synchronisation, ou pas de synchronisation du tout… Peut être que ça a changé mais bon je me suis dit ça plusieurs fois et j'ai été déçu a chaque fois. Cette partie doit être très robuste
Donc en plus de ne pas rediriger vers les définitions de méthodes, j'imagine qu'il ne peut pas non plus faire l'inverse, afficher toute les utilisations dans le projet d'une méthodes, ou d'une variable.
Je suppose donc aussi qu'on n'a pas de complétion ou de vérification temps réel sur les méthodes existantes ou sur les paramètres passés. Et l'import automatique ?
Ce qui me semble quand même des fonctions de base que j'utilise beaucoup même sur des petits projets.
Je ne suis pas spécialement étonné j'ai longtemps essayé de faire de vim un IDE digne de ce nom et en fait le problème est toujours le même. Ça reste très basique. Je ne suis pas sûr que l'efficacité de la saisie de texte sur vim ou sa légèreté justifie son utilisation sur un projet avec plusieurs fichiers. D'autant plus de beaucoup d'éditeurs proposent un mode vim.
Bon par contre VSCode ce n'est pas tellement mieux. Sur le papier c'est beaucoup mieux. En pratique la complétion casse régulièrement, et le CPU n'en fait qu'à sa tête. J'ai testé avec plusieurs langages. Je ne comprends pas l'engouement.
En fait rien ne vaut les IDE Jetbrains. C'est les gros bouzins comme on les imagine : lourd en RAM, du temps pour tout indexer au démarrage… Mais on sait pourquoi : tout fonctionne out of the box et c'est très stable. Bon ils ne sont pas tous open source
RAM intégré c'est caca (c'est l'évolution logique, déjà fait ailleurs pour l'intégration et 99% des gens préfèrent l'intégration à l'évolution)
95% de ces 99% ne savent pas:
- Ce que c'est que la RAM
- Que c'est souvent le facteur limitant à la performance
- Qu'on peut en ajouter facilement et pour pas cher sans changer de machine
Donc dire qu'ils préfèrent l'intégration à la possibilité d'évolution en connaissance de cause je ne suis pas d'accord. Même si je suis d'accord qu'une majorité n'y touchera jamais. Pour une utilisation personnelle, c'est probablement suffisant pour pratiquement tout le monde.
J'ai dû ajouter de la mémoire dans ma machine pro, je suis passé de 16 à 32. Je n'ai pas une utilisation folle, je développe avec un émulateur Android, plus Android Studio et quelques onglets de navigateurs et tu y es vite.
Pour une machine professionnelle qu'on garde plusieurs années, ça aurait fait tâche de devoir tout racheter (et à réinstallation qui va avec).
[^] # Re: Le sondage est sans appel !
Posté par ff9097 . En réponse au lien Sondage : Linux majoritaire sur le desktop. Évalué à 4.
Linux 88% Windows 28% tout est dit !
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par ff9097 . En réponse au lien C’était mieux avant tous ces sites pleins de javascript. Évalué à 3.
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….
[^] # Re: Alors, je suis désolé mais...
Posté par ff9097 . En réponse à la dépêche PySimpleGUI : prenez plaisir à faire des interfaces graphiques en Python. Évalué à 7.
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.
[^] # Re: Dur…
Posté par ff9097 . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 2.
Manque de quel type de contributeurs ? LO m'a l'air très actif niveau développement.
[^] # Re: Dur…
Posté par ff9097 . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 3.
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é ?
[^] # Re: Dur…
Posté par ff9097 . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 2.
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.
[^] # Re: Dur…
Posté par ff9097 . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 1.
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 ?
[^] # Re: Qui écrit le patch ?
Posté par ff9097 . En réponse au journal CVE-2021-3156 Vulnérabilité majeure dans sudo. Évalué à -1.
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 ?
# Qui écrit le patch ?
Posté par ff9097 . En réponse au journal CVE-2021-3156 Vulnérabilité majeure dans sudo. Évalué à 3.
Est-ce que chaque patch est écrit dans l'urgence par les distributions ou on attend upstream ?
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par ff9097 . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 1.
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.
[^] # Re: Insulte
Posté par ff9097 . En réponse au lien « L’école d’informatique recrutera en mode "Hunger Games" » (l'école attrape-couillon). Évalué à 0.
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.
[^] # Re: Programmation
Posté par ff9097 . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 4.
Désolé pour toi…
[^] # Re: Bépo, mécanique, orthogonal
Posté par ff9097 . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 1.
Je ne vois pas de bépo sur ces sites.
# Bépo, mécanique, orthogonal
Posté par ff9097 . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 3.
Je crois que cette combinaison n'existe pas. Quelqu'un connait quelque chose qui s'en rapproche le plus ?
[^] # Re: Programmation
Posté par ff9097 . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à -1.
Et les choix de claviers quasi inexistant.
[^] # Re: Chouette dépêche
Posté par ff9097 . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 5.
Il y a quelques années, la migration Gtk vers Qt de subsurface avait fait beaucoup de bruit. Le mainteneur principal avait tenu une conférence à ce sujet où il avait notamment constaté que GTK était développé dans les faits uniquement pour Gnome. Ça a peut être changé depuis mais ce que je lis au dessus ne m'étonne donc pas.
[^] # Re: Flutter et le libre...
Posté par ff9097 . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 1.
C'est un framework mobile à l'origine, ce qui peut expliquer certaines limitations bizarres. Le web avec flutter est toujours en beta. On peut imaginer que ça changera
[^] # Re: Oui, mais ce n'est pas une raison pour modifier la réalité...
Posté par ff9097 . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 2.
Avec les flex et grid ça devient simple et logique mais avant ça, gérer le positionnement était une horreur
[^] # Re: dans mon labo …
Posté par ff9097 . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 2.
Après il faut accepter la charge de travail pour la maintenance, backup, … Tu peux avoir des techniques pro open source mais encore il faudra rapidement quelqu'un de dédié à cette gestion.
# Client nextcloud
Posté par ff9097 . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 5.
J'avais testé plusieurs fois dans le passé le client de synchronisation Nextcloud pour expérimenter un éventuel déploiement professionnel : c'était tout simplement une catastrophe. Un peu de déplacement et de renommage de fichiers et il était rapidement perdu… Pas mal d'erreurs de synchronisation, ou pas de synchronisation du tout… Peut être que ça a changé mais bon je me suis dit ça plusieurs fois et j'ai été déçu a chaque fois. Cette partie doit être très robuste
[^] # Re: Et ça donne quoi coté réactivité?
Posté par ff9097 . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à 4.
Donc en plus de ne pas rediriger vers les définitions de méthodes, j'imagine qu'il ne peut pas non plus faire l'inverse, afficher toute les utilisations dans le projet d'une méthodes, ou d'une variable.
Je suppose donc aussi qu'on n'a pas de complétion ou de vérification temps réel sur les méthodes existantes ou sur les paramètres passés. Et l'import automatique ?
Ce qui me semble quand même des fonctions de base que j'utilise beaucoup même sur des petits projets.
Je ne suis pas spécialement étonné j'ai longtemps essayé de faire de vim un IDE digne de ce nom et en fait le problème est toujours le même. Ça reste très basique. Je ne suis pas sûr que l'efficacité de la saisie de texte sur vim ou sa légèreté justifie son utilisation sur un projet avec plusieurs fichiers. D'autant plus de beaucoup d'éditeurs proposent un mode vim.
Bon par contre VSCode ce n'est pas tellement mieux. Sur le papier c'est beaucoup mieux. En pratique la complétion casse régulièrement, et le CPU n'en fait qu'à sa tête. J'ai testé avec plusieurs langages. Je ne comprends pas l'engouement.
En fait rien ne vaut les IDE Jetbrains. C'est les gros bouzins comme on les imagine : lourd en RAM, du temps pour tout indexer au démarrage… Mais on sait pourquoi : tout fonctionne out of the box et c'est très stable. Bon ils ne sont pas tous open source
[^] # Re: GNOME 40 ?
Posté par ff9097 . En réponse au lien GNOME 40 Mutter Moves Input Work To A Separate Thread - phoronix. Évalué à 4.
Nouveau schéma de version, décoléré de la version de GTK utilisé. Donc non pas de GTK 4 sur cette version
[^] # Re: Pertinence ?
Posté par ff9097 . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 3. Dernière modification le 29 novembre 2020 à 09:39.
95% de ces 99% ne savent pas:
- Ce que c'est que la RAM
- Que c'est souvent le facteur limitant à la performance
- Qu'on peut en ajouter facilement et pour pas cher sans changer de machine
Donc dire qu'ils préfèrent l'intégration à la possibilité d'évolution en connaissance de cause je ne suis pas d'accord. Même si je suis d'accord qu'une majorité n'y touchera jamais. Pour une utilisation personnelle, c'est probablement suffisant pour pratiquement tout le monde.
J'ai dû ajouter de la mémoire dans ma machine pro, je suis passé de 16 à 32. Je n'ai pas une utilisation folle, je développe avec un émulateur Android, plus Android Studio et quelques onglets de navigateurs et tu y es vite.
Pour une machine professionnelle qu'on garde plusieurs années, ça aurait fait tâche de devoir tout racheter (et à réinstallation qui va avec).
[^] # Re: Pertinence ?
Posté par ff9097 . En réponse au journal MacOS contre Debian sur un test de build de Firefox. Évalué à 1.
Explication ici https://www.macg.co/mac/2020/11/la-ram-des-apple-m1-est-si-rapide-que-loption-16-go-est-rarement-utile-118017
[^] # Re: certes mais...
Posté par ff9097 . En réponse au lien Scaleway sort une machine capable de compiler Firefox en moins d'1h. Évalué à 1.
Pourquoi chromium serait significativement plus long que Firefox a compiler ?