freeze a écrit 207 commentaires

  • [^] # Re: pip, npm ?

    Posté par . En réponse à la dépêche Nix pour les développeurs. Évalué à 1.

    Certes dans ce cas, les overlays peuvent être une solution (utilisée par Mozilla concernant rust, afin de proposer les version stables, beta et nightlies très facilement). mais effectivement ça impose d'avoir un ou plusieurs overlays qui étendent ce comportement.

  • [^] # Re: pip, npm ?

    Posté par . En réponse à la dépêche Nix pour les développeurs. Évalué à 4.

    Hello,

    Pour npm et pour pip, même combat: il existe des outils pour générer les dérivations nix à partir du fichier requirements.txt[1]/package.json[2].

    Cela te permettra donc de ne t'occuper que du fichier classique et regénérer de temps en temps le fichier nix listant les dépendances qui ne seraient pas déjà dans nixpkgs (qui se remplit très vite également). Il est aussi fréquent que le dépot nixpkgs soit mis à jour avec des scripts qui aspirent le contenu des dépots de type pipy.

    Dans le manuel de nixpkgs, tu as également des exemples[3] par langages pour expliquer comment adapter à ton cas (Erlang/Elixir, Go, Coq, Haskell, Idris, Java, JS, Lua, Perl, Python, R, Ruby, Rust (via overlay)). Pour te donner une idée des dérivations existantes, il y a la liste sur le site [4].

    [1] https://pypi.python.org/pypi/pip2nix/0.6.0 (distribué uniquement via pip bizarrement)
    [2] https://github.com/NixOS/npm2nix (paquet officiel installable via nix-env)
    [3] https://nixos.org/nixpkgs/manual/#python
    [4] https://nixos.org/nixos/packages.html

  • [^] # Re: Point de vue de novice

    Posté par . En réponse à la dépêche Le compilateur GHC Haskell en version 8.0.1. Évalué à 1.

    Dans les cours/tuto on montre souvent des codes comme ça, mais il avec le temps, tu en écriras de moins en moins aussi

    Pour ton exemple, on peut s'en sortir avec Data.Digits, sum, fold, map
    Ces deux dernières sont vraiment des outils auxquels on s'habitue.

    Bon courage pour la suite en tout cas ;)

  • [^] # Re: Ben, euh....

    Posté par . En réponse au journal Être linuxien est pire qu’être pirate. Évalué à 6.

    ben si c'est une demande client, ça se facture, non ?

  • [^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus

    Posté par . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.

    Pas tout à fait: chroot partage le même espace dans /proc (si tu fais un point de montage et la pile réseau)
    alors LXC/docker utilisent les mécanismes d'espaces de nommages qui isolent ces aspects là.

  • [^] # Re: systemctl list-unit-etc.

    Posté par . En réponse au journal systemd: je me lance. Évalué à 3.

    L'installation par défaut n'utilise pas systemd, mais il est possible d'installer un paquet systemd-sysv pour basculer complètement dans le merveilleux monde de systemd, avec tout ce qu'il faut pour utiliser selon les services les .unit ou les fichiers dans /etc/init.d

    Bref, la transition est en cours.

  • [^] # Re: Qt

    Posté par . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 4.

    malheureusement non … grosso modo, il y a moyen de faire le boulot de la même façon, mais en utilisant des technos différentes…

    Qt utilise des fichiers XML .ui, ou du QML maintenant
    GTK Builder part d'autres fichiers XML .ui .. mais différents

    Et puis, à l'ancienne on peut coder l'ui à la main, mais je ne pas que ça soit vraiment répandu

  • [^] # Re: Support pour les traductions

    Posté par . En réponse à la dépêche GCompris se refait une beauté... avec votre aide. Évalué à 1.

    Genre ça:

    https://hosted.weblate.org/

    Mais pour le coup, je crois que c'est très poussé par openSUSE, donc les fans du NIH vont forcément en inventer un autre. (Je n'ai pas vérifié non plus que c'était le premier produit comme ça).

  • [^] # Re: Migrer ?

    Posté par . En réponse à la dépêche openSUSE 13.2 : nouvelle version du caméléon disponible !. Évalué à 2.

    Il me semble que surtout, par défaut, openSUSE installe les recommandations, ce qui gonfle forcément les dépendances.
    Une fois que le flag est bien configuré, ça doit pas être si loin des dépendances de Debian.

  • # Concernant la fusion de Factory et Tumbleweed

    Posté par . En réponse à la dépêche openSUSE 13.2 : nouvelle version du caméléon disponible !. Évalué à 10.

    J'ajoute comme information pour ceux qui ne l'auraient pas vu que les utilisateurs actuels des distributions Factory et Tumbleweed ont des manipulations à effectuer pour prendre en compte la fusion des 2 distributions Rolling Release d'openSUSE.

    Les détails sont par là:
    http://lists.opensuse.org/opensuse-factory/2014-11/msg00073.html

    Les utilisateurs de Tumbleweed doivent le faire rapidement, ceux de Factory, dans un délai de 6 mois, avant que le dépot ne soit supprimé définitivement.

    Sinon, je suis très content de 13.2 et en particulier de KF5, je suis tout triste quand je retourne sur la version 4, et pourtant, elle est encore jeune.

    On est très loin de la migration de KDE3 vers KDE4, c'est un vrai plaisir

  • [^] # Re: Dibab ?

    Posté par . En réponse au journal Une idée de distribution Linux. Évalué à 9.

    Ben c'est pareil:
    1. Tu commences, t'es enthousiaste
    2. Et le temps de couper les oignons … tu pleures

  • [^] # Re: Séparation en 3

    Posté par . En réponse au journal Une idée de distribution Linux. Évalué à 4.

    ça ressemble beaucoup à une proposition de Lennart qui parlait plus de Système/Framework/App, mais ça serait assez intéressant à creuser (mais pas par moi ;))

  • [^] # Re: Description de systemd ?

    Posté par . En réponse à la dépêche systemd versions 212 à 215. Évalué à 5.

    Mais qu'est-ce qui t'empêche de faire une unité systemd qui fait le même job ?
    Elle n'est pas fournie (a priori) en standard, mais je ne vois pas ce qui t'empêche d'avoir une unité personnelle très tôt dans la séquence.

  • [^] # Re: list-machines ?

    Posté par . En réponse à la dépêche systemd versions 212 à 215. Évalué à 8.

    Je pense que ça vient de deux aspects:
    - Comme tu le dis, systemd est le royaume des cgroups, donc autant y aller jusqu'au bout et donc incorporer LXC (les fonctionnalités, pas le binaire)
    - Ensuite, avec la mode du cloud, on aime avoir des services qui démarrent dans tous les sens, dans des sandbox etc, donc on aimerait pouvoir démarrer des conteneurs aussi facilement que des services classiques.

    Avec ce point de départ, il y a la solution classique: on démarre lxc/docker depuis systemd, et puis il a la solution systemd, on fusionne (j'imagine en espérant profiter des synergies).

    Effectivement, la question au bout du compte c'est dans cette situation LXC sert-il encore à quelque chose ? Docker a au moins quelques autres cordes à son arc avec les dépots et les layers, mais je suppose que ça sera aussi intégré à systemd 220 ;)

  • [^] # Re: Formation

    Posté par . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 2.

    voire même … entre distributions GNU/Linux.

  • [^] # Re: Ruby

    Posté par . En réponse au journal Python comme premier langage de programmation ?. Évalué à 1.

    puts c'est comme puts() en C, ça permet juste d'afficher les différentes valeurs calculées.

  • [^] # Re: Tu sais

    Posté par . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 2.

    Non, position supérieure ;)

  • [^] # Re: Pascal...

    Posté par . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.

    Ça me chatouille cette distinction que vous faites entre les ensembles et les arborescences.

    De mon point de vue, en considérant les branches filles comme des sous-ensembles de l'ensemble correspondant au noeud courant, c'est assez équivalent. Il y a moins de richesse avec l'arborescence, mais on peut bien faire une correspondance entre l'arborescence de classes et … une logique ensembliste.

    Pourriez-vous m'éclairer ?

  • [^] # Re: Premier langage? Javascript! Première plate-forme,

    Posté par . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.

    Tu peux toujours le dire, mais si ça compile, même par erreur, ils vont le découvrir et se croire plus malin que toi parce que … ça marche.

  • [^] # Re: Attendons encore un peut...

    Posté par . En réponse au journal FirefoxOS: ou pas.... Évalué à -1.

    oui enfin il ne faut pas prendre son cas pour une généralité. Chez d'autres ça marche (variante de "chez moi, ça marche")…

  • [^] # Re: jolla

    Posté par . En réponse au journal FirefoxOS: ou pas.... Évalué à 3.

    Effectivement, la base c'est MER donc libre, mais l'interface graphique est globalement propriétaire.
    Petit à petit, certains morceaux (browser par exemple) commence à être libéré.

    Mais les gars de Jolla semblent contribuer à pas mal de briques libres.

  • [^] # Re: jolla

    Posté par . En réponse au journal FirefoxOS: ou pas.... Évalué à 9.

    Il est un peu jeune, mais il grandit vite, il y a déjà eu 8 mises à jour qui ont apporté pas mal de modifications, alors certes, le nombre d'applications natives a encore un peu de mal à progresser, mais vu qu'on a accès aux applications Android, ça permet de patienter tranquillement.

    Je n'ai pas un usage très avancé d'un téléphone, mais il fait bien son travail, tant au niveau des applications disponibles que du matériel. On peut toujours espérer mieux, et moi je suis en fait assez déçu qu'un certain nombre de projets libres ne tentent pas l'expérience (je sais, «j'ai qu'à patcher», mais pour le moment ça ne me démange pas assez).

    Dans les points plus sombre, on sort souvent l'écran qui est 4.5" en qHD (donc assez peu de pixel par rapport à la concurrence), les polices sont assez grosses dans les applications, donc, finalement, on est peut-être un peu à l'étroit, mais pour mon usage, ça va.

    Son ergonomie toute en glisse me va complètement et je m'arrache les cheveux quand je dois toucher un android (à cliquer)

    Donc comme tu as demandé un avis: c'est un peu jeune, mais il pousse bien

  • [^] # Re: "migré" de Sun Solaris vers Linux

    Posté par . En réponse au journal Kiabi migre son SI sur Linux pour gagner en performance et indépendance. Évalué à 6.

    systemd PID 1 aussi

    En fait, c'est un problème de communication je pense.

    systemd = { pid1, logind, networkd, … }

    sauf que pid1 … s'appelle aussi systemd (en tout cas je ne lui ai pas vu de nom différent) donc systemd-pid1 est assez proche de ta vision de SMF.

  • [^] # Re: Quid de Razor Qt ?

    Posté par . En réponse à la dépêche Du nouveau du côté de LXQt. Évalué à 2.

    LXQt = fusion de Razor-Qt et LXDE si j'ai bien compris

  • [^] # Re: C'est la vie...

    Posté par . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.

    Justement à mon avis, s'il ne fallait qu'un seul format, RPM serait vachement plus adaptable à ce genre de problèmes. J'ai longtemps préféré les deb (et je préfère toujours les règles de nommage de Debian), mais pour avoir un peu joué à faire des paquets dans mon coin:

    Avec les deb, les dépendances sont des paquets donc si tu dépend de java-truc et que sur une autre distrib, le même contenu est appelé truc-java, ben c'est foutu, tu dois modifier/forker ton paquet,, alors qu'en RPM, tu dis juste que tu as besoin de /usr/bin/java est c'est bouclé. Et en plus, pour les bibliothèques rpm passe un coup de ldd pour en déduire ce dont tu as besoin, donc t'as même pas à les lister à la main.

    Et je rejoints Zenitram, 2 formats pour faire le même job (parce que fondamentalement, je ne vois pas de raison autre qu'historique à avoir 2 espèces de tar+dépendances, et c'est pénible.