J'ai été confronté à ce problème quand j'ai développé irccd. Au début j'avais commencé à écrire la documentation sous forme de wiki, exactement comme löve. Seul problème c'est que lorsque tu souhaites rajouter/enlever des fonctionnalités, tu commences à avoir un bordel monstre. Par exemple ce module comporte des fonctions présentes plus tard et d'autres supprimées. Ça devient compliqué pour l'utilisateur…
Autre point, si tu suis le semantic versioning correctement, et souhaites maintenir deux versions de ton logiciel (par exemple 4.5, 5.1) tu vas devoir fournir les deux documentations le temps que les gens migrent de la 4 à la 5.
Le plus simple, est de livrer ta documentation avec ton application, ou d'en faire plusieurs pages sur ton site. En tout cas, je déconseille fortement les wikis.
Pour ta deuxième question, j'ai tendance à préférer la documentation dans le même dépôt. Ça facilite le travail et la maintenance.
git is great because linus did it, mercurial is better because he didn't
Merci systemd, écrire des fichiers de service n'a jamais été aussi simple. En plus je peux faire en sorte que mon service s'exécute que si mon disque dur est branché, monté et le timer lancé.
git is great because linus did it, mercurial is better because he didn't
Les DRM, c'est une plaie. Vraiment. J'achète la musique et les films (en général en CD/DVD) parce que je veux soutenir les artistes et aussi parce que je veux ma musique en flac. J'ai aussi une liseuse et j'ai voulu commencer à acheter des ebooks. Seulement, lorsque j'ai commencé à faire des recherches sur les ebooks protégés j'ai compris qu'il fallait absolument utiliser Adobe Digital Editions (un logiciel privateur non portable). Du coup je me dis qu'à force de forcer les gens à utiliser ce genre de solutions, je comprends pourquoi et comment il y a autant de téléchargement illégaux et ces DRM ne vont faire qu'empirer le téléchargement illégal.
Pour ma part, je n'achèterai jamais d'ebook protégés :) C'est bien dommage.
git is great because linus did it, mercurial is better because he didn't
Moi je ne le fais plus depuis un moment. C'est trop énervant et frustrant. Je le faisais au début quand j'ai commencé à utiliser Linux aux alentours de 2003. Mais convertir des personnes lambda n'a aucun intérêt. À la place, vous allez être pris d'appels incessant « comment je fais ci ou ça » ou « c'est de la merde ça marche pas ». Du coup, maintenant je ne le fais qu'aux personnes qui me le demandent directement :)
git is great because linus did it, mercurial is better because he didn't
Du coup je me demandais, est-ce que le PoE nécessite des switch spéciaux ? Par exemple, est-ce que je peux alimenter ma raspberry depuis le port ethernet de ma livebox orange ?
J'avoue ne pas connaître beaucoup le PoE :)
git is great because linus did it, mercurial is better because he didn't
Et BSD est, par tradition, plus attaché à la philosophie UNIX (et KISS) que Linux.
Ça dépend des points. Linux est beaucoup plus orienté « tout est fichier » que les BSD. Par exemple, sous FreeBSD regarder le niveau de la batterie, la luminosité ou quelque paramètres liés aux sont se passent avec sysctl.
En revanche, les outils de l'userland sont beaucoup plus simples.
git is great because linus did it, mercurial is better because he didn't
Arrêtez avec ce mythe. J'ai eu des kernel panic sur un HP ProBook parce que je débranchais mon câble d'alimentation. J'en ai eu parce que j'ai utilisé conky. J'en ai eu parce que j'ai utilisé mon touchpad.
Mon serveur a aussi crashé il y a quelques semaines, sans raison.
Mon dernier kernel panic sous Linux remonte aux alentour de 2003, quand j'avais encore une carte nvidia.
git is great because linus did it, mercurial is better because he didn't
Je suis aussi adepte de FreeBSD et n'utilise que ça en serveur, mais je peux pas dire qu'il n'y aucun défaut. En fait il y en a plein.
Les ports ne sont pas versionnés
Ça pose pas mal de problème quand tu veux mettre à jour ta machine. Par exemple, chez OpenBSD les ports sont faits pour aller avec une version précise de ton OS. Du coup chez FreeBSD on peut se retrouver avec des conditions de versions dans les ports les rendant beaucoup plus compliqués à tester. Mais ils ne souhaitent pas changer ça pourtant c'est clairement ce qu'il faudrait faire. Pire encore, à chaque mise à jour, vous ne pouvez pas être sur que tout va encore fonctionner. Exemple : j'utilise etherpad qui dépend de nodejs. J'avais une version 6 de node.js et en mettant à jour mes ports (dans une poudriere, je suis pas masochiste), je me suis retrouvé avec une version 7 et etherpad ne fonctionnait plus. Avec un système de version par OS, ça ne serait jamais arrivé. Alors oui de temps en temps on rajoute des ports comme www/node6, www/node7 etc. Mais ce n'est pas non plus la solution.
Le support matériel est anémique
Non franchement, oubliez votre thinkpad de 2016, c'est même pas la peine d'y penser.
Les ports ne sont pas testés
Beaucoup de committers ne testent pas leur ports avant de les mettre à jour. En fait, ils le mettent à jour, vérifient que ça compile et commit.
Sauf que je me suis déjà retrouvé dans ce genre de cas :
mumble ne permettait plus de communiquer, c'est vrai il se lançait mais il manquait des codecs (liés à celt IIRC), du coup pas d'audio. C'est tout de même cocasse pour une application de voip.
redmine, mon préféré. Son mainteneur ne teste absolument jamais le port avant de le commit. Résultat, j'ai arrêté de l'utiliser et je l'installe à la main moi même.
Pas mal d'incohérences
Bien que ce soit purement esthétique, il y a quand même pas mal d'incohérence chez FreeBSD. Exemples bêtes, en général on aime bien concevoir un service sous forme serviced, servicectl. Chez FreeBSD on a préféré le suffixe control, du coup on a du mélange
camcontrol
nvmecontrol
conscontrol
swapctl
hastctl
C'est pas grand chose, mais j'aime le souci du détail :)
C'est à peu près pareil avec les fichiers de conf, ils ont pas toujours la même syntaxe (blacklistd.conf, jail.conf, devfs.conf).
Le bluetooth
Oui j'utilise des technologies comme le bluetooth. En fait sur FreeBSD je pense qu'il devrait être complètement supprimé. Le mainteneur ne travaille plus dessus et le support est plus que dérisoire.
git is great because linus did it, mercurial is better because he didn't
C'est vrai, j'aurai pu redescendre à 95% alors. Le lecteur d'empreinte pour moi est assez accessoire. C'est pas comme si c'était un gros point négatif non plus.
Ce n'est qu'un problème d'où mon sauf. S'il y en avait eu d'autre (s2r, hibernation, luminosité, ou je ne sais quoi) je n'aurais pas utilisé la combinaison tout sauf
git is great because linus did it, mercurial is better because he didn't
Quand j’avais un portable sous Linux (un thinkpad en plus, donc bon support et bonne documentation), 100% des fonctionnalités n’ont jamais marché, malgré des dizaines d’heures à bidouiller. Que ce soit le multi écrans, la gestion de l’energie ou les « périphériques » spécifiques, il y a toujours eu des soucis.
J'ai deux thinkpads :
un x1 carbon de 2016
un t470s de 2017
Les deux fonctionnent à 100% sur Linux, il y a qu'un seul truc qui ne fonctionne pas c'est le lecteur d'empreinte. De ce que j'ai lu il y aurait un driver propriétaire apparemment mais du coup je ne l'utilise pas.
Après il y a beaucoup de choses qu'on peut juger :
le support matériel directement ? (ok pour moi)
la stabilité des environnement ? perso j'ai arrêté GNOME, j'ai jamais vu un desktop aussi bancal (calendar, evolution, web ou tout simplement goa ne font que planter/mal fonctionner)
la complexité de résoudre des problèmes spécifiques ? (comme un driver wifi proprio, nvidia, etc)
Pour ma part j'ai aussi un iMac au travail, c'est stable dans l'ensemble mais j'ai aussi eu le droit à quelques problèmes. Une fois mon dock a planté, j'ai du ouvrir un terminal et faire un killall Dock pour qu'il se décide de se relancer.
À mon avis chaque système se vaut aujourd'hui, je dirai juste que résoudre des problèmes est plus ou moins facile sur un que sur l'autre.
git is great because linus did it, mercurial is better because he didn't
Je ne sais pas vous, mais moi ça me fait penser à :
En règle générale, c'est vrai que beaucoup d'utilisateurs Linux utilisent Linux juste parce qu'ils détestent Windows. Les autres libristes (plus souvent la communauté BSD) eux s'en fichent royalement de ce qu'il se passe chez les OS proprios. Différence de mentalité disons :)
git is great because linus did it, mercurial is better because he didn't
Mon SSD a laché sur mon x1 carbon 2016 après seulement 4 mois d'utilisation. Le BIOS ne le voyait plus, j'avais un erreur de détection SSD. Et après quelques reboot c'était un système inutilisable avec des milliers d'erreur d'inode.
Heureusement il m'a été remplacé sous garanti.
Cependant, un ami a aussi eu ces problèmes d'inodes sur un intel NUC, il avait aussi moins d'un an. Je suis pas tellement convaincu pour le moment.
git is great because linus did it, mercurial is better because he didn't
# Oui
Posté par David Demelier (site web personnel) . En réponse au journal Documentation pour un logiciel même version que le logiciel ?. Évalué à 4. Dernière modification le 26 mars 2018 à 10:02.
Oui, pour moi c'est très important.
J'ai été confronté à ce problème quand j'ai développé irccd. Au début j'avais commencé à écrire la documentation sous forme de wiki, exactement comme löve. Seul problème c'est que lorsque tu souhaites rajouter/enlever des fonctionnalités, tu commences à avoir un bordel monstre. Par exemple ce module comporte des fonctions présentes plus tard et d'autres supprimées. Ça devient compliqué pour l'utilisateur…
Autre point, si tu suis le semantic versioning correctement, et souhaites maintenir deux versions de ton logiciel (par exemple 4.5, 5.1) tu vas devoir fournir les deux documentations le temps que les gens migrent de la 4 à la 5.
Le plus simple, est de livrer ta documentation avec ton application, ou d'en faire plusieurs pages sur ton site. En tout cas, je déconseille fortement les wikis.
Pour ta deuxième question, j'ai tendance à préférer la documentation dans le même dépôt. Ça facilite le travail et la maintenance.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Merci Fedora
Posté par David Demelier (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 1. Dernière modification le 23 mars 2018 à 11:41.
Merci systemd, écrire des fichiers de service n'a jamais été aussi simple. En plus je peux faire en sorte que mon service s'exécute que si mon disque dur est branché, monté et le timer lancé.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Communication et remontée de bugs = 0 pointé
Posté par David Demelier (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre. Évalué à 1.
Perso les quelques bugs que j'ai rapporté ont été résolus très vite (un problème avec TortoiseHG et Qt Creator).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: bien mais ça devient lourd...
Posté par David Demelier (site web personnel) . En réponse à la dépêche GNOME 3.28. Évalué à 2.
Chez moi gnome-shell consomme toujours et encore ~230Mo de RAM.
git is great because linus did it, mercurial is better because he didn't
# Pareil pour les ebooks
Posté par David Demelier (site web personnel) . En réponse au journal Je ne demande qu’à payer !. Évalué à 5.
Hello,
Les DRM, c'est une plaie. Vraiment. J'achète la musique et les films (en général en CD/DVD) parce que je veux soutenir les artistes et aussi parce que je veux ma musique en flac. J'ai aussi une liseuse et j'ai voulu commencer à acheter des ebooks. Seulement, lorsque j'ai commencé à faire des recherches sur les ebooks protégés j'ai compris qu'il fallait absolument utiliser Adobe Digital Editions (un logiciel privateur non portable). Du coup je me dis qu'à force de forcer les gens à utiliser ce genre de solutions, je comprends pourquoi et comment il y a autant de téléchargement illégaux et ces DRM ne vont faire qu'empirer le téléchargement illégal.
Pour ma part, je n'achèterai jamais d'ebook protégés :) C'est bien dommage.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le pire
Posté par David Demelier (site web personnel) . En réponse au journal Copyleft is censorship. Évalué à 7.
Une des autres raison d'héberger le code soi même plutôt que d'utiliser des forge non libres :)
git is great because linus did it, mercurial is better because he didn't
# Sans macro
Posté par David Demelier (site web personnel) . En réponse au journal Obfusque ton code avec C++. Évalué à 3.
Bon, déjà l'ensemble est terrible, mais est-ce possible de passer cats en function template ?
git is great because linus did it, mercurial is better because he didn't
# Perte de temps
Posté par David Demelier (site web personnel) . En réponse au sondage La prochaine personne que je pense convertir au libre :. Évalué à 5.
Moi je ne le fais plus depuis un moment. C'est trop énervant et frustrant. Je le faisais au début quand j'ai commencé à utiliser Linux aux alentours de 2003. Mais convertir des personnes lambda n'a aucun intérêt. À la place, vous allez être pris d'appels incessant « comment je fais ci ou ça » ou « c'est de la merde ça marche pas ». Du coup, maintenant je ne le fais qu'aux personnes qui me le demandent directement :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'est pas rien
Posté par David Demelier (site web personnel) . En réponse au journal Sortie de raspberry pi 3B+. Évalué à 1.
Du coup je me demandais, est-ce que le PoE nécessite des switch spéciaux ? Par exemple, est-ce que je peux alimenter ma raspberry depuis le port ethernet de ma livebox orange ?
J'avoue ne pas connaître beaucoup le PoE :)
git is great because linus did it, mercurial is better because he didn't
# Mort
Posté par David Demelier (site web personnel) . En réponse au journal Fini Firefox, vive Midori !. Évalué à 4.
Midori c'est mort, instable et buggé. Il y a plein d'alternative cool à firefox. surf, qupzilla (falkon dans KDE), palemoon, …
git is great because linus did it, mercurial is better because he didn't
# NSA
Posté par David Demelier (site web personnel) . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à -6.
J'espère que Intel va couler, au plus vite. Vive RISC-V.
git is great because linus did it, mercurial is better because he didn't
# Ulteo
Posté par David Demelier (site web personnel) . En réponse à la dépêche Campagne de financement d’eelo pour un smartphone respectueux de la vie privée. Évalué à 3.
À mon avis, ça va faire comme ulteo.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 2.
Ça dépend des points. Linux est beaucoup plus orienté « tout est fichier » que les BSD. Par exemple, sous FreeBSD regarder le niveau de la batterie, la luminosité ou quelque paramètres liés aux sont se passent avec
sysctl.En revanche, les outils de l'userland sont beaucoup plus simples.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 1.
Tiens comme par hasard, crash de mon serveur aujourd'hui :))
git is great because linus did it, mercurial is better because he didn't
[^] # Re: BSD oui à la stabilité mais pas sans inconvénients
Posté par David Demelier (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 2. Dernière modification le 18 décembre 2017 à 15:28.
Arrêtez avec ce mythe. J'ai eu des kernel panic sur un HP ProBook parce que je débranchais mon câble d'alimentation. J'en ai eu parce que j'ai utilisé conky. J'en ai eu parce que j'ai utilisé mon touchpad.
Mon serveur a aussi crashé il y a quelques semaines, sans raison.
Mon dernier kernel panic sous Linux remonte aux alentour de 2003, quand j'avais encore une carte nvidia.
git is great because linus did it, mercurial is better because he didn't
# Oui et non
Posté par David Demelier (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 8.
Je suis aussi adepte de FreeBSD et n'utilise que ça en serveur, mais je peux pas dire qu'il n'y aucun défaut. En fait il y en a plein.
Les ports ne sont pas versionnés
Ça pose pas mal de problème quand tu veux mettre à jour ta machine. Par exemple, chez OpenBSD les ports sont faits pour aller avec une version précise de ton OS. Du coup chez FreeBSD on peut se retrouver avec des conditions de versions dans les ports les rendant beaucoup plus compliqués à tester. Mais ils ne souhaitent pas changer ça pourtant c'est clairement ce qu'il faudrait faire. Pire encore, à chaque mise à jour, vous ne pouvez pas être sur que tout va encore fonctionner. Exemple : j'utilise etherpad qui dépend de nodejs. J'avais une version 6 de node.js et en mettant à jour mes ports (dans une poudriere, je suis pas masochiste), je me suis retrouvé avec une version 7 et etherpad ne fonctionnait plus. Avec un système de version par OS, ça ne serait jamais arrivé. Alors oui de temps en temps on rajoute des ports comme www/node6, www/node7 etc. Mais ce n'est pas non plus la solution.
Le support matériel est anémique
Non franchement, oubliez votre thinkpad de 2016, c'est même pas la peine d'y penser.
Les ports ne sont pas testés
Beaucoup de committers ne testent pas leur ports avant de les mettre à jour. En fait, ils le mettent à jour, vérifient que ça compile et commit.
Sauf que je me suis déjà retrouvé dans ce genre de cas :
Pas mal d'incohérences
Bien que ce soit purement esthétique, il y a quand même pas mal d'incohérence chez FreeBSD. Exemples bêtes, en général on aime bien concevoir un service sous forme serviced, servicectl. Chez FreeBSD on a préféré le suffixe control, du coup on a du mélange
C'est pas grand chose, mais j'aime le souci du détail :)
C'est à peu près pareil avec les fichiers de conf, ils ont pas toujours la même syntaxe (blacklistd.conf, jail.conf, devfs.conf).
Le bluetooth
Oui j'utilise des technologies comme le bluetooth. En fait sur FreeBSD je pense qu'il devrait être complètement supprimé. Le mainteneur ne travaille plus dessus et le support est plus que dérisoire.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C’est toujours mieux qu’un open-bar.
Posté par David Demelier (site web personnel) . En réponse au journal Et ca continue encore et encore ... avec la pomme ... la grande rigolade. Évalué à 3. Dernière modification le 04 décembre 2017 à 09:57.
Je ne dirai pas que c'est normal. Lenovo a fait une erreur d'intégrer un chipset dont synaptics n'a pas envie de fournir les spécifications.
C'est vrai, j'aurai pu redescendre à 95% alors. Le lecteur d'empreinte pour moi est assez accessoire. C'est pas comme si c'était un gros point négatif non plus.
Ce n'est qu'un problème d'où mon sauf. S'il y en avait eu d'autre (s2r, hibernation, luminosité, ou je ne sais quoi) je n'aurais pas utilisé la combinaison tout sauf
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C’est toujours mieux qu’un open-bar.
Posté par David Demelier (site web personnel) . En réponse au journal Et ca continue encore et encore ... avec la pomme ... la grande rigolade. Évalué à 1.
Pour ma part c'est l'inverse. J'ai un écran hidpi et un écran externe et une télé juste fullhd. Et c'est assez pénible.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C’est toujours mieux qu’un open-bar.
Posté par David Demelier (site web personnel) . En réponse au journal Et ca continue encore et encore ... avec la pomme ... la grande rigolade. Évalué à 8. Dernière modification le 30 novembre 2017 à 16:43.
J'ai deux thinkpads :
Les deux fonctionnent à 100% sur Linux, il y a qu'un seul truc qui ne fonctionne pas c'est le lecteur d'empreinte. De ce que j'ai lu il y aurait un driver propriétaire apparemment mais du coup je ne l'utilise pas.
Après il y a beaucoup de choses qu'on peut juger :
Pour ma part j'ai aussi un iMac au travail, c'est stable dans l'ensemble mais j'ai aussi eu le droit à quelques problèmes. Une fois mon dock a planté, j'ai du ouvrir un terminal et faire un
killall Dockpour qu'il se décide de se relancer.À mon avis chaque système se vaut aujourd'hui, je dirai juste que résoudre des problèmes est plus ou moins facile sur un que sur l'autre.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C’est toujours mieux qu’un open-bar.
Posté par David Demelier (site web personnel) . En réponse au journal Et ca continue encore et encore ... avec la pomme ... la grande rigolade. Évalué à -4.
Je ne sais pas vous, mais moi ça me fait penser à :
En règle générale, c'est vrai que beaucoup d'utilisateurs Linux utilisent Linux juste parce qu'ils détestent Windows. Les autres libristes (plus souvent la communauté BSD) eux s'en fichent royalement de ce qu'il se passe chez les OS proprios. Différence de mentalité disons :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Merci pour l'info !
Posté par David Demelier (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
Utilisateur Mercurial depuis toujours, je ne me suis pas incliné à git :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: S'il te plaît Lennaert, remplace GRUB
Posté par David Demelier (site web personnel) . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 2.
Ça existe depuis un moment et ça s'appelle systemd-boot (voir bootctl).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ah le désespoir
Posté par David Demelier (site web personnel) . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 6.
systemd, pas SystemD. sinon on a pas fini avec HttpD, NgircD, DhcpcD,
git is great because linus did it, mercurial is better because he didn't
# SSD mort sur x1 carbon 2016
Posté par David Demelier (site web personnel) . En réponse au journal Endurance des SSD. Évalué à 2.
Mon SSD a laché sur mon x1 carbon 2016 après seulement 4 mois d'utilisation. Le BIOS ne le voyait plus, j'avais un erreur de détection SSD. Et après quelques reboot c'était un système inutilisable avec des milliers d'erreur d'inode.
Heureusement il m'a été remplacé sous garanti.
Cependant, un ami a aussi eu ces problèmes d'inodes sur un intel NUC, il avait aussi moins d'un an. Je suis pas tellement convaincu pour le moment.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: 1 an
Posté par David Demelier (site web personnel) . En réponse au journal Devuan Jessie 1.0. Évalué à -3.
Mate ça fonctionne mais on ne peut pas dire que c'est ultra populaire.
git is great because linus did it, mercurial is better because he didn't