Ubuntu Server 16.04 LTS : mémoire et fraîcheur

Ubuntu Server LTS 16.04 : faible consommation mémoireJe viens de finir l’installation de Linux Ubuntu Server LTS 16.04, dite Xenial Xerus. Elle vient de passer nativement à systemd. Je n’ai pas compris grand chose à l’intérêt de Snap, si ce n’est qu’il s’agirait d’un nouveau système de gestion de paquets. Le problème, c’est que je n’ai pas trouvé grande littérature sur l’utilisation de Snap/Snappy.

Minimisation des services

Je vous ai concocté un petit script dont l’objet est de désactiver les services potentiellement inutiles sur Ubuntu Server LTS  :

#!/bin/bash
#AppArmor et pare-feu
systemctl disable apparmor
systemctl disable ufw
#Gestion des crashs
systemctl disable apport
#L'autre planificateur de tâches
systemctl disable atd
#iSCSI
systemctl disable iscsid
systemctl disable open-iscsi
#LVM
systemctl disable lvm2-lvmetad
systemctl disable lvm2-monitor
#LXC / LXD
systemctl disable lxcfs
systemctl disable lxd-containers
#RAID logiciel
systemctl disable mdadm
#Snappy : le nouveau système de paquets
systemctl disable snapd

Consommation mémoire

Du coup, la consommation mémoire atteint les 30 Mo, comme vous pouvez le voir sur la copie d’écran ci-dessous dans laquelle est retranscrit le résultat de la commande free :

free-ubuntu-server-lts-16-04

Fraîcheur des paquets LAMP

En terme de fraîcheur des paquets LAMP, Ubuntu 16.04 fait globalement mieux que Fedora 23 sur le plan applicatif, notamment en proposant le PHP 7.0 :

Ubuntu  / Formateur Linux Formateur Ubuntu Server Linux Ubuntu Server 

Commentaires

@Bernard

Peux-tu m’expliquer quel intérêt, dans des environnements professionnels, il y a à parler du testing, unstable et backport ? Comme très souvent, ton propos se dilue dans la verbosité bien inutile et, du coup, devient presque sans intérêt.

Pour Snap sij’ai tout bien saisi, cela permet une containérisation des applis, permettant:

– de les mettre à jour à la volée en gardant le système « étanche » aux changements/contraintes
– de récupérer une app complète à 100% en terme de dépendances permettant ainsi d’éviter de se balader avec des repos spécifiques/unstable ou autre parce que le dev a mis dans ses pré requis des fonctionnalités hors prod

@Jeremy

Très bien. Comment ça marche ? Elle est où la doc ?

Tout est la avec apprentissage par l’exemple :)

https://developer.ubuntu.com/en/desktop/

Pour le noyau, on peut penser que c’est au minimum un 4.4.5, voire un 4.4.6

Le dernier changelog concernant la paquet Linux-image 4.4.0 contient ceci (n’ayant pas trouvé le 4.4.0-21) :

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.4.0-20.36/changelog

— Tim Gardner Mon, 21 Mar 2016 10:15:31 -0600

linux (4.4.0-15.31) xenial; urgency=low
[…]
Xenial update to v4.4.6 stable release (LP: #1558330)
[…] »

Ça, c’est de la numérotation à la c** ! :)

@Frédéric

C’est du 4.4.0-21.37, très précisément.

Le problème avec Canonical, c’est qu’ils ne suivent pas – contrairement à Red Hat – la numérotation officielle en amont.

Car comment savoir que le noyau 4.4.0-21.37 correspond à une version adaptée du noyau 4.4.6 voire du 4.4.7, mais comme le changelog du 4.4.0-21.37 n’est pas encore disponible…

C’est pour cela que j’ai pris le dernier disponible ici :

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/

J’ai comme l’impression que Canonical semble être faché avec la numérotation officielle qui permettrait pourtant de savoir quelle version du noyau a été « rustinée » pour obtenir la version d’Ubuntu.

Ce qui donne la fausse impression que le noyau est plus vieux qu’il n’est en réalité.

@Frédéric

J’ai fait aptitude show linux-headers. Je suis sur Ubuntu Server 16.04 LTS, sans backport. L’information de version est la même avec uname -a : 4.4.0-21-generic #37-Ubuntu SMP.

Il y a 2 numérotations différentes. Celle de Canonical et celle employée upstream et par 99,9% des distributions en dehors des Ubuntu-based.

Si on lit le changelog dont j’ai fourni le lien plus haut, on apprend que le code source utilisé est celui du noyau linux 4.4.6 en upstream.

D’ailleurs, le bug concernant l’utilisation du code source de Linux 4.4.6 pour le noyau de la Ubuntu 16.04 : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1558330

Donc, il y a de quoi s’emmeler les crayons. Merci Canonical de ne pas utiliser la numérotation proposée en upstream.

Finalement, cela donner l’impression trompeuse que le noyau est une version 4.4.0 alors qu’en réalité, la base employée est basée sur le code source de la version 4.4.6.

Cf ce que fait la Fedora dans ce domaine :

https://apps.fedoraproject.org/packages/kernel

Au 25 avril 2016, pour la Fedora 22 : 4.4.6-201.fc22 ; Pour la Fedora 23 : 4.4.7-300.fc23

C’est quand même plus clair, non ? :D

@Frédéric

Moralité : vive Fedora et le RPM ! ;+)

Laisser un commentaire

(requis)

(requis)