Pour mon utilisation personnelle (jet d'encre), j'ai opté pour des cartouches rechargeables et transparentes, achetées sur AliExpress ( à chercher sur https://fr.aliexpress.com/wholesale?catId=0&initiative_id=SB_20180401003340&SearchText=ink+cartridge par exemple ). Elles sont munies d'une puce qui fonctionne un peu à la manière d'une YesCard: à la question « reste-t-il de l'encre dans la cartouche », celles ci répondent toujours par l'affirmative.
Pour quelques dizaines d'euros, on a donc un système qui permet de remplir soi-même ses cartouches. Plutôt utile (mais ça n'est qu'une rustine sur un problème imposé par les constructeurs).
Ça remet en cause le prétendu aspect décentralisé, si un acteur peut décider de ce qui est légitime ou non.
Ça tombe bien, un acteur ne peut pas décider ça :)
Ce que propose le fondateur d'Ethereum, c'est de modifier le code des clients pour leur faire considérer que les transactions mettant en jeu cette adresse ne sont pas valides. C'est un choix arbitraire, et seuls ceux qui utilisent les clients modifiés considéreront ces transactions comme invalides. Les autres, non. C'est ça qui est appelé "soft fork".
Ça aboutira peut être à l'existence simultanée de deux états "légitimes" de la chaîne, ceux qui pensent qu'il faut considérer ces transactions comme invalides et ceux qui pensent qu'il faut considérer ces transactions comme valides.
C'est très intéressant du côté moral: faut il considérer "The DAO", qui n'était qu'une simple application sur Ethereum, comme un cas spécial ? Faut il faire quelque chose alors que finalement le "petit malin" n'a fait qu'utiliser un code qui n'avait par ailleurs pas d'autre spécification et le revendiquait ? ("The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code."). Bref, c'est très rigolo et intéressant.
Mon « pour l'instant » est mal choisi. Searx n'a aucun but d'inter-connexion affiché actuellement. Ça peut peut être changer dans le futur, je n'en sais rien.
Searx est actuellement un « simple » métamoteur, qui possède tout de même un intérêt majeur par rapport à Seeks: il est maintenu et actif.
Notons que Seeks n'a pas subi de changement majeur depuis 2 ou 3 ans, et que dans l'état, il me semble que l'interconnexion n'est pas du tout utilisable. Voir https://github.com/beniz/seeks pour l'activité sur le projet.
J'utilise personnellement Searx qui est un méta-moteur, présenté rapidement dans cet article. Il me sert simplement à faire passer mes requêtes par mon serveur, c'est un intermédiaire. Il est possible d'utiliser plein de moteurs avec Searx mais je n'utilise que Google, les autres étant globalement pourris au niveau des résultats qu'ils proposent.
Du coup, j'essaye de ramener des gens pour l'utiliser, histoire de « camoufler » mes requêtes et les requêtes de différents utilisateurs dans la masse des autres requêtes. À noter que Searx n'est pas le « nouveau Seeks » puisque qu'il ne s'agit que d'un méta-moteur, et qu'il n'a aucun but d'inter-connexion pour l'instant, même si il a été inspiré par Seeks.
Du coup, je rappelle la page qui liste les instances publiques de Searx: https://github.com/asciimoo/searx/wiki/Searx-instances
Si ça vous parait lent, vous pouvez désactiver certain des 15 moteurs de recherche qui sont cochés dans la page de préférences.
Je rebondis sur le commentaire de mathieui. Pourquoi vouloir maintenir une configuration par défaut compatible avec deux systèmes d'init, dont un est par défaut non installé ? Le split de rc.conf est utile pour les gens qui utilisent systemd, mais pourquoi imposer ça à tout le monde quand le système d'init de archlinux par défaut n'est pas systemd, et quand ce dernier est loin d'être majoritaire ? Ça oblige le système d'init par défaut actuel à appeler les binaires de systemd pour comprendre cette nouvelle configuration.
Comme l'a dit Ionut Biru (un développeur de ArchLinux) dans la mailing-list:
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
Je trouverais ça plus logique que de modifier l'init actuel pour lui faire bouffer la syntaxe de configuration de systemd, pour trouver, par exemple, /usr/lib/systemd/systemd-remount-fs à la place de mount -o rw,remount / dans le /etc/rc.sysinit (et après, on prétend que c'est kiss).
Ces derniers mois des changements comme le déplacement de /var/run et /var/lock vers /run et /run/lock, ou encore le remplacement du paquet udev par systemd-tools, ont été considérés comme des pas de plus vers l'utilisation de systemd en tant que système d'init par défaut, il faut cependant noter que cette progression est celle de toute les distributions, et est nécessaire pour l'utilisation d'udev, pour le premier exemple , et pour le second une décision d'upstream, donc pas d'affolement de ce côté.
Le fameux rc.conf, fichier de configuration principal de la distribution, n'est pas non plus abandonné, il est simplement conseillé d'utiliser désormais des fichiers séparés dans l'optique de la compatibilité avec systemd.
Des discussions animées sont en cours sur les listes de diffusion, à ce propos.
Cela est peut être le signe d'une transition en douceur, l'avenir nous le dira.
Yaourt n'est qu'un wrapper à Pacman et à makepkg, avec quelques autres fonctionnalités en plus. Le transit des paquets d'une version à une autre est donc la même qu'avec un paquet compilé par makepkg et installé avec pacman -U.
J'utilise aussi makepkg et pacman pour installer des paquets tiers, dont les PKGBUILD(s) sont déjà disponibles dans AUR ou par la commande ABS le plus souvent.
C'est simple et propre.
# Cartouches rechargeables
Posté par Reventlov . En réponse à la dépêche Du rififi dans ta cartouche d’encre. Évalué à 5.
Pour mon utilisation personnelle (jet d'encre), j'ai opté pour des cartouches rechargeables et transparentes, achetées sur AliExpress ( à chercher sur https://fr.aliexpress.com/wholesale?catId=0&initiative_id=SB_20180401003340&SearchText=ink+cartridge par exemple ). Elles sont munies d'une puce qui fonctionne un peu à la manière d'une YesCard: à la question « reste-t-il de l'encre dans la cartouche », celles ci répondent toujours par l'affirmative.
Pour quelques dizaines d'euros, on a donc un système qui permet de remplir soi-même ses cartouches. Plutôt utile (mais ça n'est qu'une rustine sur un problème imposé par les constructeurs).
[^] # Re: Pas aussi décentralisé que présenté
Posté par Reventlov . En réponse au journal Ethereum, The DAO et un petit malin sont sur un bateau.... Évalué à 8.
Ça tombe bien, un acteur ne peut pas décider ça :)
Ce que propose le fondateur d'Ethereum, c'est de modifier le code des clients pour leur faire considérer que les transactions mettant en jeu cette adresse ne sont pas valides. C'est un choix arbitraire, et seuls ceux qui utilisent les clients modifiés considéreront ces transactions comme invalides. Les autres, non. C'est ça qui est appelé "soft fork".
Ça aboutira peut être à l'existence simultanée de deux états "légitimes" de la chaîne, ceux qui pensent qu'il faut considérer ces transactions comme invalides et ceux qui pensent qu'il faut considérer ces transactions comme valides.
C'est très intéressant du côté moral: faut il considérer "The DAO", qui n'était qu'une simple application sur Ethereum, comme un cas spécial ? Faut il faire quelque chose alors que finalement le "petit malin" n'a fait qu'utiliser un code qui n'avait par ailleurs pas d'autre spécification et le revendiquait ? ("The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code."). Bref, c'est très rigolo et intéressant.
[^] # Re: Searx
Posté par Reventlov . En réponse à la dépêche Se passer de Google, Facebook et autres big brothers 2.0 #1 — Les moteurs de recherche. Évalué à 2.
Mon « pour l'instant » est mal choisi. Searx n'a aucun but d'inter-connexion affiché actuellement. Ça peut peut être changer dans le futur, je n'en sais rien.
Searx est actuellement un « simple » métamoteur, qui possède tout de même un intérêt majeur par rapport à Seeks: il est maintenu et actif.
Notons que Seeks n'a pas subi de changement majeur depuis 2 ou 3 ans, et que dans l'état, il me semble que l'interconnexion n'est pas du tout utilisable. Voir https://github.com/beniz/seeks pour l'activité sur le projet.
# Searx
Posté par Reventlov . En réponse à la dépêche Se passer de Google, Facebook et autres big brothers 2.0 #1 — Les moteurs de recherche. Évalué à 4. Dernière modification le 03 juin 2014 à 21:39.
J'utilise personnellement Searx qui est un méta-moteur, présenté rapidement dans cet article. Il me sert simplement à faire passer mes requêtes par mon serveur, c'est un intermédiaire. Il est possible d'utiliser plein de moteurs avec Searx mais je n'utilise que Google, les autres étant globalement pourris au niveau des résultats qu'ils proposent.
Du coup, j'essaye de ramener des gens pour l'utiliser, histoire de « camoufler » mes requêtes et les requêtes de différents utilisateurs dans la masse des autres requêtes. À noter que Searx n'est pas le « nouveau Seeks » puisque qu'il ne s'agit que d'un méta-moteur, et qu'il n'a aucun but d'inter-connexion pour l'instant, même si il a été inspiré par Seeks.
Du coup, je rappelle la page qui liste les instances publiques de Searx: https://github.com/asciimoo/searx/wiki/Searx-instances
Si ça vous parait lent, vous pouvez désactiver certain des 15 moteurs de recherche qui sont cochés dans la page de préférences.
# Note: zsh
Posté par Reventlov . En réponse au journal Quelques nouvelles de MPDC. Évalué à 2.
Bonsoir.
Je ne suis pas inscrit sur Github, alors je poste ici: avec zsh, la commande mpdc-playlist re g"electronic" renvoie
Il faut utiliser la syntaxe suivante:
Je ne sais pas si c'est à considérer comme une erreur ou non.
En tout cas, merci pour ce programme, les "modifiers" sont particulièrement utiles.
[^] # Re: Nope
Posté par Reventlov . En réponse au journal Mon point de vue sur Archlinux. Évalué à 3.
Je rebondis sur le commentaire de mathieui. Pourquoi vouloir maintenir une configuration par défaut compatible avec deux systèmes d'init, dont un est par défaut non installé ? Le split de rc.conf est utile pour les gens qui utilisent systemd, mais pourquoi imposer ça à tout le monde quand le système d'init de archlinux par défaut n'est pas systemd, et quand ce dernier est loin d'être majoritaire ? Ça oblige le système d'init par défaut actuel à appeler les binaires de systemd pour comprendre cette nouvelle configuration.
Comme l'a dit Ionut Biru (un développeur de ArchLinux) dans la mailing-list:
Je trouverais ça plus logique que de modifier l'init actuel pour lui faire bouffer la syntaxe de configuration de systemd, pour trouver, par exemple, /usr/lib/systemd/systemd-remount-fs à la place de mount -o rw,remount / dans le /etc/rc.sysinit (et après, on prétend que c'est kiss).
[^] # Re: systemd par défaut sous Archlinux ?
Posté par Reventlov . En réponse à la dépêche Une nouvelle image d'installation pour Archlinux (2012.07.15) est disponible. Évalué à 2. Dernière modification le 23 juillet 2012 à 17:27.
Le mieux pour se faire une idée des « tendances » au sein de la communauté est de suivre les différentes listes de diffusion, donc arch-dev-public.
Un exemple avec cette discussion qui clarifie les positions de quelques développeurs.
Ces derniers mois des changements comme le déplacement de /var/run et /var/lock vers /run et /run/lock, ou encore le remplacement du paquet udev par systemd-tools, ont été considérés comme des pas de plus vers l'utilisation de systemd en tant que système d'init par défaut, il faut cependant noter que cette progression est celle de toute les distributions, et est nécessaire pour l'utilisation d'udev, pour le premier exemple , et pour le second une décision d'upstream, donc pas d'affolement de ce côté.
Le fameux rc.conf, fichier de configuration principal de la distribution, n'est pas non plus abandonné, il est simplement conseillé d'utiliser désormais des fichiers séparés dans l'optique de la compatibilité avec systemd.
Des discussions animées sont en cours sur les listes de diffusion, à ce propos.
Cela est peut être le signe d'une transition en douceur, l'avenir nous le dira.
[^] # Re: Pacman/Yaourt
Posté par Reventlov . En réponse au sondage Qu'utilisez vous pour l'installation de vos logiciels tiers ?. Évalué à 0.
Yaourt n'est qu'un wrapper à Pacman et à makepkg, avec quelques autres fonctionnalités en plus. Le transit des paquets d'une version à une autre est donc la même qu'avec un paquet compilé par makepkg et installé avec pacman -U.
J'utilise aussi makepkg et pacman pour installer des paquets tiers, dont les PKGBUILD(s) sont déjà disponibles dans AUR ou par la commande ABS le plus souvent.
C'est simple et propre.
[^] # Re: avant de s'énerver
Posté par Reventlov . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 10.
Je me permets de laisser ça ici, à ce propos: https://mail.gnome.org/archives/distributor-list/2012-January/msg00003.html
C'est un message de la liste de diffusion de Gnome, avec sources, qui confirme les dires du développeur de Archlinux