Affirmation péremptoire qui ne demande qu'à être explicité, même si le trolldi est passé…
Affirmation de quelqu'un qui a utilisé FreeBSD plusieurs années sur plusieurs laptops différents avec comme constats :
L'ACPI est toujours aussi mal supporté. Plusieurs fois le status de la batterie ne se faisait plus mettre à jour, aucun moyen de savoir à combien de % je suis sur la batterie.
Bis, la mise en veille marche une fois sur cinq.
Après une mise à jour, impossible de refaire fonctionner mon touchpad correctement.
Autonomie de la batterie largement en deça de Linux.
Si vous avez besoin de faire quelques trucs autres que la bureautique basique, vous êtes vite coincé. Exemple : le développement Android est très compliqué sous FreeBSD.
Le support du bluetooth est dérisoire.
Wayland ? pas encore.
Carte graphique dernière génération ? Bonne chance, ou utilise -CURRENT.
Note, pour avoir une fois testé OpenBSD, j'ai été surpris car tout l'ACPI fonctionnait correctement. De la mise en veille à l'hibernation. OpenBSD a eu la bonne idée de développeur leur propre pile ACPI, j'espère qu'un jour la fondation FreeBSD sponsorisera la même idée :)
git is great because linus did it, mercurial is better because he didn't
Moi sur un serveur dédié depuis plus de 10 ans. J'ai par ailleurs contribué plusieurs ports. En serveur c'est vraiment top (ZFS, jails, système ultra flexible, beauté, simplicité, etc.)
Par contre je déconseille largement en desktop (encore moins en laptop).
git is great because linus did it, mercurial is better because he didn't
C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)
Désolé mais je ne vois pas le rapport et je pense que tu n'as pas compris. Dans des projets node.js on utilise npm qui va installer les dépendances externes directement dans le dépôt de l'application alors que la tradition dans les applications C et C++ c'est d'utiliser celles installées par le gestionnaire de paquet de la distribution (donc de les garder externes).
J'ai pourtant bien précisé « qu'on intègre plus rarement une bibliothèque externe directement dans son code ».
git is great because linus did it, mercurial is better because he didn't
Aucun n'est véritablement portable, ça n'est pas très amusant d'utiliser docker sous windows et MacOS par exemple. Sur BSD je ne sais même pas comment s'est distribué.
Oui je sais bien, mais tu installes un sur ton serveur qui te plait et tu reste avec :-)
Ah oui, mais le mainteneur a une Debian stable, alors que moi je suis sur Fedora donc on utilise pas les même versions de bibliothèques… Ton logiciel doit passer les versions de bibliothèques en même temps que tu fais tes mises à jours d'OS ?
Dans mon cas, les bibliothèques que j'utilise ne sont pas du genre à casser la compatibilité d'une version mineure à l'autre (c'est d'ailleurs un critère de choix). J'utilise Boost principalement, Qt 5 ou parfois SDL 2. Et SDL 2 je sais que ça va rester pendant encore un moment (combien il y a d'années entre SDL 1 et SDL 2 ? tellement que les distributions fournissent les deux côte à côte) donc pour le moment je ne peux pas dire que j'ai eu des problèmes de compatibilité de version. Mon seul gros problème c'est la version des compilateurs sur les distributions car j'utilise déjà beaucoup de fonctionnalités du C++17 et je sais que ça va être compliqué pour les utilisateurs de debian, mais bon si je dois commencer à me restreindre pour des distributions je ne pourrai jamais coder en C++17. Il faut dire que la philosophie des développeur C ou C++ est largement différente de npm (pour ne citer que celui ci) justement parce que la retro compatibilité est bien plus forte et qu'on intègre plus rarement une bibliothèque externe directement dans son code alors que dans npm on peut se le permettre bien plus.
git is great because linus did it, mercurial is better because he didn't
Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes
C'est sûr que la libc change vraiment souvent… Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.
Comment tu fais pour expliquer à tes contributeurs la liste de tes dépendances qu'ils utilise nix, debian, redhat ou gentoo ?
Je leur dis « Boost, CMake, Qt5, libzip » enfin bref, le nom upstream de mon composant, à eux de trouver le nom dans leur gestionnaire de paquet (qui est souvent assez identique).
Comment tu t'assure que tes dépendances ont bien les bonnes options de compilation ?
La plupart des distributions compilent avec les valeur par défaut d'upstream, j'ai jamais eu de souci à ce niveau là. Puis les bibliothèque externes que j'ai utilisées jusque là n'ont pas d'options par défaut que les distibutions changent par ci par là.
git is great because linus did it, mercurial is better because he didn't
Par pitié non, je désespère quand je dois utiliser quelque chose en node.js qui rapatrie le monde entier à chaque installation. S'il y a bien une chose qui me déplaît dans ces façons de faire c'est qu'après avoir téléchargé ton dépôt, tu dois encore télécharger des dizaines d'autre dépôt pour pouvoir construire ton application. Avec C et C++ on a la chance de les avoir déjà dans le système ce qui permet entre autre de ne pas gaspiller du temps de compilation inutile et de la place.
git is great because linus did it, mercurial is better because he didn't
CMake, encore et toujours. Ça fait environ 10 ans que je l'utilise (déjà !). Il a ses défauts mais il fait tellement de chose et bien en plus il est supporté par un bon nombre d'IDE le rendant bien intégré. Pour ma part je l'utilise avec vim (vim-cmake) et Qt Creator.
git is great because linus did it, mercurial is better because he didn't
D'autant que comme le souligne un autre commentaire, Debian laisse laisse la possibilité de changer de system d'init.
Ceux qui sont assez compétent pour savoir faire la différence entre SysV et systemd, ont la compétence pour changer de system d'init rapidement.
Perso je n'ai pas les compétences pour déterminer ce qui est le mieux entre sysv et systemd et je fais confiance aux distrib pour faire le bon choix. systemd a probablement des défauts mais la plupart des distribs populaires l'ont adopté par défaut.
systemd n'a pas spécialement de défauts (il y a bien deux trois choses discutables mais bon), il a surtout changé la façon de faire en bien nombre de points:
les commandes (systemctl, journalctl, machinectl, coredumpctl)
gestions des services,
écritures des services,
système de journaux,
…
Et comme certains dinosaures n'ont pas envie de migrer, ils crient au scandale. Sauf que systemd apporte des bienfaits considérables comme faire dépendre un service sur des points de montage ou des sockets et ça, ça n'a pas de prix.
git is great because linus did it, mercurial is better because he didn't
Tu veux dire pour que tout le monde se mette à utiliser tous les patchs que Facebook a fait à mercurial, qu’ils utilisent en interne?
Je ne suis pas sûr de comprendre ce que tu essaies de dire, est-ce mal ? Facebook a fait (et continue) de nous faire beaucoup de contributions et nous apprécions. Ils ont écrit des extensions intéressantes (journal, amend, absorb).
Si c'est vraiment ce que je comprends de ton message, nous devrions nous méfier du noyau Linux aussi qui a eu de nombreuses contributions d'entreprises.
git is great because linus did it, mercurial is better because he didn't
Electron embarque le moteur de chromium. Donc chaque application démarre autant de ressources que chromium. Le pire c'est que maintenant on s'attaque à des applications encore plus banales.
git is great because linus did it, mercurial is better because he didn't
Je le savais que ça allait arriver. J'héberge mes dépôts Mercurial depuis 10 ans et on m'a demandé des dizaines de fois « toujours réfractaire à Git et Github ? », maintenant toutes ces personnes ont leur réponses.
git is great because linus did it, mercurial is better because he didn't
Personne a dit que Gtk est mort. Le seul « problème » c'est que Gtk ça favorise surtout Linux, alors le rendu des applications sous autre chose que Linux est particulièrement moche (testez gimp, geany sur windows).
Alors oui GNOME c'est GNOME, mais certaines applications pourraient être indépendantes et utilisées sur autre chose que Linux. Mise à part ça, Qt c'est puissant, propre, simple et il y a QML. Par exemple Plasma permet de faire des widgets en QML, et QML c'est juste la classe.
git is great because linus did it, mercurial is better because he didn't
On parle souvent des fonctionnalités supprimées… mais jamais celles ajoutées. Depuis GNOME 3.28 on peut enfin mettre des fichiers « favoris » dans Nautilus. Ce n'est pas rien !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Qui utilise ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche FreeBSD 11.2. Évalué à 1.
Pour les 4 derniers points cité dans mon précédent message.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Qui utilise ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche FreeBSD 11.2. Évalué à 5. Dernière modification le 03 juillet 2018 à 11:26.
Affirmation de quelqu'un qui a utilisé FreeBSD plusieurs années sur plusieurs laptops différents avec comme constats :
Note, pour avoir une fois testé OpenBSD, j'ai été surpris car tout l'ACPI fonctionnait correctement. De la mise en veille à l'hibernation. OpenBSD a eu la bonne idée de développeur leur propre pile ACPI, j'espère qu'un jour la fondation FreeBSD sponsorisera la même idée :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Qui utilise ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche FreeBSD 11.2. Évalué à 1.
La PS Vita aussi :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Les ports
Posté par David Demelier (site web personnel) . En réponse à la dépêche FreeBSD 11.2. Évalué à 2.
Les flavors, c'est de lui. Il est juste un peu membre de l'équipe portmgr soit dit en passant ;)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Qui utilise ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche FreeBSD 11.2. Évalué à 1.
Moi sur un serveur dédié depuis plus de 10 ans. J'ai par ailleurs contribué plusieurs ports. En serveur c'est vraiment top (ZFS, jails, système ultra flexible, beauté, simplicité, etc.)
Par contre je déconseille largement en desktop (encore moins en laptop).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quel courage :
Posté par David Demelier (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 1.
GitHub n'est pas pauvre. N'oubliez pas qu'il y a aussi des entreprises et particuliers qui payent pour des dépôts privés.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2. Dernière modification le 18 juin 2018 à 13:45.
Désolé mais je ne vois pas le rapport et je pense que tu n'as pas compris. Dans des projets node.js on utilise npm qui va installer les dépendances externes directement dans le dépôt de l'application alors que la tradition dans les applications C et C++ c'est d'utiliser celles installées par le gestionnaire de paquet de la distribution (donc de les garder externes).
J'ai pourtant bien précisé « qu'on intègre plus rarement une bibliothèque externe directement dans son code ».
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3.
Oui je sais bien, mais tu installes un sur ton serveur qui te plait et tu reste avec :-)
Dans mon cas, les bibliothèques que j'utilise ne sont pas du genre à casser la compatibilité d'une version mineure à l'autre (c'est d'ailleurs un critère de choix). J'utilise Boost principalement, Qt 5 ou parfois SDL 2. Et SDL 2 je sais que ça va rester pendant encore un moment (combien il y a d'années entre SDL 1 et SDL 2 ? tellement que les distributions fournissent les deux côte à côte) donc pour le moment je ne peux pas dire que j'ai eu des problèmes de compatibilité de version. Mon seul gros problème c'est la version des compilateurs sur les distributions car j'utilise déjà beaucoup de fonctionnalités du C++17 et je sais que ça va être compliqué pour les utilisateurs de debian, mais bon si je dois commencer à me restreindre pour des distributions je ne pourrai jamais coder en C++17. Il faut dire que la philosophie des développeur C ou C++ est largement différente de npm (pour ne citer que celui ci) justement parce que la retro compatibilité est bien plus forte et qu'on intègre plus rarement une bibliothèque externe directement dans son code alors que dans npm on peut se le permettre bien plus.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5.
C'est sûr que la libc change vraiment souvent… Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.
Je leur dis « Boost, CMake, Qt5, libzip » enfin bref, le nom upstream de mon composant, à eux de trouver le nom dans leur gestionnaire de paquet (qui est souvent assez identique).
La plupart des distributions compilent avec les valeur par défaut d'upstream, j'ai jamais eu de souci à ce niveau là. Puis les bibliothèque externes que j'ai utilisées jusque là n'ont pas d'options par défaut que les distibutions changent par ci par là.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: build sous android
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3. Dernière modification le 15 juin 2018 à 16:13.
Et CMake en natif (sans passer par celui du ndk) supporte la cross-compilation pour Android en seulement quelques variables:
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Une défense des autotools
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3.
Sauf que autotools est beaucoup trop Linux only. Oublie les projets autotools sur Windows.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Par pitié non, je désespère quand je dois utiliser quelque chose en node.js qui rapatrie le monde entier à chaque installation. S'il y a bien une chose qui me déplaît dans ces façons de faire c'est qu'après avoir téléchargé ton dépôt, tu dois encore télécharger des dizaines d'autre dépôt pour pouvoir construire ton application. Avec C et C++ on a la chance de les avoir déjà dans le système ce qui permet entre autre de ne pas gaspiller du temps de compilation inutile et de la place.
git is great because linus did it, mercurial is better because he didn't
# CMake
Posté par David Demelier (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 1.
CMake, encore et toujours. Ça fait environ 10 ans que je l'utilise (déjà !). Il a ses défauts mais il fait tellement de chose et bien en plus il est supporté par un bon nombre d'IDE le rendant bien intégré. Pour ma part je l'utilise avec vim (vim-cmake) et Qt Creator.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mais il y a bien mieux !
Posté par David Demelier (site web personnel) . En réponse au journal Sortie de Devuan ASCII 2.0. Évalué à 5.
Slackware, le site avec 0 CSS !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Parti pour du trollage?
Posté par David Demelier (site web personnel) . En réponse au journal Sortie de Devuan ASCII 2.0. Évalué à 7. Dernière modification le 11 juin 2018 à 15:58.
systemd n'a pas spécialement de défauts (il y a bien deux trois choses discutables mais bon), il a surtout changé la façon de faire en bien nombre de points:
Et comme certains dinosaures n'ont pas envie de migrer, ils crient au scandale. Sauf que systemd apporte des bienfaits considérables comme faire dépendre un service sur des points de montage ou des sockets et ça, ça n'a pas de prix.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: intégration de Hg
Posté par David Demelier (site web personnel) . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 2.
Oui c'est aussi la première chose que j'ai regardée, dommage.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mercurial
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 3.
Je ne suis pas sûr de comprendre ce que tu essaies de dire, est-ce mal ? Facebook a fait (et continue) de nous faire beaucoup de contributions et nous apprécions. Ils ont écrit des extensions intéressantes (journal, amend, absorb).
Si c'est vraiment ce que je comprends de ton message, nous devrions nous méfier du noyau Linux aussi qui a eu de nombreuses contributions d'entreprises.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mercurial
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à -2.
Il restera toujours bitbucket, mais je plussoie ton idée ;)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je le savais
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 0.
Je parle simplement de l'autohébergement.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et avec Github...
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 10.
Electron embarque le moteur de chromium. Donc chaque application démarre autant de ressources que chromium. Le pire c'est que maintenant on s'attaque à des applications encore plus banales.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je le savais
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 2. Dernière modification le 04 juin 2018 à 14:12.
Je ne compare pas Git / GitHub / Mercurial, je parle simplement du fait de ne pas héberger un projet chez un tiers.
git is great because linus did it, mercurial is better because he didn't
# Je le savais
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à -6. Dernière modification le 04 juin 2018 à 13:03.
Je le savais que ça allait arriver. J'héberge mes dépôts Mercurial depuis 10 ans et on m'a demandé des dizaines de fois « toujours réfractaire à Git et Github ? », maintenant toutes ces personnes ont leur réponses.
git is great because linus did it, mercurial is better because he didn't
# WM ?
Posté par David Demelier (site web personnel) . En réponse au lien Lobotomizing GNOME. Évalué à 1.
Pour les gens qui font presque uniquement du terminal + firefox, pourquoi ne pas choisir un WM simple ? Avec ou sans tiling. il y en a des sympas.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dialogue imaginaire
Posté par David Demelier (site web personnel) . En réponse au journal Un million de dollars sur deux ans promis à la Fondation GNOME. Évalué à 9.
Personne a dit que Gtk est mort. Le seul « problème » c'est que Gtk ça favorise surtout Linux, alors le rendu des applications sous autre chose que Linux est particulièrement moche (testez gimp, geany sur windows).
Alors oui GNOME c'est GNOME, mais certaines applications pourraient être indépendantes et utilisées sur autre chose que Linux. Mise à part ça, Qt c'est puissant, propre, simple et il y a QML. Par exemple Plasma permet de faire des widgets en QML, et QML c'est juste la classe.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: super
Posté par David Demelier (site web personnel) . En réponse au journal Un million de dollars sur deux ans promis à la Fondation GNOME. Évalué à 1.
On parle souvent des fonctionnalités supprimées… mais jamais celles ajoutées. Depuis GNOME 3.28 on peut enfin mettre des fichiers « favoris » dans Nautilus. Ce n'est pas rien !
git is great because linus did it, mercurial is better because he didn't