Tryton est une plate-forme applicative de haut-niveau, d'architecture trois tiers, sous licence GPL-3, écrite en Python et utilisant PostgreSQL comme moteur de base de données. C'est le cœur d'une solution complète pour entreprise qui fournit modularité, évolutivité et sécurité.
Pour essayer de comprendre de quoi il s'agit, j'enlève la description technique du fonctionnement interne du projet:
Tryton est une plate-forme applicative. C'est le cœur d'une solution complète pour entreprise qui fournit modularité, évolutivité et sécurité.
Pas bien avancé, j'enlève la novlangue commerciale:
Tryton est une plate-forme applicative pour entreprise.
Supair. Il faut lire la description des modules pour y voir un peu plus clair:
Actuellement, les principaux modules disponibles de Tryton couvrent les champs d'activités suivants: Comptabilité, Facturier, Gestion des ventes, Gestion des achats, Comptabilité analytique, Gestion de stock. Ils établissent une base saine et une abstraction simple et puissante des concepts clés pour toute adaptation métier.
Dois-je comprendre que c'est une sorte d'ORM dédié à la gestion ?
Lier un nom à un vote, c'est tout de même une idée naïve (pour ne pas dire autre chose). Toutes les garanties institutionnelles ou techniques n'atteindront jamais la cheville de la meilleure des garanties qui consiste à ne jamais lier ces informations.
Ça me semble encore plus dangereux s'il s'agit de faire des sommes homomorphes de ces données: on chiffre soit un 0, soit un 1, et comme il n'y a normalement qu'un 1 parmi plusieurs 0 dans la table, on a vite fait, sans même avoir à déchiffrer le vote, de savoir pour qui untel a voté.
D'accord, la machine crache des données chiffrées, et puisque la clé est partagée, il faut être plusieurs pour les déchiffrer. Mais on s'en fout un peu: qui nous dit que la machine reçoit les bonnes données, qui nous dit qu'elle n'ajoute pas des votes (la clé de chiffrement est justement publique), qui nous dit qu'elle calcule bien, qui nous dit que l'algorithme utilisé est effectivement homomorphe…
Amhà, le chiffrement ne fait qu'ajouter une boite noire à une boite noire.
Après avoir relu nos différents posts, il m'apparaît que nous sommes d'accord en fait. Je n'ai pas été très clair, j'en conviens.
Gunnars Ritter a expliqué qu’il avait modifié l’algorithme de Knuth-Plass entre autres parce que ces débordements ne lui semblaient pas utiles. Ou du moins, c’est ce que j’ai cru comprendre.
Tu as très bien compris, Heirloom Troff préfère rétrécir les espaces que rejeter une partie du texte hors marge (ce qui est dommage à mon avis…).
C'est vrai que ce n'est pas très précis. Je crois que je voulais dire «applications basées sur le framework Qt destinées aux interfaces graphiques», mais je ne sais pas si c'est plus précis. Quoi qu'il en soit, merci pour tes explications.
Si la réponse peut éclairer la question, Jiyuu y a très bien répondu, et toi aussi, en seconde partie de ton post.
J'ai l'impression que deux choses sont mélangées dans le problème ici en question: les caractères hors marge, et les mécanismes d'alignement de Tex.
Je ne crois pas que l'algorithme de Tex utilise le débordement de caractère pour corriger l'espace inter-mot, je crois que le débordement de caractère n'est utilisé qu'a posteriori: lorsque la ligne est créée, si le dernier caractère est un tiret, celui-ci est légèrement décalé pour paraître aligné. C'est du moins ainsi que fonctionne Troff, et je crois qu'il en est de même pour Tex.
C'est probablement pour cela qu'il n'y a pas de message d'alerte: le mécanisme de création de ligne n'est pas en jeu ici.
Si on veut aller plus loin, et adapter le crénage au travail en cours, effectivement ça devient un travail de spécialiste.
Pour bien faire, il faudrait probablement des macros strictes, dédiées à un jeu de polices et à une mise en page spécifique, et gérant tous ces détails.
Il me semble que GTK a fondé une partie de sa gloire sur le fait qu'il était tout a fait possible de trouver des applications GTK ne dépendant pas de l'environnement de bureau Gnome (à une époque pas si lointaine), ce qui faisait sens sur du matériel poussif.
À cette même époque, j'avais l'impression qu'en dehors de KDE, il n'y avait pas beaucoup d'applications Qt. Mais les choses ont dû changer depuis, d'où ma question: aujourd'hui, est-il possible de trouver les applications de bases d'un environnement graphique Qt qui ne dépendent pas de KDE?
Dites-moi, ce genre de dépassement n'est-il pas annoncé dans le terminal durant la compilation?
En passant, à ma connaissance, il n'y a aucune autre méthode que l'œil nu pour adapter le dépassement des caractères, et il faut effectivement le faire pour chaque police. Les créateurs de polices ont l'habitude de gérer ce genre de problèmes, en proposant d'ores et déjà des règles de crénages, mais (toujours à ma connaissance) aucun format de police ne leur donne la possibilité de coder en dur les règles de dépassement. Du reste, lorsque l'on utilise plusieurs polices dans un même paragraphe (ne serait-ce que de l'italique et du romain), il faudrait normalement aussi adapter les règles de crénages inter-polices, qui ne peuvent évidemment pas être codée dans la police.
M'enfin, rares sont ceux qui ont l'œil suffisamment exercé pour voir ces détails.
J'ai moi aussi un vieil ordinateur, qui peine avec le flash, et pour youtube, plutôt que de regarder la vidéo avec mon navigateur, j'utilise youtube-dl pour pouvoir la regarder directement avec un vrai lecteur vidéo (mplayer). En gros, le script suivant fait l'affaire:
#! /bin/sh# ytplay: play youtube video with mplayer# usage:# ytplay "http://youtube/video"url=$($(youtube-dl --get-url --format 18 "$1")if["$url"==""];thenyoutube-dl --list-formats "$1"echo"Select format: "read format
url=$(youtube-dl --get-url --format $format"$1")fi
mplayer "$url"
Concrètement, lorsque je veux regarder une vidéo sur youtube, je me contente d'en copier l'adresse et de la passer comme argument au script: ytplay "http://youtube/video" (ne pas oublier les guillemets). Au final, c'est bien plus confortable de regarder les vidéos ainsi.
Pour naviguer confortablement malgré tout, j'utilise un navigateur économe en ressources (jumanji), un proxy qui filtre les pubs et autres lourdeurs à la mode (privoxy), et je grapille toutes les ressources que je peux sur la machine (le moins possible de démons, pas d'environnement de bureau, etc.).
Maintenant, pour répondre à ta question : Ta fais comme il y a 20 ans.
C'est bien ce que je me disais: c'était mieux à vent.
PS:
Excuse-moi si j'ai pu paraître offensant. Dans mon esprit, « une seule machine à administrer », « les données sont centralisées », « l'environnement de travail se retrouve d'un terminal à l'autre », « les terminaux n'ont pas besoin de puissance de calcul », « un boot loader évolué qui irait chercher dans l'unité centrale son noyau », « une simple commande pourrait permettre donner le choix d'utiliser la puissance de calcul locale ou distante » et « plan9 propose une telle architecture distribuée », orientait tellement les « pistes d'exploration » demandées hors des chemins du cloud, que je ne comprenais pas pourquoi tu insistais.
Tes remarques, et celles de Pierre Matthieu Anglade finissent de me convaincre. Il reste à voir si j'aurai le courage de faire le saut, car mine de rien, c'est une petite révolution pour moi et mon foyer.
Je n'ai pas trouvé pour le moment le moyen de faire booter pxe sur du wifi. Du coup dans le cas d'applications "mobile" faut revenir au vieux système de client lourd.
J'y ai vaguement réfléchi, et je pensais simplement synchroniser un système de fichier local avec celui du serveur:
- soit simplement pour booter et lancer ssh -x, la synchronisation se faisant alors lors de l'extinction de la machine cliente.
- soit pour avoir un copie de son espace de travail en déplacement. Dans ce cas, je pensais ne faire la synchronisation qu'à la demande: du serveur vers le portable avant le voyage, du portable vers le serveur après le voyage.
- rsync me semble être un bon candidat pour la synchronisation.
C'est différent, mais c'est juste la même chose un niveau au dessus.
Non, ça n'a rien à voir, et ton post est hors sujet. Je demande comment n'avoir qu'une machine à administrer pour plusieurs terminaux légers, tu me parles de clients lourds, ayant chacun leur système d'exploitation, et ayant besoin d'un navigateur web pour accéder aux données évaporées et faire tourner des appli javascript qui ne font pas le quart de ce que font les logiciels dont j'ai besoin.
Ou alors tu m'expliques comment le cloud répond à mon problème pour les trois applications déjà proposées en exemple: bash, openbox, firefox.
Tu as mille fois raison, « maîtriser » était de trop dans ma phrase.
Mais je ne dis pas que le shell c'est bien parce que tout le monde comprend, je dis surtout que c'est parce que c'est l'outil par défaut qu'on apprend à le connaître. C'est le fait d'utiliser l'outil par défaut pour les scripts du système de base qui me semble pertinent.
On pourrait préférer avoir un autre outil par défaut, mais là n'est pas la question. On pourrait aussi considérer que l'idée d'un outil par défaut n'est pas bonne – là est peut-être la question.
apres si tu veux juste faire du "bureau a distance", le protocole à l'epoque c'etait XDMCP.
Depuis la version 5, ltsp utilise simplement ssh -x.
D'après ce que j'ai pu comprendre, le fonctionnement de ltsp est finalement très standardisé: boot PXE, montage du système de fichier via nfs, puis ssh -x (ou simplement startx pour les clients lourds). Le système de fichier du client, s'il diffère de celui du serveur, est peuplé via un chroot sur le serveur, et en utilisant le gestionnaire de paquet de la distribution. Enfin, chaque client peut configurer /etc/ avec les fichiers qui lui sont propres.
« L'utilisation de clients lourd pour accéder à ses données mises en réseau en échange de leur exploitation commerciale et politique. »
J'ai gagné quelque chose ?
Au cas où ce n'était pas une blague, je rappelle que ce ne sont pas seulement les données mais aussi les utilitaires que j'entends mettre sur serveur. Si tu m'expliques comment le cloud répond à mon problème pour les trois exécutables indispensables que sont bash, openbox, et firefox, je suis prêt à y réfléchir.
Rho le gros pâté de shell… Bah c’est pas très beau, mais bon faudrait une vraie comparaison (même démon et code équivalent).
Un paté de shell ça vaut un paté de python, de C, ou de n'importe quoi d'autre, je ne vois pas le problème. La fonction ici implémentée en [a]sh peut être implémentée ailleurs et autrement, il n'en reste pas moins qu'il faut l'implémenter quelque part: si ce n'est pas dans ce script, ce peut-être directement dans le logiciel d'init ou par ajout d'une option à la commande qui va bien, mais, je le répète, ça doit bien être implémenté quelque part.
L'intérêt du shell, à mon avis, c'est que c'est le langage par défaut d'administration de la machine, et celui qu'on trouve par défaut en console. On y est confronté à un moment ou un autre, et normalement, on apprend à le connaître et à le maîtriser. C'est, pour l'utilisateur final, une certaine garantie quant à la possibilité de toucher à son init.
Et de fait, lorsqu'on veut faire quelque chose qui sort des clous, le plus simple reste d'écrire un script shell. Je crois que même avec systemD, dans certains cas particulier, l'administrateur n'a pas d'autre choix que d'écrire un script shell qui va bien.
Pour ma part, j'ai souvent du modifier l'init réseau pour qu'il gère correctement ma configuration du wifi. Peu à peu, la procédure s'est normalisée, et maintenant ces hacks ne sont plus nécessaires. Mais j'imagine qu'il y aura toujours des situations où ce qu'ont prévu les développeurs d'init et les distributions ne correspond pas à une situation particulière.
Puisque j'ai du chercher de quoi on parlait:
- pkgsrc est l'hisotrique gestionnaire de paquets des bsd.
- pkgin est un gestionnaire moderne, créé par Imil pour NetBSD, et reposant sur le format et les outils de pkgsrc.
- pkgng est un gestionnaire moderne, créé par bapt pour FreeBSD, ayant son propre format de paquet, et totalement indépendant de pkgsrc.
Du coup, je m'interroge sur l'avenir de pkgin: ne risque-t-il pas d'être très isolé? NetBSD n'aurait-il pas intérêt à préférer pkgng à pkgin?
Je vais néanmoins écrire un petit mail au créateur d'exovis pour lui proposer de rajouter quelques liens à son site. Ne serai-ce que sur wikipédia, il y a plein d'informations sur les étoiles, et les planètes: par exemple Kepler-62, Kepler-62b, Kepler-62c, Kepler-62d, Kepler-62e, Kepler-62f.
En visitant le site exovis, où l'on découvre la forme des systèmes solaires, je me suis pris à imaginer à quoi pouvait ressembler les planètes, puis j'ai été pris de vertige face à l'immensité de certains systèmes, et au final, c'est comme si j'avais lu un bon roman de science fiction. C'est un beau site (si ce n'est qu'il ne manque de faire exploser mon ordinateur).
Mais que c'est pauvre en information. Il n'y a vraiment rien sur les dites planètes, ni d'ailleurs sur les étoiles autour desquelles elles tournent. J'imagine que des suppositions sur leurs masses, voire leurs structures font l'objet d'articles et de batailles scientifiques, et qu'en cherchant bien dans le net, je finirais par trouver quelques petites informations plus précises, mais je regrette que le site ne soit pas plus bavard.
[^] # Re: Tryton
Posté par Sygne (site web personnel) . En réponse au journal Utiliser Tryton dans son application Flask. Évalué à 3.
Merci, je comprends mieux maintenant.
# Tryton
Posté par Sygne (site web personnel) . En réponse au journal Utiliser Tryton dans son application Flask. Évalué à 8.
Pour essayer de comprendre de quoi il s'agit, j'enlève la description technique du fonctionnement interne du projet:
Pas bien avancé, j'enlève la novlangue commerciale:
Supair. Il faut lire la description des modules pour y voir un peu plus clair:
Dois-je comprendre que c'est une sorte d'ORM dédié à la gestion ?
[^] # Re: Une piste
Posté par Sygne (site web personnel) . En réponse au message Cherche boitier pour serveur «maison». Évalué à 2.
Et comment il installe debian dessus ?
[^] # Re: électron, piège à ...
Posté par Sygne (site web personnel) . En réponse au journal Le Chiffrement Homomorphe. Évalué à 4.
Lier un nom à un vote, c'est tout de même une idée naïve (pour ne pas dire autre chose). Toutes les garanties institutionnelles ou techniques n'atteindront jamais la cheville de la meilleure des garanties qui consiste à ne jamais lier ces informations.
Ça me semble encore plus dangereux s'il s'agit de faire des sommes homomorphes de ces données: on chiffre soit un 0, soit un 1, et comme il n'y a normalement qu'un 1 parmi plusieurs 0 dans la table, on a vite fait, sans même avoir à déchiffrer le vote, de savoir pour qui untel a voté.
[^] # Re: électron, piège à ...
Posté par Sygne (site web personnel) . En réponse au journal Le Chiffrement Homomorphe. Évalué à 2.
Lapin compris non plus…
D'accord, la machine crache des données chiffrées, et puisque la clé est partagée, il faut être plusieurs pour les déchiffrer. Mais on s'en fout un peu: qui nous dit que la machine reçoit les bonnes données, qui nous dit qu'elle n'ajoute pas des votes (la clé de chiffrement est justement publique), qui nous dit qu'elle calcule bien, qui nous dit que l'algorithme utilisé est effectivement homomorphe…
Amhà, le chiffrement ne fait qu'ajouter une boite noire à une boite noire.
[^] # Re: Pourquoi cette protrusion ?
Posté par Sygne (site web personnel) . En réponse au journal LaTeX sans douleur. Évalué à 2.
Après avoir relu nos différents posts, il m'apparaît que nous sommes d'accord en fait. Je n'ai pas été très clair, j'en conviens.
Tu as très bien compris, Heirloom Troff préfère rétrécir les espaces que rejeter une partie du texte hors marge (ce qui est dommage à mon avis…).
[^] # Re: Qt question
Posté par Sygne (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4.
C'est vrai que ce n'est pas très précis. Je crois que je voulais dire «applications basées sur le framework Qt destinées aux interfaces graphiques», mais je ne sais pas si c'est plus précis. Quoi qu'il en soit, merci pour tes explications.
Si la réponse peut éclairer la question, Jiyuu y a très bien répondu, et toi aussi, en seconde partie de ton post.
[^] # Re: Pourquoi cette protrusion ?
Posté par Sygne (site web personnel) . En réponse au journal LaTeX sans douleur. Évalué à 4.
J'ai l'impression que deux choses sont mélangées dans le problème ici en question: les caractères hors marge, et les mécanismes d'alignement de Tex.
Je ne crois pas que l'algorithme de Tex utilise le débordement de caractère pour corriger l'espace inter-mot, je crois que le débordement de caractère n'est utilisé qu'a posteriori: lorsque la ligne est créée, si le dernier caractère est un tiret, celui-ci est légèrement décalé pour paraître aligné. C'est du moins ainsi que fonctionne Troff, et je crois qu'il en est de même pour Tex.
C'est probablement pour cela qu'il n'y a pas de message d'alerte: le mécanisme de création de ligne n'est pas en jeu ici.
Pour bien faire, il faudrait probablement des macros strictes, dédiées à un jeu de polices et à une mise en page spécifique, et gérant tous ces détails.
# Qt question
Posté par Sygne (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
Il me semble que GTK a fondé une partie de sa gloire sur le fait qu'il était tout a fait possible de trouver des applications GTK ne dépendant pas de l'environnement de bureau Gnome (à une époque pas si lointaine), ce qui faisait sens sur du matériel poussif.
À cette même époque, j'avais l'impression qu'en dehors de KDE, il n'y avait pas beaucoup d'applications Qt. Mais les choses ont dû changer depuis, d'où ma question: aujourd'hui, est-il possible de trouver les applications de bases d'un environnement graphique Qt qui ne dépendent pas de KDE?
[^] # Re: Pourquoi cette protrusion ?
Posté par Sygne (site web personnel) . En réponse au journal LaTeX sans douleur. Évalué à 3.
Dites-moi, ce genre de dépassement n'est-il pas annoncé dans le terminal durant la compilation?
En passant, à ma connaissance, il n'y a aucune autre méthode que l'œil nu pour adapter le dépassement des caractères, et il faut effectivement le faire pour chaque police. Les créateurs de polices ont l'habitude de gérer ce genre de problèmes, en proposant d'ores et déjà des règles de crénages, mais (toujours à ma connaissance) aucun format de police ne leur donne la possibilité de coder en dur les règles de dépassement. Du reste, lorsque l'on utilise plusieurs polices dans un même paragraphe (ne serait-ce que de l'italique et du romain), il faudrait normalement aussi adapter les règles de crénages inter-polices, qui ne peuvent évidemment pas être codée dans la police.
M'enfin, rares sont ceux qui ont l'œil suffisamment exercé pour voir ces détails.
[^] # Re: Une distribution un peu trop comme les autres justement (ou pas assez)
Posté par Sygne (site web personnel) . En réponse au journal Frugalware, une distribution pas comme les autres.. Évalué à 6.
En intégrant continuellement la dernière version des logiciels dans les dépôts pardi.
=>[]
[^] # Re: youtube-dl
Posté par Sygne (site web personnel) . En réponse au message FlashPlayer prend 100% de la charge CPU. Évalué à 3.
Il y a une typo dans la 6e ligne du script:
# youtube-dl
Posté par Sygne (site web personnel) . En réponse au message FlashPlayer prend 100% de la charge CPU. Évalué à 4.
J'ai moi aussi un vieil ordinateur, qui peine avec le flash, et pour youtube, plutôt que de regarder la vidéo avec mon navigateur, j'utilise youtube-dl pour pouvoir la regarder directement avec un vrai lecteur vidéo (mplayer). En gros, le script suivant fait l'affaire:
Concrètement, lorsque je veux regarder une vidéo sur youtube, je me contente d'en copier l'adresse et de la passer comme argument au script:
ytplay "http://youtube/video"(ne pas oublier les guillemets). Au final, c'est bien plus confortable de regarder les vidéos ainsi.Pour naviguer confortablement malgré tout, j'utilise un navigateur économe en ressources (jumanji), un proxy qui filtre les pubs et autres lourdeurs à la mode (privoxy), et je grapille toutes les ressources que je peux sur la machine (le moins possible de démons, pas d'environnement de bureau, etc.).
[^] # Re: Cloud
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 2.
C'est bien ce que je me disais: c'était mieux à vent.
PS:
Excuse-moi si j'ai pu paraître offensant. Dans mon esprit, « une seule machine à administrer », « les données sont centralisées », « l'environnement de travail se retrouve d'un terminal à l'autre », « les terminaux n'ont pas besoin de puissance de calcul », « un boot loader évolué qui irait chercher dans l'unité centrale son noyau », « une simple commande pourrait permettre donner le choix d'utiliser la puissance de calcul locale ou distante » et « plan9 propose une telle architecture distribuée », orientait tellement les « pistes d'exploration » demandées hors des chemins du cloud, que je ne comprenais pas pourquoi tu insistais.
Je comprends mieux maintenant.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 2.
Tes remarques, et celles de Pierre Matthieu Anglade finissent de me convaincre. Il reste à voir si j'aurai le courage de faire le saut, car mine de rien, c'est une petite révolution pour moi et mon foyer.
J'y ai vaguement réfléchi, et je pensais simplement synchroniser un système de fichier local avec celui du serveur:
- soit simplement pour booter et lancer
ssh -x, la synchronisation se faisant alors lors de l'extinction de la machine cliente.- soit pour avoir un copie de son espace de travail en déplacement. Dans ce cas, je pensais ne faire la synchronisation qu'à la demande: du serveur vers le portable avant le voyage, du portable vers le serveur après le voyage.
- rsync me semble être un bon candidat pour la synchronisation.
[^] # Re: Cloud
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 1.
Non, ça n'a rien à voir, et ton post est hors sujet. Je demande comment n'avoir qu'une machine à administrer pour plusieurs terminaux légers, tu me parles de clients lourds, ayant chacun leur système d'exploitation, et ayant besoin d'un navigateur web pour accéder aux données évaporées et faire tourner des appli javascript qui ne font pas le quart de ce que font les logiciels dont j'ai besoin.
Ou alors tu m'expliques comment le cloud répond à mon problème pour les trois applications déjà proposées en exemple: bash, openbox, firefox.
[^] # Re: systemd
Posté par Sygne (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 2.
Tu as mille fois raison, « maîtriser » était de trop dans ma phrase.
Mais je ne dis pas que le shell c'est bien parce que tout le monde comprend, je dis surtout que c'est parce que c'est l'outil par défaut qu'on apprend à le connaître. C'est le fait d'utiliser l'outil par défaut pour les scripts du système de base qui me semble pertinent.
On pourrait préférer avoir un autre outil par défaut, mais là n'est pas la question. On pourrait aussi considérer que l'idée d'un outil par défaut n'est pas bonne – là est peut-être la question.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 2.
Depuis la version 5, ltsp utilise simplement ssh -x.
D'après ce que j'ai pu comprendre, le fonctionnement de ltsp est finalement très standardisé: boot PXE, montage du système de fichier via nfs, puis ssh -x (ou simplement startx pour les clients lourds). Le système de fichier du client, s'il diffère de celui du serveur, est peuplé via un chroot sur le serveur, et en utilisant le gestionnaire de paquet de la distribution. Enfin, chaque client peut configurer /etc/ avec les fichiers qui lui sont propres.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 2.
Effectivement, ça a dû beaucoup évoluer depuis 2002.
Grâce au mot clé lstp, j'ai pu trouver un simili équivalent pour netbsd. Tout ça me semble très bon…
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 2.
Merci, LTSP a l'air d'être exactement ce que je cherche. Tu l'as utilisé un peu ? Tu en penses quoi ?
[^] # Re: Cloud
Posté par Sygne (site web personnel) . En réponse au message Architecture terminal / unité centrale aujourd'hui. Évalué à 4.
« L'utilisation de clients lourd pour accéder à ses données mises en réseau en échange de leur exploitation commerciale et politique. »
J'ai gagné quelque chose ?
Au cas où ce n'était pas une blague, je rappelle que ce ne sont pas seulement les données mais aussi les utilitaires que j'entends mettre sur serveur. Si tu m'expliques comment le cloud répond à mon problème pour les trois exécutables indispensables que sont bash, openbox, et firefox, je suis prêt à y réfléchir.
[^] # Re: systemd
Posté par Sygne (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 10.
Un paté de shell ça vaut un paté de python, de C, ou de n'importe quoi d'autre, je ne vois pas le problème. La fonction ici implémentée en [a]sh peut être implémentée ailleurs et autrement, il n'en reste pas moins qu'il faut l'implémenter quelque part: si ce n'est pas dans ce script, ce peut-être directement dans le logiciel d'init ou par ajout d'une option à la commande qui va bien, mais, je le répète, ça doit bien être implémenté quelque part.
L'intérêt du shell, à mon avis, c'est que c'est le langage par défaut d'administration de la machine, et celui qu'on trouve par défaut en console. On y est confronté à un moment ou un autre, et normalement, on apprend à le connaître et à le maîtriser. C'est, pour l'utilisateur final, une certaine garantie quant à la possibilité de toucher à son init.
Et de fait, lorsqu'on veut faire quelque chose qui sort des clous, le plus simple reste d'écrire un script shell. Je crois que même avec systemD, dans certains cas particulier, l'administrateur n'a pas d'autre choix que d'écrire un script shell qui va bien.
Pour ma part, j'ai souvent du modifier l'init réseau pour qu'il gère correctement ma configuration du wifi. Peu à peu, la procédure s'est normalisée, et maintenant ces hacks ne sont plus nécessaires. Mais j'imagine qu'il y aura toujours des situations où ce qu'ont prévu les développeurs d'init et les distributions ne correspond pas à une situation particulière.
[^] # Re: Youpi !
Posté par Sygne (site web personnel) . En réponse à la dépêche DragonFly BSD 3.6. Évalué à 5.
Puisque j'ai du chercher de quoi on parlait:
- pkgsrc est l'hisotrique gestionnaire de paquets des bsd.
- pkgin est un gestionnaire moderne, créé par Imil pour NetBSD, et reposant sur le format et les outils de pkgsrc.
- pkgng est un gestionnaire moderne, créé par bapt pour FreeBSD, ayant son propre format de paquet, et totalement indépendant de pkgsrc.
Du coup, je m'interroge sur l'avenir de pkgin: ne risque-t-il pas d'être très isolé? NetBSD n'aurait-il pas intérêt à préférer pkgng à pkgin?
[^] # Re: Exovis
Posté par Sygne (site web personnel) . En réponse à la dépêche Comment les idées du mouvement Open-source peuvent aider à étudier les exoplanètes. Évalué à 5.
Ah oui, effectivement.
Je vais néanmoins écrire un petit mail au créateur d'exovis pour lui proposer de rajouter quelques liens à son site. Ne serai-ce que sur wikipédia, il y a plein d'informations sur les étoiles, et les planètes: par exemple Kepler-62, Kepler-62b, Kepler-62c, Kepler-62d, Kepler-62e, Kepler-62f.
# Exovis
Posté par Sygne (site web personnel) . En réponse à la dépêche Comment les idées du mouvement Open-source peuvent aider à étudier les exoplanètes. Évalué à 4.
En visitant le site exovis, où l'on découvre la forme des systèmes solaires, je me suis pris à imaginer à quoi pouvait ressembler les planètes, puis j'ai été pris de vertige face à l'immensité de certains systèmes, et au final, c'est comme si j'avais lu un bon roman de science fiction. C'est un beau site (si ce n'est qu'il ne manque de faire exploser mon ordinateur).
Mais que c'est pauvre en information. Il n'y a vraiment rien sur les dites planètes, ni d'ailleurs sur les étoiles autour desquelles elles tournent. J'imagine que des suppositions sur leurs masses, voire leurs structures font l'objet d'articles et de batailles scientifiques, et qu'en cherchant bien dans le net, je finirais par trouver quelques petites informations plus précises, mais je regrette que le site ne soit pas plus bavard.