Vu que NixOS fait du gringue à certains, je vous rappelle juste de faire attention à une chose; faites attention aux scripts qui commencent par « #!/usr/bin/<machin> » et compagnie, ça ne fonctionne forcément pas et c'est vite chiant...

@Knakis En effet, après c'est pas trop compliqué de faire des symlinks entre (/usr)/bin/* et /run/current-system/sw/bin/*.

Et par défaut on a quand même /bin/sh et /usr/bin/env donc ça calme une partie des shebang.

Et tous les scripts qui sont installés via les paquets officiels sont passés par `patchShebang` donc on se retrouve avec des trucs du genre :

1. !/nix/store/{{hash}}-bash-4.2-p51/bin/sh

(Mais au moins ça marche.)

+ Knakis, tu as déjà testé NixOS ?

D'ailleurs NixOS vient sans which(1) (c'est un paquet à part entière ), ça casse aussi tous les scripts qui utilisent `which` au lieu de `command -v`.

J'ai soumis un patch à i3 pour ça d'ailleurs.

Non, je l'ai utilisé à temps plein, comme un utilisateur lambda qui voulait une roue de secours en cas de crash (autre que le « upgradepkg /mnt/hd/slackware64/**/* » que j'ai utilisé la dernière fois pour repasser à une version antérieure de mes paquets).

Donc, si tu as une question, je veux bien tenter de répondre comme je peux.

Okay Knakis, j'ai pas de questions pour l'instant mais j'hésiterai pas si besoin.

@Caletlog

« This is exactly analogous to purely functional data structures in a language such as Haskell (since the store is a purely functional data structure): updating the first element of a list is cheap, while updating the last element is expensive. »

D'après http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf (page 30).

+ « Nix has a tool (nix-store --optimise) to optimise disk space usage by searching the store for identical files and replacing them with hard links to a single copy. »

Claaaaaasse.
J'ai un vieux laptop qui traîne, je testerais là-dessus.
C'est totalement indépendant des autres distros niveau paquets, c'est ça ? C'est bien fourni quand même ?

https://github.com/NixOS/nixpkgs

Boom.

$ nix-env -qa | wc -l
13221

J'ai trouvé le peu de paquets dont j'ai besoin quotidiennement, après je verrai à la longue si il me manque quelque chose ou pas, mais ça a pas l'air bien compliqué de créer une définition de paquet donc si besoin je soumettrai une PR.

Le seul paquet qui me manque en fait c'est i3blocks, mais à part sous Arch où il est dans l'AUR, je suis toujours obligé de le compiler à la main donc ça me change pas des masses.

Faut que je test NixOS, vous m'intrigué la

Bon y'a pas encore GitLab dessus, y'a une issue pour ça mais rien de concret : https://github.com/NixOS/nixpkgs/issues/2745

En même temps ça a l'air d'être vraiment chiant à packager comme truc.

Je vais essayer de faire tourner un conteneur sous Debian dans NixOS pour installer le package Debian officiel. Ça m'embête d'installer LXC sous NixOS comme y'a déjà nixos-container, mais je ne vois pas comment on peut initialiser un conteneur NixOS avec debootstrap donc bon…

Mais bon dans tous les cas pour LXC c'est mort : https://nixos.org/wiki/NixOS_and_LXC

Fuck.

Moopie pareil

D'ailleurs vava Gitlab a quoi de mieux que Github ?

ça a de mieux que c'est parfaitement pas la même chose

GitHub est un site qui utilise une plateforme (développée par ses soins, avec Git pour socle).
GitLab est une plateforme libre installable chez soi / dans sa boîte / etc., donc si tu n'as pas envie que ton code soit dans les mains de github MAIS que tu aimerais bien avoir "un peu plus" qu'une interface GitWeb sur ton dépôt... ben les solutions comme GitLab sont assez intéressantes.

Je l'ai déployé pour la Junior Entreprise où je bosse et c'est le pied (reste à trouver des consultants qui aiment Git / sachent s'en servir mais j'y travaille).

Ah j'avais pas compris le principe de GitLab

Ya d'autres solutions du genre mais j'ai instantanément oublié leurs noms respectifs. C'est du même acabit que les interfaces web pour SVN, et c'est compatible avec d'autres trucs (notamment pour le bugtracking).

Dans le genre y'a Gitorious, mais GitLab me semble plus complet.

Et en effet la différence avec GitHub c'est que c'est libre et installable sur son propre serveur.

Bon j'ai réussi à faire un conteneur Debian avec systemd-nspawn ( ), il boot et j'ai du réseau dessus… reste à y installer le paquet de GitLab. Pour l'instant ça merde sur `gitlab-ctl reconfigure`, il arrive pas à lancer Redis et sleep indéfiniment.

D'après cette issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/160 j'ai lancé /opt/gitlab/embedded/bin/runsvdir-start en parallèle, et ça a marché.

Bon après j'ai eu un problème d'allocation mémoire avec PostgreSQL, erreur documentée ici : https://gitlab.com/gitlab-org/omnibus-gitlab/issues/129

Solutionné en ajoutant `postgresql['shared_buffers'] = "10MB"` à la conf de GitLab.

Putain ça marche !

J'pense que je vais attendre un peu avant d'installer GitLab via le paquet du coup

ça vient de quelle branche de debian?

Jouer avec les conteneurs LXC, ça me tente aussi.

Mais j'ai pas le temps (tm).

Concernant Postgres, évite de mettre des rôles avec authentification "trust"

Mets le mode md5 au minimum

La sécurité toussa toussa...