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.
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.
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).
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
pour ceux qui se demandent quoi faire avec ce fichier XML, on peut créer/importer ceux-ci via la commande virsh.
On peut générer ces fichiers depuis une ligne de commande qemu par exemple, puis compléter la configuration de la machine via "virt-manager", et re dumper le fichier XML, parce que les arguments qemu sont complexes à spécifier à la main.
Par exemple :
créer un de ces fichiers depuis un domaine existant
$ virsh dumpxml "domain" > domain.xml
depuis votre ligne de commande qemu préférée
$ virsh domxml-from-native qemu "qemu-args"
recréer la ligne de commande qemu après modifications dans virt-manager
$ virsh domxml-to-native "domain" (marche pas toujours)
voila. pour le cpu, je force systématiquement kvm32 ou kvm64, ça marche mieux avec ma mageia, mais j'en suis pas à faire du "passthrough" pour utiliser directement une CG depuis la machine virtuelle.
Je suis énervé, il est tôt et je tappe depuis mon téléphone portable. Bref, je pige pas qu'il y en ait encore pour remettre en cause la pertinence de journalctl.
Je trouve que les géniteurs de systemd ont vraiment du mérite à supporter des débats d'un tel niveau. Je trouvais leurs méthodes un peu directe, mais franchement, arriver à mélanger autant de concepts, pour justifier n'importe quoi, c'est faire preuve soit de malice, soit d'inexpérience.
Je ne vais pas me contenter de donner un avis personnel, mais sans être du niveau d'un Shannon, on sait tous, sans exception, que plus on transforme une donnée (par exemple une date en long (Long long) vers char[]) plus on perd de l'information de base, plus on perd du temps pour faire la conversion, plus on perd du temps a faire la conversion inverse pour pouvoir agir efficacement sur la donnée de base (par exemple si je veux juste les lignes d'un intervalle de temps), plus on est obligé de specifier comment convertir l'info, on doit mettre en plus tout le monde d'accord… je pourrais continuer, en gardant le format binaire de base, TOUT cela est inutile.
De plus, journalctl apporte bien plus que seulement le respect des formats binaire de base.
Je trouve logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log, je ne reproche rien au message du dessus.
c'est une TRÈS bonne nouvelle, je pense. Même si il est bon d'avoir la liberté de proposer des choses différentes, ça permettra à SystemD de se confronter à un panel bien plus large d'utilisateurs (exigeants).
Ce sera autant profitable à Debian, qu'a SystemD. Pour arrêter les banalités, je dirais que ce projet est mené de manière exemplaire, que les critiques sur l'impacte de l'écosystème sont justifiées, mais, si tous le monde s'y met (et Debian, c'est beaucoup de monde), ça permettra d'avoir moins peur de RH et de son emprise sur ce projet. Cette décision rassure avant tout, les utilisateurs de SystemD.
[^] # Re: Offres oss: Bientôt le 1 avril tous les jours.
Posté par YBoy360 (site web personnel) . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 2.
Réponse en vrac:
je croyais que plus on est flou plus on de riz moi. Mais pas peut-être que.
[^] # Re: Obsèques
Posté par YBoy360 (site web personnel) . En réponse au journal [ HS ] Triste nouvelle pour toute une génération. Évalué à 1.
Sim, si célèbre au pays de shwarzy, avec toutes ces villes à son nom.
[^] # Re: Dart
Posté par YBoy360 (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 2.
Groovy aussi.
[^] # Re: Let's get Groovy, Baby!
Posté par YBoy360 (site web personnel) . En réponse au journal Esod mumixam !. Évalué à 1.
Trop simple!
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
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.
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à -1.
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.
[^] # Re: trop de bruit pour rien
Posté par YBoy360 (site web personnel) . En réponse au journal Devuan forks Debian: un choc ou c'était inévitable?. Évalué à -4.
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.
[^] # Re: Source
Posté par YBoy360 (site web personnel) . En réponse au journal Les temps changent ?. Évalué à 10.
C'est de la comm, c'est pareil.
[^] # Re: Autres solutions
Posté par YBoy360 (site web personnel) . En réponse au journal Libre office, ça suçe des ours en Alaska.. Évalué à 2.
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.
[^] # Re: En vrac
Posté par YBoy360 (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 0.
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.
[^] # Re: En vrac
Posté par YBoy360 (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à -1.
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.
[^] # Re: En vrac
Posté par YBoy360 (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à -4.
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.
[^] # Re: En vrac
Posté par YBoy360 (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à -6.
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.
[^] # Re: Kernel stack
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 3.
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).
[^] # Re: Kernel stack
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 3.
Mettre la stack en cache, quelle idée…
[^] # Re: virsh & quelques commandes
Posté par YBoy360 (site web personnel) . En réponse au journal VGA Passthrough par vfio sur libvirt / qemu / kvm sous Debian Jessie : ca fonctionne !. Évalué à 3.
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.
# virsh & quelques commandes
Posté par YBoy360 (site web personnel) . En réponse au journal VGA Passthrough par vfio sur libvirt / qemu / kvm sous Debian Jessie : ca fonctionne !. Évalué à 3. Dernière modification le 13 avril 2014 à 08:20.
pour ceux qui se demandent quoi faire avec ce fichier XML, on peut créer/importer ceux-ci via la commande virsh.
On peut générer ces fichiers depuis une ligne de commande qemu par exemple, puis compléter la configuration de la machine via "virt-manager", et re dumper le fichier XML, parce que les arguments qemu sont complexes à spécifier à la main.
Par exemple :
créer un de ces fichiers depuis un domaine existant
$ virsh dumpxml "domain" > domain.xml
depuis votre ligne de commande qemu préférée
$ virsh domxml-from-native qemu "qemu-args"
recréer la ligne de commande qemu après modifications dans virt-manager
$ virsh domxml-to-native "domain" (marche pas toujours)
voila. pour le cpu, je force systématiquement kvm32 ou kvm64, ça marche mieux avec ma mageia, mais j'en suis pas à faire du "passthrough" pour utiliser directement une CG depuis la machine virtuelle.
[^] # Re: Avis de Windowsien
Posté par YBoy360 (site web personnel) . En réponse à la dépêche VM4nerds : téléchargez des VMs sous Linux ou BSD prêtes à l'emploi sous QEMU-KVM. Évalué à 3.
moi j'utilise Libvirt avec Qemu-kvm.
par contre je veux le faire sans être root, et sans utiliser SELinux, et là, je sèche un peu pour le réseau (polkit, connexion de plusieurs machine…).
Bref, c'est sûr ça tabaze virtualbox.
Je cherche un gars bon dans ce domaine (si ça t’intéresse…).
[^] # Re: Le cas goto
Posté par YBoy360 (site web personnel) . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à -3.
Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.
[^] # Re: NIH ?
Posté par YBoy360 (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 7.
pinit (2006)
http://forum.mandriva.com/fr/viewtopic.php?t=51698&p=240925
et le développement était ouvert.
[^] # Re: NIH ?
Posté par YBoy360 (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 4.
Mandriva/(Mandrake?!) avait un système d'init parallèle avant Ubuntu.
[^] # Re: solr
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Sortie d'Elasticsearch en version 1.0. Évalué à 1.
Les agrégations, il me semble que soir le fait et de manière très performante.
Sinon il y a ce lien qui me permet d'avoir une liste de differences :
http://www.ymc.ch/en/why-we-chose-solr-4-0-instead-of-elasticsearch
Mais j'imagine que les choses évoluent vite, et qu'il est difficile de maintenir ce genre de liste a jour
# solr
Posté par YBoy360 (site web personnel) . En réponse à la dépêche Sortie d'Elasticsearch en version 1.0. Évalué à 3.
Quel est l'avantage par rapport à un bon vieux solr des familles ?
Parce que solr à vraiment evolué depuis la création d'es. Peut être la scalabilité ou le support d'Amazon?
[^] # Re: Mon avis personnel
Posté par YBoy360 (site web personnel) . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 0.
Je suis énervé, il est tôt et je tappe depuis mon téléphone portable. Bref, je pige pas qu'il y en ait encore pour remettre en cause la pertinence de journalctl.
Je trouve que les géniteurs de systemd ont vraiment du mérite à supporter des débats d'un tel niveau. Je trouvais leurs méthodes un peu directe, mais franchement, arriver à mélanger autant de concepts, pour justifier n'importe quoi, c'est faire preuve soit de malice, soit d'inexpérience.
Je ne vais pas me contenter de donner un avis personnel, mais sans être du niveau d'un Shannon, on sait tous, sans exception, que plus on transforme une donnée (par exemple une date en long (Long long) vers char[]) plus on perd de l'information de base, plus on perd du temps pour faire la conversion, plus on perd du temps a faire la conversion inverse pour pouvoir agir efficacement sur la donnée de base (par exemple si je veux juste les lignes d'un intervalle de temps), plus on est obligé de specifier comment convertir l'info, on doit mettre en plus tout le monde d'accord… je pourrais continuer, en gardant le format binaire de base, TOUT cela est inutile.
De plus, journalctl apporte bien plus que seulement le respect des formats binaire de base.
Je trouve logstash très intéressant si tu utilises syslog old school et si tu as 30 serveurs pour stocker tes log, je ne reproche rien au message du dessus.
# bon dimanche
Posté par YBoy360 (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 0.
c'est une TRÈS bonne nouvelle, je pense. Même si il est bon d'avoir la liberté de proposer des choses différentes, ça permettra à SystemD de se confronter à un panel bien plus large d'utilisateurs (exigeants).
Ce sera autant profitable à Debian, qu'a SystemD. Pour arrêter les banalités, je dirais que ce projet est mené de manière exemplaire, que les critiques sur l'impacte de l'écosystème sont justifiées, mais, si tous le monde s'y met (et Debian, c'est beaucoup de monde), ça permettra d'avoir moins peur de RH et de son emprise sur ce projet. Cette décision rassure avant tout, les utilisateurs de SystemD.