YBoy360 a écrit 809 commentaires

L'ICE est bien plus récent que le TGV.

La France c'est le pays de le coopération économique européenne. Ariane Espace, Airbus… Ce sont des projets initié par la France.

Même le TGV devait être européen. Je vois pas ce que l'Allemagne à fait d'équivalent.

Xgene2 un processeur armv8 dispose de l'ACPI et de l'UEFI. Mais éviter d'avoir un BIOS qui sert à rien sous linux, c'est pas un avantage? J'avais jamais entendu parlé du BIOS comme un argument de pérennité.. Si c'est ton seul argument à l'encontre d'ARM, ça me rassure.

De plus il y a coreboot qui supporte ARM.

Les serveurs disposent de 2 Gio de RAM et d'un ssd local, sur le pcb du serveur, de 20 Gio.

Je ne dis pas que l'offre est intéressante, elle est pas la moins cher, je dis juste avoir été surpris des performances d'un ARM v7 a 1.3 GHz.

Une application d'entreprise typique peut être utilisable. C'est tout. Et je trouve que c'est rassurant pour notre liberté de choix dans le future, concernant les CPU.

En pratique un Snapdragon 801 explose tout ce que fait Intel en rapport prix performance, avec un procédé de fabrication moins performant.

A procédé de fabrication égale, ARM a un rapport consommation sur performance plus faible. Ce qui sauve Intel, ce sont les 500 ingénieurs qui optimisent Android pour que ce soit pas trop ridicule fasse a ARM, et leurs usines.

Apple voulait faire d'Intel un fondeur, car ils ont les meilleurs usines. ARM sont des gignoles a côté en terme de moyen, pourtant ils y arrivent aisément. On site le K1 de Nvidia, mais la conception de ce CPU a coûté une fraction de ce qu'Intel dépense pour concevoir un CPU.

L'intérêt d'ARM c'est que tout le monde peut en faire et qu'a procédé de fabrication identique, ça consomme moins qu'intel. Google, Facebook ne sont jamais passé à SPARC ou PowerPC, pourtant il se mettent a utiliser de l'ARM.

C'est pas miraculeux, mais ça n'empêche pas de tester ces applications en conditions réelles pour voir. Pour avoir travaillé 5 ans sur des bench CPU constructeur, les benchs des autres ont trop d'intérêt marketing pour être significatif et partial bien souvent. Ça se regarde avec prudence.

il y a une photo du serveur que j'utilise, il y a plein de modules indépendants
https://www.scaleway.com/features

photo d'un module (en milieu de page
https://www.scaleway.com/

pour une même consommation électrique, on a plein de core pas trop puissant (avec plein de contrôleur mémoire indépendant, donc en absolue une bonne grosse bande passante). En cela, ça favorise plutôt la "scalability horizontal", avec peu de corrélation entre les traitements.

Réponse en vrac:

je croyais que plus on est flou plus on de riz moi. Mais pas peut-être que.

Sim, si célèbre au pays de shwarzy, avec toutes ces villes à son nom.

Groovy aussi.

Trop simple!

Merci pour cette précision, du coup je vois pas bien où s'interpose SMF. Pour moi il remplissait le rôle de l'init.

Sinon Android, busybox ont aussi des init alternatifs, il s'appelle aussi init (de même que pour systemd si ma mémoire est bonne) mais sont plus simple, donc le nom de la commande n'est pas suffisant. Il y a aussi pinit, mais comme c'est français les américains le siteront jamais.

Le sous entendu que les avantages de systemd se limite au desktop est gonflant aussi. Quite a étaler la confiture sur tout les systèmes d'init, il en manque des gros.

Apple, Solaris et autres n'utilise plus l'init depuis un baille.

C'est pareil pour ce journal, aucun argument contre systemd, mais c'est de bon alloie de leur faire la morale, comme un prof incompétent qui cherche a garder la tête haute.

Le préjudice humain, il est du côté des dev de systemd, menacés de mort. Venir critiquer la methode, c'est adjoindre l'ignorance à l'incompétence.

C'est de la comm, c'est pareil.

Google drive est pas mal pour les présentations.

perso je pense qu'il faut payer les gens à faire autre chose que de la mise en forme de présentation dans une boite sérieuse.

Sauf que dans mon cas, word a été compilé avec un compilateur c dans une autre lib. Pas g++. C'est tellement gros comme manque que je pense que j'ai merdé.

En 2005, je pouvais linker sans problème des lib fortran 77 compiler en 1996 avec du c++. Maintenant si on peut plus utiliser un pointeur de fonction c, compilé avec un compilo c avec du c++, c'est que les concepteurs du c++ sont dans les nuages.

J'arrive pas a comprendre comment on peut soutenir que l'ABI du c++ n'est pas une GROSSE MERDE.

Pourtant, je préfère 100 fois Qt à Gtk.

La dernière fois que j'ai fait du c++, je n'ai pas réussi à linker un pointeur de fonction vers une fonction compiler avec un compilateur c. Le B.A.-BA. Je sais pas quelle pédanterie il aurait fallu (genre un proxy bien dégueulasse)…

Je ne comprends même pas que ce soit compliqué. Avant ça ne posait aucun problème et heureusement, peut être n'est-ce pas dû a la norme, mais pour moi c dramatique.

Je comprends pas, si gtk a eut le soutient de tout les gros acteurs, et est en c, c'est que l'abi du cpp pue (même aujourd'hui). Si java a eut du succès c'est sûrement pas grâce aux qualité du c++. Qt utilise des pointeurs vers des struct pour masquer les évolutions de la structure interne et sauver son ABI.

Perso je ne critique pas le c++ dans sa globalité, mais après 10 ans de c++, des 10aines de millions de lignes de code compiler, la certification de compilateur et un gros paquet d'optimisation CPU de code c++, je ne peux toujours pas prétendre connaitre le c++ globalement sur toutes les plateformes, je ne connais bien que le sous ensemble de ce qu'en fait Qt.

Depuis 1992 on reproche les mêmes choses encore et encore au c++ et c'est pleinement justifié, d'où java et gtk. Le problème c'est qu'on est obligé de ne pas utiliser plein de fonctionnalités du c++ pour qu'il reste proche du c. Et Qt y arrive très bien.

Les nouvelles normes foutent la merde.

Kernel ou pas, que tu mettes quelques octets en cache en haut de la stack, ok (et encore), mais d'une manière générale, tu mets pas en cache ce que tu accèdes de manière séquentiel. Même les cpu les moins puissant depuis 2002 optimise l'accès aux données séquentiels.

D'autre part, on met des caches lines en cache, pas des pages, d'ailleurs il est impossible de mettre des page complète en cache sur la plupart des CPU. Une page ne se map qu'en quelques caches lines dont la taille << taille d'une page (dépendant de la quantité de mémoire physique sur certains CPU).

Mettre la stack en cache, quelle idée…

j'me réponds pour m'compléter (parce que je peux pas éditer):

virt-manager, c'est le clickodrome où on utilise ces domaines. C'est sympa, en tout cas, plus que qemu en ligne de commande, même si on connait toutes les options, ça rend la chose plus accessible. Mais il faut savoir une chose important : il y a 2 modes concernant le driver qemu :

Soit on lance en mode session (qemu se lance alors en user),
$ virt-manager -c qemu:///session

soit en mode system, et là, il vaut mieux connaitre SELinux, ou autre joyeusetées dans ce genre.

virt-manager permet aussi de gérer plusieurs serveurs en un seul endroit

$ virt-manager -c qemu+ssh://user@machine/session

faut faire gaffe à ça.