As-tu déjà utilisé quelque chose comme virtualenv en python, bundler en ruby, cabal (avec les sandbox) en haskell ou encore bien d’autres pour d’autres langages ? Ils permettent entre autre tous de définir, pour chaque projet, l’ensemble des dépendances dont tu as besoin, et ce, de manière indépendante d’un projet à l’autre. Pour chaque projet, tu peux ainsi générer un environnement correspondant à la définition voulue.
C’est particulièrement utile si tu as de projets qui utilisent une même dépendance dans des versions différentes, ou si tu as une version de maintenance d’un projet qui utilise une librairie dans une version donnée, et la version HEAD qui nécessite une version plus récente. Tu n’a pas à installer et ré-installer la librairie dans une version et une autre en permanence quand tu bascules d’un projet à l’autre.
Outre le fait que chaque utilisateur peut effectivement installer ses propres paquets, nix est une solution qui permet de faire exactement ça, mais de manière totalement agnostique du langage de programmation que tu utilises. Qui n’a jamais eu de problème parce que une librairie python / ruby / … nécessite une librairie C ? Le gestionnaire de paquet associé à ton langage gère pas son installation, il suppose qu’elle est là quelque part. Du coup il n’est d’aucun secours pour gérer les éventuelles questions de version de celle-ci.
C’est de mon point de vue (de dev) le plus gros intérêt que tu pourrais avoir à utiliser nix sur une distribution autre (en plus du fait que chaque utilisateur peut éventuellement installer ce dont il a besoin sans avoir la main sur l’admin du système global).
Pour les paquets, nix dispose des « recettes » de compilation / installation. Il récupère les sources là où le mainteneur lui dit de les récupérer (généralement les dépôts upstream) et compile. Pour gagner du temps, il y a un cache binaire disponible qui permet de récupérer un paquet pré-compilé si celui-ci a déjà été généré par le serveur d’intégration continue (https://hydra.nixos.org/), mais rien de grave si le paquet est absent (typiquement, si c’est un paquet bien à toi, pas géré par nixpkgs).
Enfin, nix ne remplacera pas apt/dnf, à moins de passer complètement à nixos. nix vit à côté sons gêner le gestionnaire de paquet présent, et sans que le gestionnaire ne vienne gêner nix (tout ce que nix installe est sous /nix, donc pas de conflit avec les sytèmes « classiques »).
J’espère avoir répondu à tes questions (même si j’ai plus d’un point de vue de dev que d’utilisateur « lambda »).
Tout d’abord, merci pour cette dépêche très bien construite et qui me fait regretter de ne pas utiliser plus ce langage.
Il y a une typo dans les imports, c’est Options.Generic, non Option.Gereric (notez le s).
Ensuite, la signature de la fonction forkPhilosopher ne correspond pas à ce que fait la fonction. Le type de forkIO est IO () -> IO ThreadId et non IO () -> IO (). La signature de forkPhilosopher doit donc être la suivante:
En général, ce qui est favorisé est que le service NixOS expose des options qui sont exprimables dans le langage de Nix pour avoir une configuration déclarative.
Ce qui se passe derrière, c’est que le fichier de configuration « réel » est généré en fonction de ce qui a été déclaré dans le DSL nix. Il est tout à fait possible que des options ne soient pas accessibles via le DSL nix. En général, les mainteneurs exposent les principales configurations via des attributs nix, et pour le reste il y a souvent un attribut « fourre tout » qui va contenir un blob de texte qui va être inséré direct dans le fichier de conf généré.
Pour openssh, ce paramètre magique est services.openssh.extraConfig.
On peut donc facilement avoir une déclaration comme ça :
services.openssh = {
enable = true;
ports = [ 44 ];
extraConfig = ''
Match User linuxfr
ChrootDirectory /home/linuxfr
AllowTCPForwarding no
ForceCommand internal-sftp
'';
};
Pour ce qui est de la localisation des fichiers de config, autant que faire ce peut, elles ne sont pas dans /etc. Les configurations sont un résultat d’après la config de l’utilisateur, et sont donc rangées avec tous les résultats, dans /nix/store. Dans la majorité des cas, les scripts de lancement des services (ici l’unit systemd) va lancer openssh en lui spécifiant où trouver le fichier de configuration :
Il est également possible de regarder http://nixos.org/nixos/options.html pour trouver les options disponibles. C’est en général plus rapide de regarder là que dans la source du service.
Au « pire », le lecteur curieux essayant avec la configuration de la dépêche aura un message l’invitant à renommer kde5 en plasma5, donc rien de bien méchant ;)
Pour python, chaque paquet/librairie est installé dans un préfix qui lui est propre. Cependant, nous avons tous les mécanismes en place pour pouvoir composer ces différents paquets.
Une appli packagée (installée sous un préfix qui lui est propre) charge ses dépendances là où elles sont. Pour ça les applis sont patchées à l’installation. Par exemple, voici ce que ça donne pour poezio (seules les premières lignes sont propres à nix, les suivantes viennent de poezio) :
Ça a l’air un peu barbare, mais si on regarde tranquillement, ça nous donne (entre autre*) :
l’interpréteur (exact) à utiliser en première ligne
l’ensemble des chemins où les différentes dépendances se trouvent
Dans les gros avantages à cela, on trouve une réelle facilité à faire co-éxister différents interpréteurs et différentes librairies sans que l’ajout de l’un ou l’autre (ni sa mise à jours d’ailleurs) ne vienne perturber une appli que est installée et qui tourne telle qu’elle est.
Par rapport à un venv « classique » à la python où tu installes toutes tes dépendances dans un même prefix (ce qui peut être fais si vraiment on le souhaite), l’approche nix a l’avantage que les composants sons ré-utilsables d’un contexte à un autre. Qui a déjà du monter, et remonter des venvs avec numpy / scipy comprendra très vite l’intérêt de ne pas avoir à refaire une install (et donc une compilation des modules natifs) des différents composants…
Le second très grand avantage de nix par rapport à un venv se fait sentir quand on ne fais pas que du pure python, mais qu’on va avoir des environnements utilisant des composants non gérés par pip.
* Le script python réel nommé .poezio-wrapped est en fait appelé par un wrapper poezio utilisé pour mettre en place différentes variables d’environnement (dont PATH afin de pouvoir gérer les dépendances éventuelles vers des applis / outils devant être accessible à poezio)
La conf sera-t-elle enregistrée ? Je ne pourrai pas être là, mais étant un utilisateur ravi de NixOs, je suis intéressé de savoir ce que deviens la distro cousine qu’est Guix.
Posté par lancelotsix .
En réponse à la dépêche Sortie de poezio 0.9.
Évalué à 4.
Dernière modification le 03 août 2015 à 17:31.
Merci pour la news.
poezio-0.9 est d’ailleurs maintenant dispo dans la branche master de NixPkgs (la base de « paquets » de NixOs), et devrait rapidement rejoindre unstable. Et oui, même pas peur de python-3.4 !
Bonne question, mais j'aurais tendance à dire qu'avec moi ça fait une de plus, et j'ai pas mal de monde dans mon entourage dans ce cas _^
Bon après, je suis d'accord que la composition de mon entourage n'est pas totalement indépendante de mes choix / modes de vie. Du coup ça biaise un peu ce que je peux voir de mon point de vue.
avec un projet de laptop entièrement libre (pas de blob firmware, etc)
Disons un projet qui vise à être entièrement libre. Ce n'est pas encore totalement gagné. Quelques extraits:
While the BIOS is not yet free, the Librem 15 will be the first laptop ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS code, allowing for a future where free software can replace the proprietary, digitally signed BIOS binaries. This marks one of the largest hurdles to a laptop that runs 100% free software and firmware
…
There are also hardware components, like the HD or SSD, that are flashable, and therefore upgradeable, but that currently run firmware that is not yet freed
Ceci dit, l'objectif est plus que louable et je suis ravis que certains essayent (c'est un pré-requis pour y arriver).
The 1080p screen is confirmed as matte. The 4k screen is very likely also going to be matte, if we can confirm our source supplier provides matte we will be shipping matte for all screens.
Donc pour l'écran 4k, on n'en sait encore rien mais pour le "normal", c'est mat.
Pour le prix : oui ça pique… C'est le moins qu'on puisse dire. Mais au moins, même s'il reste pour l'instant limité à $400000, ils montrent qu'il y a un marché pour du matériel 'libéré'. Si ça deviens une demande des utilisateurs finaux, ça jouera sur les prix. Tant que tout le monde s'en cogne, ça restera un marché de niche et demandera énormément d'efforts pour de petites quantités, d'où le prix.
Enfin, et non des moindre, du (vieux) thinkpad conditionné et totalement libéré (du BIOS à l'OS), ça existe. C'est même une des rares machines à avoir obtenu la certification RYF de la FSF (ce qui n'est pas le cas du Librem15 pour l'instant).
Bon, j'ai oublié de le mentionner certaines choses ^
Certains composants du BIOS ne sont pas libres et dépendent d'intel (c.f ici)
Though the bootloader, Linux kernel, GNU OS, and all software applications are completely free/libre software without any binary blobs, the BIOS does use coreboot, which includes a binary from Intel, called FSP
Pour l'instant, probablement pas de clavier AZERTY
We’d love to offer other keyboards (EU, French, German, etc.), but probably cannot at this time due to the high minimum order quantity needed to justify the high tooling costs for each new keyboard
Dans les outils assez similaires à github, on a aussi gitorious, qui a l'avantage d'être publié sous AGPL. Je dois avouer que je ne l'ai jamais déployé, et je suppose que c'est plus ou moins aussi gourmand que gitlab en resources. Je ne l'ai utilisé que de manière très superficielle, mais en gros ça fait le taf.
Sinon, pour revenir sur la question posée, pour ce qui est des projets auto-hébergés, j'utilise gitolite. On n'a pas d'interface graphique (à moins de déployer un gitweb). Ça se limite à gérer les droits d'accès mais dans mon cas c'est suffisant (je conçoit qu'on ait besoin de plus). Il faut dire que je collabore essentiellement avec moi même pour les projets hébergés à la maison… ;)
Pour la question des fichiers un peu trop volumineux pour ta connection, tu peux utiliser le fait que git est décentralisé. Un dépot "principal" à la maison sur lequel tu travailles, et un clone chez gitorious ou github pour «déporter la charge». C'est en gros ce que fait Qt.
Je ne suis plus certain. Une dérivée de dérivée d'Ubuntu je crois. Basé sur voyager si ma mémoire n'est pas trop défaillante.
Parce qu'il me semble que lors d'une installation d'Ubuntu l'installer te demande si tu veux installer ce genre de package (libdvdcss, mpg123, etc…) ? Me gourré-je ?
Ça fait bien longtemps que je n'ai pas installé d'Ubuntu, mais de tête non. Justement à cause de problèmes de risques juridiques. Selon l'article sur la libdvdcss :
Many GNU/Linux distributions do not contain libdvdcss (for example Debian, Fedora, SUSE Linux, and Ubuntu) due to fears of running afoul of DMCA-style laws, however they may provide the tools to let the user install it themselves. For example, it used to be available in Ubuntu through Medibuntu, which is no longer available.
Le problème n'est pas neuf. Je me souviens qu'à l'époque de mes débuts (sur mandraque), exactement le même problème existait. Il fallait avoir recours aux miroirs de Penguin_Liberation_Front pour pouvoir installer la lib. Et encore une fois, ce problème qui a mis de épines dans les pieds à pas mal est un problème de droit. Un problème similaire se pose d'ailleurs encore pour la lecture des blu-ray (c.f. les recours de l'asso videolan pour savoir si ils pouvaient intégrer ou non les algos permettant de lire les contenus dans leur logiciel libre).
je pense qu'il doit y avoir un poil de mauvaise volonté tout de même
C'est certain. Le problème de libdvdcss a fait dire que comme avant, il faut tout se fader à la main (ce qui est bien entendu faux). Ça plus le syndrome du «ça marche po pareil» ou du «mon soft couteau suisse que j'utilise depuis xxx années est super mal porté, c'est quoi que cte #####» (oui, mais il y a des alternatives mieu intégrées, au prix de quelques changements d'habitudes) ont fini par le décourager. Les vielles habitudes ont la vie dure. Et c'est pas faute d'avoir proposé / apporté du support.
Après, chacun est libre de ne pas l'être. J'explique de quoi il est question quand on parle de logiciels libres, pourquoi j'ai fait le choix d'utiliser ces logiciels plutôt que d'autres, mais je ne force personne ;)
Parce que sous Windows (c'est de moins en moins vrai je sais) des trucs à installer après l'installation de l'OS il y en a plus d'un…
Oui, mais après plus de 10 ans à ré-installer son XP au moins plus d'une fois par an, n'importe qui intègre la procédure :p C'est d'ailleurs ce qui a été fait dans le cas sus-cité.
La dernière personne de mon entourage qui a voulu ré-essayé de passer sous GNU/Linux après n'avoir pas pas réussi à accrocher il y a quelques années a tout de suite décroché. Pourquoi ? Parce que «out of the box» il ne pouvait pas lire un DVD. Il devait aller suivre des tutos demandant d'ouvrir un terminal pour installer la libdvdcss, et la il a dit «non pas encore, en fait ça ne s'est pas arrangé depuis la dernière fois que j'ai essayé il y a 10 ans.». Et il a lâché l'affaire.
Un problème de barbu qui ne font que des trucs pas in-utilisable ? Non, pas vraiment. Seulement des problèmes légaux.
OK, c'est un micro problème, mais ce n'est pas la première fois que je vois des gens qui prennent peur à cause de ça. Donc oui, beaucoup d'outils ne sont pas suffisamment «user friendly», mais ce n'est pas [toujours] du à une mauvaise volonté.
Thème très intéressant ! Malheureusement je ne pourrais y assister. Est-ce que par chance il est prévu que les interventions soient enregistrées et re-diffusées ?
C'est une façon de répondre à la contrainte. C a cet avantage que les concepts qu'il manipule (proches de la machine) forment un bon «dénominateur commun» à bon nombre de langages. Si on cherche à développer quelque chose de facilement réutilisable dans de nombreux langages, il semble assez pertinent de se limiter à ces concepts.
Ceci étant dit, et étant donné que beaucoup de langages s'interfacent facilement avec le C, je suppose qu'il est également possible de faire le contraire. Écrire la librairie dans son langage qu'on aime bien et qui est trop fort de la mort qui tue, prévoir une interface se limitant aux concepts simplement manipulables en C et ensuite écrire un binding en C.
Je cherche un exemple percutant où ça aurait été fait, mais je n'en ai pas qui me vienne à l'esprit :( Est-ce que quelqu'un a un exemple qui ait utilisé ce genre d'artifice ?
Je ne sais pas encore, mais dès que j'ai réussi à trouver pour moi je te dis ;)
Comme ça a été mentionné, Ada est assez cantonné à des domaines particuliers (embarqué / temps réel / critique) qui peuvent demander de justifier du bon «background» et d'une expérience différente de celle nécessaire à du web.
Donc je résume vos propos :
1) Ada c'est mieux que le C pour l'aspect langage de haut niveau
Ada est plus adapté que le C pour faire du haut niveau (il est d'ailleurs fait pour ça). «Mieux» est un mot un peu fort, c'est très subjectif…
2) Ada permet quand même de faire du bas niveau.
3) Le compilateur est plus exigeant
C'est un doux euphémisme
4) On ne peut pas dépasser les bornes d'un tableau par exemple (pas de dépassement de tampon possible?)
Non. Tout comme en Java d'ailleurs (c.f. le procès entre google et oracle sur la vérification du fait qu'un indice est dans les bornes)
5) Les gardes fous d'ADA sont un atout significatifs dans le sens où un développeur un peu distrait n'aura pas de soucis
Oh si il en aura, mais avec le compilo ;) Le grand intérêt est que (hormis cas vraiment extrême), si le programme passe les vérifications du compilateur et ne fait pas ce qu'on attend de lui, c'est que l'erreur est dans la logique du code et pas dans sa traduction dans le langage.
Ma question étant sur java, le code compilé peut-il fonctionner en multitâche sans problème ?
Le code ada compilé fonctionne en multitache sans problème, c'est même un prérequis. Bien sur, ça demande un minimum «glue», qui a pour mission de faire le lien entre les abstractions du langage et les primitives fournies par le système cible. Mais ça c'est le taf du compilo, pas celui du développeur.
Par exemple, intel a créé un compilateur pour la programmation parallèle pour le langage C/C++.
Comparativement à java ce serait comment ADA et si vous pouvez y répondre comparativement aux possibilités du compilateur d'intel, ca s'en rapproche ?
Ne connaissant pas ce compilateur ni ses possibilités, je ne peux pas répondre.
2) Le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.
…
4) Le langage assembleur est très lié au matériel, donc votre remarque n'est pas pertinent sur le sujet.
C'est parce qu'il a une vocation différente qu'il est toujours délicat de le comparer à ADA. C est pensé comme un assembleur portable. De son côté, Ada est un langage de haut niveau permettant énormément d'abstractions impossibles en C (les enums sont plus que des entiers, les tableaux sont plus qu'un pointeur vers le premier élément, la sémantique du multi-tache construite dans le langage et bien d'autres encore…).
Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux.
Quoi qu'il en soit, par philosophie le C est permissif et pré-suppose que le développeur sait exactement ce qu'il fait. Il laisse faire même si parfois c'est une erreur évidente. C'est d'ailleurs (en partie) source de failles de sécurités en tout type (genre cela). De son côté Ada empêche tant que faire se peu que le développeur fasse des choses «risquées» (genre écrire en dehors des bornes d'un tableau), est parfois verbeux pour éviter tout ambiguïté, et dispose de compilateurs pointilleux.
Bien sur, une discipline importante permet de faire du C très propre et fiable, et bon nombre de systèmes extrêmement robustes en sont la preuve indiscutable. Cependant, il peut être intéressant de placer des garde fous au niveau du langage en plus de ceux permettant de faire du bon C.
En ce qui me concerne je considère que c'est un atout significatif.
5) J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.
Dans les grandes lignes : Ada est compilé nativement alors que Java nécessite un VM. Il est ainsi plus aisé de faire du bas niveau en Ada qu'en Java (constructions permettant d'être très précis sur la représentation machine des objets utilisés, on peu faire comme en C et accéder directement à la mémoire si vraiment on en a besoin, …). Après Java a d'autres avantages, dont notamment la capacité de faire de l'introspection ce qui n'est pas envisageable en Ada.
Il est en général plus intéressant de comparer Ada à C++ car ils se ressemblent plus sur ces aspects (et bien d'autres).
Bon, j'avoue que je prêche un peu pour ma paroisse, mais sachez que je ne dénigre pas le reste pour autant ! L'ensemble des langages disponibles offrent une diversité très profitable, surtout si on regarde ce qui se fait chez les voisins. Ça donne de bonnes idées et permet d’acquérir de bonnes pratiques parfois.
[^] # Re: Nix (le gestionnaire) sur d'autres distros.
Posté par lancelotsix . En réponse au journal le "style fonctionnel" en vidéos (Nix, NixOS, Haskell). Évalué à 8.
As-tu déjà utilisé quelque chose comme
virtualenven python,bundleren ruby,cabal(avec les sandbox) en haskell ou encore bien d’autres pour d’autres langages ? Ils permettent entre autre tous de définir, pour chaque projet, l’ensemble des dépendances dont tu as besoin, et ce, de manière indépendante d’un projet à l’autre. Pour chaque projet, tu peux ainsi générer un environnement correspondant à la définition voulue.C’est particulièrement utile si tu as de projets qui utilisent une même dépendance dans des versions différentes, ou si tu as une version de maintenance d’un projet qui utilise une librairie dans une version donnée, et la version HEAD qui nécessite une version plus récente. Tu n’a pas à installer et ré-installer la librairie dans une version et une autre en permanence quand tu bascules d’un projet à l’autre.
Outre le fait que chaque utilisateur peut effectivement installer ses propres paquets, nix est une solution qui permet de faire exactement ça, mais de manière totalement agnostique du langage de programmation que tu utilises. Qui n’a jamais eu de problème parce que une librairie python / ruby / … nécessite une librairie C ? Le gestionnaire de paquet associé à ton langage gère pas son installation, il suppose qu’elle est là quelque part. Du coup il n’est d’aucun secours pour gérer les éventuelles questions de version de celle-ci.
C’est de mon point de vue (de dev) le plus gros intérêt que tu pourrais avoir à utiliser nix sur une distribution autre (en plus du fait que chaque utilisateur peut éventuellement installer ce dont il a besoin sans avoir la main sur l’admin du système global).
Pour les paquets, nix dispose des « recettes » de compilation / installation. Il récupère les sources là où le mainteneur lui dit de les récupérer (généralement les dépôts upstream) et compile. Pour gagner du temps, il y a un cache binaire disponible qui permet de récupérer un paquet pré-compilé si celui-ci a déjà été généré par le serveur d’intégration continue (https://hydra.nixos.org/), mais rien de grave si le paquet est absent (typiquement, si c’est un paquet bien à toi, pas géré par nixpkgs).
Enfin, nix ne remplacera pas apt/dnf, à moins de passer complètement à nixos. nix vit à côté sons gêner le gestionnaire de paquet présent, et sans que le gestionnaire ne vienne gêner nix (tout ce que nix installe est sous
/nix, donc pas de conflit avec les sytèmes « classiques »).J’espère avoir répondu à tes questions (même si j’ai plus d’un point de vue de dev que d’utilisateur « lambda »).
# Quelques erreurs (mineures) dans le programme des philosophes
Posté par lancelotsix . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 4.
Tout d’abord, merci pour cette dépêche très bien construite et qui me fait regretter de ne pas utiliser plus ce langage.
Il y a une typo dans les imports, c’est
Options.Generic, nonOption.Gereric(notez le s).Ensuite, la signature de la fonction
forkPhilosopherne correspond pas à ce que fait la fonction. Le type deforkIOestIO () -> IO ThreadIdet nonIO () -> IO (). La signature deforkPhilosopherdoit donc être la suivante:Pour que ceci fonctionne, il faut également importer
ThreadIddepuisControl.Concurrent:Une fois ces petite ajustements faits, ça marche très bien !
[^] # Re: configuration
Posté par lancelotsix . En réponse à la dépêche L’heure du test — épisode 1 — NixOS. Évalué à 4.
Très bonne question ;)
En général, ce qui est favorisé est que le service NixOS expose des options qui sont exprimables dans le langage de Nix pour avoir une configuration déclarative.
Ce qui se passe derrière, c’est que le fichier de configuration « réel » est généré en fonction de ce qui a été déclaré dans le DSL nix. Il est tout à fait possible que des options ne soient pas accessibles via le DSL nix. En général, les mainteneurs exposent les principales configurations via des attributs nix, et pour le reste il y a souvent un attribut « fourre tout » qui va contenir un blob de texte qui va être inséré direct dans le fichier de conf généré.
Pour openssh, ce paramètre magique est
services.openssh.extraConfig.On peut donc facilement avoir une déclaration comme ça :
Pour ce qui est de la localisation des fichiers de config, autant que faire ce peut, elles ne sont pas dans
/etc. Les configurations sont un résultat d’après la config de l’utilisateur, et sont donc rangées avec tous les résultats, dans/nix/store. Dans la majorité des cas, les scripts de lancement des services (ici l’unit systemd) va lancer openssh en lui spécifiant où trouver le fichier de configuration :Bien sur,
sshd.serviceest également généré via nix, il est donc lui-même dans/nix/store:C’est ce mécanisme qui fait qu’il est simple de passer d’une config / version à l’autre « juste » en mettant à jours un lien symbolique.
[^] # Re: configuration
Posté par lancelotsix . En réponse à la dépêche L’heure du test — épisode 1 — NixOS. Évalué à 3.
Il est également possible de regarder http://nixos.org/nixos/options.html pour trouver les options disponibles. C’est en général plus rapide de regarder là que dans la source du service.
Par exemple pour openssh, http://nixos.org/nixos/options.html#services.openssh donnera toutes les options utiles.
# Une configuration non à jours
Posté par lancelotsix . En réponse à la dépêche L’heure du test — épisode 1 — NixOS. Évalué à 3.
Bonjour,
Je me permet de signaler un changement récent qui est intervenu dans la dernière release (
17.03).Pour activer KDE5, il ne faut plus utiliser
comme indiqué dans la dépêche, mais
Au « pire », le lecteur curieux essayant avec la configuration de la dépêche aura un message l’invitant à renommer
kde5enplasma5, donc rien de bien méchant ;)[^] # Re: Python
Posté par lancelotsix . En réponse à la dépêche NixOS, collection printemps‐été 17. Évalué à 2.
Pour python, chaque paquet/librairie est installé dans un préfix qui lui est propre. Cependant, nous avons tous les mécanismes en place pour pouvoir composer ces différents paquets.
Une appli packagée (installée sous un préfix qui lui est propre) charge ses dépendances là où elles sont. Pour ça les applis sont patchées à l’installation. Par exemple, voici ce que ça donne pour
poezio(seules les premières lignes sont propres à nix, les suivantes viennent depoezio) :Ça a l’air un peu barbare, mais si on regarde tranquillement, ça nous donne (entre autre*) :
Dans les gros avantages à cela, on trouve une réelle facilité à faire co-éxister différents interpréteurs et différentes librairies sans que l’ajout de l’un ou l’autre (ni sa mise à jours d’ailleurs) ne vienne perturber une appli que est installée et qui tourne telle qu’elle est.
Par rapport à un venv « classique » à la python où tu installes toutes tes dépendances dans un même prefix (ce qui peut être fais si vraiment on le souhaite), l’approche nix a l’avantage que les composants sons ré-utilsables d’un contexte à un autre. Qui a déjà du monter, et remonter des venvs avec
numpy/scipycomprendra très vite l’intérêt de ne pas avoir à refaire une install (et donc une compilation des modules natifs) des différents composants…Le second très grand avantage de nix par rapport à un venv se fait sentir quand on ne fais pas que du pure python, mais qu’on va avoir des environnements utilisant des composants non gérés par
pip.* Le script python réel nommé
.poezio-wrappedest en fait appelé par un wrapperpoezioutilisé pour mettre en place différentes variables d’environnement (dontPATHafin de pouvoir gérer les dépendances éventuelles vers des applis / outils devant être accessible àpoezio)# Enregistrement de la conf prévu ?
Posté par lancelotsix . En réponse à la dépêche Conf/démo: GNU Guix et déploiement logiciel, le lundi 9 novembre 2015 à 19h à Rennes. Évalué à 2.
Très bonne nouvelle.
La conf sera-t-elle enregistrée ? Je ne pourrai pas être là, mais étant un utilisateur ravi de NixOs, je suis intéressé de savoir ce que deviens la distro cousine qu’est Guix.
# NixOs
Posté par lancelotsix . En réponse à la dépêche Sortie de poezio 0.9. Évalué à 4. Dernière modification le 03 août 2015 à 17:31.
Merci pour la news.
poezio-0.9est d’ailleurs maintenant dispo dans la branche master de NixPkgs (la base de « paquets » de NixOs), et devrait rapidement rejoindreunstable. Et oui, même pas peur depython-3.4![^] # Re: Qui sont les bénéficiaires ?
Posté par lancelotsix . En réponse au journal Redevance Radio France. Évalué à 8.
Je retrouve ça (cgt-radiofrance) qui référence le site mentionné dans le journal.
Sinon une publication sur le site de l'huma donne les coordonnées pour faire un donc par voie postale.
Et je suis d'accord que publier l'appel au don initial permet de ne pas se poser la question de la légitimité de la page payname.
[^] # Re: Redevance radio
Posté par lancelotsix . En réponse au journal Redevance Radio France. Évalué à 6.
Bonne question, mais j'aurais tendance à dire qu'avec moi ça fait une de plus, et j'ai pas mal de monde dans mon entourage dans ce cas _^
Bon après, je suis d'accord que la composition de mon entourage n'est pas totalement indépendante de mes choix / modes de vie. Du coup ça biaise un peu ce que je peux voir de mon point de vue.
[^] # Re: Les Olinuxino ne sont pas libres ?
Posté par lancelotsix . En réponse à la page de wiki ordinateurs-libres. Évalué à 1 (+0/-0).
A cause d'une erreur ! (corrigée)
[^] # Re: Purism
Posté par lancelotsix . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 6.
Disons un projet qui vise à être entièrement libre. Ce n'est pas encore totalement gagné. Quelques extraits:
Ceci dit, l'objectif est plus que louable et je suis ravis que certains essayent (c'est un pré-requis pour y arriver).
L'info est (partiellement) disponible ici:
Donc pour l'écran 4k, on n'en sait encore rien mais pour le "normal", c'est mat.
Pour le prix : oui ça pique… C'est le moins qu'on puisse dire. Mais au moins, même s'il reste pour l'instant limité à $400000, ils montrent qu'il y a un marché pour du matériel 'libéré'. Si ça deviens une demande des utilisateurs finaux, ça jouera sur les prix. Tant que tout le monde s'en cogne, ça restera un marché de niche et demandera énormément d'efforts pour de petites quantités, d'où le prix.
Enfin, et non des moindre, du (vieux) thinkpad conditionné et totalement libéré (du BIOS à l'OS), ça existe. C'est même une des rares machines à avoir obtenu la certification RYF de la FSF (ce qui n'est pas le cas du Librem15 pour l'instant).
[^] # Re: Profitons de l'occasion :)
Posté par lancelotsix . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 2.
Salut
Une personne a abordé le sujet à «Pas Sage en Seine» 2014. La conférence est visible en deux parties ici et là (problème d'enregistrement je pense ).
# Les quelques oublis
Posté par lancelotsix . En réponse au journal Une campagne de Crowdfunding promet un portable utilisable avec du 100% libre. Évalué à 3.
Bon, j'ai oublié de le mentionner certaines choses ^
# gitorious
Posté par lancelotsix . En réponse au journal GitLab, mais encore ?. Évalué à 8.
Dans les outils assez similaires à github, on a aussi gitorious, qui a l'avantage d'être publié sous AGPL. Je dois avouer que je ne l'ai jamais déployé, et je suppose que c'est plus ou moins aussi gourmand que gitlab en resources. Je ne l'ai utilisé que de manière très superficielle, mais en gros ça fait le taf.
Sinon, pour revenir sur la question posée, pour ce qui est des projets auto-hébergés, j'utilise gitolite. On n'a pas d'interface graphique (à moins de déployer un gitweb). Ça se limite à gérer les droits d'accès mais dans mon cas c'est suffisant (je conçoit qu'on ait besoin de plus). Il faut dire que je collabore essentiellement avec moi même pour les projets hébergés à la maison… ;)
Pour la question des fichiers un peu trop volumineux pour ta connection, tu peux utiliser le fait que git est décentralisé. Un dépot "principal" à la maison sur lequel tu travailles, et un clone chez gitorious ou github pour «déporter la charge». C'est en gros ce que fait Qt.
[^] # Re: le goût et les couleurs
Posté par lancelotsix . En réponse au journal "beauté du code". Évalué à 3.
Tu parles de ça ?
[^] # Re: Linux est-il prêt pour le desktop ? Je passe le prendre à quelle heure ?
Posté par lancelotsix . En réponse au journal C'est vendredi, c'est trolldi, c'est permis : l'open source n'est pas secure. Évalué à 0.
Je ne suis plus certain. Une dérivée de dérivée d'Ubuntu je crois. Basé sur voyager si ma mémoire n'est pas trop défaillante.
Ça fait bien longtemps que je n'ai pas installé d'Ubuntu, mais de tête non. Justement à cause de problèmes de risques juridiques. Selon l'article sur la libdvdcss :
Le problème n'est pas neuf. Je me souviens qu'à l'époque de mes débuts (sur mandraque), exactement le même problème existait. Il fallait avoir recours aux miroirs de Penguin_Liberation_Front pour pouvoir installer la lib. Et encore une fois, ce problème qui a mis de épines dans les pieds à pas mal est un problème de droit. Un problème similaire se pose d'ailleurs encore pour la lecture des blu-ray (c.f. les recours de l'asso videolan pour savoir si ils pouvaient intégrer ou non les algos permettant de lire les contenus dans leur logiciel libre).
C'est certain. Le problème de libdvdcss a fait dire que comme avant, il faut tout se fader à la main (ce qui est bien entendu faux). Ça plus le syndrome du «ça marche po pareil» ou du «mon soft couteau suisse que j'utilise depuis xxx années est super mal porté, c'est quoi que cte #####» (oui, mais il y a des alternatives mieu intégrées, au prix de quelques changements d'habitudes) ont fini par le décourager. Les vielles habitudes ont la vie dure. Et c'est pas faute d'avoir proposé / apporté du support.
Après, chacun est libre de ne pas l'être. J'explique de quoi il est question quand on parle de logiciels libres, pourquoi j'ai fait le choix d'utiliser ces logiciels plutôt que d'autres, mais je ne force personne ;)
Oui, mais après plus de 10 ans à ré-installer son XP au moins plus d'une fois par an, n'importe qui intègre la procédure :p C'est d'ailleurs ce qui a été fait dans le cas sus-cité.
[^] # Re: Linux est-il prêt pour le desktop ? Je passe le prendre à quelle heure ?
Posté par lancelotsix . En réponse au journal C'est vendredi, c'est trolldi, c'est permis : l'open source n'est pas secure. Évalué à 1.
C'est en partie vrai, mais en partie seulement.
La dernière personne de mon entourage qui a voulu ré-essayé de passer sous GNU/Linux après n'avoir pas pas réussi à accrocher il y a quelques années a tout de suite décroché. Pourquoi ? Parce que «out of the box» il ne pouvait pas lire un DVD. Il devait aller suivre des tutos demandant d'ouvrir un terminal pour installer la libdvdcss, et la il a dit «non pas encore, en fait ça ne s'est pas arrangé depuis la dernière fois que j'ai essayé il y a 10 ans.». Et il a lâché l'affaire.
Un problème de barbu qui ne font que des trucs pas in-utilisable ? Non, pas vraiment. Seulement des problèmes légaux.
OK, c'est un micro problème, mais ce n'est pas la première fois que je vois des gens qui prennent peur à cause de ça. Donc oui, beaucoup d'outils ne sont pas suffisamment «user friendly», mais ce n'est pas [toujours] du à une mauvaise volonté.
# Conférence enregistrée ?
Posté par lancelotsix . En réponse à la dépêche Conférence "Technologies Open-Source pour les IHM embarquées" le 30 juin 2014 à Paris. Évalué à 3.
Thème très intéressant ! Malheureusement je ne pourrais y assister. Est-ce que par chance il est prévu que les interventions soient enregistrées et re-diffusées ?
# MovSim
Posté par lancelotsix . En réponse au message simulation de réseau routier. Évalué à 2.
Tu as une liste de simulateurs ici : http://en.wikipedia.org/wiki/Traffic_simulation#Microscopic (liste non exhaustive mais déjà conséquente). Parmi eux, Aimsun est une référence, mais comme la majorité il n'est pas libre…
Un bon projet académique et open-source est MovSim (http://movsim.org). Il devrait répondre à tes attentes.
Cdt
# La FSF cherche aussi
Posté par lancelotsix . En réponse au message Alternative à Skype, de pair à pair(s) et chiffré. Évalué à 1.
Salut
Je n'ai vraiment pas fait une revue pour savoir si ça existe ou pas, mais il semblerait que travailler sur une alternative libre à Skype fasse parti des projets prioritaires de la FSF : http://www.fsf.org/campaigns/priority-projects/free-software-replacement-for-skype
[^] # Re: Proust alors.
Posté par lancelotsix . En réponse au journal Ada, langage et ressources. Évalué à 1.
Oui.
C'est une façon de répondre à la contrainte. C a cet avantage que les concepts qu'il manipule (proches de la machine) forment un bon «dénominateur commun» à bon nombre de langages. Si on cherche à développer quelque chose de facilement réutilisable dans de nombreux langages, il semble assez pertinent de se limiter à ces concepts.
Ceci étant dit, et étant donné que beaucoup de langages s'interfacent facilement avec le C, je suppose qu'il est également possible de faire le contraire. Écrire la librairie dans son langage qu'on aime bien et qui est trop fort de la mort qui tue, prévoir une interface se limitant aux concepts simplement manipulables en C et ensuite écrire un binding en C.
Je cherche un exemple percutant où ça aurait été fait, mais je n'en ai pas qui me vienne à l'esprit :( Est-ce que quelqu'un a un exemple qui ait utilisé ce genre d'artifice ?
[^] # Re: où faire de l'ada
Posté par lancelotsix . En réponse au journal Ada, langage et ressources. Évalué à 1.
Je ne sais pas encore, mais dès que j'ai réussi à trouver pour moi je te dis ;)
Comme ça a été mentionné, Ada est assez cantonné à des domaines particuliers (embarqué / temps réel / critique) qui peuvent demander de justifier du bon «background» et d'une expérience différente de celle nécessaire à du web.
[^] # Re: Proust alors.
Posté par lancelotsix . En réponse au journal Ada, langage et ressources. Évalué à 2.
Ada est plus adapté que le C pour faire du haut niveau (il est d'ailleurs fait pour ça). «Mieux» est un mot un peu fort, c'est très subjectif…
C'est un doux euphémisme
Non. Tout comme en Java d'ailleurs (c.f. le procès entre google et oracle sur la vérification du fait qu'un indice est dans les bornes)
Oh si il en aura, mais avec le compilo ;) Le grand intérêt est que (hormis cas vraiment extrême), si le programme passe les vérifications du compilateur et ne fait pas ce qu'on attend de lui, c'est que l'erreur est dans la logique du code et pas dans sa traduction dans le langage.
Le code ada compilé fonctionne en multitache sans problème, c'est même un prérequis. Bien sur, ça demande un minimum «glue», qui a pour mission de faire le lien entre les abstractions du langage et les primitives fournies par le système cible. Mais ça c'est le taf du compilo, pas celui du développeur.
Ne connaissant pas ce compilateur ni ses possibilités, je ne peux pas répondre.
[^] # Re: Proust alors.
Posté par lancelotsix . En réponse au journal Ada, langage et ressources. Évalué à 6.
C'est parce qu'il a une vocation différente qu'il est toujours délicat de le comparer à ADA. C est pensé comme un assembleur portable. De son côté, Ada est un langage de haut niveau permettant énormément d'abstractions impossibles en C (les enums sont plus que des entiers, les tableaux sont plus qu'un pointeur vers le premier élément, la sémantique du multi-tache construite dans le langage et bien d'autres encore…).
Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux.
Quoi qu'il en soit, par philosophie le C est permissif et pré-suppose que le développeur sait exactement ce qu'il fait. Il laisse faire même si parfois c'est une erreur évidente. C'est d'ailleurs (en partie) source de failles de sécurités en tout type (genre cela). De son côté Ada empêche tant que faire se peu que le développeur fasse des choses «risquées» (genre écrire en dehors des bornes d'un tableau), est parfois verbeux pour éviter tout ambiguïté, et dispose de compilateurs pointilleux.
Bien sur, une discipline importante permet de faire du C très propre et fiable, et bon nombre de systèmes extrêmement robustes en sont la preuve indiscutable. Cependant, il peut être intéressant de placer des garde fous au niveau du langage en plus de ceux permettant de faire du bon C.
En ce qui me concerne je considère que c'est un atout significatif.
Dans les grandes lignes : Ada est compilé nativement alors que Java nécessite un VM. Il est ainsi plus aisé de faire du bas niveau en Ada qu'en Java (constructions permettant d'être très précis sur la représentation machine des objets utilisés, on peu faire comme en C et accéder directement à la mémoire si vraiment on en a besoin, …). Après Java a d'autres avantages, dont notamment la capacité de faire de l'introspection ce qui n'est pas envisageable en Ada.
Il est en général plus intéressant de comparer Ada à C++ car ils se ressemblent plus sur ces aspects (et bien d'autres).
Bon, j'avoue que je prêche un peu pour ma paroisse, mais sachez que je ne dénigre pas le reste pour autant ! L'ensemble des langages disponibles offrent une diversité très profitable, surtout si on regarde ce qui se fait chez les voisins. Ça donne de bonnes idées et permet d’acquérir de bonnes pratiques parfois.