"Hi, today we've made the first release of OSv, a new operating system for running applications on virtual machines."
Un nouvel OS vient de sortir dédié au cloud. En bon français, on pense que cela ne marchera jamais rien qu'à cause des drivers pléthoriques à écrire (en C++). Mais eux visent uniquement les environnements virtuels. Cela limite donc le développement à 1 ou 2 plateformes (kvm, xen). 2 des codeurs sont des codeurs de KVM.
L'OS est dédié à ne faire tourner qu'une seul tâche sur un VM, comme par exemple une JVM, pour des raisons de simplicité et de performance.
"OSv can run ordinary Linux shared objects, such as, for example, an
unmodified JVM (e.g., OpenJDK) executable, and of course on that you can
run any application written in Java, JRuby , Clojure, or any other JVM
language. Even at this early stage of OSv's development, OSv can already
successfully run several interesting workloads such as Netperf, Memcached,
Cassandra and SpecJVM - and usually match or even beat Linux's performance."
L'annonce : http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010649.html
Le site : http://www.osv.io/
Les sources : https://github.com/cloudius-systems/osv
une news : http://www.linux.com/news/featured-blogs/200-libby-clark/748578-osv-the-open-source-cloud-operating-system-that-is-not-linux
PS: Je ne peux pas résister à un lâcher de troll : Est-ce que réinventer un DOS (monotâche), écrit en C++, pour lancer des applications Java en 2013, est une bonne chose ?
PS2: Cette annonce m'excite plus que la sorte de Linux 3.12, enfin un peu de nouveauté !
# LCE: The failure of operating systems and how we can fix it
Posté par navaati . Évalué à 2.
Un lien : http://lwn.net/Articles/524952/
[^] # Re: LCE: The failure of operating systems and how we can fix it
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"Containers, while may be a great idea (and personally, I'm a big fan of that idea), are simply not a solution to the same problem."
http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010663.html
"La première sécurité est la liberté"
# ==
Posté par lordblackfox . Évalué à 1.
Merci pour l'info; Mais:
Donc "pléthorique à écrire" ça ne veut rien dire.
De plus on n'est pas vendredi? Parce que bon, on tape assez bien sur le C++, mais on oublie que tout dépend de comment tu l'utilises. À côté de ça, on surkiffe le C, dans lequel on implémente une couche "objet" de façon crade (oui oui, les pointeurs de fonction dans des structures, bien lisibles, qu'on retrouve dans le noyaux Linux)… Grave.
kiss
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
pléthorique se réfère à "drivers"… c'est pas compliqué, c'est le mot d'avant.
Le "problème" de c++, c'est les appels à la création de mémoire caché à l'utilisateur (selon Linus).
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3.
Ah c'est ça le problème ? De quels appels caché parle t on ?
Personnellement je pense que C++ est probablement le meilleur langage pour écrire un OS.
Mature et performant, quoi demander de mieux ?
(On me souffle dans l'oreillette plus facile et plus sûr, mais on peut pas tout avoir. :-) (et C n'est pas plus facile ou plus sûr. Plutôt l'inverse) )
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"De quels appels caché parle t on ?"
De mémoire, il me semble qu'un passage d'objet par valeur fait un appel à calloc/malloc.
"(et C n'est pas plus facile ou plus sûr. Plutôt l'inverse)"
ça c'est faux. Il suffit de voir la taille des normes respectives.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3.
Oui en effet, il est possible que le constructeur de copie de certains object alloue de la mémoire. C'est la responsabilité du développeur de le savoir. Il doit connaître l'API des object qu'il utilise et c'est documenté.
Mais bon, pour utiliser un langage il faut l'apprendre. Un peu comme si je disais "Le problème en C c'est que ça crash tout le temps"
La taille des normes ne veux rien dire. C'est parce que le C++ a une plus grosse bibliothèque standard qui fait plus de chose. Le standard est plus gros car le développeur dois faire moins.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à -8.
Y'a pas de lib standard en C++ ou presque.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Stibb . Évalué à 3.
si, elle s'appelle la librairie standard
[^] # Re: ==
Posté par lordblackfox . Évalué à -3. Dernière modification le 18 novembre 2013 à 22:43.
Nicolas, je suis désolé, mais ton nom de va à merveille.
calloc/malloc pour passer des variables par valeur? Y'a pas de lib standard en C++? NC.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La lib standard de c++ est tellement plus grosse que celle de C, que personne n'a écrit boost ou Qt, c'est connu.
Je ne sais plus quelle fonction d'allocation mémoire est appelé exactement par le code compilé, mais il suffit de lire le code assembleur, c'est marqué dedans.
Concernant la vanne éculé sur mon nom, ta de la chance de n'être pas en face de moi :)
"La première sécurité est la liberté"
[^] # Re: ==
Posté par barmic . Évalué à 3.
Et tu va dire que la libc n'existe pas parce que sinon GObject n'existerait pas par exemple ? Tu te rend compte que tu avance des choses fausses en voulant faire un euphémisme et pour l'expliquer tu avance des arguments bidons ? Que la bibliothèque standard du C++ soit light et n'adresse pas suffisament de cas d'utilisation, ça peut se discuter, le fait qu'elle n'existe pas est tout simplement faux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Je ne dis pas qu'elle n'existe pas, je dis qu'elle n'est pas plus riche que celle du C. Donc, que cela n'explique pas du tout la différence de la taille de la norme, qui est l'argument de départ.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 4.
Pourquoi tu dis que c'est anodin ? C'est si difficile à comprendre que chaque opération est un appel de fonction ?
Ces deux postes ont déjà été écrit maintes fois. Les postes n'ont aucun arguments et sont juste des préférence. « Ugly » et « Utter crap » ne sont pas des arguments. Linus a l'habitude du C et il est trop vieux pour changer peut être. RMS m'aime peut être pas le hard rock (« too harsh »), ça m'empêche pas d'en écouter.
Bha il me semble que ce projet le prouve.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 18 novembre 2013 à 14:32.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 5.
C'est caché pour quelqu'un qui ne connait pas le C++ peut être. En attendant, le code en C++ est plus clair et moins prône à l'erreur.
Non, ce que je vois c'est juste les délires d'un vieux grincheux qui a peur de ce qu'il ne connait pas. Il n'y a que du subjectif dans son mail et aucun vrai argument..
Parce que ils ont été écrit dans les années 90 avant même que C++ ne soit standardisé.
Maintenant on est en 2013, il faut évoluer.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 1.
C'est très discutable, en tout cas maitriser la norme C++ et ses sous-ensembles est humainement impossible.
La légèreté du C a l'avantage de permettre d'en connaitre ses limites et de prédire exactement son comportement (en C++ c'est vite difficile, même pour un expert).
Avoir du C standard est plus rapide à porter sur n'importe quelle architecture, pour le C++ le travail sera plus long (ou limité à une fraction du standard).
Cet avantage est énorme pour les systèmes embarqués et de facto pour la conception d'un noyau.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3. Dernière modification le 18 novembre 2013 à 15:55.
C n'est pas facile non plus. Même les experts on du mal a prédire son comportement. (undefined behaviour, ….)
Même Linus se fait avoir: http://lwn.net/Articles/478657/
Euh non, pourquoi ?
Sinon j'ai trouvé des exemples de OS écrit en C++: Symbian / Haiku.
Les nouveaux OS ne sont plus écrit en C
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Un comportement indéterminé l'est par la norme, l'objectif est de dire :
"Cette instruction est interprétée comme le souhaite le compilateur pour simplifier l'implémentation". Cependant tu peux connaitre la liste des comportements indéterminés et savoir ainsi si une instruction donnée ne devrait pas être réécrite pour avoir le comportement souhaité.
En C++, c'est bien plus délicats. Et c'est sans parler de la correspondance instruction / binaire qui est également délicat (et pour un noyau, c'est gênant, en embarqué tu dois parfois regarder le binaire généré…).
Bah si, c'est un fait que le C est plus rapide à porter sur une architecture donnée (ou alors tu m'expliques comment un langage avec une norme de 1700 pages fait pour être porté plus vite qu'un langage de 700 pages de normes…).
Je n'ai pas dit que ça empêchait le C++ d'être utilisé pour faire un noyau mais que ce n'était pas sans inconvénient. Bref, le C n'est pas parfait et le C++ non plus.
[^] # Re: ==
Posté par Antoine . Évalué à 4.
Tu peux, mais ça reste chiant. Sans compter que tant que ça marche sur certaines versions de certains compilateurs, tu n'es pas forcément au courant qu'il y a un problème latent.
On confondrait pas deux choses là ? Porter un langage (compilateur + runtime) vs. porter un programme écrit dans ce langage ?
Et si on réinventait l'eau tiède en passant ? :)
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2. Dernière modification le 18 novembre 2013 à 16:25.
Non, en C++ c'est exactement pareil.
Dans les deux cas il y a des nuances compliquées. (Mais c'est normal que un expert en C qui ait des années d'expérience en C comme Linus soit plus habitué au nuances du C qu'à celle du C++.)
Pareil en C et C++.
Un code en C est en général plus verbeux qu'un code en C++. Donc je dirais que c'est l'inverse.
Parce que tu ne réécris pas le compilateur quand tu porte. Tu réécris seulement le backend. Par exemple, dans le cas de LLVM tu ne réécris que la partie de génération de code, qui est la même pur C et C++
Oui, mais le C++ est mieux. Plus confortable et plus sûr.
C'est pour ça que je pense que le C++ est le meilleur choix.
(Pas qu'il est parfait, et peut être que dans 5 ans il existera un meilleur pour faire un OS. (rust?))
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 1.
Sauf que je reviens dans mon exemple, tu peux appréhender les 700 pages de la norme du langage C pour connaitre ses limites et les nuances délicates. En C++ tu ne peux pas, pas de manière aussi exhaustive.
Bof, comme il y a moins d'instructions, et encore moins d'instructions trop éloignées de la machine, le code assembleur provenant du C est plus proche que ce que le programmeur C a écrit que le gars avec le C++. Bien que le compilateur optimise beaucoup par endroit.
Je connais un minimum l'architecture des compilateurs, merci.
Cependant je te signale que GCC et LLVM ne sont pas les seuls compilateurs du monde, les fondeurs de nouvelles architectures créent souvent le leur.
Bof, là encore je pense que c'est discutable par moment.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
Raté, Je connais mieux le C++ que le C.
Personne ne peux connaître parfaitement aucun des deux standards. Si tu n'utilise pas les exception ou ne fait pas de métaprogrammation, tu peux sauter cette partie.
Petit jeux: si tu prédends si bien connaître le C, voici un petit exercice: trouve l'erreur dans ce code en C
Meilleure vérification des types, smart pointers, destructeurs, templates (au lieu de macro non sûr), et j'en passe. Je ne vois pas comment tu peux discuter ça.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 18 novembre 2013 à 17:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 1.
Bien vu, c'est une erreur de compilation. (Le K&R c'était pour induire en erreur :-)). Mais tu vois quel est le problème?
(Après avoir corrigé le warning avec
s/complex /double complex /g)[^] # Re: ==
Posté par Tonton Th (Mastodon) . Évalué à 1.
Un ++ mal placé ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 7.
Je veux montrer que même le C est compliqué et a des messages d'erreurs difficile à comprendre.
En général on fait
Et on se retrouve avec une erreur de compilation incompréhensible dans
monheader.hPar ailleurs, le brainfuck par exemple a une bien plus petit standard, mais ça n'en fait pas un langages plus facile.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3. Dernière modification le 18 novembre 2013 à 18:28.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 5.
Et moi je prétends au contraire que tout développeur C utilise parfois des variable d'une lettre. Qui de nous deux à raison ?
Pour la majuscule ça dépends du coding style. Par exemple, dans LLVM, les variables commencent par une majuscule. Et il y a beaucoup de variables d'une lettre.
(Hop, un contre exemple pour ta proposition. Arrivera tu a trouver un exemple de projet dans lequel il n'y a aucune variable d'une lettre?).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 1.
Bah c'est facile, ma sœur de 5 ans peut mieux connaitre le C++ du C si je lui apprends les bases du C++.
Je parle personnellement de connaitre de manière exhaustive un langage, ça n'a rien à voir avec la connaissance relative d'un langage par rapport à un autre (qui dépendra de tes goûts et de ton parcours).
Ton code est foireux pour plusieurs raisons :
Tu en veux d'autres ?
Ah des histoires sympas sur le débogages de template, il y en a des sympas. ;)
C'est loin d'être aussi idyllique.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3.
Tu parlais de moi. Pas de ta sœur.
Mais personne (pratiquement) ne connais de manière exhaustive le C.
Non. Pas déprécié, juste facultatif.
Interdite par qui ? Pas par le standard en tout cas. (même si les fonction sans protoype sont marqué comme obsolète, ils font toujours partie du standard. C'est loin d'être interdit)
Non plus.
J'utilise une macro (car
Iest une macro). Et le truc c'est que c'est pas évident de voir en lisent le code ou les message d'erreur que c'est le cas.Oui je veux bien.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Ah pardon, mais je n'ai jamais dit que de mieux connaitre le C++ que le C est impossible, mais que connaitre exhaustivement l'un des deux est totalement impossible. C'est une nuance importante.
Il y a des gens assez fous pour mieux connaitre le Cobol que le Python ou le C tu sais… Ça ne veut pas dire que c'est un langage simple !
Non, très peu, mais se référer à la norme est plus simple et la lecture d'un code fait appel à moins de notions.
Et le C++ est problématique car tu as pas mal de manières de faire une tâche donnée, ce qui peut rendre le code plus sale.
C'est vrai, soyons précis.
Mais personnellement je fais du code portable, donc j'évite de dépendre de fonctionnalités présentes dans un seul compilateur. Surtout, comme ici, où la fonctionnalité est peu utilisée et assez gadget.
Hum non, la norme ANSI a justement interdit certaines écritures bien sales.
Le problème est que certains compilateurs comme GCC comprend ces codes d'avant la normalisation et les accepte, ça ne signifie pas que c'est utilisable.
Essaye de compiler un tel code avec -ansi et -pedantic en options, tu verras que tu seras plus limité dans ces aberrations.
Merci mais ici la macro I est une constante.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 4.
GCC et Clang acceptent sans problème le style K&R, et le même le fait d'omettre le type de retour n'est qu'un warning. Normal le standard dit que c'est autorisé.
Oui mais on peux redéfinir des constantes dans une autre scope. Si
Iétait juste une constante, le code compilerais sans problème. Le problème c'est que les macros polluent tout et ne respectent pas les scopes.Enfin de toute façon c'est du pinaillage. Mais ça prouve que même si le C est simple comme tu dit. Tu ne connais pas tout non plus. (Pour ta défense, tu n'as jamais dit que tu maîtrisais tout le C).
Bah tout les langages de programmation on plusieurs manières. là encore C et C++ sont au même niveau.
Bref, tout les inconvénients que tu attribues au C++ le sont juste parce que tu a plus d'expérience en C. Et tu passe totalement à coté des nombreux aventages du C++.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 4.
Bon tu m'as eu. Malgré tout ce que j'ai pu lire sur le sujet, bah c'est faux.
Après, c'est vraiment un style de notation désuet et peu courant de nos jours. J'admets ma connerie.
En effet, je ne maitrise pas tout et je le sais que trop bien. Maitriser un langage parfaitement demande énormément de temps.
Note que si le C n'est pas simple (ça je le sais), le C++ n'est pas mieux (il a aussi sa dose de zones d'ombres).
Non vraiment, le C++ c'est à un autre niveau d'ensemble et de sous-ensembles. C'est son avantage et son inconvénient, il est plus complet mais forcément plus lourd et avec plus de mal à faire une conception homogène.
[^] # Re: ==
Posté par needs . Évalué à 2.
J’essaye, de mémoire et avec l'aide du manuel :)
Il manque du contexte mais déjà je dirais qu'il manque la fonction
main().Ensuite d'après le
man complex.h,Iest déjà définit donc c'est une très mauvaise idée d'utiliser ce nom pour une variable.Autre chose : La façon dont est défini la fonction est du C K&R non ? Alors que la forme suivante est introduite par le C99 :
Je ne sais pas si c'est strictement une erreur, mais c'est surement une incohérence. De plus,
complex.hsemble être aussi introduit par C99.Au niveau des détails, je penses que c'est mieux de s'assurer que
Cn'est pasNULL, avec par exemple :[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Oui, le style pré-ANSI est totalement incompatible avec complex.h et la déclaration en dehors du début du bloc de fonction.
Puis en plus, complex.h n'a jamais été vraiment utilisé (fonctionnalité assez inutile) qu'il a été déprécié pour le C11…
[^] # Re: ==
Posté par flan (site web personnel) . Évalué à 2.
J'ai un peu du mal à comprendre pourquoi on peut maîtriser parfaitement un langage de 700 pages, mais pas un langage de 1 700 pages. Ok, il y a un facteur 2,5 entre les deux, mais ce n'est pas énorme.
Ou alors, on ne peut pas maîtriser parfaitement un langage décrit sur 700 pages, ça ne me semblerait pas délirant.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il y a bien plus de fonctionnalité en C++, rien que les templates définissent un deuxième langage complet.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Tu négliges la complexité des pages en plus. Le C reste un langage petit et léger qui pourrait être un langage d'assemblage moderne.
Le C++ est bien plus vaste, avec pleins de fonctionnalités, d'ajouts et de mode de pensées différentes en son sein.
Typiquement, une fonctionnalité très appréciée est le template mais ça induit une complexité énorme derrière et son usage est particulièrement vaste en terme de possibilité comme en difficulté dans sa gestion et le débogage.
Et puis personnellement, déjà que 700 pages ce n'est pas facile à avaler (une norme n'est pas écrite comme un roman), le facteur 2,5 en plus en prend un coup supplémentaire…
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 1.
C: a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language
Parce que des macro c'est plus facile à débugger peut être ?
Au moins les templates sont typées et pas avec des
(void*)à tout bout de champs.Bref, plus sûr et plus confortable. (Et pas plus compliquée que d'autre notions du C)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Le C est souvent décrit comme le nouvel langage d'assemblage car :
* Le C est portable ce qui est un grand avantage en terme de développement, notamment dans les systèmes embarqués qui utilisent encore un langage d'assemblage ;
* Le C est plus haut niveau ce qui est plus simple d'accès mais pas trop, il est suffisant pour les besoins de bases ;
* À cause de ces données, le langage C remplace de plus en plus les langages d'assemblages aux rares endroits où ils étaient très présents : les systèmes embarqués ;
C'est un peu comme le fait que Python est décrit comme le nouveau Basic, non à cause de leurs propriétés, mais que l'un remplace l'autre dans un contexte où l'autre dominait par le passé.
[^] # Re: ==
Posté par barmic . Évalué à 2.
J'entends plus souvent parler de forth comme langage d'assemblage (avec la particularité d'utiliser une pile plutôt que des registres).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
C'est surtout qu'en règle général, chaque instruction C se mappe plus ou moins directement avec des instructions assembleurs, et que cela ne va jamais générer un truc énorme ou à problème potentiel (allocation mémoire, GC, insertion de boucle, etc…).
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Moonz . Évalué à 2. Dernière modification le 19 novembre 2013 à 07:52.
Oui, quand les choses commencent à devenir vraiment bizarre avec les macro tu peux sortir
cpppour voir ce qu’il se passe derrière. C’est quoi l’équivalent pour les templates C++ ?Et je ne comprend pas ta critique des macros dans le débat C/C++. C++ a exactement le même préprocesseur que C.
Je serais curieux de savoir quelle notion de "compliquée" de C n’existe pas en C++…
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
Bah le compilateur. Quand il y a un truc louche il te donne une erreur détaillée avec une « backtrace » des instentiations.
Pour quelqu'un qui connais bien le C et n'a jammais appris le C++ je comprends que les templates peuvent parraître difficile. Mais un dévelopeur C++ est sensé apprendre le language pour l'utiliser. Après la lecture du chapitre « template » du bouquin qu'il utilise pour apprendre le C++, les templates ne seront plus une bête noir qui fait peur.
Les notions compliquées du C existe aussi en C++ mais elles sont moins importante.
En C++ on fait moins appel au préprocesseur pour implémenter des conteneurs ou méthode générique car on a les template en C++.
En C++ on fait moins de casting vers
void*car on a un système de type correct, et donc on a moins de problème de type aliasing ou de se tromper de type ou se genre de chose. En C++ on a des smart pointer et donc on a moins de problème de memory leak.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3.
Qu'est-ce que tu essaye de démontrer ?
Oui, il y a des pitfals en C++ comme en C.
C++ est plus gros et a donc plus de pitfals. Mais un développeur normal n'utilise pas tout le langage et en particulier n'utilise pas de la même manière les fonctions du C. Mettant les deux langage à égalité en pratique.
Par contre, les fonctionnalités du C++ rendent le dévelopemment plus confortable, moins fastidieux, et plus sûr. Ce qui rends le langage C obsolète face au C++.
Le C n'est plus simple que pour quelqu'un qui a plus d'expérience en C et peu en C++. La bonne nouvelle c'est que l'expérience s'aquiert vite quand on y met du sien.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"Oui, il y a des pitfals en C++ comme en C. "
Non, il démontre qu'il y a tous les pitfals C en C++, plus un gros paquet d'autre qui n'exite pas en C. Et que dire le contraire, c'est juste du "Fanboyisme" de base.
C++ est un langage rapide, mais est sans doute le langage le plus compliqué qui existe, avec un paquet de notion différente.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
Il n'y a pas tout les pitfals.
Par example:
Et tu me dira que c'est du K&R et que personne utilise ça et tu auras raison. De la même manière, le C++ s'utilise différamment et les pitfalls du C ne sont donc pas directement gênantes en pratique.
Par ailleurs, si tu veux un langage sans pitfals, tu prends le brainfuck. Une spécifications qui tiens en une page, clair et facile à comprendre. Mais ça ne rends pas la programmation plus facile.
De même, le C++ est plus complex que le C, avec plus de pitfalls, mais en même temps plus facile à utiliser.
Je conseil aux « fanboys » C comme toi de lire un bouquin pour apprendre le C++ moderne, et faire un peu de code en C++. Et tu verra que après ça tu ne voudras plus retourner au C.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'ai pas envie de tester mais j'ai du mal à croire que cela compile, vu que a b sont des doubles et que 4 et 5 sont des entiers, après si le cast implicite est accepté, je ne vois pas pourquoi cela ne marcherait pas.
Et je ne vois pas non plus ce que tu trouves bizarres dans ton code. Et tu peux écrire exactement la même chose en C++.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 3.
Ça compile, parce que c'est une fonction sans prototype dont type ne sont pas testé à la compilation.
Donc
barmet des int sur la stack (ou dans les registre) etfooles interprette comme des double et donc ça donne n'importe quoi comme résultat.Le code en C++ interdit la syntaxe K&R, donc tu ne peux pas écrire la même chose en C++.
Autre exemple:
C++ ne compilera pas ce code car on ne peux pas caster implicitment par
void*en C++. Alors qu'on fait tout le temps ça en C.Et d'après toi, qu'est-ce que ce programme affiche ? Tu penses 45 peut être, puisque a et b pointent vers le même entiers. Mais pourtant gcc -O2 m'affiche 108. (Voilà ce qui arrive quand on fait de l'alias de type)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Tu veux dire que le compilo ne vérifie pas le type d'une fonction si la notation K&R est utilisé ?
"Alors qu'on fait tout le temps ça en C"
Euh non. J'ai coder quelques programmes en C (professionnel, qui tournent), et je n'ai jamais eu besoin d'utiliser un "void *", jamais.
"Tu penses 45 peut être, puisque a et b pointent vers le même entiers."
Tu passes par le type "struct A" tout de même. Si gcc ne génère pas d'erreur,cela m'étonnerait beaucoup qu'il ne génère pas de warning avec un code pareil .
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 4. Dernière modification le 19 novembre 2013 à 15:35.
Oui, car la fonction n'a pas de prototype. C'est comme déclarer
Et ni clang ni gcc me donnent un warning. (Il me mettent juste un warning car j'utilise printf sans
<stdio.h>)Tu ne fait jamais appel à malloc ou memcpy ? Tu n'as jamais de callback qui prennent un
void *userdata? Jamais de macro pour implémenter des liste ou table avec des void* un peu partout ?Quel genre de code fait tu?
Essaye et sois étonné. :-) Pas de warning pour moi avec
-Wall(mis a part le fait d'utiliser printf sans inclure stdio, et que j'ai oublié les return)[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"Tu ne fait jamais appel à malloc ou memcpy ? Tu n'as jamais de callback qui prennent un void userdata ? Jamais de macro pour implémenter des liste ou table avec des void un peu partout ?"
Lors de l'utilisation de malloc ou memcpy, on ne donne pas de variable void * à ses fonctions, on les utilise juste.
Niveau call back, j'imagine que c'est pour faire des GUI. J'ai fait un modèle simulant une puce, donc plutôt du traitement du signal. Un driver linux et Un ou 2 firmewares.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
(Je ne sais pas ce que tu essaye de faire avec ton
static_castqui serait si intuitif dans un autre language.)Je n'ai pas dit qu'il était impossible d'écrire des bugs en C++.
Je m'exprime peut être mal car apparemment je n'ai pas été compris.
Ce que je veux dire c'est que en C comme en C++ il y a des difficultés. Mais le langage courrant qu'un développeur C++ est amené à utiliser en pratique est plus simple d'utilisation que le C.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
Mais ce n'est pas un problème. Il n'est pas nécessaire de tout utiliser.
Oui, le C++ est multi-paradigme. Et c'est un avantage.
C++ « makes it harder » grâce au fait qu'il est plus strictement typé et à une bonne gestion des resources (destructeurs). Et je ne comprends pas ce qu'il veut dire par « blows your whole leg off ». Peut être juste parce que le langage est plus puissant. Mais c'est juste une plaisenterie qu'il ne faut pas prendre sérieusement. (Il l'explique ici)
Bjarne à aussi dit:
« There are only two kinds of languages: the ones people complain about and the ones nobody uses. »
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'héritage en diamant est un bon exemple de fonctionnalité qui rend la maintenance d'un gros code complètement cauchemardesque.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par barmic . Évalué à 1.
Ça fait un paquet de temps que je n'en ai pas vu, notamment parce qu'utiliser une délégation (même s'il s'agit d'une délégation du pauvre comparé à ce que propose certains langages) est plus flexible. Il y a des cas classiques (le carré par exemple), mais globalement, je ne fait de l'héritage que pour manipuler le système de type, si ça permet de factoriser du code tant mieux, mais ce n'est pas l'objectif, les cas où tu va avoir à de l'héritage en diamant n'est pas existant mais assez rare du coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui quand tu sais que faire de l'héritage multiple est souvent une mauvaise idée. Souvent, une simple interface fait très bien l'affaire.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par groumly . Évalué à -1.
Tu vois rarement de l'heritage multiple parce que c'est une idee horrible.
Ya une bonne raison pour laquelle c++ est le seul language a offrir ca: c'est une mauvaise solution au probleme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 0.
Tu n'es pas obligé d'utiliser l'héritage multiple si tu trouves que ce n'est pas nécésaire.
En général on en a pas besoin, sauf quand justement on arrive sur un cas où c'est utile. Il est vrai que j'utilise rarement l'héritage multiple. Mais parfois il y a des cas où l'héritage multiple convient parfaitement et on a la chance de l'avoir dans le langage. Là ou dans d'autre language on a besoin de ressortir à des hacks imondes.
(Par contre, je n'ai jamais eu de cas où j'ai eu besoin de l'héritage virtuel)
[^] # Re: ==
Posté par groumly . Évalué à 5.
Ca fait 10 ans que j'écrit du soft a longueur de journée, pas une seule fois je me suis dit "'tin ca serait cool si ma class "véhicule" pouvaitetre a la fois une "moto" et une "voiture"". Parce que c'est un peu a ca que se resume l'heritage multiple.
Le moment ou t'as besoin de ca, c'est quasi certainement parce que t'as foire ton modele objet, et que tu subclasses essentiellement pour partager du code (ou pire, des attributs), ce qui est la premiere raison pour laquelle ne PAS subclasser.
Ensuite, les raisonnement a la "si t'en as pas besoin, l'utilises pas" ca aide pas. Juste parce que Java a fait l'erreur d'être trop simple et pas assez flexible (dans une certain mesure, en tout cas ils auraient certainement pu évoluer en 20 ans), ca justifie pas la foire a la saucisse qu'est le c++.
Ca a un coup sur le temps de compilation (c'est pas pour rien que le c++ est repute pour être monstrueusement lent a compiler), ca a un coup sur la qualité des compilateurs, ca fait chier parce que yaura toujours un gros malin qq part pour se croire plus malin et s'en servir.
Ca construit un monstre a 3 têtes ou chaque ligne de code peut avoir tellement d'implication et de choses cachées que ca devient très dur de comprendre a la fois ce qu'il se passe réellement et quelle était l'intention du developeur.
Empiler les modes de passages d'argument avec des choix de designs plus que douteux (ne t'en sert pas!), les new vs les malloc (ne t'en sert pas!), se retrouver avec une syntaxe non context free parce que quelqu'un a pense que c'était une bonne idée d'implicitement allouer les objets (ne t'en sert pas!), le modèle d'exception foireux (ne t'en sert pas!), les opérateurs surcharges (ne t'en sert pas!), les templates qui te pondent des messages d'erreurs plus long qu'un jour sans pain (ne t'en sert pas!), l'ABI a la mord moi le noeud (ne t'en sert… heu, ouais, la ca va être dur), c'est bien joli, mais ca n'a aucune coherence et toutes ces features que t'es pas cense utiliser, ben un jour tu vas te retrouver avec du code qui l'utilise.
Parce que le gars qui bossait la avant toi se sentait oblige d'affirmer son intelligence supérieure, parce que du code tiers que tu peux pas faire autrement que de l'utiliser s'en sert. Si tu bosses tout seul dans ton coin, oui, tu peux t'en sortir. Mais si tu bosses tout seul dans ton coin, on est en droit de se demander pourquoi tu choisis qq chose d'aussi complique que le c++ pour des gains douteux a cette echelle.
Du C ou de l'objective c te donne du natif rapide qui est très gerable a l'échelle d'une personne, avec autant si ce n'est plus de souplesse, et si tu veux de la flexibilité, va voir du cote de ruby/python ou les JVM languages qui ont le vent en poupe en ce moment.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ==
Posté par barmic . Évalué à 5.
Je pense qu'il y a un gros mélange entre :
void*. C'est le genre de cas où si l'implémentation initiale est simple, la complexité vient après sur la maintenance du code (un code constitué de copier/coller est plus compliqué à maintenir que celui qui possède une grande factorisation).Après je pense que la complexité (quelque soit le type de complexité) n'est pas très important. Implémenter un noyau c'est compliqué (incroyablement) c'est pas pour ça que Linus ne l'a pas fait. Je pense à mon avis que c'est un bon gros geek qui s'intéresse trop au langage (quoi ton batiment est en parpain et pas en brique ?! C'est idiot les parpains moi je préfère reconstruire un batiment en brique plutôt qu'utiliser le tien (en plus c'est que des connards qui utilisent les parpains)). Il n'aime pas l'orienté objet de base et le décrit généralement comme le grand mal, c'est à prendre avec des pincettes lorsque l'on voit de bons logiciels bien fonctionner avec des langages objets. Pour moi une bonne partie de son argumentaire doit être vue comme une querelle de clochet (même s'il peut avoir de bons arguments).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"Mais le C++ apporte des facilités importantes, il permet notamment d'utiliser le système de type comme un outil (les structures de données sont typées par exemple), là où C oblige soit à duppliquer le code soit à utiliser le jocker void*"
Tu as un exemple de pattern pour illustrer ça ?
"La première sécurité est la liberté"
[^] # Re: ==
Posté par zul (site web personnel) . Évalué à 1.
Classiquement, implémenter une liste générique.
Soit tu te retrouve avec une sys/queue.h plein de macros dégeux,
soit tu retrouve avec une API plein de void* (genre g_slist) et là tu peux mettre un peu n'importe quoi dedans
soit enfin, tu reimplémente un template de pauvre en écrivant des macros qui vont générer des fonctions avec dedans le nom du type qui va bien et les bons paramètres.
L'autre truc intéressant possiblement du C++, c'est d'éviter de reimplémenter n fois des vtables de pauvre (genre le vfs, le dispatcher de paquets, et un tas d'autres auxquels je ne pense pas).
Les namespace ne seraient certainement pas une mauvaise chose à priori dans le noyau, plutôt que de préfixer tout par le namespace en question.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En quoi cela duplique le code ?
"La première sécurité est la liberté"
[^] # Re: ==
Posté par barmic . Évalué à 4.
Crée un arbre bicolore pour des
intet pour deschartoute l'intelligence de la structure devras soit être générée via des macro, soit considérée que tout estvoid*, soit être réécrite.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Linux fait comment pour ses read/black tree qu'il utilise un peu partout ?
"La première sécurité est la liberté"
[^] # Re: ==
Posté par zul (site web personnel) . Évalué à 7.
Une variante du void*.
L'idée c'est un truc du genre
On insère les rbnode dans l'arbre avec un rb_insert. Et on utilise la macro magique container_of pour récupérer l'adresse de my_custom en faisant un truc du genre
Évidemment, à ce moment, si quelqu'un a introduit un truc qui n'est pas de type my_custom dans le rbtree, ça va faire n'importe quoi. Et il n'y a rien qui l'empêche (à par la vigilance des reviewers).
Pour info, container_of, c'est
Je n'irai pas jusqu'à dire que c'est une solution simple :) Élégante peut être pour une certaine définition de l'élégance. Mais clairement pas type-safe là ou on pourrait "sans problème" avoir une solution type-safe en C++.
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à -3.
"Mais clairement pas type-safe là ou on pourrait "sans problème" avoir une solution type-safe en C++."
Forcément avec les templates, tu as un langage complet exécuté à la compilation. Par contre, le nombre de cerveau le maitrisant est assez restreint sur terre.
"La première sécurité est la liberté"
[^] # Re: ==
Posté par zul (site web personnel) . Évalué à 2.
Tu me demande une réponse, je t'en donne une. Le code C++ pour faire ça est probablement plus court et type-safe.
Écrire un container avec un paramètre template, ça n'a rien de bien compliqué.
Évidemment, on peut faire des choses très compliqué avec des templates, mais on peut aussi faire des choses relativement simples (sûrement plus que le container_of trick) et qui simplifient la vie (et la correction du code dans ce cas là).
[^] # Re: ==
Posté par dave_null (site web personnel) . Évalué à 5.
Ouais carrément, moi aussi je préfère maitriser mes void * que d'utiliser des templates à bon escient.
Puis ce qui est bien avec les void * c'est que t'as toujours beaucoup de suspense à l'exécution.
[^] # Re: ==
Posté par barmic . Évalué à 2.
Ça illustre parfaitement ce que je dis, le C++ fait partis des langages où le typage est un outil du développeur (puissant et complexe mais un outil) là où en C il est une contrainte : on
castla mémoire dans le type que l'on veut parce que l'on sait mieux que le compilateur ce qu'il y a dans la mémoire. Quand on parle de cast, on sait qu'on a aucune vérification statique et là pour le coup on peut avoir la pire chose possible : mettre n'importe quoi dans la strcuture et que ça continue à fonctionner (un certain temps).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Zylabon . Évalué à 2.
Au mieux un programme est typé, plus il a de chance d'être correct, en C comme dans les autres langages.
L'argument du « quand je fais de la merde le compilateur me demande de mettre des casts partout et après, à l’exécution, le programme fait de la merde » est douteux. Le système de type est un outil du développeur, si le compilateur voit un problème de type, c'est qu'il y a un problème de type (la réciproque n'est pas vraie malheureusement, la faute à un système trop laxiste).
Please do not feed the trolls
[^] # Re: ==
Posté par barmic . Évalué à 2.
Je ne vois pas bien la différence entre « Au mieux un programme est typé, plus il a de chance d'être correct, en C comme dans les autres langages » et « quand je fais de la merde le compilateur me demande de mettre des casts partout et après, à l’exécution, le programme fait de la merde ».
L'idée c'est que le typage c'est un ensemble de validation que le compilateur fait (c'est particulièrement visible lorsqu'on utilise un langage qui a de l'inférence de type). Dans le système de type le
castest une façon de dire au compilateur « nan mais t'inquiète, je sais ce que je fais ne t'inquiète pas c'est moi qui gère » et ça désactive le système de type pour une action donnée.Si le typage est assez sophistiqué pour exprimer ce que tu fait, tu peut faire des programme plus sûr car mieux validé par le compilateur. Alors que les typages plus faibles ou plus basiques donnent plus de travail aux développeurs pour s'assurer de ce qu'ils font et/ou ne pas avoir à dupliquer du code.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 4.
Et encore, il a fallut ressortir des
typeofou des expressions{ }qui sont des extantions GCC non standard. (Forcément, avec un langage minimal il faut des extensions pour faire quoi que ce soit:-))Mais d'après toi il y a plus de cerveau capable de comprendre cette jolie macro que de comprendre cette ligne de code:
[^] # Re: ==
Posté par barmic . Évalué à 2.
N'importe quelle structure de données par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ==
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
En quoi, cela duplique du code ?
"La première sécurité est la liberté"
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2. Dernière modification le 18 novembre 2013 à 16:03.
Mince, double post, désolé.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2. Dernière modification le 18 novembre 2013 à 15:01.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 1.
Bof non, c'est convertit directement en opcode sans appels de fonctions intermédiaires. Donc pas d'allocation sur la pile, pas d'interruption pour charger la fonction et y aller pour y faire des actions…
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
On parlais du C++ là, pas du C. Il s'agit de deux langages différents je te rappel.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 2.
Ça dépend, si a, b c sont des entiers alors l'opération en C comme en C++ a = b + c sera transformé directement en opcodes correspondants. Si en C++ ce n'est pas le cas pour les types natifs, c'est encore pire que ce que je pensais.
[^] # Re: ==
Posté par reno . Évalué à 2.
Tu oublie la surcharge d'opérateur en C++, mais bon typiquement quand on code un OS ce genre de fonctionnalités est interdite.
[^] # Re: ==
Posté par Gof (site web personnel) . Évalué à 2.
Pourquoi l'interdire ? C'est pratique pour des itérateurs par exemple.
En cherchant rapidement dans les sources de OSv, j'ai pas trouvé d'
operator+Par contre, j'ai vu de la surcharge pour==,++,*,->, et<[^] # Re: ==
Posté par lordblackfox . Évalué à 3.
Évite de confondre le code écrit et compilé, ça t'évitera cette erreur (c'est pas pour rien qu'on parle de surcharge).
La surcharge d'opérateur te permet d'écrire de façon plus lisible en disant au compilateur que l'opération est plus complexe qu'une simple opération. Bêtement, la comparaison de chaine de caractère en C++ et en C, ou bien la concaténation. Ce serait crétin de faire un appel de fonction pour des opérations arithmétiques de types natifs.
[^] # Re: ==
Posté par Renault (site web personnel) . Évalué à 3.
Pardon mais avec le contexte je n'ai pas vu de manière si évidente que cela parlait de surcharge d'opérateur.
Je sais bien quel est son utilité. ;)
[^] # Re: ==
Posté par MsieurHappy . Évalué à 2.
C’est pas difficile à comprendre. Mais précisément, c’est un comportement qui n’est probablement pas souhaitable quand on veut minimiser la consommation mémoire et/ou la simplicité du modèle mental. Chaque fois qu’on utilise un opérateur, il faut plonger dans le code pour savoir ce qui se passe réellement.
# un OS entier dans une VM c'est un peu con...
Posté par superna (site web personnel) . Évalué à 6.
Pour lancer plusieurs VMs pour des services simples (postfix, dns, dhcp, …) je trouve que c'est du gachi d'instancier autant de choses pour juste lancer un seul service….
Alors oui c'est un peu extrême ce genre de mono tâche, mais il faudrait un juste milieu, non ?
Même si ça peux être très intéressant pour lancer une tâche dans une pool très large de VMs et les migrer entre serveurs physiques ou les créer dynamiquement, sans avoir à lancer un linux entier
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par karteum59 . Évalué à 3. Dernière modification le 18 novembre 2013 à 16:28.
Entièrement d'accord.
Le "juste milieu" c'est peut-être les containers ? (Jails BSD, OpenVZ, VServer, LXC…)
N.B. j'ai deux VM chez un hébergeur, une en OpenVZ et l'autre en KVM, et j'observe toutefois que le OpenVZ a parfois des limitations, par exemple sur iptables (logique, mais c'est pour souligner que ce n'est pas 100% iso-fonctionnel).
J'en profite pour parler d'un hyperviseur qui semble méconnu, conçu pour le monde ARM (sans besoin de support Hardware comme dans les Cortex A15), et qui se base sur le micro-noyau L4. ça s'appelle Codezero et ça permet apparemment de multiplexer Android et Linux sur une Pandaboard ou un Galaxy Nexus. Je n'ai pas essayé mais je suis preneur de tout retour d'expérience !
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 18 novembre 2013 à 16:42.
Le but est d'utiliser les vendeurs de cloud qui font une abstraction du hardware. C'est impossible à faire avec les containers.
En plus, une VM semble lourde parce que tu penses à linux, osv, semble beaucoup plus simple.
"La première sécurité est la liberté"
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par karteum59 . Évalué à 3.
Quand je regarde la page du repo Github, je comprends que ça tourne au dessus de Linux/KVM (c'est juste que l'OS guest est allégé), donc j'ai du mal à voir comment ça pourrait être plus léger que des containers.
Tu as des hébergeurs qui te proposent une VM OpenVZ et d'autres qui te proposent une VM KVM (souvent les mêmes d'ailleurs, souvent plus cher en KVM). Oui, cet OS nécessite KVM et ne marchera pas sur du OpenVZ. Mais faire marcher cet OS n'est pas un but en soi, c'est l'application qui est un but. En fait, je pense que les corner-case pour lesquels OpenVZ est insuffisant sont des cas où il y a besoin de flexibilité sur le noyau (iptables, etc.), et donc de faire tourner un vrai Linux guest. Je ne veux pas critiquer le projet (c'est déjà bien sympa pour les auteurs de mettre le code en open-source, et ça servira sûrement à des gens) mais à mon niveau je ne vois pas de cas d'utilisation pour cet OS "cloud" qui ne soit pas déjà parfaitement adressé par les containers (N.B. je vais faire un peu de pub, mais chez IperWeb on a une VM OpenVZ pour 1.5 €/mois avec 384Mo de RAM, 12Go de stockage et 2To de trafic ! J'ai pas encore trouvé mieux…).
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
1 core dans le cadre de la virtualisation, cela veut dire quoi ? Il y a une garanti de performance cpu ? Est-ce qu'il y a une gestion de panne hardware avec transfert de l'image sur une machine qui marche ?
"La première sécurité est la liberté"
[^] # Re: un OS entier dans une VM c'est un peu con...
Posté par groumly . Évalué à 2.
Gachis, oui et non.
Oui, car ca bouffe plus de resources, techniquement.
Non, car ca ouvre la porte a une automatisation des environments, et la tu gagnes beaucoup de temps, d'argent et de possibilités. Du temps et de l'argent parce que des environments automatises, ca marche tout seul, ca evite les erreurs humaines et les donc incidents de production qui en découlent.
Des possibilités, parce que des déploiements automatises ca rend les equipes de dev plus autonomes, réduit de beaucoup le temps dev ->production, enleve pas mal de friction dans le déploiement de nouvelles choses et ouvre donc la porte a de nouvelles idées. Le continuous delivery c'est pas juste un fantasme de CTO, ca devient nécessaire de nos jours dans pas mal de domaines consommateurs ou il faut avancer très vite.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.