[Wiki] Linux

Répondre
Partager Rechercher
Message supprimé par son auteur.
On peut simplement espérer que dans l'affaire les développeurs de Canonical renforcent les équipes en présence sur Wayland (en lieu et place de Mir). Pour la convergence, il ne restera donc plus que Kirigami à l'état d'embryon. Et pour les DE, disons qu'il y en a déjà une pléthore. Il est possible par ailleurs de retrouver les sensations de Unity via les thèmes sur Plasma.
Depuis Gnome 3 et Unity je suis parti du coté de KDE et de XFCE, avec un peu de d'OpenBox. L'annonce me surprend aussi, Mir c'était un peu devenu une arlésienne mais l'investissement sur Unity par contre a tout de même été conséquent. J'ai pas accroché à ce DE mais il faut bien admettre qu'il trouvait sa place auprès de la plupart des utilisateurs d'Ubuntu. Le retour d'une Ubuntu Gnome édition l'année dernière aurait dû me mettre la puce à l'oreille.
Message supprimé par son auteur.
Le monde Linux m'est toujours un peu compliqué sur ses orientations. Je suis toujours débutant dedans.

Il me semble qu'en 2014, chez la plupart des clients chez qui j'allais pour de la programmation, c'était Linux Mint qui était en faveur. Et je crois avoir compris qu'il est un dérivé d'Ubuntu ?

Depuis 2016, j'ai l'impression de voir surtout du Debian 8 et du CentOS 7.
Les bouquins d'apprentissage de logiciels ou langages informatiques prennent souvent pour base ceux-là (les derniers livres sur Puppet, Docker, Elasticsearch, Hadoop, assument que leur lecteur en serait équipé), et quand quelqu'un que je côtoie se monte une VM Linux, c'est encore un de ceux-là qu'il choisit alors qu'il pourrait à cet instant installer très librement Fedora, Ubuntu ou n'importe quoi d'autre.

À quoi est-ce du que ceux deux-là ont le vent en poupe ces temps-ci ?

Certes, je me rappelle que Linux Mint, qui était populaire, avait subi une déconvenue lorsque ses concepteurs avaient raté un passage de version (de mémoire, je crois que migrer de la version 15 à 17 – ou quelque-chose comme ça –, pendant quelques temps, c'était une machine gelée à réinstaller entièrement "à la Windows"), mais un incident de ce genre ne suffit pas, à lui tout seul, à justifier un déclin.

Quant à des pures installations Ubuntu. Vous m'excuserez, mais...
... je n'en ai jamais vu ! Jamais !
Par la presse, je sais qu'il est version 17 ou 18 ?

Qu'est-ce qui oriente aujourd'hui ceux qui installent leurs distributions Linux ?
Comment font-ils leur choix aujourd'hui ? Qu'est-ce qui les attire chez l'un, les révulse chez l'autre ?
Citation :
Publié par Caniveau Royal
Il me semble qu'en 2014, chez la plupart des clients chez qui j'allais pour de la programmation, c'était Linux Mint qui était en faveur. Et je crois avoir compris qu'il est un dérivé d'Ubuntu ?
Depuis 2016, j'ai l'impression de voir surtout du Debian 8 et du CentOS 7.
[...]

À quoi est-ce du que ceux deux-là ont le vent en poupe ces temps-ci ?
Personnellement, pour les OS serveurs, la seule question que je me pose c'est si je vais devoir installer les packages dont j'ai besoin avec YUM ou avec APT et si les repository sont correctement configurés.
J'ai pas vraiment de préférence entre les deux (et les OS sous-jacents).

En YUM, toutes les distrib seront des dérivés de RedHat avec en particulier souvent du CentOs pour les pauvres. Les packages sont les mêmes de toutes façons.
En APT, toutes les distrib (Ubuntu, etc...) sont des dérivés de Debian.

En me basant sur plusieurs dizaines de clients, c'est la majorité du temps du CentOs qui est utilisé dernièrement.
En général les admins système utilisent déjà le système de satellite redhat pour le déploiement des mises à jours RedHat car c'est souvent cette distribution qui est préconisée par les éditeurs quand l'architecture serveur est conçue même si c'est au final plus une histoire de gros-sous que de stabilité.
Et du coup c'est plus facile pour les admins systèmes de refaire la même chose pour un parc de serveur sous CentOs que de repenser quelque chose de différent pour un parc de Debian ou autre distrib.
C'est également plus simple d'administrer un parc homogène que hétérogène si tu souhaites automatiser un maximum de choses.

Mais après l'OS ça n'a pas vraiment d'importance, tu retrouveras globalement les mêmes packages, avec peut-être la logique d'installation qui diffèrera un peu, de même que la configuration par défaut.
Le package proposé dans la distrib de base sera souvent limité niveau version, pour des questions de stabilité et de maintenabilité.
C'est de toutes façons aussi ce que les gens cherchent, un serveur stable en priorité sauf s'ils ont besoin d'une fonctionnalité spécifique non inclue dans la version du package fourni par la distrib.
Mais dans ces cas précis, la plupart des éditeurs de solutions maintiennent des packages à jour pour les principales distributions Debian / CentOs, il suffit de déclarer des repository supplémentaires. Et ces packages peuvent souvent être déployés sur leurs OS dérivés sans problème.



Edit: Petite remarque en passant, dans un environnement professionnel, c'est toujours mieux d'utiliser les versions pré-packagées fournies avec la distrib.
Si tu as besoin d'une fonctionnalité spécifique d'une version récente, à ce compte-là, il est préférable d'utiliser une version pré-packagée par l'éditeur du logiciel en demandant de préférence aux admins systèmes de rajouter des repository custom dans l'OS (ceux de l'éditeur).
Si vraiment tu ne peux pas appliquer un des deux cas précédents ou si tu as un besoin très spécifique (mettre à disposition plusieurs versions de java sur un système par exemple) alors tu peux compiler toi-même les binaires, les packager et les déployer sur tes serveurs.
Il est par contre impératif de documenter cette procédure.

Pourquoi ? Pour des questions de maintenabilité et pour automatiser au maximum la gestion des patchs de sécurité lors des maintenances récurrentes et planifiées des systèmes.
Si tu fais des installations sauvages, hautement customisées et surtout non documentées tu te feras haïr par ceux qui devront assurer la maintenance derrière ainsi que les futures migrations.
Et ce sera aussi la porte grande ouverte en cas de vulnérabilité de sécurité.

Dernière modification par Lael ; 07/04/2017 à 20h33.
Les trucs que j'ai souvent vu faire, mais c'est parce que j'ai rarement été au contact de grands experts,
c'est pour installer typiquement le Docker 1.12+ sur la version Debian 7 qui ne le peut pas, c'est une entrée dans /etc/apt/sources.list pour rajouter des entrées de backport,

Ce que je ne savais pas, c'est ce qui se passerait si derrière un jour quelqu'un faisait un apt-get upgrade, tout ce qui en découlerait alors. Ça doit patcher le Debian 7 avec plein de bouts de 8 et tout rendre instable, en fin de compte, non ?
Ou bien on peut mettre des backport comme on veut ?
Je dirais qu'il se base sur le poids (priorité) du repository qui peut être influencé par ce qu'il y a dans /etc/apt/preferences.
Tu peux volontairement prioriser un repository interne par exemple.

Par défaut un repository "stable" est toujours prioritaire pour une mise à jour sauf si le package a été installé depuis un autre repository, à ce compte-là il est mis à jour depuis ce repository.

Ensuite à poids équivalent il prend le package avec la version la plus récente.
Tu peux avoir plus d'info sur la décision qu'il va prendre via "apt-cache policy" ou pour un package spécifique "apt-cache policy <package>"

Code:
apt-cache policy
 100 http://debian.mirrors.ovh.net/debian/ jessie-backports/main amd64 Packages
     release o=Debian Backports,a=jessie-backports,n=jessie-backports,l=Debian Backports,c=main
     origin debian.mirrors.ovh.net
 500 http://debian.mirrors.ovh.net/debian/ jessie-updates/main amd64 Packages
     release o=Debian,a=stable-updates,n=jessie-updates,l=Debian,c=main
     origin debian.mirrors.ovh.net
 500 http://security.debian.org/ jessie/updates/main amd64 Packages
     release v=8,o=Debian,a=stable,n=jessie,l=Debian-Security,c=main
     origin security.debian.org
Priorité plus faible donc pour backport car non défini comme "stable"

Code:
apt-cache policy samba
samba:
  Installé : 2:4.2.14+dfsg-0+deb8u4
  Candidat : 2:4.2.14+dfsg-0+deb8u5
 Table de version :
     2:4.5.8+dfsg-1 0
          1 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages
     2:4.2.14+dfsg-0+deb8u5 0
        500 http://security.debian.org/ jessie/updates/main i386 Packages
 *** 2:4.2.14+dfsg-0+deb8u4 0
        100 /var/lib/dpkg/status
     2:4.2.14+dfsg-0+deb8u2 0
        500 http://ftp.fr.debian.org/debian/ jessie/main i386 Packages
Il installera la mise à jour de sécurité depuis le repository security.debian.org même si c'est pas la version la plus récente, car c'est celle avec la priorité la plus élevée.


Edit: Et le problème des backports c'est aussi que parfois les dépendances n'arriveront pas à être résolues à cause de conflits et du coup rien ne sera fait.
"apt-get upgrade" te mettre même un "les packages suivants ont été conservés" (en FR) mais il faut en fait comprendre qu'il a lamentablement échoué à résoudre les dépendances et qu'il a cessé la mise à jour des packages en question.

Dernière modification par Lael ; 07/04/2017 à 22h12.
Citation :
Publié par Caniveau Royal
Ce que je ne savais pas, c'est ce qui se passerait si derrière un jour quelqu'un faisait un apt-get upgrade, tout ce qui en découlerait alors. Ça doit patcher le Debian 7 avec plein de bouts de 8 et tout rendre instable, en fin de compte, non ?
Ou bien on peut mettre des backport comme on veut ?
Il n'est pas conseillé de multiplier les backports, même si ça résiste généralement très bien à des apt-get update (qui n'ira chercher que le strict nécessaire dans les backports).
Message supprimé par son auteur.
Citation :
Publié par SiroTeur
Mais récemment, par exemple, des boites comme OVH, qui vient de racheter l’activité Cloud de VMware, et Oracle viennent de signer avec Canonical pour fournir Ubuntu.
Si des entreprises signent des contrats avec Canonical en ce moment c'est entre autres parce que ces derniers se rappellent à leurs bons souvenirs pour des histoires de licence (vous n'avez pas le droit de fournir un kernel modifié* tout en gardant le logo et le nom Ubuntu sans payer).
Vu que la demande pour de l'Ubuntu préinstallé existe, les hébergeurs signent (en râlant plus ou moins) et ça fait plein de communiqués de presse de signature de contrat qui donnent l'impression que Ubuntu se généralise, alors qu'ils ont toujours été présents.

* selon les techno de virtualisation/container, il est parfois nécessaire d'utiliser un noyau différent de celui fourni par une distribution.
Message supprimé par son auteur.
Mon propos ne porte pas sur le fait que les gens râlent, mais sur le fait que si il y a eu des annonces sur du des contrats Ubuntu récemment, c'est parce que Canonical est allé les chercher et pas pour une évolution du marché des distrib influencé par le développement du cloud, actuellement en tout cas.

Ça pourrait évoluer avec un développement du VDI (peu de distrib desktop proposent du support, donc Canonical a des atouts à faire valoir, l'abandon d'Unity me surprend dans ce contexte d'ailleurs), mais actuellement c'est quasi uniquement du Windows que je vois.
Citation :
Publié par Caniveau Royal
Qu'est-ce qui oriente aujourd'hui ceux qui installent leurs distributions Linux ?
Comment font-ils leur choix aujourd'hui ? Qu'est-ce qui les attire chez l'un, les révulse chez l'autre ?
L'UX au quotidien.

Depuis que je suis passé sous Linux (il y a presque deux ans), je suis toujours resté sur des distributions basés sur Ubuntu. Sur le desktop, je suis resté 1 an avec Elementary OS 0.3 puis j'ai migré sur Ubuntu 16.10 et sur le laptop, je suis sur Mint 18 depuis le début (juillet 2016). J'ai testé Debian plusieurs fois, mais j'avais pas spécialement accroché à Gnome (je sais, ça se change) et surtout, les dépôts sont très (trop?) "ancien". Du coup, un des trucs les plus cool de Linux (la gestion des paquets) par rapport à Windows, bah ça devient la galère. Tu passes ton temps à devoir rajouter des dépôts à la main (sans apt add-repository) ou à installer via tarball

Puis, à défaut d'être superbe, je trouve Unity très effiace et, vu que j'ai une centaine de jeux sur Linux, je me suis dit que ça serait certainement plus facile sur Ubuntu avec le support officiel de Steam. Enfin, je me souviens m'être pris la tête aussi avec le shell et sudo sur Debian. Bon après, c'était il y a plus d'un an, j'étais encore un noob.

Avec Debian, j'avais plus l'impression de me battre avec l'OS beaucoup trop souvent, alors avec Ubuntu/Mint, It Just Works. Elementary OS ça marche plutôt bien (peut-être même mieux qu'Ubuntu), mais vu que c'est basé sur Ubuntu 14.04 (ou .10 je sais plus), bah comme pour Debian, tu te coltines des dépôts du siècle dernier et c'est relou.

M'enfin, j'attends quand même avec impatience la prochaine version de Debian.
Citation :
Publié par Caniveau Royal
Qu'est-ce qui oriente aujourd'hui ceux qui installent leurs distributions Linux ?
Comment font-ils leur choix aujourd'hui ? Qu'est-ce qui les attire chez l'un, les révulse chez l'autre ?
Contrairement @Clap², je sépare les deux sujets.
On a d'abord le socle système sur lequel on va vouloir pouvoir configurer son GRUB, son système d'initialisation, son système de gestion de paquets, ...
Ensuite on a l'UX qui doit être plus ou moins facile à changer/modifier en fonction du socle (en général, c'est facile).

Pour le socle, j'en ai essayé quelques uns. Ubuntu, Debian, Crunchbang, Manjaro, ...
Au final, j'ai décidé d'adopter Archlinux. A cela plusieurs raisons :
  • La documentation du wiki, rien d'équivalent nulle part ailleurs
  • Le AUR, le système de packaging communautaire le plus abouti et réutilisé même par d'autres distributions
  • Le système de mise à jour en rolling-release qui me permet d'être sur les dernières nouveautés à chaque fois
  • La taille de la communauté et l'activité dont elle fait preuve (en lien direct avec la qualité du wiki)
  • La souplesse de la distribution vis-à-vis des DE et de la customization du socle système
Depuis que je suis sur Archlinux, je dois souligner que j'ai plusieurs fois perdu mon OS (suite à des mises à jour toute bête ou à des fausses manipulations) mais j'ai su systématiquement remonter et récupérer mon OS sans pertes de données et ça grâce à la politique mené par Archlinux. L'utilisateur doit comprendre comment Linux fonctionne à peu près pour pouvoir installer son Archlinux.

On ne peut pas en dire autant de Windows (ou de Ubuntu).

Sur le DE, je suis sur KDE. Quand ils sortiront la 5.10, si je suis motivé, je ferai un post ici d'une démo/présentation de KDE.

PS : un graphique rigolo mais périmé.
Bah tiens j'en profite.

J'attend de me trouver une bonne excuse pour changer de pc et de passer sur Linux. Je connais déjà un peu (mais pas trop) du coup ce sera sans dual boot et j'hésite entre deux distrib, Fedora et Manjaro.

Fedora est celle que j'ai utilisé le plus longtemps mais y'a longtemps (Fedora 12-15) ça marche nickel, pas trop compliqué à prendre en main* mais un copain tente de me vendre du rêve avec les features de Manjaro (dont AUR) et... ça marche pas trop mal.

Je connais Arch de réputation et je sais que si ça pète je ne saurais pas réparer, mais Manjaro est quand même bien tentant.

Bref, vous conseillerez quoi? Rester sur Fedora que je connais un peu ou tenter l'aventure Manjaro que je connais pas mais qui a l'air de faire jouir mon pote à chaque instant de sa vie?

*Sauf quand ta carte son est pas reconnue et que c'est le cas sur toutes les distribs Linux, Creative Sound Blaster Z pour les curieux
Un truc qui m'a fait tiquer dans le comparatif : c'est de dire que fedora est une version de test pour la distribution Redhat enterprise. C'est vrai mais ça ne veut pas dire que Fedora n'est pas un système stable. Il faut plutôt le voir comme le laboratoire de la future version de RHEL.

L'autre truc est à propos du contenu avec "licence" : ok, ce n'est pas dans la distribution fedora de base. Mais il suffit d'ajouter un repository ou deux et le tour est joué. La question c'est comment fait archlinux pour mélanger des composants avec des licences qui peuvent être incompatibles.
Message supprimé par son auteur.
Citation :
Publié par Metalovichinkov
Bref, vous conseillerez quoi?
Si Linux t'intéresse, manjaro peut être sympa (mais tu pourrais en faire tout autant avec une autre distrib), si tu veux juste que ça fonctionne fedora/ubuntu (et dérivés Mint/Elementary...)
Citation :
Publié par Metalovichinkov
Manjaro VS Fedora
D'une optique purement gamerz : Manjaro rechigne à lancer certains jeux "natifs Linux". Je pense à X-Plane 11, Devil Daggers, et une poignée d'autres.

Je n'saurais comparer avec Fedora ni dire si cette info te sera pertinente.
Je connaissais pas ce topic tiens, ça tombe bien.


Je suis en pleine réflexion en ce moment, je compte me monter un petit serveur sous peu, principalement pour expérimenter et mettre les mains dans le cambouis. Parmi les rôles qui seront endossés : serveur web, base sql, serveur de fichiers, tunnel SSH, voire serveur d'authentification.

Concrètement je cherche une distro assez hardcore, avec pour objectif d'en apprendre le plus possible sur l'architecture des OS GNU/Linux : le strict minimum d'installé, pas de GUI...

Etant en DUT j'ai quelques notions sur Linux vu qu'on s'en sert tout le temps ou presque (pour des raisons obscurs nos cours de SQL se font sur Oracle sur Windows), mais en termes de sysadmin pour l'instant on n'a rien fait ou presque. On utilise Arch, et les profs ont l'air d'en être très satisfaits, mais j'aimerais un avis extérieur. De mon coté j'ai une VM Debian qui me sert à bosser, mais j'ai jamais vraiment touché à l'OS, si ce n'est installer quelques paquets pour pouvoir dev.

Des recommandations ?
Selinux ... C'est complexe à mettre en œuvre et au final presque personne ne l'utilise (je ne parle pas du mode permissif qui ne sert à rien). Regarde plutôt du côté des container si tu veux faire de l'isolation d'application (docker ou autre)
Ça dépend dans quel domaine on bosse : perso toutes mes machines d'infra doivent être durcies.
Mieux vaut se frotter à SELinux quand on apprend, et là il est clairement dans les cas d'école (serveur de fichier, serveur web, bdd) qui sont très bien documentés. Ça n'empêche pas, bien au contraire, de faire fournir des services avec des containers, pour comprendre ce que chaque approche apporte.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés