freeze a écrit 205 commentaires

La question du support est très complexe: celui qui fournit le support veut que ça lui coûte le moins possible et le client veut le meilleur support pour le moins cher …

Je comprends l'idée de ne pas utiliser les ressources les plus chères pour les réponses les plus simples. Et en même temps parfois en tant que client je veux vite avoir accès à un "bon" support.

Ce n'est pas un problème facile à doser.

Concernant le problème du télétravail, je ne veux pas non plus, vu mes tâches, revenir au bureau où c'est moins efficace et confortable mais je pense avoir à expliquer cela à mes responsables.

Par contre pour mes subalternes je suis prêt à leur donner cette liberté car c'est une histoire de confiance…

Au moins, on peut voir un côté positif à cette période de pandémie : une bonne occasion d'y trouver des aspects positifs (ou à minima de discussion pour discuter de l'organisation du travail)

Si on doit gérer un parc de cette taille, on va donc partir du principe qu'on utilise soit cachix, soit un serveur au sein de l'infra pour présenter la configuration voulue.

Je vais isoler deux cas:

1) la nouvelle version d'apache dont on parle est livrée par la release officielle de Nixpkgs/Nixos

Dans ce cas, il suffit de faire une mise à jour des canaux des 500 machines (sur nixos, il y a un module pour faire cela régulièrement)

2) la nouvelle version n'est pas distribuée dans nixpkgs

Dans ce cas, il faut fournir un channel particulier pour les paquets custom (ça demande un peu plus de travail, mais ça permet de faciliter les personnalisations).

La logique reste la même, il faut juste prévoir un channel (dans un dépôt git) pour présenter les paquets spécifiques.

Dans le cas où certaines installations sont longues, on poussera les binaires sur l'espace cachix / le serveur cache de l'infra pour que les déploiements soient juste des téléchargements

C'est assez proche de l'expérience de puppet. Le seul point à scripter soi-même, serait le provisionnement en mode push pour un hotfix (ssh + nix-channel --update && nixos-rebuild switch, donc rien de mortel) qui n'est pas proposé par défaut.

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.

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

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 ;)

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

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à.

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.

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

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).

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.

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

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

ç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 ;))

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.

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 ;)

voire même … entre distributions GNU/Linux.

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

Non, position supérieure ;)

Ç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 ?

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.

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")…

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.

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

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.