Ce n'est pas ce que pense Stéphane Botzmeyer, apparemment (slide 19) ipv6 déploiement
C'est une présentation de 2011 certes… mais je me dis que, si par exemple les cours, les TP, les TD sont entièrement en ipv6 ça faciliterait le déploiement puisque les jeunes auraient moins d'appréhension.
Je me demande si l'enseignement a fait vraiment son boulot au final.
Je sais que Renater a été un réseau d'expérimentation pour ipv6 très tôt… mais de ce que je vois dans les labs, c'est plutôt de l'ipv4.
Non, le calcul n'est pas biaisé. Il est correct sur la base seule de l'élaboration.
Je te rappelle que la puissance fournit pour une éolienne est au cube de la vitesse des vents.
Le vent est de combien sur les côtes? Le vent est de combien à 1000 km des côtes?
on peut peut-être économiser sur le diamètre des câbles et le dimensionnement des transformateurs.
Comment tu fais?
Je veux dire… que tu es connecté au réseau électrique afin de renvoyer le surplus de ton éolienne au réseau ( tu le revends quoi…).
Une éolienne est inductive… ce qui donne un cos phi pas génial pour le réseau… il faut donc pour chaque ménage réfléchir sur le déphasage.
Pour limiter les pertes par effet joule le long des câbles, il faut exercer une forte tension…il faut réfléchir à ton propre réseau électrique pour chaque ménage.
Je peux plus facilement mettre à l'échelle et m'adapter avec une éolienne forte puissance… que de réfléchir sur un ensemble du parc d'un point de vue énergétique ( avec le réseau existant).
Tu considères que l'élaboration est à coût nulle également…
Qu'est qui coute énergétiquement le plus cher?
La fabrication d'une éolienne d'1MW et pesant en gros une demi-tonnes de cuivre?
La fabrication de mini-éolienne de 4 kg de cuivre (en gros) fournissant quelques kilowatt (pour en gros un million d'habitant au moins)?
On a les moyens techniques de produire de l'énergie de façon décentralisée : on sait faire des éoliennes de toits qui s'adaptent au particularité du vent en ville, on sait produire de l'eau chaude solaire, etc.
Si on prend l'exemple de l'éolien, la puissance récupérable varie en gros au cube de la vitesse du vent. Ne vaut-il donc pas mieux se concentrer sur les sites fournissant des vent forts, comme les régions côtières?
Sans compter qu'une éolienne a besoin d'une certaine quantité de cuivre. Mieux vaut-il donc pas se focaliser à l'élaboration d'un système centralisé étant donné que ce qui fournit l'énergie d'un point de vue optimum se trouve localisé? ( on peut prendre le même argument pour le solaire,etc…).
Est-il encore pertinent pour FreeBSD d'essayer de coller au développement de Xorg et consort?
Je veux dire, ces projets deviennent de plus en plus linux-centric. Le développement est tellement rapide et bouge sans cesse, que je me demande s'il est pertinent d’allouer des ressources la-dedans.
Je suis plus ce que se passe chez NetBSD, mais quand je vois le petit "incident" qu'il y a eu lorsque un dev chez intel a changé un gros morceaux dans KMS/GEM et la micro gueulante des FreeBSDistes. Je me disais, à quoi bon… autant orienter le max de ressources pour une optimisation/spécialisation serveur du projet.
J'adorerais avoir une station de travail sous NetBSD ( ou FreeBSD au pire :) ) par exemple mais bon je sais m'en passer sans problème…
Est-ce que le développement de FreeBSD comme station de travail est-il encore pertinent?
Netbsd supporte pas mal d'archi. et devoir compiler et crosscompiler l'OS (noyau+userland) doit représenter un gros boulot à chaque changement de version.
C'est un travail de 3 ans pour tout stabiliser sur toutes les archi. La base s'est fixée à gcc 4.5
pour la stabilisation.
Sonnenberger travaille sur le support de LLVM/Clang dans la base et pkgsrc.
L'un des avantages de Clang/LLVM qui intéresse, c'est qu'il a un ensemble de warning plus efficace que gcc ( en ce moment ça discute sévère pour l'activation de -Werror car apparemment ce n'est pas du tout stable avec pas mal de faux positif: ici entre les différentes versions).
Clang est nettement moins aggressif sur l'optimisation du code ce qui permet un meilleur debogage.
Par contre Clang/LLVM supporte nettement moins d'archi que gcc.
C'est toi qui par au quart de tour sur des propos que je n'ai pas tenu (juste retranscrit sans donner mon avis).
???
Je suis intervenu sur la mutualisation.
Après c'est toi qui interprète que c'est tendu.
ensuite tes dires:
Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.[…]"
Personnellement, ca n'a rien à voir avec mon intervention initiale (le reste je trouvais pertinent).
Si on doit parler d'init (hors mutualisation des ressources), moi je veux bien. J'ai une question pourquoi un design orienté événement est pertinent pour un init?
si je veux être vraiment sérieux, je ne poste pas sur trollfr… sinon précédemment, c'était une figure de style. Franchement, parler de systemd est infaisable ( c'est d'ailleurs pour ça que je m'étais branché sur la mutualisation).
Être interopérable c'est pouvoir faire fonctionner un script par exemple un script de démarrage de postgre sur fedora comme sur maegia.
Non pour moi ça c'est être compatible…
Je ne sais même pas si on peut vraiment parler d'interopérabilité entre les différentes distro… il faudrait avoir différents "opérateurs" dont la structure même du système soit différente ce qui n'est pas vraiment le cas.
Je prends les distro. comme étant pratiquement un même opérateur ( un GNU/Linux).
je mets ça en référence pour développer mes propos:
Si tu te demande pourquoi tu semble n'être qu'un trolleur de bas étage…
tu penses ce que tu veux, personnellement, je m'en fiche, ce n'est pas mon problème.
Tu peste sans argumenter, tu pointe du doigt toute une série de logiciel sans expliquer pourquoi (qu'est ce viens faire Debian, Fedora et KDE ici ?).
Pour dire que tu peux mettre n'importe quels projets à côté, parler d'interopérabilité pour des GNU/linux n'a pas de sens ( en tout cas pour moi ).
Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.
Si je voulais parler sérieusement ( le vrai sérieux): la plupart des noyaux sont de plus en plus orienté évènements avec des interfaces asynchrones/non bloquantes (epoll, /dev/poll, aio, kqueue), celà permet une meilleure montée en charge.
systemd/upstart/klaunchd/init SMF de solaris sont tous orientés événements et c'est ce que veut tous les partisans de systemd. Pour eux c'est un design moderne, que n'importe quel autre type d'init n'a pas et qu'il est un non sens d'utiliser ( cf flamewar debian-dev a propos RFC sur openrc). En quoi un paradigme orienté évènement est-il bon pour un init?
Pour ce qui est de la supervision: il existe déjà des alternatives (runit et s6 de Bernstein). Pour les init BSD il a un projet FreeBSD pour de la supervision. En quoi ces alternatives sont mauvaises ou pas populaires?
Réellement je n'ai pas encore touché à systemd et je suis plutôt attiré par sysint et openrc, mais c'est pas une raison pour faire preuve de mauvaise fois.
Je te signale encore que je ne parlais pas de systemd mais de mutualisation, lance le troll une fois de plus si tu veux… mais je n'interviendrais pas.
Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard.
FreeDesktop n'est pas un peu linux-centré, non? ( j'sais pas. Il y a des gars coté solaris ou de BSD qui s'éclament dans leur "standards"?) La dernière fois que j'ai entendu quelque chose c'est pour KMS/GEM avec une refonte énorme du code et un pétage de câble côté FreeBSD pour leur port.
Finalement, c'est quoi un standard FreeDesktop? ( ça c'est la vraie question sérieuse)
c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.
Interopérabilité de quoi? On est sur un OS identique avec des toolchains identiques, un userland aussi différent qu'il y a de différences génétique entre l'homme et le singe!
Si être interopérable, c'est de sauter entre un Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora… alors la communauté linuxienne a un problème.
Les différent gestionnaires de paquets viennent de dissensions qui n'ont jamais étaient résolu (malgré une tentative avec LSB).
Comme il y a en ce moment avec systemd….
et franchement qu'est-ce que ça change a aptitude install, un synaptic, yum, pour les utilisateurs/admin ..etc tant que ça gère les dépendances et ça installe. D'ailleurs il y a pakagekit maintenant…
L'autre problème des mainteneurs, c'est la gestion des dépendances et le versionning… pourquoi ne pas mutualiser?
Mais je suis très sérieux! Au final, s'il y a un problème de maintenance, donc de personne pourquoi ne pas mutualiser tout? Faire comme font les BSD, un OS, avec un noyau, un userland spécifique puis un dépôt tiers?
Que l'on réponde franchement, pourquoi ne pas faire ainsi?
Si c'est un problème de mutualisation, pourquoi les distrib. ne font pas un système de distribution binaire commun?
Par exemple, celui de Red-Hat pour tous les appli binaires communes à toutes les distrib. puis modulo des arbres spécifiques à chaque distrib. pour ce qui n'intéresse pas Red Hat. Pourquoi les mainteneurs ne font pas ça?
Ca leur faliciterait la vie, un gros arbre commun, de plus comme le matos sera Red Hat moins de gestion matériel.
Pourquoi ne pas mutualiser le boot et l'init sur linux aussi?
Pourquoi ne pas caser tout ce qui est nécessaire au boot dans un bien sympa initramfs géré avec dracut (celui-ci gère aussi l'orienté événement)?
Tout le monde aurait le même script automatisé? Mise à jour? hop script dracut!
Pourquoi ne pas faire un partitionnement commun, unique?
hop /boot et / sans /usr puisqu'il ne sert plus à rien!
Comme tous les scripts démons seront tous mutualisés par systemd… plus personne n'aura à s'en faire.
On pourrait aussi mutualiser les méthodes d'install!
hop par défaut /boot et / .
Quoi tu es admin? hop mode expert raid,lvm sur / (qui aura /share /local /var /bin /sbin /home) ou bien du nfs?
Franchement pourquoi les distrib. ne font pas un installeur commun.
En plus c'est génial tout ça car on aurait un seul endroit pour géré les rapports de bug! Et on aurait plein de beta testeur!
Une pour les mutualiser toutes!
Enfin de compte Lennart a complètement raison, autant faire un OS complet à la BSD.
"In other words: systemd and journald are separate enough from each other
to make them two processes, but way too integrated to separate them from
each other entirely and allow one running without the other."
Je veux bien qu'il réponde au problème d'un init orienté évènementiel, qu'il fasse de la supervision de démons…
mais il fait plus d'un million ligne de code! Oui il fait plus qu'un init… mais en attendant il n'init pas tous les cas existants…
Gentoo a eu une lutte interne en 2006/2007 comme il en arrive partout…
Non, ce n'est pas le nombre d'utilisateurs qui fait la qualité d'une distro (ça se serait)… c'est le nombre de gens qui y participe activement!
un exemple tout con, qui secoue pas mal le monde linux à l'heure actuelle: systemd
Excluons toutes discussions techniques dessus ou passionnelles. Ce qui fait réellement le succès de systemd c'est le fait:
1/ qu'il soit développé par Red Hat: les dev principaux ( Lennart, Sievers, Hoyer,…)
2/ qu'il soit activement maintenu.
Les distro qui ont migré le font principalement pour la facilité de maintenance!
Je ne sais pas si tu suis la mailing list debian-dev ou celles de gentoo, mais les dev. veulent maintenir officiellement un et un init, sinon ça représente un travail colossal pour le nombre de personnes disponibles.
Il y a des fights colossaux la-dessus car:
1/ énormément de distro. sont de moins en moins dépendantes car il y a peu de leur dev. qui soit développent soit contribuent fortement sur les couches basses du système ou sur linux lui-même.
2/ il y a peu de gens pour maintenir plus de logiciels. La liberté et le choix coutent énormément de ressources!
Greg KH le dit lui même… les distro. généralistes deviennent un non sens face à la quantité de travail qu'il y a fournir. Autant faire une chose et le faire bien. Les distro. devraient se spécialiser.
[^] # Re: Et pour en remettre une couche
Posté par wolowizard . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Il n'est pas à "l'abandon" ce projet? Le portage n'est pas abandonné?
launchd sur Freebsd
Même sur sourceforge, il n'y a plus grand chose qui se passe: http://sourceforge.net/projects/launchd4freebsd/
Il y a même un possible port sur NetBSD , mais on se demande pourquoi chez FreeBSD, ça n'a pas abouti.
http://wiki.netbsd.org/projects/project/launchd-port/…
Et quand on lit certains threads sur la mailing-list, ça me laisse pensif:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-June/039350.html
En plus pour le contrôle des démons, il y a fscd(8) bien que je ne sais pas où ça en est…
[^] # Re: Education
Posté par wolowizard . En réponse au journal Du NAT en veux-tu en voilà. Évalué à 1.
Salut,
Ce n'est pas ce que pense Stéphane Botzmeyer, apparemment (slide 19)
ipv6 déploiement
C'est une présentation de 2011 certes… mais je me dis que, si par exemple les cours, les TP, les TD sont entièrement en ipv6 ça faciliterait le déploiement puisque les jeunes auraient moins d'appréhension.
Je me demande si l'enseignement a fait vraiment son boulot au final.
Je sais que Renater a été un réseau d'expérimentation pour ipv6 très tôt… mais de ce que je vois dans les labs, c'est plutôt de l'ipv4.
# Education
Posté par wolowizard . En réponse au journal Du NAT en veux-tu en voilà. Évalué à 4.
Salut,
Dans l'enseignement en général pour les admins, devs de demain, qu'apprend-t-on quand on fait du réseau? Ipv4 ou Ipv6?
[^] # Re: Moi je suis un peu déçu ...
Posté par wolowizard . En réponse au journal OpenSilicium est de retour en 2013. Évalué à 2. Dernière modification le 10 janvier 2013 à 14:55.
Moi c'était celui sur Systemd qui a mis le troll aux poudres :)
------------> [ ]
[^] # Re: Production décentralisée
Posté par wolowizard . En réponse au journal Le patron de l'agence de contrôle nucléaire Belge sceptique sur le nucléaire.. Évalué à 0.
Je t'en prie
Non, le calcul n'est pas biaisé. Il est correct sur la base seule de l'élaboration.
Je te rappelle que la puissance fournit pour une éolienne est au cube de la vitesse des vents.
Le vent est de combien sur les côtes? Le vent est de combien à 1000 km des côtes?
Comment tu fais?
Je veux dire… que tu es connecté au réseau électrique afin de renvoyer le surplus de ton éolienne au réseau ( tu le revends quoi…).
Une éolienne est inductive… ce qui donne un cos phi pas génial pour le réseau… il faut donc pour chaque ménage réfléchir sur le déphasage.
Pour limiter les pertes par effet joule le long des câbles, il faut exercer une forte tension…il faut réfléchir à ton propre réseau électrique pour chaque ménage.
Je peux plus facilement mettre à l'échelle et m'adapter avec une éolienne forte puissance… que de réfléchir sur un ensemble du parc d'un point de vue énergétique ( avec le réseau existant).
[^] # Re: Production décentralisée
Posté par wolowizard . En réponse au journal Le patron de l'agence de contrôle nucléaire Belge sceptique sur le nucléaire.. Évalué à 0.
Tu considères que l'élaboration est à coût nulle également…
Qu'est qui coute énergétiquement le plus cher?
La fabrication d'une éolienne d'1MW et pesant en gros une demi-tonnes de cuivre?
La fabrication de mini-éolienne de 4 kg de cuivre (en gros) fournissant quelques kilowatt (pour en gros un million d'habitant au moins)?
[^] # Re: "Nucléaire < Fossile" ?
Posté par wolowizard . En réponse au journal Le patron de l'agence de contrôle nucléaire Belge sceptique sur le nucléaire.. Évalué à 3.
Salut,
Avec une pareille définition, je mets tout dedans.
L'oxygène, l'eau, l'espèce humaine, etc …
Wolowizard et Xavier Claude sont un polluant car il rejette du C02 au delà d'un certain seuil…
[^] # Re: "Nucléaire < Fossile" ?
Posté par wolowizard . En réponse au journal Le patron de l'agence de contrôle nucléaire Belge sceptique sur le nucléaire.. Évalué à -1.
Alors là… honnêtement en quoi c'est un polluant?
[^] # Re: Production décentralisée
Posté par wolowizard . En réponse au journal Le patron de l'agence de contrôle nucléaire Belge sceptique sur le nucléaire.. Évalué à 3.
Salut,
Si on prend l'exemple de l'éolien, la puissance récupérable varie en gros au cube de la vitesse du vent. Ne vaut-il donc pas mieux se concentrer sur les sites fournissant des vent forts, comme les régions côtières?
Sans compter qu'une éolienne a besoin d'une certaine quantité de cuivre. Mieux vaut-il donc pas se focaliser à l'élaboration d'un système centralisé étant donné que ce qui fournit l'énergie d'un point de vue optimum se trouve localisé? ( on peut prendre le même argument pour le solaire,etc…).
# Pile graphique...
Posté par wolowizard . En réponse au journal FreeBSD 9.1 est sorti. Évalué à 2.
Je me pose une question toute bête….
Est-il encore pertinent pour FreeBSD d'essayer de coller au développement de Xorg et consort?
Je veux dire, ces projets deviennent de plus en plus linux-centric. Le développement est tellement rapide et bouge sans cesse, que je me demande s'il est pertinent d’allouer des ressources la-dedans.
Je suis plus ce que se passe chez NetBSD, mais quand je vois le petit "incident" qu'il y a eu lorsque un dev chez intel a changé un gros morceaux dans KMS/GEM et la micro gueulante des FreeBSDistes. Je me disais, à quoi bon… autant orienter le max de ressources pour une optimisation/spécialisation serveur du projet.
J'adorerais avoir une station de travail sous NetBSD ( ou FreeBSD au pire :) ) par exemple mais bon je sais m'en passer sans problème…
Est-ce que le développement de FreeBSD comme station de travail est-il encore pertinent?
[^] # Re: A suivre ....
Posté par wolowizard . En réponse au journal Les big balls de gentoo. Évalué à 3.
Ecrasé, j'en connais pas tant… mais des forks qui vivent bien, j'en connais:
OpenBSD
DragonFlyBSD
Shinken …
[^] # Re: GCC
Posté par wolowizard . En réponse à la dépêche NetBSD 6.0. Évalué à 10.
Salut,
Netbsd supporte pas mal d'archi. et devoir compiler et crosscompiler l'OS (noyau+userland) doit représenter un gros boulot à chaque changement de version.
C'est un travail de 3 ans pour tout stabiliser sur toutes les archi. La base s'est fixée à gcc 4.5
pour la stabilisation.
[^] # Re: GCC
Posté par wolowizard . En réponse à la dépêche NetBSD 6.0. Évalué à 6.
Salut,
Sonnenberger travaille sur le support de LLVM/Clang dans la base et pkgsrc.
L'un des avantages de Clang/LLVM qui intéresse, c'est qu'il a un ensemble de warning plus efficace que gcc ( en ce moment ça discute sévère pour l'activation de -Werror car apparemment ce n'est pas du tout stable avec pas mal de faux positif: ici entre les différentes versions).
Clang est nettement moins aggressif sur l'optimisation du code ce qui permet un meilleur debogage.
Par contre Clang/LLVM supporte nettement moins d'archi que gcc.
un lien sur l'évolution de Clang/LLVM:
http://mail-index.netbsd.org/tech-toolchain/2012/04/19/msg001862.html.
[^] # Re: VirtIO
Posté par wolowizard . En réponse à la dépêche NetBSD 6.0. Évalué à 4. Dernière modification le 18 octobre 2012 à 11:14.
Salut,
Si ça t'intéresse, c'est la réponse d'un dev. Netbsd ( Jean-Yves Migeon) à propos des drivers Virtio, sur la mailing list de Netbsd.
Il y a aussi un lien pour le benchmark:
http://mail-index.netbsd.org/tech-kern/2012/08/08/msg013760.html
[^] # Re: Pourquoi passer à systemd ?
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 1.
???
Je suis intervenu sur la mutualisation.
Après c'est toi qui interprète que c'est tendu.
ensuite tes dires:
Personnellement, ca n'a rien à voir avec mon intervention initiale (le reste je trouvais pertinent).
Si on doit parler d'init (hors mutualisation des ressources), moi je veux bien. J'ai une question pourquoi un design orienté événement est pertinent pour un init?
[^] # Re: Pourquoi passer à systemd ?
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2. Dernière modification le 16 octobre 2012 à 19:43.
si je veux être vraiment sérieux, je ne poste pas sur trollfr… sinon précédemment, c'était une figure de style. Franchement, parler de systemd est infaisable ( c'est d'ailleurs pour ça que je m'étais branché sur la mutualisation).
Non pour moi ça c'est être compatible…
Je ne sais même pas si on peut vraiment parler d'interopérabilité entre les différentes distro… il faudrait avoir différents "opérateurs" dont la structure même du système soit différente ce qui n'est pas vraiment le cas.
Je prends les distro. comme étant pratiquement un même opérateur ( un GNU/Linux).
je mets ça en référence pour développer mes propos:
tu penses ce que tu veux, personnellement, je m'en fiche, ce n'est pas mon problème.
Pour dire que tu peux mettre n'importe quels projets à côté, parler d'interopérabilité pour des GNU/linux n'a pas de sens ( en tout cas pour moi ).
Si je voulais parler sérieusement ( le vrai sérieux): la plupart des noyaux sont de plus en plus orienté évènements avec des interfaces asynchrones/non bloquantes (epoll, /dev/poll, aio, kqueue), celà permet une meilleure montée en charge.
systemd/upstart/klaunchd/init SMF de solaris sont tous orientés événements et c'est ce que veut tous les partisans de systemd. Pour eux c'est un design moderne, que n'importe quel autre type d'init n'a pas et qu'il est un non sens d'utiliser ( cf flamewar debian-dev a propos RFC sur openrc). En quoi un paradigme orienté évènement est-il bon pour un init?
Pour ce qui est de la supervision: il existe déjà des alternatives (runit et s6 de Bernstein). Pour les init BSD il a un projet FreeBSD pour de la supervision. En quoi ces alternatives sont mauvaises ou pas populaires?
Je te signale encore que je ne parlais pas de systemd mais de mutualisation, lance le troll une fois de plus si tu veux… mais je n'interviendrais pas.
FreeDesktop n'est pas un peu linux-centré, non? ( j'sais pas. Il y a des gars coté solaris ou de BSD qui s'éclament dans leur "standards"?) La dernière fois que j'ai entendu quelque chose c'est pour KMS/GEM avec une refonte énorme du code et un pétage de câble côté FreeBSD pour leur port.
Finalement, c'est quoi un standard FreeDesktop? ( ça c'est la vraie question sérieuse)
[^] # Re: Pourquoi passer à systemd ?
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 1. Dernière modification le 16 octobre 2012 à 15:28.
Interopérabilité de quoi? On est sur un OS identique avec des toolchains identiques, un userland aussi différent qu'il y a de différences génétique entre l'homme et le singe!
Si être interopérable, c'est de sauter entre un Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora… alors la communauté linuxienne a un problème.
Comme il y a en ce moment avec systemd….
et franchement qu'est-ce que ça change a aptitude install, un synaptic, yum, pour les utilisateurs/admin ..etc tant que ça gère les dépendances et ça installe. D'ailleurs il y a pakagekit maintenant…
L'autre problème des mainteneurs, c'est la gestion des dépendances et le versionning… pourquoi ne pas mutualiser?
[^] # Re: Pourquoi passer à systemd ?
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 2. Dernière modification le 16 octobre 2012 à 14:58.
Mais je suis très sérieux! Au final, s'il y a un problème de maintenance, donc de personne pourquoi ne pas mutualiser tout? Faire comme font les BSD, un OS, avec un noyau, un userland spécifique puis un dépôt tiers?
Que l'on réponde franchement, pourquoi ne pas faire ainsi?
[^] # Re: Pourquoi passer à systemd ?
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 1. Dernière modification le 16 octobre 2012 à 14:44.
Si c'est un problème de mutualisation, pourquoi les distrib. ne font pas un système de distribution binaire commun?
Par exemple, celui de Red-Hat pour tous les appli binaires communes à toutes les distrib. puis modulo des arbres spécifiques à chaque distrib. pour ce qui n'intéresse pas Red Hat. Pourquoi les mainteneurs ne font pas ça?
Ca leur faliciterait la vie, un gros arbre commun, de plus comme le matos sera Red Hat moins de gestion matériel.
Pourquoi ne pas mutualiser le boot et l'init sur linux aussi?
Pourquoi ne pas caser tout ce qui est nécessaire au boot dans un bien sympa initramfs géré avec dracut (celui-ci gère aussi l'orienté événement)?
Tout le monde aurait le même script automatisé? Mise à jour? hop script dracut!
Pourquoi ne pas faire un partitionnement commun, unique?
hop /boot et / sans /usr puisqu'il ne sert plus à rien!
Comme tous les scripts démons seront tous mutualisés par systemd… plus personne n'aura à s'en faire.
On pourrait aussi mutualiser les méthodes d'install!
hop par défaut /boot et / .
Quoi tu es admin? hop mode expert raid,lvm sur / (qui aura /share /local /var /bin /sbin /home) ou bien du nfs?
Franchement pourquoi les distrib. ne font pas un installeur commun.
En plus c'est génial tout ça car on aurait un seul endroit pour géré les rapports de bug! Et on aurait plein de beta testeur!
Une pour les mutualiser toutes!
Enfin de compte Lennart a complètement raison, autant faire un OS complet à la BSD.
[^] # Re: Parallèle avec dragonfly
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 3. Dernière modification le 15 octobre 2012 à 09:35.
L'existant?
Alors explique-moi les commentaires de Lennart:
"In other words: systemd and journald are separate enough from each other
to make them two processes, but way too integrated to separate them from
each other entirely and allow one running without the other."
http://www.spinics.net/lists/fedora-devel/msg172203.html
[^] # Re: Parallèle avec dragonfly
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -2. Dernière modification le 15 octobre 2012 à 09:12.
Bon ben au final je me suis royalement chié dessus… moinssez moi. Ce sera ma punition pour dire de la merde sans vérifier par moi même.
[^] # Re: Parallèle avec dragonfly
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -3.
Non, tu as raison, je me suis grave trompé dans les ordres de grandeurs.
Il fait dans les 300 mille lignes de codes.
[^] # Re: Parallèle avec dragonfly
Posté par wolowizard . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -1.
Qu'il ne fait pas son job… je ne boote pas mes systèmes existants ( pas d'initramfs et pas /sur par sur /), c'est un peu cocasse pour un init.
Maintenant, systemd embarque un moteur http :
http://www.spinics.net/lists/fedora-devel/msg171856.html
Je veux bien qu'il réponde au problème d'un init orienté évènementiel, qu'il fasse de la supervision de démons…
mais il fait plus d'un million ligne de code! Oui il fait plus qu'un init… mais en attendant il n'init pas tous les cas existants…
[^] # Re: Une version binaire de Gentoo
Posté par wolowizard . En réponse au journal Ma Gentoo... je t'adore mais.... Évalué à 1.
tu es un rootkit à toi tout seul ! :)
[^] # Re: Manque de main d'oeuvre comme beaucoup d'autres
Posté par wolowizard . En réponse au journal Ma Gentoo... je t'adore mais.... Évalué à 4.
Gentoo a eu une lutte interne en 2006/2007 comme il en arrive partout…
Non, ce n'est pas le nombre d'utilisateurs qui fait la qualité d'une distro (ça se serait)… c'est le nombre de gens qui y participe activement!
un exemple tout con, qui secoue pas mal le monde linux à l'heure actuelle: systemd
Excluons toutes discussions techniques dessus ou passionnelles. Ce qui fait réellement le succès de systemd c'est le fait:
1/ qu'il soit développé par Red Hat: les dev principaux ( Lennart, Sievers, Hoyer,…)
2/ qu'il soit activement maintenu.
Les distro qui ont migré le font principalement pour la facilité de maintenance!
Je ne sais pas si tu suis la mailing list debian-dev ou celles de gentoo, mais les dev. veulent maintenir officiellement un et un init, sinon ça représente un travail colossal pour le nombre de personnes disponibles.
Il y a des fights colossaux la-dessus car:
1/ énormément de distro. sont de moins en moins dépendantes car il y a peu de leur dev. qui soit développent soit contribuent fortement sur les couches basses du système ou sur linux lui-même.
2/ il y a peu de gens pour maintenir plus de logiciels. La liberté et le choix coutent énormément de ressources!
Greg KH le dit lui même… les distro. généralistes deviennent un non sens face à la quantité de travail qu'il y a fournir. Autant faire une chose et le faire bien. Les distro. devraient se spécialiser.