Misc a écrit 6254 commentaires

Il faut constater qu'Intel fait le strict minimum avec Linux https://01.org/

Bah je compte 31 projets, et je compte que dans le tas, bluez, j'utilise, les drivers intel pour carte graphique, j'utilise, kvm, etc.

Je dirais pas que c'est le strict minimum

Autre solution plus généraliste, utiliser une sandbox selinux :
http://danwalsh.livejournal.com/28545.html

Ou glimpse :
https://launchpad.net/glimpse

Ou arkose :
https://launchpad.net/arkose

Ou celle basé sur app armor quand quelqu'un aura fini de l'écrire :
http://wiki.apparmor.net/index.php/AppArmorSandboxing

Car bon, si je me trompe pas, quelqu'un avec 10000 point de cosmos karma va être quelqu'un qui poste direct à 3, et donc les gens qui postent à 2 ont 1000 points. Mais au dela de ça, c'est impossible de connaitre son score, non ?

Si je veux corriger sun/oracle java truc ( la version proprio ), c'est de l'ordre du peu probable, car oracle fait tout pour que je puisse pas, notamment via la license.

Si je veux corriger openjdk, les codeurs sauf erreur de ma part ne m’empêchent pas de le faire. Les seules choses qui l’empêche, c'est de mon coté. Comme tu dit, le fait de pas avoir de temps, de pas avoir les compétences, et que ça soit ma faute directement ( genre j'ai passé mon temps au bar au lieu d'aller en cours de C, ou j'ai passé mon temps dans un assoce qui sauve des bébés phoques au lieu d'apprendre le C ) ou indirectement ( je me suis fait rouler dessus et j'ai passé 20 ans dans le coma ), ça reste que dans une relation codeur/demandeur, les soucis restent du coté du demandeur, d'ou "sa faute". Certes, j'aurais pu trouver sans doute mieux comme formulation.

c'est que le journal a besoin d'un effort de standardisation au niveau de sa présentation. Le format binaire ne
représente pas la seule et unique méthode pour y arriver.

Pour standardiser, tu as 2 choix. Soit tu va dire à tout le monde "maintenant, c'est ça" et tu t'assures que tout le monde le fait. Soit tu mets un truc entre les logs et le programme qui va se charger de faire ça. Notamment dans le cas de la date, c'est flagrant. C'est ce 2eme cas que journald a choisi.

Ensuite, journald a le choix entre stocker ça en binaire ou en texte. En texte, soit tu prends un format ad-hoc ( ce qui est actuellement mis dans les logs ), soit tu reprends un truc existant ( genre du json, du xml, du yaml ) avec une grammaire. Les auteurs de journald se sont orienté vers le binaire et fait de tout mettre dans une base de données directement pour éviter de faire du parsing sans arrêt.
Les avantages sont multiples. Comme c'est indexé, l'accès aux données est peu couteux et ça permet de voir les logs avec systemctl status. Comme c'est indexé, les recherches sur la date peuvent se faire de manière précise.

Comme les champs sont souvent répétés ( hostname, boot_id, etcetc ), il y a moyen de compresser ça de manière efficace, ce qui permet de logger plus d'info sans pour autant prendre plus de place. Et d'utiliser les informations. Par exemple, plus besoin de regarder la date d'un truc pour savoir si un log correspond au boot courant ou pas, l'information est stocké dans boot_id. L'utilisateur et le service sont enregistré, plus de magouille avec la commande logger. Donc c'est pas "on rajoute des champs pour rien". De plus, la compression a mon avis peut jouer dans le cas de l'embarqué ( embarqué qui inclue aussi les tablette ), et on peut râler ce qu'on veut sur Apple, si on veut pas avoir un futur ou ils deviennent le microsoft d'hier, faut prendre en compte ce cas.

Ouais, on aurait pu faire autrement. Guess what, au lieu de troller sur linuxfr, y a des gens qui ont commencés le boulot :
https://fedorahosted.org/lumberjack/

L'origine est expliqué ici : http://bazsi.blogs.balabit.com/2012/02/project-lumberjack-to-improve-linux-logging/

Donc tu va pouvoir maintenant défendre le fait d'utiliser xml :
https://fedorahosted.org/lumberjack/wiki/sampleXml#ExamplelumberjackLogEventsinXMLFormat
ou json :
https://fedorahosted.org/lumberjack/wiki/sampleJson#ExamplelumberjackLogEventsinJSONFormat

Tu peux même trouver des choses comme https://github.com/deirf/libumberlog pour faire ce que tu veux, à savoir un format texte standardisé pour les logs. Je te propose donc de compiler la lib chez toi, de l'utiliser et de nous dire après 2 mois comment ça a trop changé ta vie. Moi, j'utilise le journal et systemd, et j'ai déjà expliqué pourquoi je trouve que le résultat est pratique.

Ce n'est pas parce que le format de date du journal est inadéquat qu'il faut passer au binaire.
Il suffisait de changer le format de cette date.

Au vue des cris d'orfraie poussé à l'idée de mettre un système de log à coté de syslog ( car comme dit partout à commencer dans l'annonce, journald passe les logs à syslog pour compatibilité et ne compte pas retirer ça ), j'ose pas imaginer les cris si on touche directement à syslog au point de rendre son format incompatible avec les outils existants.

Et au fait, dans le fichier binaire, little ou big endian?

"The on disk format uses exclusively 64bit LE (little endian) offsets," cf l'annonce
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs

Le lien vers la spec : http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Et en fait, je vois pas ce que vient faire systemd la dedans ( part que c'est sans doute logind qui rajoute le répertoire ). C'est trivialement implémentable dans /run/. D'ailleurs, oh tiens :

$ echo $XDG_RUNTIME_DIR
/run/user/500

Actuellement, xorg mets ça dans /tmp ( genre /tmp/.X11-unix/X0 ).

Le format texte est effectivement universel. Quelle que soit la plateforme, le fichier peut être lu tel quel, sans
interpréteur … à condition de respecter le jeu de caractères, bien sûr, mais même sans ça un fichier texte dont les
accents, par exemple, apparaissent "bizarrement" reste lisible par n'importe quel humain sur n'importe quelle machine.

Mais le format des données n'a rien de standard :

$ head -n 1 yum.log messages iscsiuio.log mcollective.log httpd/access_log-20120626 certmaster/certmaster.log-20120220
==> yum.log <==
Jan 01 18:06:22 Installed: python-distutils-extra-2.29-1.fc16.noarch

==> messages <==
Oct 21 11:19:15 liliana dbus-daemon[880]: dbus[880]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)

==> iscsiuio.log <==
INFO  [Sun Oct 21 11:17:01 2012]Initialize logger using log file: /var/log/iscsiuio.log

==> mcollective.log <==
# Logfile created on 2012-10-19 20:35:38 +0200 by logger.rb/31641

==> httpd/access_log-20120626 <==
::1 - - [25/Jun/2012:23:14:12 +0200] "GET /dashboard HTTP/1.1" 200 1773 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1"

==> certmaster/certmaster.log-20120220 <==
2012-02-12 16:42:30,003 - DEBUG - submitting CSR: /etc/pki/certmaster/liliana..csr  to certmaster http://akroma.local:51235/

Y a quoi d'universel dans tout ça ? Tantôt j'ai la date a un format, tantôt à un autre, tantôt j'ai le hostname, parfois non, j'ai des commentaires. Et j'ai pas du chercher longtemps pour montrer que c'est le merdier.

En même temps, soyons clair, si on t'a vendu le logiciel libre comme étant la liberté pour les utilisateurs, on t'a mal vendu le truc.

Sur les 4 libertés de la GPL et de la FSF, tu as :
- la liberté d'étudier ( pour contributeur )
- la liberté d'utiliser ( pour contributeur et pour non contributeur )
- la liberté de distribuer ( pour contributeur et pour non contributeur )
- la liberté d'améliorer et de distribuer ( pour contributeur )

On note quand même que la moitié des 4 libertés sont juste pour les contributeurs, et donc que sur les fondements du libre, les non contributeurs profitent moins du libre.

Donc oui, ceux qui utilisent sans contribuer, ils sont dépendant des autres. Mais c'est uniquement leur faute, car la seule chose qui les retient, c'est eux mêmes.

Et pour systemd, y a pas ?

Va voir le bugzilla, regarde les RFE.
Par exemple, quelqu'un a demandé le format du journal, la doc a été écrite ( heck, c'est même le titre de la dépêche ). L'option --until/--since a été proposé sur les listes fedora. Le fait de faire une rotation par date et pas par taille de fichier, ça a été demandé sur les listes Fedora.

Je vais pas faire la liste des choses ou les demandes ont été prises en compte, mais je pense que tu confonds "ma demande n'a pas été accepté" avec "personne n'a été écouté". Les gens peuvent dire non.

Et si la demande est "journal devrait faire des logs en ascii", c'est le boulot de rsyslog. C'était très clair dans la première annonce, et ça me semble parfaitement logique d'un point de vue de l'architecture. A la base, journald n'était la que pour servir systemd ( les lignes de logs qu'on voit quand on fait systemctl status, ça vient de la ). Ensuite, l'idée a été d'exposer ça pour que les utilisateurs puissent le lire. Puis des gens se sont dit "tiens, on peut faire des tas de trucs qu'on fait pas facilement avec du texte". Comme par exemple, afficher la date dans la timezone local sans avoir à passer des tonnes de regexp pour parser et convertir la date, ou afficher les couleurs sur la base de la sévérité du message dans la sortie. Ou le fait d'afficher les données de 2 unités systemd mais pas des autres ( genre bind et dhcp ), correctement mélés ( chose un chouia plus compliqué avec des fichiers et avec des corners cases moisi, comme "oups, le tri lexical fait de la merde entre "Oct 30" et "Nov 01" ).

C'est comme git vs svn/cvs, le fait d'avoir un moyen rapide de faire certains traitements change la donne et offre des possibilités. Faire un svn rebase, ça serait vachement plus long et couteux. Faire un svn grep serait difficilement envisageable. Avoir changer a donne et fait un truc ultra rapide rends les choses différentes.

Avec journald, c'est pareil. C'est rien de différent, mais le fait d'avoir un fichier binaire, ça rends certains algos possibles alors que ça serait couteux autrement.

Le souci, c'est que les gens savent pas lire, ou prenne pas le temps ( ou simplement n'ont pas le temps )
.
D'un coté, on a un système qui évolue vite, au point que ça dépasse presque la capacité d'absorption d'un humain, sauf si il passe son temps à faire de la veille. De l'autre, on a des gens dont le temps libre diminue ( famille, travail ), et qui applique face au changement la stratégie de survie classique de "si ça marche, faut pas toucher, j'ai investi du temps".

Personnellement, je pense que les gens semblent oublier les racines du libre, la recherche en informatique. Stallman était chercheur, et son but était de faire en sorte que le savoir ne soit pas privatisé, certes, mais ne soit pas privatisé pour qu'il puisse continuer à faire son taf, qui était la recherche. Et la recherche, ça vient par l'expérimentation, l'essai de nouvelles choses. Et c'est sur la base de ce genre d'éclairage qu'on voit que le bazar est l'expression du bouillonnement créatif autour du libre.
Et que donc oui, les changements, y en aura encore d'autres, et si le but est d'avoir un système qui ne bouge plus, y a pas de souci, c'est du logiciel libre, vous pouvez le garder comme vous voulez. Si ensuite, le souci est de se retrouver tout seul, alors faut se dire "mais pourquoi pas assez de monde m'a suivi".

Avec tcc ( http://bellard.org/tcc/ )

En fait, visiblement, syslog vient de sendmail, donc des années 80 ( cf wikipedia ).

Par contre, utmp semble être la depuis le début :
http://man.cat-v.org/unix-1st/5/utmp
( issue du projet "Unix First Edition Manuals" http://man.cat-v.org/unix-1st/ )

Donc je pense que les concepteurs d'unix au début n'ont pas prévu de faire des logs dans des fichiers textes, qui sont arrivés après. Donc oui, soit c'était pas prévu, soit c'était prévu en binaire.

Ensuite, peut être que les sacro-saints 40 ans d'héritages d'Unix, ça commence dans les années 80 et je sais pas compter. Peut être aussi qu'on devrait rajouter sendmail et m4 dans l'héritage Unix, et bruler les impies comme Wietse Venema et Philip Hazel.

Y a surtout que sqlite supporte pas les accès concurrents. J'ai tenté sur puppet, ça monte pas des masses en charge ( genre à partir de 7/8 clients, ça fait de la merde, on monte à plus de 300 fois plus au taf avec mysql )

Être flat, ça veut rien dire. Tout au plus, on parle de flat file, et la, je propose de regarder :

http://www.sqlite.org/fileformat.html

à comparer avec

http://en.wikipedia.org/wiki/Flat_file_database

Sqlite utilise un arbre binaire ( b-tree ) pour accéder à des enregistrements ( records ). C'est pas exactement la définition de wikipedia. Donc sauf à dire "oui, c'est plat sauf la ou c'est pas plat", je pense que tu es dans l'erreur.

Plus je relit ce que tu demandes, plus ça me semble embrouillé, mais ça doit être moi. Tu parles d'inittab et tu dis que c'est normal que systemd supporte ça alors qu'on parle de multiseat. Bien que ça soit exact, c'est pas exactement la même chose. Si je te dit "gdm supporte le multiseat, tu peux aller sur le terminal avec ctl alt f1", tu va pas être d'accord. Donc gardons le multiseat à la définition communément prise pour gdm, à savoir avoir 2 fois le matos ( 2 cartes graphiques, 2 moniteurs, 2 claviers, 2 souris )

Le souci principal pour gdm, c'est pas de pas supporté d'être lancé 2 fois ( comme j'ai dit, gdmflexiserver montre bien que c'est faisable, ne serais ce que via le flag -n ). Le souci, c'est pas de lancer xorg 2 fois ( pareil, c'est trivial à faire à la main, je viens de le refaire ). Le souci, c'est "je branche une clé usb, qui va la voir sur son bureau".

Lancer xorg avec une config spécifique ( genre qui pointe sur l'adaptateur pci de la carte ), ça se fait. Lancer gdm en lui faisant croire qu'il est dans Xnest, ça se fait aussi. ( ou même sans ça, lancer 2 fois gdm avec un prefix différent ) C'est d'ailleurs le premier lien. Voir mieux, lancer xorg sur un periph usb, ça se fait ( http://0pointer.de/blog/projects/multi-seat )

La ou ça devient touchy, c'est le partage de la puce 3d. Sauf que sauf erreur de ma part, ça n'a rien a voir avec le multiseat tel que la plupart des gens l'entendent, vu que l'idée, c'est d'avoir 2 claviers, 2 souris, 2 écrans. La, tu es dans le même cas que quelqu'un avec une carte nvidia optimus, avec 2 puces. Sauf erreur de ma part, c'est pas très bien supporté pour le moment.

Donc la solution serait de gérer le client local comme si c'était un client distant. Ie, d'avoir un xorg dédié à faire tourner virtualgl ( pas besoin de gdm pour ça, vu que personne ne se connecte en local dessus ), et de faire tourner gdm sur l'autre puce, et d'utiliser un client ( par exemple vnc ) pour lancer les applis comme si c'était un thin client.

Mais je suppose que ça réponds pas à ton besoin ?

Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les
améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?

la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )

Ben justement non j'en ai aucun.

Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"

Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support
(payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".

Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.

Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de
l'utilisabilité du bigniou par des sysadmins.

Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".

Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.

Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une
solution mais elle est trop complexe pour être backportée

Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )

Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un
fichier de lock qui traine dessus. COOOL

Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.

Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.

Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".

Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.

Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne
idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse
quelqu'un ? )

C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.

Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).

Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".

Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre

Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".

Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )

Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :

a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.

Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).

b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont
pas possible avec systemd.

En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"

c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui
rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)

Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".

Y en a qui ont plus ? Ou moins ? ( je doit reconnaitre que je me suis jamais posé la question )

Enfin l'idée est surtout qu'il y a un ordre de magnitude moins d'avis à donner sur /. que sur linuxfr, au moins pour moi. Genre 5 pour 2 semaines vs 100 /j. Même si quelqu'un a que 10 point, ça fait beaucoup plus.

Ensuite, peut être qu'on peut parler du 99% de gens qui n'ont pas le karma requis pour vivre au dessus du seuil de pauvreté karmique, mais bon…

Je pense que ta maitrise de l'anglais doit te jouer des tours, car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire, ouais, peut être.

Et donc pour que tout le monde puisse juger de tes sources, j'invite les gens à voir les fameux vagues slides sur :
http://rhsummit.files.wordpress.com/2012/03/burke_rhel_roadmap.pdf , voir la conf sur
http://videos.cdn.redhat.com/2012-summit-bestof-04.ogg , vers la 37eme minute.

Mais j'aurais tendance à dire qu'il y a d'autres choses qui font penser que systemd va se retrouver dans RHEL 7, comme :
https://github.com/openshift/origin-server/blob/master/broker/openshift-origin-broker.spec

Notons les lignes 13 et consorts :
%if 0%{?fedora} >= 16 || 0%{?rhel} >= 7
%define with_systemd 1
%else
%define with_systemd 0
%endif

Pour les non initiés aux rpms, ça définit une variable "with_systemd" qui est utilisé par la suite dans le fichier pour savoir si on embarque un fichier .service ou un script d'init. Notons l'idiome "si la valeur de la variable fedora est supérieur ou égale" à 16, suivi de "ou si la variable rhel est supérieur ou égale à 7", laissant supposer que pour une fedora supérieur à 16 ou une rhel supérieur à 7, systemd serait utilisé ( je laisse le reste du fichier spec à titre d'exercice ).

Sachant que le fichier spec est celui utilisé par le projet openshift, projet lancé par RH, et que les commits sont fait par des gens de la boite, on peut donc supposer qu'ils ont fait des déductions un chouia plus éclairé que les tiennes, basés sur des informations un chouia mieux sourcés ( au moins concernant le produit de leur employeur ).

On peut aussi regarder ailleurs, par exemple, en prenant au hasard des checkouts qui traineraient sur le disque ( ce qui est mon cas ), et tomber sur :
http://pkgs.fedoraproject.org/cgit/abrt.git/tree/abrt.spec

La, on voit une construction un chouia plus complexe avec le contre intuitif bcond_without ( qui rajoute l'option pour désactiver une option, donc qui l'active par défaut ), et le fait qu'il y a aussi des unités systemd prévu dans un paquet pour RHEL 7.

Ou on peut aussi aller en prendre au pif parmi les paquets Fedora maintenus par des gens de RH, comme au hasard, libvirt :
http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec#n145

Un commentaire court mais sans équivoque.

Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet, je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH qui ont dit "faut pas mettre systemd, kaane m'a dit que ça pue".

Sinon, tu noteras en pratique que ni Suse, ni Red Hat ne communique pour le moment sur la sortie des produits tout court, ou sur aucune feature. Red Hat en a parlé lors de sa conférence annuelle, et Suse a du faire pareil et basta.

Est ce que ça veut dire qu'ils vont abandonner toutes les fonctionnalités du monde ? Non, je crois pas.
La ou tu vois une défiance envers systemd ( ie, la ou tu interprète les faits pour ne pas remettre en cause ta vision myopique de la chose ), je vois juste du bon sens de ne pas faire de foin sur un version de leurs distributions qui ne sont pas encore fini.

Suse a visiblement un cycle de 3 ans, mais on peut supposer que le rachat et la réorganisation de Novell par Attachmate a pu fortement perturbé ça, ce qui laisse encore du temps pour une release en 2013. ( mais bien sur, tu peux sans doute continuer à croire que systemd a totalement tout mis en l'air, et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même )

D'ailleurs, quand je vois la page du bugzilla sur le kernel, je me demande si Suse ne va pas abandonner linux, car bon, ça fait peur, y a 200 bugs ouverts :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=kernel

Ou lacher yast ( 167 bugs ) :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=yast

Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.

On peut, mais par defaut, ça ne le fait pas.

Donc ouais, "on peut coder tel truc", sauf que quand il s'agit de faire autre chose que de poster sur linuxfr, y a plus personne.

C'est ce que fait slashdot. Si tu participes aux commentaires d'un article, toute la modération s'efface. mais tu as aussi 5 votes de temps en temps, et pas 100 par jours comme ici.

Dans ce cas, ça va juste être remplacé par un "chut" moins cordiale et moins silencieux. Je doute que ça améliore l'ambiance. Ensuite, j'aurais tendance à dire qu'il suffit juste de pas dire n'importe quoi pour pas finir à 0. C'est pas si dur vu que plein de gens y arrivent. S'en foutre de la note, c'est pas mal aussi comme façon de vivre sa vie sans souci.

bah suffit de le faire en perl, ou est le problème :)
http://search.cpan.org/~hmbrand/DBD-CSV-0.36/lib/DBD/CSV.pm

( je l'utilise sur un script maison qui dumpe les offres de jobs, ça marche assez bien et je trouve ça drole de faire un select sur du csv, mais je précise que bien sur c'est pas une solution entreprise ready, ça supporte pas encore xquery )

C'est un peu expliqué dans le lien donné par le journal, sinon un moteur de recherche doit pouvoir te redonner les raisons.

Globalement, il y a des raisons techniques de complexité des algos pour la recherche, le stockage, etc, le fait de pouvoir avoir des indexes, etc. Par exemple, si tu veux pouvoir donner accès que à certaines metadonnées, avoir un format binaire sera plus rapide qu'une regexp pour trier tout ça ( et c'est sans doute la raison de la présence de plugin de log dans mysql/postgresql pour rsyslog ). Dans systemd, les infos affichés par systemctl status sont obtenus par le journal, et je pense qu'il est important d'avoir un accés indexé aux infos ( et pas relire les megaoctets de logs pour afficher les infos )

Ensuite, il y a le fait de vouloir pouvoir avoir du binaire dans les logs ( dump en cas d'erreur etc, etc ).

Il y a aussi des discussions sur http://lwn.net/Articles/468381/ , mais bon, vu qu'il suffit d'avoir rsyslog pour avoir les logs au format texte, j'ai du mal à voir le souci pour les gens.

Visiblement, ça a été rajouté :
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

Aussi bien le format binaire que le format d'export.