J'ai un dossier current qui contient un sous-dossier pour chaque appareil et chaque groupement de fichiers à sauvegarder. Les fichiers y sont déposés, suivant les dossiers par des scripts avec rsync ou des applications mobiles ou à la main, bref tout moyen capable de déposer un fichier dans un dossier.
C'est sur ce dossier current que les snapshots de subvolume sont effectués, sachant que cette partition en RAID 1 ne sert qu'à ça.
Mon système est à peu près similaire, sauf que les sauvegardes distantes en question sont hors ligne. Ce sont des disques durs chiffrés qui sont ailleurs que chez moi, non branchés. Quand je veux mettre à jour les sauvegardes distantes, je ramène le disque, et je lance mon script qui fait:
- mountage du disque, luksOpen et tout le toutim
- effacement complet du contenu du disque
- copie des fichiers avec un rsync tout simple (c'est pour la reprise en cas de pépin)
- scrub de toute la partition ntfs
- si le scrub est ok, la sauvegarde est supposée bonne, luksClose et umount, puis je débranche.
- si je souhaitais valider une sauvegarde, suffit de brancher le disque et de faire un scrub
Mon système a deux failles:
- les snapshots ne sont pas en lecture seule. Faut faire hyper gaffe. Mais en relisant de la doc, je viens de découvrir que ça existe en btrfs et que je ne le savais pas, btrfs subvolume snapshot -r
- la sauvegarde distante ne marche que si ma sauvegarde courante est bonne. si j'avais un soucis avec la sauvegarde locale, ça foire tout.
Ça part aussi du principe que la clé de chiffrement est sur un autre média que tout ce que j'ai cité. Je l'ai en 3 copies, une sur le serveur local de sauvegarde, deux sur des clés usb chiffrées avec veracrypt.
Ouais, enfin pas fait pour le desktop, un humain normal avec des besoins normaux en termes de perf (pas un serveur, quoi) ne verra pas la différence. La compression est très appréciable sur un laptop avec peu de disque, quand on veut grater de l'espace disque. J'imagine que l'utilisateur lambda va pas être spécialement intéressé par les snapshots et les checksums, mais ça reste pratique.
Franchement, en deux ans d'utilisation régulière de btrfs sur desktop, même pour du dev et de la compilation, je n'ai pas ressenti de souci de perf notable empiriquement. Avec des benchmarks assassins, je dis pas, mais ma vraie vie voit pas le soucis.
Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales avec un coût ultra faible et des scripts hyper simples, sur mon NAS (PC de récup). Combiné avec les scrub hebdomadaires ça a un coût de stockage faible et une fiabilité raisonnable une fois combiné avec un RAID 1 (mirroring) et des sauvegardes offline mensuelles.
Mais ça n'est clairement pas le genre d'installation que je ferais en entreprise, par contre…
Quel est exactement le problème avec la compression sur btrfs ?
J'ai juste rencontré des soucis d'usage de CPU avec l'algo zlib, sur des machines faiblardes, mais pas de soucis en lzo au bout de 1 an et demi sur mon modeste serveur de backup en ligne.
Pour les remarques précédentes, le BTRFS n'a pas comme cible la haute performance, tout comme le ZFS. Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.
Au sujet de Red Hat, ça reste l'une des distro les plus conservatrices qui soient. Le fait que BTRFS ne soit pas juste une nouvelle version d'un système de fichier existant ne doit pas trop aider à son acceptation, d'autant plus que j'entends fréquemment des histoires de scénarios catastrophes à son sujet (jamais rencontrés personnellement sur mes mini prods). Et la compression ou les snapshots, ça reste des problèmes qu'on peut résoudre en balançant bêtement plus d'espace disque. Ça ne laisse donc pas beaucoup d'avantages sur les autres fs malgré cette liste de features.
J'ai l'impression que vous n'avez jamais tenté de soumettre un nouvel article ou une modification sur la Wikipedia. Je suis désolé, mais j'ai bien du mal à mettre en phase votre vision de Wikipedia et la mienne.
Wikipedia n'a clairement jamais été démocratique et ses modérateurs (humains et robots) ont toujours le dernier mot.
La Wikipedia, déjà, si vous n'avez pas un sujet de page qui plaise à un des modérateurs, le robot vous la supprimera automatiquement (testé et déprimé plusieurs fois). Les modérateurs ont un temps limité pour accepter les nouveaux articles ; passé ce délai ils sont automatiquement refusés et effacés. Oui, par défaut, votre savoir donné à la communauté sera par défaut supprimé. C'est donc le premier souci : la sélection oligarchique de l'article, selon les priorités des modérateurs. La Wikipedia n'est pas le savoir universel, c'est le savoir considéré important par les modérateurs. Le savoir universel a sa place ailleurs sur le web, grâce à sa décentralisation.
Le deuxième sujet est donc les citations. Si votre sujet a été considéré comme intéressant, vous avez déjà passé la première étape. Maintenant, il vous faut des sources qui sont référencées sur le web ou des ISBN, ou numéro de référence équivalent (qui ne sera de toute façon pas forcément vérifié). Votre source est une obscure publication ? A moins que vous ne la mettiez sur le web, sans nécessairement avoir le droit d'ailleurs, ce qui est cocasse, aucune garantie que votre article soit conservé. Le syndrome du citation needed et des articles qui risquent d'être effacés faute de source. Oui, vous avez remarqué que j'en revient encore à l'effacement. Sans source, votre article ne vaut rien, oui car la Wikipedia n'est pas une source de savoir original mais un agrégat, un résumé. On peut y voir làune qualité ou un défaut. Mais vu le nombre de wikis parallèles qui pullulent partout sur le web, on peut discerner que le savoir spécialisé, original et libre n'a sa place qu'ailleurs.
Imaginez maintenant que votre article est sur le web, et que vous avez des sources. Pensez-vous vraiment que vos sites de sources vont survivre disons 5 ans ? 10 ans ? 20 ans ? Vous voyez donc le problème final émerger : le savoir qu'on accumule sur la Wikipedia, s'il ne se base pas sur des livres trouvables est périssable. Votre article devra donc avoir des références maintenues à jour sous peine de suppression possible, ou de fiabilité contestable de l'information sur le long terme. On en revient à l'idée que ça n'est pas une source de savoir de référence et que ça ne le sera jamais.
Tout ça pour dire que Wikipedia est un excellent outil, mais en aucun cas un outil de référence. Avant d'y voir une source de liberté, de débat, il faudrait déjà voir Wikipedia pour ce que c'est : un outil qui a strictement les mêmes travers que les encyclopédies privées. Ça n'est pas un vrai lieu de débat, car ses fondements mêmes sont biaisés par sa modération. Wikipedia est donc la vision du monde par ses modérateurs.
Ne mettez pas dans Wikipedia des valeurs et des qualités qui n'y sont pas.
Tout n'est pas noir au sujet de la migration systemd. systemd-sysv-generator aide pas mal pour la migration des scripts /etc/init.d ; les scripts fonctionnent par défaut. Ce qui n'est pas le cas sous Arch, versions 2017. Et avec la commande "service" et les logs syslog activés par défaut à l'ancienne, la migration s'est vraiment faite sans accroc sous Debian.
Autant, je ne vois pas le bénéfice de ma petite lorgnette, autant, c'est clairement pas pire qu'avant.
Ce n'est pas le rôle de git de gérer les pull requests, tout comme montrer les commits sur un site web n'est pas non plus son travail.
Une pull request, c'est un message servant à prévenir qu'il faut valider un ensemble de commits pour l'intégrer à une branche de travail. Donc c'est plutôt un outil de messagerie qu'il faut utiliser. Les modifs attachées au message peuvent être hébergées sur un autre repo git, ou être fournies dans le message lui même. Ca n'a aucune importance, il n'y a même pas de dépendances à une techno particulière, que ce soit un VCS (système de contrôle de version) ou à une méthode d'envoi du message (forum, github, e-mail, message IRC, etc…). Pour des raisons de traçabilité et de simplicité, Linux utilise des emails pour gérer ça, mais ça n'a pas vraiment de couplage avec git.
Et si vous cherchez un truc sans dépendances pénibles, pas trop gourmand et ultra facile à installer sur n'importe quoi, vous avez aussi Gitbucket. C'est le point faible de tous les autres que j'ai eu l'occasion de tester, le côté overkill et complexité à administrer quand on a moins de 10 utilisateurs.
Ca n'est évidemment pas le même cas d'utilisation que Gitlab, outil excellent, avec plein de fonctionnalités intégrées (et débilement gourmand sur une petite install).
Posté par damaki .
En réponse au journal Opus 1.2.
Évalué à 1.
En plus de tous les arguments énoncés, les bitrates fixes ne sont plus trop utilisés quand on règle l'encodage. On utilise plutôt un niveau de qualité qui vise à peu près un bitrate (VBR), mais si l'encodeur juge qu'il a besoin de beaucoup de données pour stocker une frame audio, il en prendra un peu plus. Inversement, s'il juge qu'il peut économiser du bitrate, il le fera.
L'encodage à bitrate constant n'est plus utilisé que pour le streaming et même Apple utilise du VBR pour ses fichiers encodés en AAC.
En résumé, même un bitrate moyen ne suffit pas pour juger la qualité, avec un codec moderne. Ca permet juste d'avoir une vague idée de si c'est écoutable ou pas suivant une échelle de références, mais ça reste une indication et pas un fait. Et l'encodeur utilisé joue beaucoup aussi. Les MP3s encodés vers 2001 ou 2002 sont désormais à peine écoutable, par exemple.
Posté par damaki .
En réponse au journal Opus 1.2.
Évalué à 3.
Il faut différencier les différents types de test, qui n'ont pas la même valeur scientifique :
- AB, test en sachant quel est l'échantillon a et quel et le B. Aucune valeur scientifique, le royaume de l'idiophile, des enceintes chaudes et du vinyl chaleureux. Si vous testez casque dans le magasin, vous le faites.
- ABX. Test en aveugle, sans savoir si on écoute l'échantillon A ou B. Valide scientifiquement si on fait suffisamment d'essais en aveugle.
- ABC/HR, assez proche de l'ABX où en plus on note la qualité de l'échantillon. Souvent utilisé avec des samples de sons problématiques sur les encodeurs. C'est valide scientifiquement également, et la qualité du test dépend du nombre de tentatives.
Il existe donc de vraies méthodologies, pas spécifiques à l'audio qui permettent de connaître avec certitude la qualité d'un codec, pour peu qu'on ait assez de participants avec une bonne oreille. A noter que la qualité du matos utilisé pour faire le test ne joue pas plus que ça. Du mauvais matos peut permettre de mieux percevoir certains défauts et du meilleur matos peut aider à en percevoir d'autres.
Juste pour rappel, une substance bien plus addictive est dans notre consommation courante, donc une affection préliminaire (pré-diabète) affecte environ 30% de la population américaine, et à peu près autant de la population française, et représente un aussi au moins gros problème de santé publique. Oui, je parle du sucre. Essayez juste une semaine sans, et vous verrez, les envies de sucre n'ont rien à envier à l'alcool.
Maintenant, est-ce qu'on devrait conseiller au gens de boire des boissons sucrées plutôt que de l'alcool ? Ah cette morale, quand on parle de drogue, en ignorant que beaucoup de ce qu'on mange provoque des addictions. Et si on parlait aussi de la caféine, donc l'arrêt brutal provoque quand on en consomme beaucoup de violent maux de tête, pendant des semaines. Et tant d'autres substances. Est-il vraiment nécessaire de continuer ?
Maintenant qu'on est dans le domaine de la science et plus de la morale, peut-on commencer à réfléchir raisonnablement et à accepter notre culture et ses travers ?
Je ne connaissais pas Raptor Engineering, mais j'avoue être perplexe sur le papier de cette boîte. C'est juste un papier corporate qui glorifie cette entreprise, non ? Alors autant, je suis tout à faire convaincu de l'importance de coreboot et c'est bien qu'une entreprise mais était-ce bien nécessaire de récupérer cette publicité pour Raptor Engineering ? D'autant plus qu'aucune solution concrète, achetable réellement n'est évoquée dans cette dépêche.
Je ne trouve pas cette publi-information pertinente.
Et 35 requêtes sont bloquées sur le simple affichage de la page d'accueil. Je n'ai jamais vu un truc pareil.
Le site a probablement été infecté récemment et/ou alors affiche du malvertising.
J'utilise au taf un model M qui a à peu près cette tronche, mais en version azerty et tous les marquages en français :)
Trouvé dans la rue à Paris. Magique.
En précommande (expédition en mars 2017) depuis l'Europe, et testé par personne à par ses créateurs. Un peu difficile à recommander.
J'avoue que je l'ai quand même précommandé depuis un an avec des Cherry MX clear, l'accessoire trackball et le groupe de trois touches en plus :D
Je pense que le principal souci est que cette techno recrée le même problème qui a provoqué la naissance du pagerank de Google : les sites qui trichaient avec leurs keywords et leur contenu. Ça part du principe que les sites sont sincères. Et ça part aussi du principe, clairement obsolète, que les métadonnées fournies par le site sont suffisantes pour mesurer la pertinence et la qualité d'un site.
Le principe même de la SEO, quelle que soit l'époque, c'est soit de mentir (dans le pire des cas) soit de customiser le site pour plus ressortir que les autres. Et même regarder le contenu même des pages est à peine suffisant pour en déduire la qualité, d'où l'ancien système pagerank avec le compte du nombre de liens hypertextes existants vers la page. Et inversement dans un cas de non optimisation des métadonnées, un site excellent pourrait aussi être ignoré par l'index d'un tel moteur de recherche.
Alors non, la main-mise de Google n'est pas une bonne chose, mais cette techno n'est en aucun cas une solution.
C'est plutôt bien fichu comme nouvelle version du catalogue de logiciels libres, bravo ! La présentation est claire est concise. Le design est propre et moderne.
Un bémol pour la catégorie cloud, dont l'intitulé risque d'en perdre plus d'un qui ne sait pas ce qu'est l'auto-hébergement et comment on utilise ces trucs. L'intention est louable de donner de la visibilité à des outils libres, mais c'est complexe de viser plusieurs publics aussi différents que des administrateurs systèmes et des utilisateurs finaux. Faudrait à mon sens deux catalogues distincts et hébergés séparément. Ça trouverait plutôt sa place dans des sites liés au projet dégooglisons internet, non ?
Vu que je ne souhaite ni utiliser un LDAP, ni des utilisateurs Linux, je l'ai volontairement mis de côté. Monter un LDAP pour 5 utilisateurs, je trouve que c'est de l'overkill et je ne suis pas fan d'utiliser du PAM pour des logins applicatifs. Mais ça reste moins pire que d'autres, en fouinant j'ai vu un serveur git+web qui stockait les mots de passe en MD5, en 2016… Hélas j'ai oublié le nom de cette abomination.
Des gens auraient testé la community avec du hardware moins costaud que ce qui est préconisé ? Je me vois difficilement mobiliser 2 Go de RAM pour un serveur git avec quelques services en plus pour 5 utilisateurs. Ils ont l'air de vivement déconseiller avec 1 Go de ram (ce qui me paraît déjà énorme, soit dit en passant).
En attendant, j'utilise Gitbucket qui fait l'affaire, tourne pour quasi rien en ressources et bientôt un Kanboard dédié, en attendant de trouver des softs léger pour les autres features.
Sinon il y a aussi actdiag et mermaid.
En fait, j'avais passé du temps à chercher une flopée d'outils du genre et les voilà :
* PlantUML pour tout UML, comme dit dans d'autres réponses
* Ditaa pour transformer de l'ascii moche en joli diagramme
* shaape idem
* blockdiag diagrammes tout bêtes ou autres (c'est une suite de softs)
* mermaid pour des tas de schémas encore.
[^] # Re: Juste une histoire de ressources de développement
Posté par damaki . En réponse au journal Btrfs ne serait plus le futur. Évalué à 0. Dernière modification le 03 août 2017 à 19:59.
J'ai un dossier current qui contient un sous-dossier pour chaque appareil et chaque groupement de fichiers à sauvegarder. Les fichiers y sont déposés, suivant les dossiers par des scripts avec rsync ou des applications mobiles ou à la main, bref tout moyen capable de déposer un fichier dans un dossier.
C'est sur ce dossier current que les snapshots de subvolume sont effectués, sachant que cette partition en RAID 1 ne sert qu'à ça.
[^] # Re: Juste une histoire de ressources de développement
Posté par damaki . En réponse au journal Btrfs ne serait plus le futur. Évalué à 1.
Mon système est à peu près similaire, sauf que les sauvegardes distantes en question sont hors ligne. Ce sont des disques durs chiffrés qui sont ailleurs que chez moi, non branchés. Quand je veux mettre à jour les sauvegardes distantes, je ramène le disque, et je lance mon script qui fait:
- mountage du disque, luksOpen et tout le toutim
- effacement complet du contenu du disque
- copie des fichiers avec un rsync tout simple (c'est pour la reprise en cas de pépin)
- scrub de toute la partition ntfs
- si le scrub est ok, la sauvegarde est supposée bonne, luksClose et umount, puis je débranche.
- si je souhaitais valider une sauvegarde, suffit de brancher le disque et de faire un scrub
Mon système a deux failles:
- les snapshots ne sont pas en lecture seule. Faut faire hyper gaffe. Mais en relisant de la doc, je viens de découvrir que ça existe en btrfs et que je ne le savais pas, btrfs subvolume snapshot -r
- la sauvegarde distante ne marche que si ma sauvegarde courante est bonne. si j'avais un soucis avec la sauvegarde locale, ça foire tout.
Ça part aussi du principe que la clé de chiffrement est sur un autre média que tout ce que j'ai cité. Je l'ai en 3 copies, une sur le serveur local de sauvegarde, deux sur des clés usb chiffrées avec veracrypt.
[^] # Re: Manque de ressources
Posté par damaki . En réponse au journal Btrfs ne serait plus le futur. Évalué à 4. Dernière modification le 02 août 2017 à 18:35.
Ouais, enfin pas fait pour le desktop, un humain normal avec des besoins normaux en termes de perf (pas un serveur, quoi) ne verra pas la différence. La compression est très appréciable sur un laptop avec peu de disque, quand on veut grater de l'espace disque. J'imagine que l'utilisateur lambda va pas être spécialement intéressé par les snapshots et les checksums, mais ça reste pratique.
Franchement, en deux ans d'utilisation régulière de btrfs sur desktop, même pour du dev et de la compilation, je n'ai pas ressenti de souci de perf notable empiriquement. Avec des benchmarks assassins, je dis pas, mais ma vraie vie voit pas le soucis.
[^] # Re: Juste une histoire de ressources de développement
Posté par damaki . En réponse au journal Btrfs ne serait plus le futur. Évalué à 4.
Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales avec un coût ultra faible et des scripts hyper simples, sur mon NAS (PC de récup). Combiné avec les scrub hebdomadaires ça a un coût de stockage faible et une fiabilité raisonnable une fois combiné avec un RAID 1 (mirroring) et des sauvegardes offline mensuelles.
Mais ça n'est clairement pas le genre d'installation que je ferais en entreprise, par contre…
[^] # Re: Juste une histoire de ressources de développement
Posté par damaki . En réponse au journal Btrfs ne serait plus le futur. Évalué à 1.
Quel est exactement le problème avec la compression sur btrfs ?
J'ai juste rencontré des soucis d'usage de CPU avec l'algo zlib, sur des machines faiblardes, mais pas de soucis en lzo au bout de 1 an et demi sur mon modeste serveur de backup en ligne.
Pour les remarques précédentes, le BTRFS n'a pas comme cible la haute performance, tout comme le ZFS. Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.
Au sujet de Red Hat, ça reste l'une des distro les plus conservatrices qui soient. Le fait que BTRFS ne soit pas juste une nouvelle version d'un système de fichier existant ne doit pas trop aider à son acceptation, d'autant plus que j'entends fréquemment des histoires de scénarios catastrophes à son sujet (jamais rencontrés personnellement sur mes mini prods). Et la compression ou les snapshots, ça reste des problèmes qu'on peut résoudre en balançant bêtement plus d'espace disque. Ça ne laisse donc pas beaucoup d'avantages sur les autres fs malgré cette liste de features.
# Les problèmes : oligarchie et citations
Posté par damaki . En réponse au journal Le problème de Wikipedia c’est l’école. Évalué à 5. Dernière modification le 27 juillet 2017 à 21:21.
J'ai l'impression que vous n'avez jamais tenté de soumettre un nouvel article ou une modification sur la Wikipedia. Je suis désolé, mais j'ai bien du mal à mettre en phase votre vision de Wikipedia et la mienne.
Wikipedia n'a clairement jamais été démocratique et ses modérateurs (humains et robots) ont toujours le dernier mot.
La Wikipedia, déjà, si vous n'avez pas un sujet de page qui plaise à un des modérateurs, le robot vous la supprimera automatiquement (testé et déprimé plusieurs fois). Les modérateurs ont un temps limité pour accepter les nouveaux articles ; passé ce délai ils sont automatiquement refusés et effacés. Oui, par défaut, votre savoir donné à la communauté sera par défaut supprimé. C'est donc le premier souci : la sélection oligarchique de l'article, selon les priorités des modérateurs. La Wikipedia n'est pas le savoir universel, c'est le savoir considéré important par les modérateurs. Le savoir universel a sa place ailleurs sur le web, grâce à sa décentralisation.
Le deuxième sujet est donc les citations. Si votre sujet a été considéré comme intéressant, vous avez déjà passé la première étape. Maintenant, il vous faut des sources qui sont référencées sur le web ou des ISBN, ou numéro de référence équivalent (qui ne sera de toute façon pas forcément vérifié). Votre source est une obscure publication ? A moins que vous ne la mettiez sur le web, sans nécessairement avoir le droit d'ailleurs, ce qui est cocasse, aucune garantie que votre article soit conservé. Le syndrome du citation needed et des articles qui risquent d'être effacés faute de source. Oui, vous avez remarqué que j'en revient encore à l'effacement. Sans source, votre article ne vaut rien, oui car la Wikipedia n'est pas une source de savoir original mais un agrégat, un résumé. On peut y voir làune qualité ou un défaut. Mais vu le nombre de wikis parallèles qui pullulent partout sur le web, on peut discerner que le savoir spécialisé, original et libre n'a sa place qu'ailleurs.
Imaginez maintenant que votre article est sur le web, et que vous avez des sources. Pensez-vous vraiment que vos sites de sources vont survivre disons 5 ans ? 10 ans ? 20 ans ? Vous voyez donc le problème final émerger : le savoir qu'on accumule sur la Wikipedia, s'il ne se base pas sur des livres trouvables est périssable. Votre article devra donc avoir des références maintenues à jour sous peine de suppression possible, ou de fiabilité contestable de l'information sur le long terme. On en revient à l'idée que ça n'est pas une source de savoir de référence et que ça ne le sera jamais.
Tout ça pour dire que Wikipedia est un excellent outil, mais en aucun cas un outil de référence. Avant d'y voir une source de liberté, de débat, il faudrait déjà voir Wikipedia pour ce que c'est : un outil qui a strictement les mêmes travers que les encyclopédies privées. Ça n'est pas un vrai lieu de débat, car ses fondements mêmes sont biaisés par sa modération. Wikipedia est donc la vision du monde par ses modérateurs.
Ne mettez pas dans Wikipedia des valeurs et des qualités qui n'y sont pas.
# Scripts inits : ça marche toujours sous Debian
Posté par damaki . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 2.
Tout n'est pas noir au sujet de la migration systemd. systemd-sysv-generator aide pas mal pour la migration des scripts /etc/init.d ; les scripts fonctionnent par défaut. Ce qui n'est pas le cas sous Arch, versions 2017. Et avec la commande "service" et les logs syslog activés par défaut à l'ancienne, la migration s'est vraiment faite sans accroc sous Debian.
Autant, je ne vois pas le bénéfice de ma petite lorgnette, autant, c'est clairement pas pire qu'avant.
[^] # Re: Le problème de fond
Posté par damaki . En réponse au journal GNOME va passer à GitLab. Évalué à 7.
Ce n'est pas le rôle de git de gérer les pull requests, tout comme montrer les commits sur un site web n'est pas non plus son travail.
Une pull request, c'est un message servant à prévenir qu'il faut valider un ensemble de commits pour l'intégrer à une branche de travail. Donc c'est plutôt un outil de messagerie qu'il faut utiliser. Les modifs attachées au message peuvent être hébergées sur un autre repo git, ou être fournies dans le message lui même. Ca n'a aucune importance, il n'y a même pas de dépendances à une techno particulière, que ce soit un VCS (système de contrôle de version) ou à une méthode d'envoi du message (forum, github, e-mail, message IRC, etc…). Pour des raisons de traçabilité et de simplicité, Linux utilise des emails pour gérer ça, mais ça n'a pas vraiment de couplage avec git.
[^] # Re: Forges
Posté par damaki . En réponse au journal GNOME va passer à GitLab. Évalué à 2.
Et si vous cherchez un truc sans dépendances pénibles, pas trop gourmand et ultra facile à installer sur n'importe quoi, vous avez aussi Gitbucket. C'est le point faible de tous les autres que j'ai eu l'occasion de tester, le côté overkill et complexité à administrer quand on a moins de 10 utilisateurs.
Ca n'est évidemment pas le même cas d'utilisation que Gitlab, outil excellent, avec plein de fonctionnalités intégrées (et débilement gourmand sur une petite install).
[^] # Re: Vorbis
Posté par damaki . En réponse au journal Opus 1.2. Évalué à 1.
En plus de tous les arguments énoncés, les bitrates fixes ne sont plus trop utilisés quand on règle l'encodage. On utilise plutôt un niveau de qualité qui vise à peu près un bitrate (VBR), mais si l'encodeur juge qu'il a besoin de beaucoup de données pour stocker une frame audio, il en prendra un peu plus. Inversement, s'il juge qu'il peut économiser du bitrate, il le fera.
L'encodage à bitrate constant n'est plus utilisé que pour le streaming et même Apple utilise du VBR pour ses fichiers encodés en AAC.
En résumé, même un bitrate moyen ne suffit pas pour juger la qualité, avec un codec moderne. Ca permet juste d'avoir une vague idée de si c'est écoutable ou pas suivant une échelle de références, mais ça reste une indication et pas un fait. Et l'encodeur utilisé joue beaucoup aussi. Les MP3s encodés vers 2001 ou 2002 sont désormais à peine écoutable, par exemple.
[^] # Re: Vorbis
Posté par damaki . En réponse au journal Opus 1.2. Évalué à 3.
Il faut différencier les différents types de test, qui n'ont pas la même valeur scientifique :
- AB, test en sachant quel est l'échantillon a et quel et le B. Aucune valeur scientifique, le royaume de l'idiophile, des enceintes chaudes et du vinyl chaleureux. Si vous testez casque dans le magasin, vous le faites.
- ABX. Test en aveugle, sans savoir si on écoute l'échantillon A ou B. Valide scientifiquement si on fait suffisamment d'essais en aveugle.
- ABC/HR, assez proche de l'ABX où en plus on note la qualité de l'échantillon. Souvent utilisé avec des samples de sons problématiques sur les encodeurs. C'est valide scientifiquement également, et la qualité du test dépend du nombre de tentatives.
Il existe donc de vraies méthodologies, pas spécifiques à l'audio qui permettent de connaître avec certitude la qualité d'un codec, pour peu qu'on ait assez de participants avec une bonne oreille. A noter que la qualité du matos utilisé pour faire le test ne joue pas plus que ça. Du mauvais matos peut permettre de mieux percevoir certains défauts et du meilleur matos peut aider à en percevoir d'autres.
wikipedia: AB
Hydrogenaudio: ABX
Hydrogenaudio: ABC/HR
[^] # Re: Sans alcool ?
Posté par damaki . En réponse à la dépêche La bière libre, ColiBibine, est de retour pour les RMLL !. Évalué à 1. Dernière modification le 09 juillet 2017 à 14:20.
Juste pour rappel, une substance bien plus addictive est dans notre consommation courante, donc une affection préliminaire (pré-diabète) affecte environ 30% de la population américaine, et à peu près autant de la population française, et représente un aussi au moins gros problème de santé publique. Oui, je parle du sucre. Essayez juste une semaine sans, et vous verrez, les envies de sucre n'ont rien à envier à l'alcool.
Maintenant, est-ce qu'on devrait conseiller au gens de boire des boissons sucrées plutôt que de l'alcool ? Ah cette morale, quand on parle de drogue, en ignorant que beaucoup de ce qu'on mange provoque des addictions. Et si on parlait aussi de la caféine, donc l'arrêt brutal provoque quand on en consomme beaucoup de violent maux de tête, pendant des semaines. Et tant d'autres substances. Est-il vraiment nécessaire de continuer ?
Maintenant qu'on est dans le domaine de la science et plus de la morale, peut-on commencer à réfléchir raisonnablement et à accepter notre culture et ses travers ?
# Les levures ?
Posté par damaki . En réponse à la dépêche La bière libre, ColiBibine, est de retour pour les RMLL !. Évalué à 2.
N'oubliez pas d'indiquer le type de levures dans les ingrédients. Juste levure, c'est extrêmement vague.
[^] # Re: Samsung
Posté par damaki . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à -1.
Ou des sous-marins sous Windows…
# Merci pour la pub
Posté par damaki . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 4.
Je ne connaissais pas Raptor Engineering, mais j'avoue être perplexe sur le papier de cette boîte. C'est juste un papier corporate qui glorifie cette entreprise, non ? Alors autant, je suis tout à faire convaincu de l'importance de coreboot et c'est bien qu'une entreprise mais était-ce bien nécessaire de récupérer cette publicité pour Raptor Engineering ? D'autant plus qu'aucune solution concrète, achetable réellement n'est évoquée dans cette dépêche.
Je ne trouve pas cette publi-information pertinente.
[^] # Re: openlaw.fr
Posté par damaki . En réponse à la dépêche Soirée déc‐ouverte LinuxFr.org, numéro 1 : FusionForge, LibreOffice et OpenLaw. Évalué à 1.
Et 35 requêtes sont bloquées sur le simple affichage de la page d'accueil. Je n'ai jamais vu un truc pareil.
Le site a probablement été infecté récemment et/ou alors affiche du malvertising.
[^] # Re: Médiathèque virtuelle
Posté par damaki . En réponse à la dépêche Revue de presse — janvier 2017. Évalué à 3. Dernière modification le 18 janvier 2017 à 16:50.
Votre besoin ressemble à ce soft sur framalibre . Mais sinon, un pauvre classeur sur framacalc (site officiel d'inventaire) ou sur une instance perso peut faire l'affaire aussi.
[^] # Re: PC122 / 5250
Posté par damaki . En réponse au journal Claviers originaux. Évalué à 1.
J'utilise au taf un model M qui a à peu près cette tronche, mais en version azerty et tous les marquages en français :)
Trouvé dans la rue à Paris. Magique.
[^] # Re: Et celui là ?
Posté par damaki . En réponse au journal Claviers originaux. Évalué à 1.
En précommande (expédition en mars 2017) depuis l'Europe, et testé par personne à par ses créateurs. Un peu difficile à recommander.
J'avoue que je l'ai quand même précommandé depuis un an avec des Cherry MX clear, l'accessoire trackball et le groupe de trois touches en plus :D
[^] # Re: Bof
Posté par damaki . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Faut pas que je poste quand je suis malade. 75% de hors-sujet. Je sors…
[^] # Re: Bof
Posté par damaki . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 0. Dernière modification le 02 janvier 2017 à 13:30.
Je pense que le principal souci est que cette techno recrée le même problème qui a provoqué la naissance du pagerank de Google : les sites qui trichaient avec leurs keywords et leur contenu. Ça part du principe que les sites sont sincères. Et ça part aussi du principe, clairement obsolète, que les métadonnées fournies par le site sont suffisantes pour mesurer la pertinence et la qualité d'un site.
Le principe même de la SEO, quelle que soit l'époque, c'est soit de mentir (dans le pire des cas) soit de customiser le site pour plus ressortir que les autres. Et même regarder le contenu même des pages est à peine suffisant pour en déduire la qualité, d'où l'ancien système pagerank avec le compte du nombre de liens hypertextes existants vers la page. Et inversement dans un cas de non optimisation des métadonnées, un site excellent pourrait aussi être ignoré par l'index d'un tel moteur de recherche.
Alors non, la main-mise de Google n'est pas une bonne chose, mais cette techno n'est en aucun cas une solution.
# Plutôt bien
Posté par damaki . En réponse à la dépêche Framalibre est en train de renaître. Évalué à 3.
C'est plutôt bien fichu comme nouvelle version du catalogue de logiciels libres, bravo ! La présentation est claire est concise. Le design est propre et moderne.
Un bémol pour la catégorie cloud, dont l'intitulé risque d'en perdre plus d'un qui ne sait pas ce qu'est l'auto-hébergement et comment on utilise ces trucs. L'intention est louable de donner de la visibilité à des outils libres, mais c'est complexe de viser plusieurs publics aussi différents que des administrateurs systèmes et des utilisateurs finaux. Faudrait à mon sens deux catalogues distincts et hébergés séparément. Ça trouverait plutôt sa place dans des sites liés au projet dégooglisons internet, non ?
[^] # Re: Config recommandée
Posté par damaki . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 1.
Vu que je ne souhaite ni utiliser un LDAP, ni des utilisateurs Linux, je l'ai volontairement mis de côté. Monter un LDAP pour 5 utilisateurs, je trouve que c'est de l'overkill et je ne suis pas fan d'utiliser du PAM pour des logins applicatifs. Mais ça reste moins pire que d'autres, en fouinant j'ai vu un serveur git+web qui stockait les mots de passe en MD5, en 2016… Hélas j'ai oublié le nom de cette abomination.
En tous cas, merci.
# Config recommandée
Posté par damaki . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 3.
Des gens auraient testé la community avec du hardware moins costaud que ce qui est préconisé ? Je me vois difficilement mobiliser 2 Go de RAM pour un serveur git avec quelques services en plus pour 5 utilisateurs. Ils ont l'air de vivement déconseiller avec 1 Go de ram (ce qui me paraît déjà énorme, soit dit en passant).
En attendant, j'utilise Gitbucket qui fait l'affaire, tourne pour quasi rien en ressources et bientôt un Kanboard dédié, en attendant de trouver des softs léger pour les autres features.
# actdiag, mermaid et d'autres en passant
Posté par damaki . En réponse à la dépêche Écrire des diagrammes de séquences. Évalué à 0. Dernière modification le 17 septembre 2016 à 22:46.
Sinon il y a aussi actdiag et mermaid.
En fait, j'avais passé du temps à chercher une flopée d'outils du genre et les voilà :
* PlantUML pour tout UML, comme dit dans d'autres réponses
* Ditaa pour transformer de l'ascii moche en joli diagramme
* shaape idem
* blockdiag diagrammes tout bêtes ou autres (c'est une suite de softs)
* mermaid pour des tas de schémas encore.