Journal Faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 (Buster)

• # Silent boot

  Posté par bubar🦥 (Mastodon) le 18 juin 2019 à 18:43. Évalué à 8. Dernière modification le 18 juin 2019 à 18:45.

  

  Bonjour Stéphane, merci pour ce premier journal : intéressant ! (solokeys, je ne connaissais pas, par exemple, et très sympa le dnscrypt_proxy !)

  Pour un ordi personnel, portable ou pas, j'aime bien avoir un boot clean, 'propre', sans aucun message, sans voir le chargeur de démarrage, sans rien jusqu'au bureau. Parceque c'est joli, agréable, que la personne ne s'intéressant pas au système n'a pas ce besoin, tandisque le 'réparateur' n'en a, lui, pas besoin :-)

  Du coup, ça donnerait grosso-modo : retrait de plymouth, 'rd.systemd.show_status=0' en option de boot, récupération de l'image 'bgrt' de l'uefi (si la distrib ne fait pas ça toute seule) pour avoir le logo constructeur, passage de grub en 'hidden' (ou timeout 0 si la distrib le fait pas). Pour au final avoir un truc comme ça Qu'en penses tu ?

  • [^] # Re: Silent boot

    Posté par stephane.gambus le 18 juin 2019 à 21:30. Évalué à 5.

    

    Bonjour Tankey,

    Merci de ton retour trés interessant.

    Je viens de tester un redémarage après modification de /etc/default/grub
    - sudo apt remove plymouth
    - modif GRUB_TIMEOUT=5 en GRUB_TIMEOUT=0
    - suppression de splash sur la ligne GRUB_CMDLINE_LINUX_DEFAULT=
    - ajout de rd.systemd.show_status=0 sur la ligne GRUB_CMDLINE_LINUX_DEFAULT=
    - sudo update-grub

    ça me parait vraiment clean en effet ! (j'ai tout de même à saisir un password à saisir pour la partition LVM chiffrée). C'est aussi beaucoup plus rapide pour démarrer. (en ressenti)

    Je viens de voir que l'on peut toujours accéder à GRUB malgré la présence de GRUB_TIMEOUT=0 en appuyant sur SHIFT, mais je n'ai pas encore testé…

    Par contre, je n'ai pas bien compris la partie "récupération de l'image 'bgrt' de l'uefi" (mon ordi est un Dell XPS 9350) J'aurais bien testé ça…

    • [^] # Re: Silent boot

      Posté par bubar🦥 (Mastodon) le 18 juin 2019 à 22:21. Évalué à 7. Dernière modification le 18 juin 2019 à 22:25.

      

      BGRT pour Boot Graphics Resource Table (bootime_graphics_resource_table_support dans le noyau), une extension acpi (EfiBootServicesData) qui indique où se trouve le 'logo' dans l'efi pour l'utiliser puis libérer cette portion.

      Plymouth intègre cette possibilité : le système extrait tout seul l'image (le logo constructeur souvent) et l'affiche en fond d'écran, en y ajoutant le logo de la distribution (et une petite animation). Cependant ce merge est assez récent et je n'ai pas regardé si Buster l'intégrait. Par défaut me suis dit "non", du coup la solution de se passer de plymouth est sympa (perso, même avec un plymouth qui fait ça, je vire quant même plymouth pour ne garder qu'un logo fixe). On trouve ce logo dans /sys/firmware/acpi/bgrt/image Ensuite, fbcon et efifb savent afficher cette image lors du boot (pas essayé / vérifié pour simple_fb), enfin .. si je me trompe pas.

      Concernant doc et discussion, ce mail sera mieux que mes mots.

      (ça me fait rudement plaisir de voir ces petits raffinements arrivés par défaut, quel changement en qq années, aujourd'hui il n'y a plus rien à faire pour que ça fonctionne)

      (j'ai tout de même à saisir un password à saisir pour la partition LVM chiffrée)

      Ah oui, ça l'idéal serait d'entrer ce mot de passe via Coreboot (ou l'uefi, à défaut) mais c'est pas encore fait :-)

      • [^] # Re: Silent boot

        Posté par stephane.gambus le 19 juin 2019 à 10:34. Évalué à 4.

        

        Salut Yvan ! (Heureux d'avoir de tes nouvelles par le biais de ce journal)

        Merci de tes explications.

        coreboot n'est malheureusement pas disponible sur mon laptop. Mon prochain sera probablement un Librem 13 pour cette raison, ainsi que pour ratatiner l'Intel Management Engine. J'attends une génération de processeur qui intègre en hardware la correction de spectre/meltdown/etc. + un clavier français. En attendant je pense prendre le téléphone Librem 5)

        Plymouth est actuellement en version 0.9.4-1.1: amd64 dans Debian 10 Buster (même version en sid)
        Je n'ai pas trouvé ce merge dans le changelog
        https://metadata.ftp-master.debian.org/changelogs//main/p/plymouth/plymouth_0.9.4-1.1_changelog

        Le format de l'image est bmp
        file /sys/firmware/acpi/bgrt/image
        /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 450 x 432 x 24

        j'ai affiché l'image en ligne de commande
        eog /sys/firmware/acpi/bgrt/image

        Le logo de DELL est bien affiché dans le viewer eog !

        Avec un flasheur de bios, on pourrait modifier le logo directement dans le firmware si Bootguard n'est pas activé. (ce qui est le cas pour mon laptop)

• # ansible

  Posté par liberforce (site web personnel) le 19 juin 2019 à 10:38. Évalué à 10.

  

  Ce type d'automatisation, c'est un boulot pour ansible.

  Pour mon setup vim, j'utilise un dépôt git à part, et je fais juste un lien symbolique vers le dossier en question vers $HOME/.vim. Pas besoin de fichier vimrc à côté ($HOME/.vimrc), car vim lit aussi $HOME/.vim/vimrc, ainsi toute la config vim tient dans un unique dossier, la rendant facilement déployable sur une nouvelle machine.

  • [^] # Re: preseed

    Posté par Gabin3 le 19 juin 2019 à 12:43. Évalué à 3.

    

    Ça a aussi bien sa place dans une config preseed. Et si l'ami se limite à Debian (ce qui est bien :)), il peut en faire un paquet, voire meta-paquet.

    • [^] # Re: preseed

      Posté par LaBienPensanceMaTuer le 19 juin 2019 à 16:03. Évalué à 3.

      

      J'ai pas bien compris pourquoi Gabin3 a été tant moinssé … ses suggestions sont on ne peut plus pertinentes … (et je dis pas ça parce que j'ai fait les mêmes 10 comments plus bas).

  • [^] # Re: ansible

    Posté par bubar🦥 (Mastodon) le 19 juin 2019 à 21:25. Évalué à 4. Dernière modification le 19 juin 2019 à 21:27.

    

    en théorie oui, en pratique non.

    ça cause de "comment aider quelqu'un à passer sous gnu/linux, ici Debian Buster, sans prise de tête ni perte de temps", pas de "comment industrialiser le process", dans ce dernier cas on aurait démarré par "bootp pxe", pas par ansible. mes 2 cents.
    Cette solution par script convient tout à fait pour une install-party, ansible aussi mais ça va pas être la même de préparation (ou alors on se pointe en disant "j'ai tout fait en 3 playbooks" … "ok, super, mais en vrai on a pas l'infra pour suivre")

    • [^] # Re: ansible

      Posté par kna le 20 juin 2019 à 11:02. Évalué à 7.

      

      on se pointe en disant "j'ai tout fait en 3 playbooks" … "ok, super, mais en vrai on a pas l'infra pour suivre")

      Tu peux utiliser ansible localement, il doit juste être installé sur la machine.

      sudo apt install git ansible
      git clone ton_repo
      cd ton_repo
      ansible-playbook --connection=local playbook.yml
      

    • [^] # Re: ansible

      Posté par Laurent J (site web personnel, Mastodon) le 20 juin 2019 à 14:10. Évalué à 4.

      

      ok, super, mais en vrai on a pas l'infra pour suivre

      Ah ? il faut une infra pour lancer Ansible ? J'ai du louper quelque chose dans son utilisation alors :-)

      Je ne pense pas que dans une install party, il soit trop compliqué d'indiquer de faire un sudo apt install ansible… Parce qu'au final, que ce soit un répertoire complet de scripts bash ou un répertoire complet de scripts ansible, ça revient au même, sauf que dans le premier cas, bash est déjà installé.

• # Ansible

  Posté par Laurent J (site web personnel, Mastodon) le 19 juin 2019 à 11:26. Évalué à 5.

  

  Je me suis fait aussi des scripts de configuration pour ma machine. Par contre j'ai utilisé Ansible. Ça m'évitait d'avoir à gérer "l'idempotence".

  • [^] # Re: Ansible

    Posté par stephane.gambus le 19 juin 2019 à 11:40. Évalué à 3. Dernière modification le 19 juin 2019 à 11:40.

    

    Javais plusieurs possibilité
    - coder en bash
    - coder en ansible
    - faire un master custom de debian et y ajouter ajouter les scripts directement (installation tout automatisée de bout en bout)

    le plus simple et rapide m'a semblé être le bash pour une première version (je n'ai pas encore regardé ansible)

    Ansible à l'air très intéressant…

    actuellement je configure ça dans .vimrc:
    ajout de la ligne "source /usr/share/vim/vim81/defaults.vim"
    ajout de la ligne "set syntax=on"
    ajout de la ligne "set mouse=r"

    Me conseillez vous d'autres lignes de configuration complémentaires pour vim ?

    • [^] # Re: Ansible

      Posté par Yves (site web personnel) le 19 juin 2019 à 13:51. Évalué à 4. Dernière modification le 19 juin 2019 à 13:51.

      

      Salut ! et merci pour cet intéressant inventaire (quoique de mon côté j’utilise plutôt Ansible).

      Pour vim, j’ai trouvé ça sur Internet et je trouve que c’est assez confortable à utiliser :

      set list
      set listchars=eol:⏎,tab:▸·,trail:␠,nbsp:⎵
      

      (à copier tel quel avec les caractères Unicode)

      J’y ai ajouté aussi :

      set runtimepath^=~/.vim/bundle/vim-editorconfig
      

      avec ~/.vim/bundle/vim-editorconfig qui est un clone de https://github.com/sgur/vim-editorconfig.git, en « detached HEAD » sur la dernière version (dernier tag).

      • [^] # Re: Ansible

        Posté par stephane.gambus le 20 juin 2019 à 13:30. Évalué à 0.

        

        Très intéressant ton projet home-server.

        Il va me falloir du temps pour tout regarder =)

    • [^] # Re: Ansible

      Posté par liberforce (site web personnel) le 19 juin 2019 à 15:49. Évalué à 10.

      

      De la config pour vim, ce n'est pas ce qui manque, c'est plutôt l'inverse. Il y a des gens qui partagent des .vimrc énormes adaptés à leur workflow, et impossible pour le profane de se les approprier. Mon conseil: fais de l'additif. Crée ta config à partir de ce que tu peux trouver à droite et à gauche, mais ne pars pas d'une grosse config existante pour l'édulcorer.

      Après plusieurs années d'utilisation de vim "à la vi", je m'y suis mis plus sérieusement.
      Les ressources que j'ai utilisées et que je conseille:
      - l'appli "Vim Master" android avec des quiz de tous niveaux. Même quand tu te trompes, comme on te donne la bonne réponse et ce que chaque réponse a comme effet, tu as moyen de comprendre pourquoi tu t'es trompé et découvrir des nouvelles fonctionnalités.
      - Vimcasts qui te donnera plein de pistes de personnalisation, par l'auteur de "Practical Vim" (que je recommande aussi). Le mieux est de reprendre toutes les vidéos (ou les transcriptions) dans l'ordre chronologique.
      - Une conférence de Max Cantor qui montre déjà plein de choses qu'on peut faire sans avoir besoin de plugins, juste en connaissant les fonctionnalités présentes de base dans vim.
      - Cet article sur comment découper et structurer son .vim plutôt qu'avoir un vimrc de plusieurs centaines de lignes (et d'autres articles)

      • [^] # Re: Ansible

        Posté par mornik le 20 juin 2019 à 09:31. Évalué à 1.

        

        Moi j'ai 2 vimrc. Celui qui se suffit à lui même et qui est transporté sur les machines sur lesquels je bosse (via une fonction qui assure la connexion ssh)
        Le second, est celui de ma machine de travail avec plusieurs plugins et tout.

        Le premier est fait pour offrir le maximum de confort/fonctionnalité sur un maximum de système ayant un vim ancien.

    • [^] # Re: Ansible

      Posté par flan (site web personnel) le 19 juin 2019 à 19:13. Évalué à 6.

      

      Mon point de vue sur la question :
      - ansible réclame une passe après installation (donc installer Ansible) et il faut pouvoir récupérer facilement le script (pas forcément compliqué, cela dit),
      - le preseed est un peu complexe à faire évoluer (faut refaire une image et c'est pénible), c'est pénible à débugguer et on ne peut pas le reclaquer facilement,
      - le metapaquet est un peu complexe à régénérer, potentiellement ça implique d'avoir un miroir Debian (avec la gestion de clefs que ça implique), c'est pénible à débugguer et il faut en plus s'occuper de la montée de version
      - le script bash va demander de réinventer pas mal de choses par rapport à Ansible (pour le structurer, pour assurer l'idempotence, …) et sera plus compliqué à prendre en main par quelqu'un d'autre.

      • [^] # Re: Ansible

        Posté par liberforce (site web personnel) le 20 juin 2019 à 14:48. Évalué à 3. Dernière modification le 20 juin 2019 à 14:49.

        

        • ansible réclame une passe après installation (donc installer Ansible) et il faut pouvoir récupérer facilement le script (pas forcément compliqué, cela dit)

        Ansible n'a besoin d'être installée que sur la machine qui exécute le script, pas la machine cible. Le cas où il n'y a qu'une machine, tu as effectivement besoin d'installer ansible, mais dans le cas où tu as plusieurs machines à administrer (ordi fixe + ordi portable par exemple), tu peux appliquer ta configuration sur tes deux machines en une seule passe, et cela potentiellement à partir d'une troisième machine.

        Comme tu le dis, ansible te permet aussi de gérer l'idempotence: tu lances plusieurs fois ton script ansible tu arrives dans le même état final F. Tu changes la config de la machine cible, relances ton script ansible → tu arrives encore dans l'état F, même si l'état initial était différent. Ansible te permet de te concentrer sur l'état final à atteindre. Après ce n'est pas une solution magique, mais globalement ça fait le job, et c'est réplicable d'une machine à une autre.

        • [^] # Re: Ansible

          Posté par flan (site web personnel) le 20 juin 2019 à 15:09. Évalué à 2. Dernière modification le 20 juin 2019 à 15:11.

          

          Je pensais plus au premier cas, en effet (machine solo), mais même dans le second, il y a potentiellement un peu de travail à faire sur la machine cible (configuration réseau si elle est un peu complexe, injection des clefs publiques si absence de mot de passe, etc.). Mais bon, dans tous les cas c'est un travail à faire :)

          Par expérience :
          - le méta-paquet est une mauvaise idée (cycle de vie du paquet à gérer, ainsi que les miroirs APT, les clefs GPG, …) dans tous les cas,
          - si on utilise un preseed (installation de l'OS automatisée), sa phase de post-install doit être minimale (en gros permettre la configuration par ansible, puppet ou tout autre équivalent) et ne surtout pas faire autre chose,
          - le bash est une mauvaise idée car trop dur à maintenir quand il est complexe.

          Mais bon, c'est assez rassurant qu'Ansible, pensé pour configurer des machines soit meilleur dans ce domaine qu'un Bash qui est très généraliste.

• # FAI

  Posté par thomasv le 19 juin 2019 à 11:54. Évalué à 6.

  

  En utilisant FAI (Fully Automatic Installation), il est possible de créer une image d’installation contenant déjà tous les paquets souhaités. Cela peut faire gagner un peu de temps si l’objectif est de déployer cette configuration sur plusieurs machines.

  Son auteur en a fait une présentation à la MiniDebConf Hamburg l’an dernier, ainsi qu’à DebConf18 (celle de la MiniDebConf a l’avantage d’être sous-titrée).

  • [^] # Re: FAI

    Posté par LaBienPensanceMaTuer le 19 juin 2019 à 16:01. Évalué à 2.

    

    Debian permet aussi nativement cette opération via son installeur.

    C'est le preseeding

• # Après le script, après ansible ... le paquet Debian ou mieux, l'image preseed !

  Posté par LaBienPensanceMaTuer le 19 juin 2019 à 16:00. Évalué à 7.

  

  … le paquet Debian !
  Puisque la cible de ta démarche est clairement de ré-installer une Debian, pourquoi ne pas tout simplement passer par un paquet Debian:

  • Par le jeu des dépendances, tu pourras installer tout les paquets de ton choix.

  • Tu pourras installer des fichiers de configuration spécifiques à ton paquet (et donc installer des crontabs, des fichiers de /etc/apt/sources.list.d, etc…)

  • Installer des diversions sur certains fichiers, etc…

  • Tu pourras passer par les scripts de postinst et preinst pour faire les diverses opérations restantes.

  Sinon, l'alternative au paquet est carrément l'installation automatisée de Debian à l'aide du système de preseed

  • [^] # Re: Après le script, après ansible ... le paquet Debian ou mieux, l'image preseed !

    Posté par stephane.gambus le 20 juin 2019 à 11:13. Évalué à 1.

    

    Un package, c'est bien, mais surtout si ça peut être basculé dans les dépôts officiels de Debian.

    Preseed, c'est bien pour faire ça propre distribution
    - installation classique + avec ajout de packages
    - installation du dernier kernel provenant des backports
    - paramétrages divers
    - changement du fond d'écran pour mettre madistrobuntu

    Toutes ces solutions sont intéressantes…

    Pour la prochaine testing:

    • je tenterais de contacter les mainteneurs de vim et bash afin de voir si ils peuvent ajouter par défaut quelques paramétrages "conviviaux" dans le cas ou la cible est un desktop ou laptop (task-desktop ou task-laptop)

    • il faudrait que je demande à Debian (qui ?) si ils accèderaient un package qui commente la ligne CDROM, qui active contrib non-free et les backports

    • il faudrait aussi que je liste la liste des packages à créer.
      par exemple:

      • un package qui tire l'ensemble des autres packages nécessaires
      • un package qui dépend de dnscrypt-proxy et qui a pour objectif de forcer network-manager à utiliser dnscrypt-proxy
      • Etc.

    L'idéal serait que le distribution s'améliore dans le cas d'utilisation Desktop/Laptop…

    • [^] # Re: Après le script, après ansible ... le paquet Debian ou mieux, l'image preseed !

      Posté par LaBienPensanceMaTuer le 20 juin 2019 à 15:05. Évalué à 4.

      

      Preseed, c'est bien pour faire ça propre distribution

      Non, pas vraiment. Yocto ou buildroot, c'est pour faire sa propre distribution.
      Le résultat d'un preseed restera une distri Debian.
      Perso je vois plus ça comme une alternative au script de OP, un moyen de se faire un "master" pour pouvoir ensuite installer des desktops et/ou serveurs à la chaine.

      je tenterais de contacter les mainteneurs de vim et bash afin de voir si ils peuvent ajouter par défaut quelques paramétrages "conviviaux" dans le cas ou la cible est un desktop ou laptop (task-desktop ou task-laptop)

      La démarche est pas idiote… pourvu qu'ils t'entendent ;-)

      il faudrait que je demande à Debian (qui ?) si ils accèderaient un package qui commente la ligne CDROM, qui active contrib non-free et les backports

      Ca devrait être desactivé depuis longtemps, cette histoire de CD-ROM.
      De mon point de vue, c'est l'installeur qui devrait poser la question à la fin de l'installation…

      il faudrait aussi que je liste la liste des packages à créer.

      Ou tout faire dans un paquet … ça marche aussi, mais en effet, c'est moins propre.
      Limite, le truc qui me vendrait du rêve serait un service web ou tu choisirais à la carte les modifs de configuration que tu veux apporter (bashrc, vimrc, …) puis, sur validation, te génèrerait à la volée un paquet genre custom-config-XXXXXXXX.deb.

      Ensuite, wget <L'url du .deb> && dpkg -i <le .deb> et on en parle plus :)

• # Centralisation du DNS

  Posté par Glandos le 20 juin 2019 à 13:26. Évalué à 3.

  

  Merci pour l'article.

  J'aurais une remarque, concernant le DNS. Pourquoi ne pas avoir tout simplement installé un résolveur local comme unbound ?

  La configuration utilisée ici permet certes de chiffrer les requêtes DNS, mais seulement jusqu'à CloudFlare ou OpenDNS. Le dernier fournit d'ailleurs un service de DNS menteur.

  Avec unbound, toutes les requêtes sont visibles en clair par un attaquant actif. Soit le F.A.I., soit une boîte noire sur le trajet. Mais le risque me paraît moins probable que de confier toutes nos requêtes à une seule entité.

  • [^] # Re: Centralisation du DNS

    Posté par stephane.gambus le 20 juin 2019 à 14:02. Évalué à 1.

    

    Suite à ta remarque, je viens de lire ceci:
    https://www.bortzmeyer.org/opendns-non-merci.html

    Il y a 2 besoins:

    1 Confidentialité
    - encrypter les requêtes DNS (protection contre attaquant/FAI/boite noire)
    - distribuer les requêtes DNS sur différents services DNS (les services DNS n'ont qu'une vue partielle + résilience)

    2 Fiabilité des réponses
    - avoir des réponses fiables et non trafiquées au requêtes DNS

    Ma configuration ne répond que au premier.
    Ta proposition unbound ne répond que au second.

    Si je comprends bien, pour permettre de répondre aux 2 besoins, il faudrait identifier d'autres providers DNS fiables et supportant dns over tls.

    Il suffirait alors de compléter la ligne de configuration:
    server_names = ['cloudflare','autre n°1','autre n°2*','autre n°…','autre n°n']

• # NixOS

  Posté par Guillaum (site web personnel) le 23 juin 2019 à 20:51. Évalué à 3.

  

  C'est typiquement le genre de chose que fait très bien NixOS: https://nixos.org/

  Toute la configuration de ton système est décrite dans un (ou plusieurs) fichier de conf qu'il est facile de versionner. Il n'y a pas "d'étapes" lors de l'installation, ou de configuration à modifier, ton système est une unique configuration qui va être déployée de façon atomique.

  À titre d'exemple, au travail nous utilisons des dell XPS 13. J'avais un modèle de 2017 qui m'a été changé vers un modèle de 2018. Lancement du live cd, copie de ma configuration, j'ai juste adapté une ligne ou deux pour prendre en compte la densité de l'écran qui n'est pas la même. nixos-install et quelques minutes plus tard, j'avais exactement ma configuration déployée, avec ma configuration d'emacs, mon .gitrc, mes comptes utilisateurs, mes images docker pre-chargés, mon installation de wine pour jouer à Diablo. Mes paramètres de configuration GTK sont aussi décrits (avec https://github.com/rycee/home-manager)

  NixOS vient avec quelques autres avantages, comme nix prè-installé, la possibilité de booter sur une ancienne configuration (i.e. toutes les configuration précédentes sont sauvegardés). Dans le rare cas ou une mise à jour se passe mal (jamais arrivé en 2 ans), tu peux reprendre la dernière version et continuer à travailler.

  Home-manager peut être utilisé sans NixOS pour seulement décrire son environnement personnel, c'est à dire toutes les applications installée pour un utilisateur particulier, ses services personnel (systemd --user) et la configuration de toutes ses applications.

  Quelques contraintes pour NixOS, c'est une distribution linux différente, ce n'est donc pas la solution si vous devez absolument conserver un environnement debian ou autre. NixOS est aussi très strict sur la reproductibilité et n'expose dans l’environnement par défaut pour ainsi dire rien. Ainsi un binaire pré-compilé chargé sur NixOS a de grande chance de ne pas fonctionner. Je vois cela comme un avantage (i.e. cela force la reproducibilité), et en pratique c'est très rare que nixpkgs (i.e. la base de paquet de nix, donc NixOS) n'ai pas le paquet demandé.

  • [^] # Re: NixOS

    Posté par stephane.gambus le 24 juin 2019 à 17:01. Évalué à 0.

    

    Changer de modèle tous les ans avec cette gamme d'ordinateur portable, c'est du luxe ! Je n'en connais pas beaucoup qui ont ce privilège…

    En effet, Nixos a l'air intéressant. Il faudra que je creuse ce sujet…

    Il me semble que Suse Linux a aussi un endroit unique de configuration. (Yast)

    Actuellement, je teste Clear Linux qui a aussi une gestion de package atypique. (il n'y a pas grand chose dans /etc et c'est déroutant)

    En marge des tests de distributions et de gestionnaires de package, je suis centré sur Debian stable pour mon ordinateur personnel car j'aime bien être en Rolling Release tous les 2 ans =)
    C'est surtout possible grâce aux backports pour certains besoins, et à flatpak pour d'autres.

    Concernant APT, j'ai identifié une nouvelle fonctionnalité disponible dans Debian 10 Buster pour renforcer sa sécurité. (désactivée par défaut)

    Extrait du draft de la release note:
    Toutes les méthodes de APT(par exemple http et https) sauf cdrom, gpgv et rsh utilisent le bac à sable) seccomp-BPF fourni par le noyau Linux pour limiter la liste des appels système autorisés, et intercepter
    les autres grâce à un signal SIGSYS.
    https://www.debian.org/releases/buster/amd64/release-notes.fr.pdf

    J'ai activé cette fonctionnalité dans mon projet sur Gitlab…

    • [^] # Re: NixOS

      Posté par Guillaum (site web personnel) le 24 juin 2019 à 18:37. Évalué à 2.

      

      Changer de modèle tous les ans avec cette gamme d'ordinateur portable, c'est du luxe ! Je n'en connais pas beaucoup qui ont ce privilège…

      Oui, enfin j’espère que ton employeur te fourni un nouveau PC quand le précédant n'est plus en état de fonctionner. En gros, me concernant, c'était un nouveau dev de chez nous qui voulait un 2017 (car il a des ports USB type B), alors j'ai échangé le mien contre un 2018 avec plaisir.

      Après on parle d'un PC à 1500 euros. C'est entre 2 jours et une demi journée de consulting. Ce n'est pas le genre de décisions que je prend, mais si j'avais a les prendre, je dirais que si mon consultant à 1500 euros la journée a besoin d'un nouveau PC à 1500 euros pour gagner 2h d'autonomie, 20% de performance et doubler sa RAM, ce qui au final va lui faire gagner plusieurs minutes par jour, je paye tout de suite.

      Actuellement, je teste Clear Linux qui a aussi une gestion de package atypique. (il n'y a pas grand chose dans /etc et c'est déroutant)

      Sous nixos, c'est /usr/bin qui est vide ;). /etc contient des liens symboliques vers la configuration courante.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.