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

0 Membres et 1 Invité sur ce sujet

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #36 le: 02 septembre 2016 à 15:03:01 »
Oula oula, pédale douce !

J'en suis resté à ça :
Citation de: kgersen
De toute facon Linux (et tout les autres OS) c'est *bientot* du passé.

Et au fait que "unikernels" et "container", ça m'apparait comme, techniquement, identique (ou "très proche", si tu veux)
Hors, les containers, ce n'est pas un rêve éloigné de chercheurs fantaisistes, c'est une réalité, chez moi par exemple
Et, en me basant sur cette expérience, non merci

Je veux bien croire que ça marche dans certaines sociétés comme google, chez qui la notion de qualité arrive peut-être à descendre sur tout les niveaux
Chez moi, et comme, il faut l'avouer, chez la plupart des gens, le dev chit, et n'essuie pas.

Je constate;

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #37 le: 02 septembre 2016 à 15:13:34 »
Et, en me basant sur cette expérience, non merci

C'est quoi ton souci d'expérience avec les containers ? souvent les changements/évolutions techniques coincent parce qu'ils sont imposés et subis et pas accompagnés de changements au niveau humain (orga, RH, etc).

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #38 le: 02 septembre 2016 à 15:16:46 »
C'est quoi ton souci d'expérience avec les containers ? souvent les changements/évolutions techniques coincent parce qu'ils sont imposés et subis et pas accompagnés de changements au niveau humain (orga, RH, etc).

Container = évolution géré par le dev = pas d'évolution autre que le code métier = software troué :)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #39 le: 02 septembre 2016 à 15:27:54 »
Container = évolution géré par le dev = pas d'évolution autre que le code métier = software troué :)

T'as eu le cas pratique ? car "software troué" c'est peu facile de sortir ca.

Le truc c'est de bien placé la limite de responsabilité/zone d'intervention.

Y'a des images de containers maintenus et d'autres non, c'est la meme chose avec les packages (apt, yum,etc) . la problématique est la meme et pas spécifique au containers.

Y'a aussi plusieurs facon de gerer les images des containers. Soit tu laisses le dev tout faire , soit tu exiges un Dockerfile et build toi meme.

A mon avis c'est plus un probleme de process/répartition des responsabilités qu'un probleme intrinsèque a la techno. Bref c'est un probleme humain et organisationnel.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #40 le: 02 septembre 2016 à 15:43:10 »
T'as eu le cas pratique ? car "software troué" c'est peu facile de sortir ca.
Je te parle toujours d'expérience hein !

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #41 le: 04 septembre 2016 à 14:42:35 »
Pour ceux qui n'y connaissent pas grand chose (dont moi), peut-on résumer le sujet ainsi?
On peut se passer de l'OS uniquement dans certains cas très particuliers d'applications tournant sur des serveurs.
Mais on ne pourra pas se passer d'OS pour les "clients" (PC, smartphones, tablettes), ni sur tous les serveurs.


Leon.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #42 le: 04 septembre 2016 à 14:49:42 »
Pour ceux qui n'y connaissent pas grand chose (dont moi), peut-on résumer le sujet ainsi?
On peut se passer de l'OS uniquement dans certains cas très particuliers d'applications tournant sur des serveurs.
Mais on ne pourra pas se passer d'OS pour les "clients" (PC, smartphones, tablettes), ni sur tous les serveurs.

C'est ce qu'avance kgersen, si j'ai bien compris

C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer

En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #43 le: 04 septembre 2016 à 15:29:26 »
C'est ce qu'avance kgersen, si j'ai bien compris

C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer

En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé
OK, ce que je comprends surtout, c'est vous êtes tous les 2 bornés, et que vous n'avez simplement pas la même définition de ce qu'est un "OS".
Donc vous avez tous les 2 raison.

Leon.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #44 le: 04 septembre 2016 à 15:31:35 »
OK, ce que je comprends surtout, c'est vous êtes tous les 2 bornés, et que vous n'avez simplement pas la même définition de ce qu'est un "OS".
Donc vous avez tous les 2 raison.

Leon.

?!?

Ma définition est celle de wikipedia, j'ignorai qu'il y en avait une autre:
An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs. All computer programs, excluding firmware, require an operating system to function.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #45 le: 04 septembre 2016 à 16:48:17 »
C'est ce qu'avance kgersen, si j'ai bien compris

C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer

En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé

tu confond machine physique et machine virtuelle la. On parle de machines virtuelles tournant au dessus d'un  hyperviseur.

L'important c'est comment une app ou des apps utilisent les ressources du hardware (mémoire, réseau, disque, etc). Soit t'as un kernel+os directement au dessus du hardware et celui permet le partage des ressources. soit tu rajoute en dessous une couche avec un hyperviseur.

Quand t'as un hyperviseur qui permet le partage des ces ressources entre plusieurs kernels (et OS au dessus de chaque kernel) on peut 'réduire au strict minimum' le kernel (et l'OS) voir les supprimer: l'application s'interface directement sur l'hyperviseur.

Exemple:
kernel = linux
os = ubuntu
app = ping

si je fais une VM qui ne fait que ca (que ping), on est bien d'accord que j'ai un "kernel+os+ping" complet juste pour faire un ping.
Maintenant si je pars du source de ping, je regarde ce que ca utilise au niveau os (fonctions de niveau (3)) et au niveau kernel (niveau (2) syscalls + drivers des ressources utilisées) et je simplifie tout ca en l'intégrant directement dans une seul "binaire executable" appelé "uni-ping". Ce binaire est l'équivalent d'une VM ,c'est comme une image de VM mais ca ne fait que 'ping' et rien d'autre. y'a donc plus vraiment de kernel et d'OS dedans et ca tourne directement sur mon hyperviseur. C'est de ca dont on parle depuis le début.

Bref vu autrement une VM qui fait touner un kernel+un OS peut faire tourner n'importe quoi d'autre. Il faut pas se restreindre qu'aux kernel+OS classiques.

ps: ca serait bien de séparer la discussion sur atime du sujet principal d'ici.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientôt* du passé
« Réponse #46 le: 04 septembre 2016 à 16:52:16 »
tu confond machine physique et machine virtuelle la. On parle de machines virtuelles tournant au dessus d'un  hyperviseur.

L'important c'est comment une app ou des apps utilisent les ressources du hardware (mémoire, réseau, disque, etc). Soit t'as un kernel+os directement au dessus du hardware et celui permet le partage des ressources. soit tu rajoute en dessous une couche avec un hyperviseur.

Quand t'as un hyperviseur qui permet le partage des ces ressources entre plusieurs kernels (et OS au dessus de chaque kernel) on peut 'réduire au strict minimum' le kernel (et l'OS) voir les supprimer: l'application s'interface directement sur l'hyperviseur.

Exemple:
kernel = linux
os = ubuntu
app = ping

si je fais une VM qui ne fait que ca (que ping), on est bien d'accord que j'ai un "kernel+os+ping" complet juste pour faire un ping.
Maintenant si je pars du source de ping, je regarde ce que ca utilise au niveau os (fonctions de niveau (3)) et au niveau kernel (niveau (2) syscalls + drivers des ressources utilisées) et je simplifie tout ca en l'intégrant directement dans une seul "binaire executable" appelé "uni-ping". Ce binaire est l'équivalent d'une VM ,c'est comme une image de VM mais ca ne fait que 'ping' et rien d'autre. y'a donc plus vraiment de kernel et d'OS dedans et ca tourne directement sur mon hyperviseur. C'est de ca dont on parle depuis le début.

Bref vu autrement une VM qui fait touner un kernel+un OS peut faire tourner n'importe quoi d'autre. Il faut pas se restreindre qu'aux kernel+OS classiques.

ps: ca serait bien de séparer la discussion sur atime du sujet principal d'ici.


C'est très clair, merci pour les précisions et les exemples, en particulier quant à la "frontière" du concept

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #47 le: 26 septembre 2016 à 00:54:37 »
T'as jamais vu de faille de secu ou d'exploit en vrai pour demander en quoi retirer ls va "aider"  ? faille dans application ou lib d'OS -> un intrus qui entre peut utiliser les binaires existants (dont ls, rm, etc) pour 'faire' des choses. si y'a pas de binaires autre que l'application -> l'intrus est plus limité dans ces actions (il doit télécharger ou refaire lui même ces commandes via des syscall, mais s'il n'y a plus de kernel y'a donc plus de syscall...ou si y'en a ils sont dans l'app et que ceux qu'elle utilise donc moins de surface d'action.
S'il n'y a plus de syscall, comment marchent les applications?

Ce que tu racontes est très mystérieux.