Auteur Sujet: Linux (et tous les autres OS) c'est *bientôt* du passé  (Lu 9878 fois)

0 Membres et 1 Invité sur ce sujet

Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 119
  • Sarrebourg (57)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #24 le: 02 septembre 2016 à 01:17:47 »
kgersen, tes idées rejoignent beaucoup ce que fait Lennart Poettering avec CoreOS.

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #25 le: 02 septembre 2016 à 01:20:00 »
Quel est le risque d'avoir ls s'il n'y a pas de fs présent?

PhilippeMarques

  • Expert
  • *
  • Messages: 860
  • SomeWhere
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #26 le: 02 septembre 2016 à 08:06:51 »
Je ne suis pas bien certain de bien comprendre non plus.
Le propos c'est d'avoir des instances de containers dans docker qui tourne dans une VM,d'avoir un "mini busybox" avec une seule application dessus ?

seb

  • Pau Broadband Country (64)
  • Client SFR fibre FTTH
  • *
  • Messages: 511
  • FTTH 100/50 Mbps sur Pau (64)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #27 le: 02 septembre 2016 à 08:49:50 »
Citation de: corrector
Quels attributs?
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !

Citation de: corrector
Comment les préserver?
Citation de: seb
Si tu veux conserver tous ses attributs, tar, cpio ou rsync sont appropriés, mais cp ne l'est pas.
. (avec les options qui vont bien, ça va de soi)

Citation de: corrector
Comment proposes-tu d'utiliser cet attribut, concrètement?
Chez un précédent client, il est utilisé pour déplacer les données peu accédées sur des unités de stockage "lentes", voire de les archiver sur bandes, afin de réduire le coût de conservation de ces données sur le long terme.
Chez mon client actuel, il est utilisé par les gestionnaires d'une arborescence tampon afin d'y faire du ménage.

Tu n'as pas idée du nombre d'entreprises qui utilisent des données en mode WORM et pour lesquelles l'information utile n'est pas de savoir quand le fichier a été modifié pour la dernière fois (puisqu'il est créé sans plus jamais être modifié par la suite), mais quand il a été effectivement utilisé pour la dernière fois.

C'est pas le C spécifiquement que tu ignores, c'est la sémantique Unix, la programmation et l'informatique en général.
Vue ton ignorance sur l'utilité de l'attribut atime, je te retourne le compliment.
« Modifié: 02 septembre 2016 à 09:13:36 par seb »

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 327
  • Malissard (26)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #28 le: 02 septembre 2016 à 09:54:52 »
C'est déjà tout à fait faisable (et fait), que je sache

En VM ? Non car il faut gérer la configuration de l'OS individuellement.

En container, t'as pas ce problème. Tu déploye une appli, point. En X fois, sans t'occuper de savoir où est-ce que ça tourne.
Tout Google fonctionne sur ce principe.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 558
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #29 le: 02 septembre 2016 à 11:35:01 »
Autre facon de voir les choses: on parle de faire tourner des applications et rien qu'elles dans un contexte minimal ou la présence d'un OS et kernel complet n'apporte rien de plus a ces applications. Dans ce cas quel intérêt de garder l'OS et le kernel complet ?
Énorme intérêt : ne pas se taper une stack réseau dans mon serveur web.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 306
  • FTTH 1Gb/s sur Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #30 le: 02 septembre 2016 à 11:49:01 »
Énorme intérêt : ne pas se taper une stack réseau dans mon serveur web.

sauf qu'en pratique on voudrait avec la stack réseau dans le code du serveur web pour pouvoir l'optimiser ou la faire évoluer plus rapidement ce que la stack de l'OS ne permet pas.

exemple typique c'est QUIC: TCP est figé et lent a évolué, si on veut des changements ou faire différent il faut changer TCP coté client et coté serveur dans tout les OS -> c'est quasi impossible. Les seuls changements qui arrivent vraiment partout sont les patchs de sécurité et encore pas toujours. solution de Google avec QUIC: ils ont "refait" eux-memes un sorte de TCP dans les applications (le serveur web d'un coté et Chrome de l'autre) au dessus d'UDP (qui lui reste celui de la stack de l'OS).

C'est ca aussi un gros des avantages des unikernels: on peut faire des changements et des évolution de technos sans dépendre qu'elles soient disponibles au niveau des OS ou des kernels, qui par nature ont une grosse inertie a changer.

On réduit donc la friction au changement due aux kernels et OS.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 558
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #31 le: 02 septembre 2016 à 11:54:34 »
sauf qu'en pratique on voudrait avec la stack réseau dans le code du serveur web pour pouvoir l'optimiser ou la faire évoluer plus rapidement ce que la stack de l'OS ne permet pas.
Oula oula, arrête ton char, c'est tout à fait possible (et encore une fois, c'est fait)

Citer
exemple typique c'est QUIC: TCP est figé et lent a évolué, si on veut des changements ou faire différent il faut changer TCP coté client et coté serveur dans tout les OS -> c'est quasi impossible. Les seuls changements qui arrivent vraiment partout sont les patchs de sécurité et encore pas toujours. solution de Google avec QUIC: ils ont "refait" eux-memes un sorte de TCP dans les applications (le serveur web d'un coté et Chrome de l'autre) au dessus d'UDP (qui lui reste celui de la stack de l'OS).
Tu me parles:
- du windows xp de bobonne; C'est de la merde, ce sera toujours de la merde, et c'est hors sujet
- du "dans tout les OS"; Genre ta boite utilise "tout les OS" ? Et pas seulement une minorité (voir seulement un seul), avec dans tout les cas un seul kernel ?

Citer
C'est ca aussi un gros des avantages des unikernels: on peut faire des changements et des évolution de technos sans dépendre qu'elles soient disponibles au niveau des OS ou des kernels, qui par nature ont une grosse inertie a changer.
Ouais, désolé mais la solution du "le monde est naze, j'vais faire mieux", sur la durée, c'est rarement fonctionnel

vivien

  • Administrateur
  • *
  • Messages: 29 343
    • Twitter LaFibre.info
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #32 le: 02 septembre 2016 à 14:25:17 »
Ca sera bien avec l'IPv6 (Une IP par application), mais avec IPv4, il faut faire du NAT pour que plusieurs applications partagent la même IP.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 306
  • FTTH 1Gb/s sur Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #33 le: 02 septembre 2016 à 14:57:19 »
Oula oula, arrête ton char, c'est tout à fait possible (et encore une fois, c'est fait)
Tu me parles:
- du windows xp de bobonne; C'est de la merde, ce sera toujours de la merde, et c'est hors sujet
- du "dans tout les OS"; Genre ta boite utilise "tout les OS" ? Et pas seulement une minorité (voir seulement un seul), avec dans tout les cas un seul kernel ?
Ouais, désolé mais la solution du "le monde est naze, j'vais faire mieux", sur la durée, c'est rarement fonctionnel

personne a dit le monde est naze on va faire mieux. Je ne comprend pas ton 'braquage' et ton négativisme. Tu juges des projets et technos qui sont a l’état de R&D / prototypes sans essayer de voir plus loin. Ca me rappelle les types qui crachaient sur VMware et autres solutions de virtualisation quand elle étaient encore confidentielles. C'est de la défensive sans ouverture d'esprit. On a vu le résultat.

Y'a pas d'universalité de toute façon. Prétendre que les OS et kernels actuels sont la seule façon valable de faire les choses c'est aussi débile que prétendre que les unikernels seront LA seule solution d'avenir ce que personne n'a prétendu ici. Pour beaucoup de gens qui sont confrontés pour de vrai (et pas en théorie) a des problématiques d' hyperscaling les OS et kernels actuels ne conviennent pas. Tout comme mettre Ubuntu dans un smartphone ou un core router ne convient pas non plus.

Moi je crois a cette voie et cette évolution car elle semble 'logique' et découle naturellement l'évolution introduite par la virtualisation:

barebone -A-> virtualisation -B-> containers -C-> unikernels

Aujourd'hui on est a peine a B avec une grosse partie (>90%) des gens qui ne font pas encore de containers. Ca ne doit pas pour autant empêcher de réfléchir et expérimenter C.

Il ne faut pas oublier que tout cela se place dans le contexte global de l'évolution de l'informatique. De la (re)centralisation due aux datacenters, de la limite récemment atteinte en terme de puissance CPU (par core du moins), etc. Il faut prendre en compte tout ces facteurs et l'impact qu'ils ont sur l’architecture des logiciels qui a leur tour ont un impact sur l'évolution de l'architecture des OS et kernels et du matériel en dessous.

eruditus

  • Client Orange adsl
  • Modérateur
  • *
  • Messages: 9 084
  • Montfort-l'Amaury (78)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #34 le: 02 septembre 2016 à 14:59:20 »
Ces technos/archis sont en train d'envahir des domaines insoupçonnés  ;)

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 306
  • FTTH 1Gb/s sur Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #35 le: 02 septembre 2016 à 14:59:54 »
Ca sera bien avec l'IPv6 (Une IP par application), mais avec IPv4, il faut faire du NAT pour que plusieurs applications partagent la même IP.

Tu peux NATer en bordure du réseau. Rien n'oblige de faire du NAT sur le serveur lui meme.

 

Mobile View