Quel est le risque d'avoir ls s'il n'y a pas de fs présent?

Quels attributs?

Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !

Comment les préserver?

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)

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.

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.

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)

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 ?

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

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.

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.