Moonz a écrit 3686 commentaires

C’est vrai que faire une interface graphique autour de gpg -e | s3cmd put c’est du domaine de la SF tellement c’est de la haute technologie.

Passer à WPF c’est pas faire évoluer une application mais la réécrire.

Par contre GNU bc n’a pas eu de release depuis 2000, c’est qu’il doit être mort et inutilisable, n’ayant plus sa place que dans les musée de l’informatique, n’est-ce pas ?

Sauf que chez toi tu peux le chiffrer avec une passphrase bien compliquée et distribuer le wallet chiffré aux quatre coins de la planète en cas d’incendie/formatage/whatever.

Avec l’or c’est un poil plus compliqué.

Et c’est vrai qu’avec la gentille régulation de l’euro par l’UE, des déposants qui perdent en toute légalité une partie de leur avoir ça peut pas arriver.

Pas de commit depuis 2 ans

Pas de commit parce qu’il fait le job et que je n’ai eu aucun bug :)

Un module FUSE, Sérieux?

Qu’est-ce que tu as contre FUSE ? IMO c’est le truc le plus utile pour le desktop qu’ait fait le noyau depuis udev (et je regrette très fort que ce soit pas plus utilisé)

ça semble engendrer des comportements bizarres avec ls

Pas en fonctionnement normal non. Ça arrive seulement quand tu as des dotfiles que tu n’as pas déplacés dans .config/

La FAQ n’est pas assez claire ? Ce serait l’occasion d’un commit, remarque :)

Sinon peut-être qu'on fait des programmes qui respectent les normes par défaut.

Ce serait la solution parfaite bien sûr, mais malheureusement c’est déjà ce qu’on me disait en 2008 quand j’ai repris libetc… Il faut bien une solution en attendant.

http://ordiluc.net/fs/libetc/
https://github.com/sloonz/rewritefs

Tu en as des tonnes sur github. La seule difficulté est de les trouver (les trucs de quelques centaines de lignes de code font rarement de la pub en première page sur /.) En auto-pub :

• https://github.com/sloonz/maildir-feed : ~250 lignes de code
• https://github.com/sloonz/kanjidic : ~350 lignes de code
• https://github.com/sloonz/utils/blob/master/bin/scan : ~250 lignes de code

C’est vrai pour les bloatware.

Pour les logiciels qui se comptent en centaine de lignes de code, c’est beaucoup moins vrai.

Je ne vois pas en quoi c’est spécifique au web. Au pif :

$ ldd =claws-mail | wc -l
85

Je préfère ça à la situation où chacun réinvente la roue (carrée) de son côté.

Je ne comprends pas ton code ou 'pseudo-code', donc la seule chose que je te dirais, est que Python n'est pas "full-object". La personne t'affirmant le contraire est un imbécile. Ruby, au contraire, est "full-object".

Qu’est-ce que tu endends par "full-object" ?

Les nombres, les modules, les fonctions, les classes sont des objets en Python.

Parce que syntaxiquement nombre + "." indique que l’utilisateur veut écrire un nombre à virgules et s’attend à un nombre après.

(1).__class__ marche très bien.

La grande majorité des failles c’est pas dans des trucs « évidemment » sensibles, c’est des sprintf mal gérés par exemple, et ça arrive dans toutes les applications.

D’autant plus que se linker à une lib qui fait les choses correctement ne garantit pas que tu utilises correctement la lib toi-même (gestion de l’IV/salt dans les opérations crypto par exemple).

En matière de sécurité, on a une obligation de résultat.

Avec de tels principes je crois que tu peux désinstaller 99% des logiciels sur ta machine (allez, je te laisse cat, mais sans shell pour l’exécuter ça va être rigolo).

Heu, non, le cas est franchement différent :

• Le bug de debian vient du fait d’essayer de suivre des bonnes pratiques (éliminer des warning d’outils d’analyse). Le bug d’Apple vient du fait de ne pas détecter/éliminer assez de warning
• Le bug de debian n’aurait jamais pu être détecté par des tests unitaire/couverture de code. Le code Apple incriminé aurait dû (si on veut faire un code de qualité bien sûr) être couvert par un test unitaire, et ne l’a visiblement pas été.

Le « scandale » que les gens font sur ce site vient du fait que l’erreur aurait dû être facilement détectée, pas du fait de son impact.

Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.

Parce que dans Fedora 20 systemd est déjà intégré à l’initrd mais pas bash ? Parce que chez moi (Archlinux) c’est l’inverse, dans l’initrd j’ai bien un shell de base (ash) et pas systemd, donc si je veux y mettre systemd-networkd je dois à priori ajouter systemd. À l’inverse, si je veux mettre un script network pas la peine de compter le shell, il y est déjà.

Tu n’oublierais pas les 1020k de systemd (qui en plus tire la libdbus de 290k) dans ton décompte ? :)

Ben si, ça signifie respecter les spécificités du système cible sans introduire de couplage fort dessus.

Cairo par exemple est portable et intégré au système : portable pas la peine de s’étendre dessus, intégré au système : il utilise Quartz sous OSX, xlib/xcb sous Linux, GDI sous Windows. Apache est portable mais capable d’utiliser des mécaniques spécifiques à l’OS (epoll sous Linux, GCD sous OSX)…

Le problème est qu’il n’y a actuellement aucune espèce de protocole pour que les applications et le compositeur se mettent d’accord.

Autrement dit, une application qui aura des décorations sous Weston (client-side decoration) n’aura aucune décoration sous KWin (server-side décoration) et inversement une application qui aura des décorations sous KWin aura une double décoration sous Weston.

Comme KWin est isolé sur la position « server-side decoration », soit un protocole sort assez rapidement pour éviter les emmerdes, soit KDE sera forcé de rentrer dans le rang et d’accepter les client-side decorations qui seront le standard de fait pour Wayland.

Tu as oublié logind et udev.

Non, "for any" fait référence au destinataire, pas à l’envoyeur. La ligne limite bien aux envoyeurs locaux ("from local").

Un développeur qui accpete un patch dans sa branche principale s'engage à maintenir le patch totue la vie du projet.

Un développeur qui supprime des fonctionnalités plus maintenues ça s’est jamais vu effectivement.

J’ai merdouillé effectivement, le script GreaseMonkey n’est pas le bon ni sur github ni sur mon serveur.

J’ai mis à jour sur mon serveur, essaie de le réinstaller et dis moi si tu as toujours des soucis : https://ks3098700.kimsufi.com/wkr/autofill.user.js

Pour changer l’URL de l’autofiller, tu as une entrée dans le menu du script (sous firefox : Tools > Greasemonkey > Raccourcis du script > Set address).

On va pas refaire le débat, mais tout ça nécessite de la structure, pas du binaire, et il est tout à faire possible de structurer du texte.

À part ça, il y en a plein.

Les arguments de ce lien ont déjà été discuté dans un précédent journal (ou dépêche ?). Rien de tout ça ne nécessite un format binaire.

Aucun problème pour signer du texte par exemple (GPG pour les mails ça marche très bien…)

Mais franchement, si tu me disais que la seule machine à ta disposition qui puisse lire les log journald c'est la machine qui les produit, parce que tu n'as rien installé pour ça ailleurs, je penserais que tu n'as sûrement rien installé non plus ailleurs pour lire les partitions de la machine Linux, du coup les logs textes n'y changeront rien.

Allons, un peu d’imagination :

• pour le cas dont tu parles : accès aux logs en NFS/Samba/SSH
• je veux faire un traitement non prévu par journalctl, il n’y a pas de lib pour mon langage de prédilection (et j’ai pas que ça à faire que de coder un binding)
• je veux faire un traitement non prévu par journalctl, c’est du quick&dirty, je connais par cœur la lib standard de mon langage de prédilection et ça me prendrait 3 fois plus de temps pour apprendre la lib spécifique journald (par opposé à : « ho tiens, c’est du JSON compressé en zlib, je pourrai faire ça les yeux fermés tout en étant complètement bourré)
• je veux intégrer ça dans ma solution d’analyse de logs maison mais mon patron a dit « pas de copyleft »

Alors oui, dans tout ces cas on peut faire autrement, non, ce n’est pas à 100% bloquant.

Maintenant j’aimerais qu’on me donne une bonne raison pour laquelle journald se passe des bienfaits d’être compatible de base avec les libs standards de tous les OS sur tous les langages. Une seule. Ensuite je me tais, promis.

Tu peux les lire d’une autre machine sous un autre OS à travers un montage réseau aussi. Je n’ai pas assez de recul pour juger si c’est très rare ou pas, mais en tout cas ça m’est déjà arrivé dans ma carrière qui n’est pourtant pas très longue.