Moonz a écrit 3657 commentaires

Avec une telle attitude, m’est avis que Linux n’est pas prêt de percer sur le Bureau.

Faudrait se décider un jour : le problème de Linux sur le bureau c’est qu’on a 50 applications qui font la même chose ou bien qu’on puisse pas choisir son application parmi les 50 qui font la même chose ?

Le problème c’est que tous les sites qui font le moindre session_start() en PHP (ou qui utilisent un framework/CMS qui le fait automatiquement, ou qui fait l’équivalent dans un autre langage) se sent obligé de mettre un bandeau de ce type…

Ça donne surtout la fausse impression que tous les cookies sont mauvais et que tout le monde nous piste.

Tu as quand même vachement plus de bruit là dedans en C++ relativement à la version Ruby: v2.begin(), v2.end() juste pour dire « la totalité de v2 », std::back_inserter(v1) juste pour dire v1, et dans cette version tu dois te poser la question « est-ce que je copie v1 dans v2 ou v2 dans v1 ? », la réponse est certes triviale et déductible en 5s même pour moi qui connaît pas l’API, mais dans la version Ruby c’est 0s, j’ai une assignation avec une sortie à gauche et une entrée à droite.

Et je dis ça, je fais aussi peu de Ruby que de C++.

Sans le return implicit ça donne juste { |value| return value.even? }

Heu non, return dans un bloc n’est pas un retour du bloc mais de la méthode contenant le bloc.

http://stackoverflow.com/questions/2325471/using-return-in-a-ruby-block

Est peut-être clair pour toi qui connaît bien ruby, est indiscutablement plus concise, mais pour moi c’est incompréhensible au premier abord

Malheureusement on a pas encore inventé de langage compréhensible par quelqu’un qui le connaît pas. La vie est mal faite.

Heu non, le code équivalent en Go à ton code C#/Ruby ce serait plutôt au choix :

chien := new(Chien);
chien := &Chien{};

Tu veux dire, un peu comme ça ?

Sinon tu peux aussi distribuer les libs nécessaires et jouer avec LD_LIBRARY_PATH

Si l'on avait fait ce logiciel en Java, les dépendances auraient été incluses dans le jar par une chaine de compilation courte et moderne de type maven et la seule et unique dépendance de l'application ainsi packagée serait alors la JVM.

Scénario que tu veux absolument éviter dans un contexte type Debian où toutes les dépendances DOIVENT êtres fournies par un paquet Debian et où tout utilisateur de ces dépendances DOIT utiliser la version empaquetée.

Évidemment, la JVM est garante du bon fonctionnement de l'application sur les différentes plateformes…

Ou pas. « Run everywhere » c’est bien plus théorique que pratique dès que tu mets jogl dans l’équation par exemple…

Une aide pour la télé ? Je suis le seul que ça choque ?

Non, le plus petit scope en Python c’est la fonction, pas le bloc (comme var en Javascript)

Surprenant parce que faisant une division entière je m’attend à un résultat entier.

Dangereux parce que si je me rend pas compte qu’il m’a renvoyé un flottant au lieu d’un entier, == et != peuvent se comporter de manière inattendue.

d est quand même surprenant (et dangereux).

De même, en openGL 1 (oui, je sais c'est obsolète, mais la question n'est pas là), il existe des fonction glbegin() et glend() qui permettent de définir entre les blocs une suite d'instructions graphiques.

class glTransaction:
    def __enter__(self):
        glBegin()
    def __exit__(self, exType, exValue, exTb):
        glEnd()
        return False

with glTransaction():
    glFoo()
    glBar()
    glBaz()

Avec la gestion des exceptions qui vient gratuitement en bonus.

utiliser son portable en RFID

RFID ou NFC ?

Un portable en tant que puce RFID c’est la première fois que j’en entend parler, et ça m’intéresse.

Ils ne doivent pas être si nombreux que ça parce que la carte de paiement avec un code à 4 chiffres ça existe depuis belle lurette et à ma connaissance personne ne se plaint de ne pas réussir à retenir le code

Que les gens se résignent à un système ne signifie rien de sa pertinence objective, ni même de ses avantages « subjectifs » (syndrome de Stockholm, toussa)

La problématique des digicodes c’est exactement la même que celle des mots de passe, et je laisserai notre ami Google expliquer mieux que moi pourquoi les mots de passe ça pue.

Ben non, tu ne peux pas transférer de chaleur d’une source froide vers une source chaude sans fournir d’énergie.

je n'arrive pas à imaginer comment il pourrait en être autrement

Le canal de contrôle c’est effectivement un socket Unix (http://wayland.freedesktop.org/docs/html/sect-Protocol-Wire-Format.html), par contre le canal de données c’est de la mémoire partagée (http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_shm.html, http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_buffer.html).

(et peut-être encore autre chose si EGL rentre en jeu, mais j’avoue que j’ai pas regardé plus en détails)

Pourquoi ne pas faire comme gPass/WKR, c’est à dire ne garder que des données chiffrées côté serveur et laisser le navigateur faire le déchiffrage en Javascript ?

Euh non. L'init a besoin que quelque chose découvre le matos avant de booter, et c'est le rôle de udev

Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).

Et dans l’autre sens udev ne dépendait pas d’un init particulier, tu pouvais l’utiliser avec initng, sysvinit, mudur, celui de slackware…

Quant à Linux c’est pas vraiment la question, udev était lié à Linux avant, il l’est tout autant avec systemd, pas de changement, je vois même pas ce qu’il y a à discuter là dessus…

Ben bah plus que dans l'ancien modèle, si ce n'est que systemd (le projet) a besoin de linux et pas un autre kernel. Encore une fois, je doute que ça change grand chose par rapport à l'ancien modèle (udev et les scripts SysV Debian tournent-ils sous BSD ? J'ai un gros doute là !)

udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.

udev a-t-il besoin de systemd ? Non. C'est juste systemd qui a besoin de udev.

Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.

Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.

Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).

Pourquoi essayer des analogies quand on peut parler de la vraie chose ?

Dans « l’ancien modèle », udev, init, le gestionnaire de service et getty sont totalement découplés.

Dans le nouveau modèle systemd, udev, systemd (init), systemd (gestionnaire de service) et (le successeur de getty dont j’ai oublié le nom) sont fortement couplés (ou plus objectivement, de plus en plus fortement couplés de version en version).

Tout ce que je dis, c’est que cette évolution :

1. existe
2. ne plait pas à certaines personnes
3. cette résistance est distincte de « les méchants réactionnaires qui aiment pas le changement »

Eric R

Hein ? Pourquoi ? Jamais entendu parler d’une sortie à la Linus ou TdR de sa part.

Et dans le cas de systemd, systemd (l'init) est indépendant de systemctl (le gestionnaire de services) : l'init n'a pas besoin de faire appel à systemctl pour booter.

Heu… source ? Parce que ce que tu es en train de dire, c’est que je peux par exemple prendre systemd en tant que /bin/init puis lancer initng (qui a besoin d’être PID 1) pour gérer mes services ?

Je peux me tromper, mais j’en doute énormément.

Et si je fais ça, les autres composants de systemd (journald, udev…) marchent toujours ? (sachant que le PID 1 n’est plus celui de systemd)

Dans le cas de SysV/Upstart/Pardus ça m'étonnerait que ce soit différent.

Ça l’est : leur gestionnaire de service était utilisable sur des systèmes sans leur init (j’ai essayé mais abandonné rapidement, préférant initng à l’époque). Tout ce dont il a besoin, c’est d’être PID 1 (c’est à dire que la seule chose nécessaire c’est que l’init puisse passer la main au gestionnaire de service une fois le système initialisé, c’était assez facile à faire sous Arch)

Mais elles ne sont pas fortes dans le cas de systemd : les outils qui le compose peuvent être remplacés.

Tu veux dire, un peu comme udev ?

Un système / programme sans dépendances : c'est un système / programme qui ne fait RIEN DU TOUT.

Ben non, si je reprend mon exemple de Pardus plus bas, leur système d’init (mudur) et leur gestionnaire de service (dont j’ai oublié le nom) étaient totalement indépendants (puisque j’ai pu utiliser l’un sans l’autre), et ils sont loin d’être inutiles.

Et pour reprendre l’exemple de sinma (projet GNU), emacs est indépendant de hurd.

De même, getty est indépendant de init, ça rend pas getty et init inutiles.

Gros paquet de nouilles interdépendant ≠ Monolithique

MacOS X n’est pas monolithique, bonne chance pour faire fonctionner son serveur graphique sans avoir tout ce qu’il y a autour. Postfix c’est plein de binaires différents et donc n’est pas « monolithique », ça n’empêche qu’ils fonctionnent de manière interdépendante.

Ben les fichiers de config aussi, et ça correspond aux scripts.

Non, du tout, si je compare à l’ancien init de Arch (connais bien moi le sysvinit classique), les scripts c’est pas seulement le démarrage des services, c’est aussi toute l’initialisation du système (/etc/rc.sysinit de mémoire), c’est à dire le montage des partitions, l’hostname, luks, lvm… et c’était typiquement pratique quand tu voulais jouer avec des trucs un peu bleeding-edge qui doivent se faire à l’initialisation du système : c’était juste un coup de vim /etc/rc.sysinit (à tes risques et périls bien sûr).

Pardus avait un système encore plus sympa avec l’équivalent de /etc/rc.sysinit écrit en Python (mudur je crois) qui passait ensuite la main à un gestionnaire de service à la systemd/initng. Je me souviens à l’époque de m’être fait un mélange des deux sous Gentoo, où l’init se faisait avec mudur et passait la main à initng — et ça marchait vraiment pas trop mal (et pour revenir dans le troll systemd, c’est justement ce genre d’expérimentations que le projet systemd va rendre de plus en plus difficile voire impossible).