Je ne cherche pas à troller, juste à donner mon avis sur mon ressenti et à avoir des commentaires
Je n'utilise pas Debian, cependant j'ai déjà regardé quelques documentations pour faire des paquets debian. Je trouve ça extrêmement compliqué. En effet, il y a plusieurs fichiers dont la plupart ont une syntaxe différente :
rules : Makefile,
control : syntaxe personnalisée, simple cependant,
changelog : syntaxe différente.
Ensuite, vient le nombre de commandes : deb-* dh_*, dpkg, … est-ce vraiment possible de tout mémoriser ? Combien de temps cela prend-il ?
J'écris quelques packages pour fedora (via mon dépôt COPR), je trouve les .spec tellement simple, en quelques lignes on a un paquet 100% fonctionnel avec une seule et unique syntaxe et commande rpmbuild. Les paquets Arch sont aussi plutôt simple.
J'aimerais bien avoir l'avis d'un développeur debian pour qu'il me dise son propre ressenti sur les paquets Debian.
git is great because linus did it, mercurial is better because he didn't
Quand je suis sur GNOME c'est GNOME Terminal, autrement st. Ils supportent tous les deux truecolors, ce qui est indispensable pour moi codant majoritairement sous vim.
git is great because linus did it, mercurial is better because he didn't
Gentoo est largement plus utilisé dans l'optimisation en terme de découpage. C'est à dire quelqu'un qui ne souhaite ni wifi, ni nls, ni bluetooth, ni avahi, ni dbus aura un système ultra léger. Les performances en revanche sont largement moins perceptibles. De toute façon toutes les applications ne sont pas forcément développées en C, C++.
git is great because linus did it, mercurial is better because he didn't
C'est vrai qu'abrt est divisé en deux, le daemon et gnome-abrt. J'ai un peu mis les deux dans le même sac cependant. Il n'empêche qu'il était installé par défaut avec la Workstation edition.
git is great because linus did it, mercurial is better because he didn't
Je suis d'accord, je pense retourner sous un wm sous peu. C'est simple, j'ai fermé GNOME Boxes, il a commencé à prendre 100% du CPU. J'ai abrt qui s'est lancé suite à un crash de firefox, il a pris 100% du CPU. Mon pauvre petit thinkpad. Sans compter les indénombrables bugs par ci par là. La qualité de GNOME a malheureusement bien chuté par rapport à ses débuts.
Fedora utilise GNOME par défaut mais fournit beaucoup de spins si tu souhaites autres chose :)
git is great because linus did it, mercurial is better because he didn't
Oui mais au moins les processeurs ARM ne tournent pas minix en arrière plan avant ton OS, permettant à intel et la NSA l'accès complet à ton PC peu importe ton OS.
git is great because linus did it, mercurial is better because he didn't
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
[^] # Re: Asciidoc
Posté par David Demelier (site web personnel) . En réponse au journal Le markdown, sous Emacs, et plus largement sous Linux. Évalué à 1.
Je plussoie pandoc, je l'ai longtemps utilisé pour générer ma documentation markdown vers différents formats (man, html, pdf). Markdown ♥
git is great because linus did it, mercurial is better because he didn't
# Compliqué
Posté par David Demelier (site web personnel) . En réponse au journal Construire des paquets DEB pour Debian (deuxième partie). Évalué à 3.
Je ne cherche pas à troller, juste à donner mon avis sur mon ressenti et à avoir des commentaires
Je n'utilise pas Debian, cependant j'ai déjà regardé quelques documentations pour faire des paquets debian. Je trouve ça extrêmement compliqué. En effet, il y a plusieurs fichiers dont la plupart ont une syntaxe différente :
Ensuite, vient le nombre de commandes : deb-* dh_*, dpkg, … est-ce vraiment possible de tout mémoriser ? Combien de temps cela prend-il ?
J'écris quelques packages pour fedora (via mon dépôt COPR), je trouve les .spec tellement simple, en quelques lignes on a un paquet 100% fonctionnel avec une seule et unique syntaxe et commande
rpmbuild. Les paquets Arch sont aussi plutôt simple.J'aimerais bien avoir l'avis d'un développeur debian pour qu'il me dise son propre ressenti sur les paquets Debian.
git is great because linus did it, mercurial is better because he didn't
# Fruits
Posté par David Demelier (site web personnel) . En réponse au sondage Comment nommez-vous vos machines ?. Évalué à 1. Dernière modification le 23 avril 2018 à 08:55.
Je mets des noms de fruits pour mes machines non professionnelles sans accents et tirets.
git is great because linus did it, mercurial is better because he didn't
# GNOME Terminal et st
Posté par David Demelier (site web personnel) . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 1. Dernière modification le 09 avril 2018 à 08:42.
Quand je suis sur GNOME c'est GNOME Terminal, autrement st. Ils supportent tous les deux truecolors, ce qui est indispensable pour moi codant majoritairement sous vim.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Le retour de gentoo?
Posté par David Demelier (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 2.
Gentoo est largement plus utilisé dans l'optimisation en terme de découpage. C'est à dire quelqu'un qui ne souhaite ni wifi, ni nls, ni bluetooth, ni avahi, ni dbus aura un système ultra léger. Les performances en revanche sont largement moins perceptibles. De toute façon toutes les applications ne sont pas forcément développées en C, C++.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Finalement adoptée
Posté par David Demelier (site web personnel) . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 3.
Non, c'est un problème connu
Non, c'est un problème connu
C'est vrai qu'abrt est divisé en deux, le daemon et gnome-abrt. J'ai un peu mis les deux dans le même sac cependant. Il n'empêche qu'il était installé par défaut avec la Workstation edition.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Finalement adoptée
Posté par David Demelier (site web personnel) . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 5. Dernière modification le 04 avril 2018 à 08:24.
Je suis d'accord, je pense retourner sous un wm sous peu. C'est simple, j'ai fermé GNOME Boxes, il a commencé à prendre 100% du CPU. J'ai abrt qui s'est lancé suite à un crash de firefox, il a pris 100% du CPU. Mon pauvre petit thinkpad. Sans compter les indénombrables bugs par ci par là. La qualité de GNOME a malheureusement bien chuté par rapport à ses débuts.
Fedora utilise GNOME par défaut mais fournit beaucoup de spins si tu souhaites autres chose :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Effet de mode?
Posté par David Demelier (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 4.
Oui mais au moins les processeurs ARM ne tournent pas minix en arrière plan avant ton OS, permettant à intel et la NSA l'accès complet à ton PC peu importe ton OS.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Eelo
Posté par David Demelier (site web personnel) . En réponse au journal C'est quoi le telephone intelligent du libriste francais de nos jours?. Évalué à 4. Dernière modification le 03 avril 2018 à 09:22.
Sans vouloir être méchant, tous les projets initiés par Gaël ont coulé.
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