Emacs permet de programmer, lire ses courriels, surfer, agenda, org-journal, shell, … Depuis le millénaire dernier, T.V. Raman, un informaticien non-voyant depuis son enfance, code son interface 100% auditive, emacspeak.
Comme les abstractions sous-jacentes sont remontées par Emacs jusqu'au programmeur, cela permet d'avoir des "fontes auditives" qui mime, en terme visuel, la coloration syntaxique des variables, fonctions, macros et les fontes en gras pour les mots clefs par exemple.
Si le moteur est suffisant, il change les voix, la vitesse ou l'intonation en fonction du contexte de ce qui est lu.
Il est possible de faire plus souple que Ubuntu/Debian, mais il faut quand même quelqu'un pour faire le travail.
Emacs a un système de paquets par hiérarchie (cathédrale ET bazar simultanément). Il y a les paquets stables, avec un mainteneur, centralisés, sûr, sans dépendances externes, et avec plusieurs propriétaires (la FSF en plus de l'auteur original), puis plusieurs niveaux de dégradations dans la qualité "garantie".
Cathédrale (les seuls configurés par défaut, environ 1000 paquets):
- paquets internes distribués avec emacs (transfert à la FSF), mis à jour uniquement avec une nouvelle version d'emacs
- paquet elpa GNU (transfert à la FSF)
- paquet elpa nonGNU (- de paperasses que le précédent)
- les paquets de niveau elpa n'utilisent que les paquets internes ou de niveaux elpa, donc pas dépendances externes.
Bazar:
- paquet melpa (communautaire, idem pip, npm, etc., environ 5000 paquets)
- paquet "straight", en direct d'un lien github
Et il est possible d'être dans plusieurs niveaux à la fois. C'est le cas de org-mode, qui est interne et elpa (m-a-j plus rapide que le cycle de emacs).
Dans les langages "modernes", personne ne veut faire ce travail de construction/évolution de la "bibliothèque standard" et c'est le nœud du problème.
Merci pour ces preuves de concepts ! Je partage votre avis. J'ai constaté que Discord (Tout aussi proprio que Zoom) était finalement assez adapté pour encadrer les projets informatique d'équipes d'étudiants sur plusieurs mois:
- audio first: bien plus interactif que tous les autres choix classiques "vidéo first" que j'ai testé: Zoom, BBB (libre et pas mal du tout en fait), Teams. Il permet un passage instantané d'une équipe à l'autre.
- sous-salons nommables pérennes (un sous-salon par équipe composé de la variante du sujet et des noms des étudiants): un truc qui a l'air simple mais qui n'existe pas dans Zoom, BBB, ou Teams
- partage d'écran possible quand même
tmate.io (à base de tmux) + Mumble était mon premier choix l'an passé, mais, hélas, pas déployable facilement pour moi (filtrage au niveau de l'université pour Mumble).
BBB n'est pas loin de vous coté dessin, mais n'a rien coté terminal.
Vos plugins seraient-ils intégrables dans Jami ou BBB ? Partager son terminal en format texte, des dessins avec des formats vectoriels, etc. au lieu de partager sa webcam est effectivement un gros plus.
Il est difficile de mesurer l'intérêt d'IPv6 tant que le travail n'est pas fait, au moins partiellement, puisque le trafic IPv6 n'est pas visible avant.
J'ai vu des coûts cachés bizarres. Exemple: un serveur cups accessible en IPv4 tout le temps, mais dont on va perdre l'accès en IPv6 (niveau routeur) sur les PC/Linux clients quelques heures après le boot. Pourquoi ? Comment ? Il faut activer IPv6 pour voir le soucis.
Mais Ipv6 a parfois un vrai gain tangible pour les terminaux: contourner la politique de l'admin réseaux, quand l'admin n'a pas le temps de vérifier les problèmes induits par sa politique. Par exemple, sur un réseau universitaire wifi faisant partie de la fédération "eduroam", le filtrage sortant par port est acceptable (déconseillé mais hélas acceptable). Il est donc parfois utilisé ! Mais en plus des ports http/https/ssh/VPNs/emails/FTP, un réseaux "eduroam" doit aussi laisser passer le protocole 41: les tunnels IPv6 (vive les brokers ! cf https://www.eduroam.fr/specif_tecnik). Et hop ! (OK, ça marche aussi avec un VPN externe, mais ce n'est pas la question :-) )
Je n'ai pas bien compris comment scrcpy a été utile. Pour moi cela ressemble à faire du VNC sur Android. Pourriez-vous précisez un peu son usage pour les corrections ? (qui installe quoi, quand et où ?)
Sinon bravo pour ce super boulot et le partage des bonnes idées !
Un autre problème avec ces deux éditeurs est qu'ils sont conçus pour des machines avec une poignée d'utilisateurs. Pour avoir quelques greffons (plugins) ils font la création, pour chaque utilisateur, de dizaine de milliers de fichiers dans les .atom/ ou .vscode/.
VScode en met un peu moins dans la racine, mais il en met dans chaque entrepôt git.
Aucun des deux ne sait partager ses fichiers entre utilisateurs.
Bref, quand vous avez un millier d'utilisateurs et des sauvegardes qui fonctionnent fichier par fichier, ils sont un problème.
Je pense que vous avez manqué un point central du succès de git: contrairement aux autres VCS modernes, il n'utilise pas une BD !
le .git/ ressemble à un site web statique: des fichiers textes contenant des liens (URL) vers d'autres fichiers textes ou des fichiers contenant le code du commit. Ils sont tous compressés avec Zip et c'est (presque) tout (Je raccourcis un peu: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)
Ce modèle de données ultra simple permet de facilement ajouter des nouveaux outils (Les nombreux gui diverses et variés, duplicity …) ou commandes par dessus (git lsf, git annex, git module, git subtree… ), les backups ne stockent pas un fichier unique au format obscur, …
Mais vous pouvez encore changer ce point, car le reste à l'air vraiment cool :-)
# emacspeak
Posté par Legrego . En réponse à la dépêche L’informatique sans écran. Évalué à 1 (+1/-0).
Emacs permet de programmer, lire ses courriels, surfer, agenda, org-journal, shell, … Depuis le millénaire dernier, T.V. Raman, un informaticien non-voyant depuis son enfance, code son interface 100% auditive, emacspeak.
Comme les abstractions sous-jacentes sont remontées par Emacs jusqu'au programmeur, cela permet d'avoir des "fontes auditives" qui mime, en terme visuel, la coloration syntaxique des variables, fonctions, macros et les fontes en gras pour les mots clefs par exemple.
Si le moteur est suffisant, il change les voix, la vitesse ou l'intonation en fonction du contexte de ce qui est lu.
[^] # rsync.net: minimum 680GB -> minimum 122 dollars/an (10$/mois)
Posté par Legrego . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 0.
680GB de minimum: 122$/an ou environ 10$/mois
# Déjà résolu: avoir un garant/distributeur pour les paquets importants. Exemple: FSF pour Emacs
Posté par Legrego . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 1.
Il est possible de faire plus souple que Ubuntu/Debian, mais il faut quand même quelqu'un pour faire le travail.
Emacs a un système de paquets par hiérarchie (cathédrale ET bazar simultanément). Il y a les paquets stables, avec un mainteneur, centralisés, sûr, sans dépendances externes, et avec plusieurs propriétaires (la FSF en plus de l'auteur original), puis plusieurs niveaux de dégradations dans la qualité "garantie".
Cathédrale (les seuls configurés par défaut, environ 1000 paquets):
- paquets internes distribués avec emacs (transfert à la FSF), mis à jour uniquement avec une nouvelle version d'emacs
- paquet elpa GNU (transfert à la FSF)
- paquet elpa nonGNU (- de paperasses que le précédent)
- les paquets de niveau elpa n'utilisent que les paquets internes ou de niveaux elpa, donc pas dépendances externes.
Bazar:
- paquet melpa (communautaire, idem pip, npm, etc., environ 5000 paquets)
- paquet "straight", en direct d'un lien github
Et il est possible d'être dans plusieurs niveaux à la fois. C'est le cas de org-mode, qui est interne et elpa (m-a-j plus rapide que le cycle de emacs).
Dans les langages "modernes", personne ne veut faire ce travail de construction/évolution de la "bibliothèque standard" et c'est le nœud du problème.
# Audio rocks ! Mettre vos plugins dans Jami ou BBB ?
Posté par Legrego . En réponse à la dépêche Des outils de téléconférence libres, sobres et souverains. Évalué à 5.
Merci pour ces preuves de concepts ! Je partage votre avis. J'ai constaté que Discord (Tout aussi proprio que Zoom) était finalement assez adapté pour encadrer les projets informatique d'équipes d'étudiants sur plusieurs mois:
- audio first: bien plus interactif que tous les autres choix classiques "vidéo first" que j'ai testé: Zoom, BBB (libre et pas mal du tout en fait), Teams. Il permet un passage instantané d'une équipe à l'autre.
- sous-salons nommables pérennes (un sous-salon par équipe composé de la variante du sujet et des noms des étudiants): un truc qui a l'air simple mais qui n'existe pas dans Zoom, BBB, ou Teams
- partage d'écran possible quand même
tmate.io (à base de tmux) + Mumble était mon premier choix l'an passé, mais, hélas, pas déployable facilement pour moi (filtrage au niveau de l'université pour Mumble).
BBB n'est pas loin de vous coté dessin, mais n'a rien coté terminal.
Vos plugins seraient-ils intégrables dans Jami ou BBB ? Partager son terminal en format texte, des dessins avec des formats vectoriels, etc. au lieu de partager sa webcam est effectivement un gros plus.
# Les coûts et gains de IPv6 restent invisibles tant que l'on reste en IPv4 only
Posté par Legrego . En réponse au journal Fini l'obligation de compatibilité IPv6 par la loi. Évalué à 0.
Il est difficile de mesurer l'intérêt d'IPv6 tant que le travail n'est pas fait, au moins partiellement, puisque le trafic IPv6 n'est pas visible avant.
J'ai vu des coûts cachés bizarres. Exemple: un serveur cups accessible en IPv4 tout le temps, mais dont on va perdre l'accès en IPv6 (niveau routeur) sur les PC/Linux clients quelques heures après le boot. Pourquoi ? Comment ? Il faut activer IPv6 pour voir le soucis.
Mais Ipv6 a parfois un vrai gain tangible pour les terminaux: contourner la politique de l'admin réseaux, quand l'admin n'a pas le temps de vérifier les problèmes induits par sa politique. Par exemple, sur un réseau universitaire wifi faisant partie de la fédération "eduroam", le filtrage sortant par port est acceptable (déconseillé mais hélas acceptable). Il est donc parfois utilisé ! Mais en plus des ports http/https/ssh/VPNs/emails/FTP, un réseaux "eduroam" doit aussi laisser passer le protocole 41: les tunnels IPv6 (vive les brokers ! cf https://www.eduroam.fr/specif_tecnik). Et hop ! (OK, ça marche aussi avec un VPN externe, mais ce n'est pas la question :-) )
# Scrcpy
Posté par Legrego . En réponse à la dépêche Interview de Laurent, instituteur et libriste. Évalué à 2.
Bonjour
Je n'ai pas bien compris comment scrcpy a été utile. Pour moi cela ressemble à faire du VNC sur Android. Pourriez-vous précisez un peu son usage pour les corrections ? (qui installe quoi, quand et où ?)
Sinon bravo pour ce super boulot et le partage des bonnes idées !
# VS et Atom: 10aines de milliers de fichiers pour quelques plugins, par utilisateur
Posté par Legrego . En réponse au journal Atom / VSCode. Évalué à 2.
Un autre problème avec ces deux éditeurs est qu'ils sont conçus pour des machines avec une poignée d'utilisateurs. Pour avoir quelques greffons (plugins) ils font la création, pour chaque utilisateur, de dizaine de milliers de fichiers dans les .atom/ ou .vscode/.
VScode en met un peu moins dans la racine, mais il en met dans chaque entrepôt git.
Aucun des deux ne sait partager ses fichiers entre utilisateurs.
Bref, quand vous avez un millier d'utilisateurs et des sauvegardes qui fonctionnent fichier par fichier, ils sont un problème.
(Pour compter: du --inodes ~/.atom )
# ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers
Posté par Legrego . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Je pense que vous avez manqué un point central du succès de git: contrairement aux autres VCS modernes, il n'utilise pas une BD !
le .git/ ressemble à un site web statique: des fichiers textes contenant des liens (URL) vers d'autres fichiers textes ou des fichiers contenant le code du commit. Ils sont tous compressés avec Zip et c'est (presque) tout (Je raccourcis un peu: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)
Ce modèle de données ultra simple permet de facilement ajouter des nouveaux outils (Les nombreux gui diverses et variés, duplicity …) ou commandes par dessus (git lsf, git annex, git module, git subtree… ), les backups ne stockent pas un fichier unique au format obscur, …
Mais vous pouvez encore changer ce point, car le reste à l'air vraiment cool :-)