Alors, pourquoi… pourquoi, même lorsque l'on tente de garder un fichier make.conf raisonnable, faut-il toujours qu'une application s'acharne à le faire grossir ? Inévitablement, mise à jour après mise à jour, on fini par tomber sur une application qui ne se compile qu'à condition de rajouter une nouvelle entrée à ma liste de "USE FLAGGS". Cette appli elle-même voudra en installer d'autres qui auront elles aussi leurs propres exigences… et le fichier minimaliste de départ finit par devenir gargantuesque.
Il peut rester simple… par contre le /etc/portage/package.use commence à grossir … je l'ai donc changé en répertoire pour m'y retrouver.
pourquoi, alors même que je m'acharne à éviter tout ce qui est flags exotiques et à rester dans la version stable, pourquoi alors faut-il toujours qu'il y ait des paquets dont la compilation échoue ?
ça arrive… mon dernier en date fut avec wine. C'est clairement un bug, faut le remonter.
Personne ne teste t-il jamais tes paquets ? Et d'ailleurs, pourquoi certains paquets sont-ils toujours uniquement disponibles dans la version instable après parfois des années ?
Tu viens de toucher du doigt le problème actuel de toute distribution qui ne dépend pas d'une entreprise: le manque de main d’œuvre… mais tu peux te proposer et rapporter les bugs :)
Il est très difficile de tester chaque option de compilation d'un ensemble d'ebuild sans compter l'environnement de chacun… ça fait énormément de tests!
Pourquoi, alors que la plupart de ta documentation est excellente, pourquoi tombe t-on parfois sur des pages oubliées depuis des années ?
idem… manque de main d’œuvre. Mais va du côte du forum français, ils sont plusieurs qui tentent de remettre à jour et d'améliorer les pages.
Tu peux proposer ton aide aussi… je pense qu'ils ne refuseront pas.
Et pourquoi, pourquoi es-tu si lente à présent quand je recherche de nouveaux paquets ? Il me semble que emerge met à présent plus de dix secondes avant de démarrer. Tu n'étais pas si lente avant pourtant.
ça faut voir, ça peut venir de plusieurs choses et probablement de python aussi.
quel USE flag pour portage? quel version de portage as-tu?
Si python3 … il n'y a plus le module cpickle et portage utilise des fichiers pickle pour les métadonnées.
ensuite si tu es en version 2.2, probablement qu'un downgrade en2.1 pourrait améliorer les choses… faut voir.
Idéalement, une version binaire de Gentoo
Je te conseille calculate-linux, elle est compatible gentoo, de gestion plus simple, et gère des packages binaires.
Posté par wolowizard .
En réponse au journal Archlinux est morte….
Évalué à 6.
Dernière modification le 10 octobre 2012 à 23:48.
…il y a une poignée "d'irréductible" qui essaient une critique constructive.
Il y a un étudiant gsoc (Xu Benda) qui a bossé sur OpenRC et une meilleure intégration avec un autre projet très sympa: Gentoo Prefix.
Ca permet d'installer l'arbre portage en mode "unprivileged" sur différente plateforme ( comme à la pkgsrc de NetBSD):http://www.gentoo.org/proj/en/gentoo-alt/prefix/
l'arbre de dépendance d'OpenRC est géré dynamiquement tandis que les scripts chez Debian utilisent les LSB, il y a un script qui lit les entêtes LSB pour les fournir à OpenRC.
Normalement OpenRC embarque avec lui les scripts réseau de Gentoo, mais il laisse la possibilité à Debian d'utiliser ses propres scripts.
Posté par wolowizard .
En réponse au journal Archlinux est morte….
Évalué à 2.
Dernière modification le 10 octobre 2012 à 13:26.
Wai, enfin la pour le coup, openrc se rapproche de systemd dans la syntaxe et le principe (de base)…
Non…
1/ il se veut portable. C'était le but du développeur initial. Il y a Robbins qui démarche chez Freebsd pour openrc . Je crois Debian se pose aussi la question d'un port.
2/ openrc n'est pas un init (c'est sysvinit ici)
3/ on utilise des scripts… chose sur quoi le débat a lieu ici.
Mais on peut pendre les scripts init rc de FreeBSD ou de NetBSD aussi … ils ne feront pas beaucoup de lignes non plus. ( haveged n'est pas pkgsrc mais l'écriture du script sera simple).
C'est intéressant comme comparaison (vraiment). Je me suis donc demandé si c'était vraiment un problème inhérent au système de scripts que systemd pourrait "solutionner". J'ai donc regardé sur la distro gentoo avec ton exemple. Gentoo utilise openrc sysvinit et un ensemble de script pour l'init donc c'est tout trouvé comme exemple alternative.
haveged est dans l'arbre portage. Pour le démon il y a 2 fichiers conf:
celui du service: /etc/init.d/haveged
#!/sbin/runscript# Copyright 1999-2011 Gentoo Foundation# Distributed under the terms of the GNU General Public License v2command="/usr/sbin/${SVCNAME}"command_args="-r 0 ${HAVEGED_OPTS}"pidfile=/var/run/${SVCNAME}.pid
depend(){
provide entropy
}
celui de la config du démon: /etc/conf.d/haveged
# Copyright 1999-2011 Gentoo Foundation# Distributed under the terms of the GNU General Public License v2WATERMARK=1024
# -r0 is added alwaysHAVEGED_OPTS="-w ${WATERMARK} -v 1"
En dehors des commentaires, autant de lignes effectives que dans l'exemple avec systemd.
La doc. est faite aussi ici.
Le problème, est-ce vraiment la logique du script ou bien la "rigueur" dans la lisibilité qui pose problème?
Je comprends le point de vue de totof2000 ( et j'ai aussi lu le linux mag sur systemd (enfin pas tout encore)).
Posté par wolowizard .
En réponse au journal Archlinux est morte….
Évalué à 2.
Dernière modification le 09 octobre 2012 à 14:30.
Très peu utile quand on utilise l'hibernation ou la mise en veille de façon générale.
Mais je n'ai pas dit le contraire… tu rajoutes une condition supplémentaire qui n'a rien à voir avec un boot à froid.
Je te dis que si tu utilises le critère de vitesse de boot comme avantage de systemd par rapport à d'autres solutions et/ou optimisations, tu vas droit dans les choux. Ce qui fait le "succès" de systemd pour ses supporters est ailleurs.
quand on a 500 serveurs sous Arch, si on gagne 6 secondes par boot par rapport à une installation à l'ancienne (pour les geeks archaïques), en cas de mise à jour du noyau on gagne quand même 50 minutes…
Attends, attends… je ne comprends pas ton deal. Tu es en train de me dire que tu bootes tes serveurs en séries (6*500/60), l'un après l'autre, c'est ça?
souplesse,administration simplifiée
Pouquoi /usr et pas une sous-arborescence (si j'anticipe)?
* pourquoi pas? on laisse le choix, c'est flexible: si tu as envie tu peux, si tu veux rester simple tu peux aussi.
* 1 ligne sur le fstab
* migration plus simple aussi
* partage entre machine virtuelle simplifée
* mise à jour plus simple
Sous Arch au démarrage avec SSD, la partie console est presque instantanée pour moi. Après, kdm prend une petite seconde et le login sous kde environ 3 ou 4 secondes
C'est mou ! :)
En des temps reculés où la révolution systemd n'existait pas… une bande de geek bootaient en 5 secondes.
Techno: une fedora/Moblin modifiée avec upstart, HAL sur un EEEPC.
Non, j'attends juste qu'on m'explique en quoi ça peut être utile :-)
J'ai des /usr sur du lvm2, raid et pour certains montages en nfs…avec la racine en dehors de ces technos… mais tout cela importe peu…
Personnellement, ceux que je ne comprends pas, ce sont "les détracteurs" d'un /usr séparé de la racine, qui prennent l'argument historique pour assoir leur affirmations.
L'objectif suivant Fedora c'est de déplacer /bin /sbin /lib en les plaçant dans /usr sous prétexte qu''historiquement l'ensemble /lib, /bin /sbin étaient là pour bootstrapper le système par manque d'espace.
En effet, sur le pdp11, Unix fonctionnait sur une paire de disque RK05 de 1.5Mo chacun.
Un seul était insuffisant pour contenir tout le système. Le 2ème disque contenait "/usr" mais /usr à cette époque contenait les données utilisateurs et les binaires utilisateurs:
"It is common for the totality of user files to be too voluminous
for a given device. It is then impossible for the directories of
all users to be members of the same directory, say /usr. Instead
they must be split into groups, say /usr1 and /usr2;" D.Ritchie p.1953-1954 Bell System Technical Journal (juillet-Août) 1978 UNIX Time-Sharing System: A Retrospective.
Il y a également des indices dans le papier de Bourne UNIX Time-Sharing System: The UNIX Shell même époque où le PATH de l'utilisateur s'écrit comme PATH=:/usr/fred/bin:/bin:/usr/bin
/usr à commencer à perdre son sens ( d'ailleurs personne ne comprends à l'heure actuelle la signification de usr: Unix ressources, User ressources…) à partir du moment où /home est apparu (données utilisateurs) et qu'on a commencer à mettre des applis systèmes dedans:
"This directory [/usr] used to be the other file system on a UNIX machine. In
the System V ABI it has lost most of its importance. The ABI states
uses only for /usr/bin and /usr/share, and the name /usr has lost its
original meaning: the ABI specifies /usr only as a location for system
files that users may wish to access. "Chapitre 4 du livre de Greg Lehey: Porting Unix Software
/usr n'a plus de sens, pourquoi le garder? En plus si c'est pour dire http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken:
"The duty of the minimal boot system that consisted of /bin, /sbin and /lib on traditional Unix, has been taken over by the initramfs of modern Linux."
Ha bah! alors, mettons tout le sytème de boot et la racine dans une initramfs alors, puisque c'était le but initial de /lib /sbin /bin … pour au final ne garder que /boot avec le noyau et l'initramfs et /others pour tout le reste sur un disque!
et enfin arrêtons d'appeler systemd/udev un system d'init dans ce cas ( l'init c'est initramfs qui va se charger du montage) mais plutôt un controlleur de démons: "An initramfs that supports mounting /usr on top of / before it starts 'init'"
La plupart des systèmes comme OpenBSD, NetBSD, Freebsd (hier(7)) definissent ce qu'on attend dans /usr "Contains the majority of user utilities and applications." Ca marche, c'est pratique, c'est rodé et le système boot sans initramfs! Je peux mettre n'importe quel filesystem dans /usr. En quoi c'est plus chiant à faire sur linux?
D'ailleurs, comment est l'arborescence dans Plan 9?
(j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
C'est Tanenbaum qui va être content… :)
Moi j'ai un truc que je ne comprends pas… il n'est pas possible de faire quelque chose de modulaire avec udev? Si on respecte "un modèle en couche" propre, a priori c'est udev qui fournit un service à init, systemd, etc… pourquoi absolument privilégier une dépendance forte?
D'ailleurs, Kaane, comme tu touches souvent du FreeBSD… il y a devd pour le remplissage à chaud de nouveau noeuds de périphériques. Tu as regardé le code? C'est une interface stable, non?
De ce que j'ai regardé, c'est simple, propre (mais c'est mon avis), ça fait son travail et ça semble stable sur le temps… c'est quoi le problème avec udev? Ce serait vraiment Sievers/Lennart?
reboot=bios ne marche que pour des archi. bien spécifiques et notamment x86. [1]
D'ailleurs, ce shutdown est un gros hack pour les machines Dell comme tu le dis [2]
Il n'y a pas ce hack dans le code x86_64… apparemment, il faut repasser en mode 32 bit pour l'activer.[3]
Salut,
Personnellement je ne suis pas Archiste. J'ai personnellement rien contre systemd à la condition que l'on ne me l'impose pas. Je suis sous OpenRC (Gentoo) et ça me convient… Le truc que je n'aime pas particulièrement ces derniers temps est udev, car le nouveau truc à la mode c'est de considérer que /usr doit être sur la même partoche que / sinon ça boote pas! ( ou bien avec une initramfs)
Maintenant que udev est mergé avec systemd… on peut considérer que c'est un même projet.
Pour l'instant on n'a pas vu Lennart mais je doute qu'il passe…
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
L'histoire se tient à propos du chargement des firmwares dans le noyau. Udev avec les nouvelles versions est très lent à les charger et ça fout la merde…
Depuis le mois d’août, il y a eu des patchs mais Kay n'en tient pas compte, limite il s'en fout…
Le pire, il accuse le noyau d'avoir des bugs … et ça gonfle clairement Linus.
Résultat des comptes, pour le chargement des firmwares et probablement des modules, le noyau risque de complètement outrepasser udev. La raison? Des mainteneurs qui en font qu'à leurs têtes et inefficaces.
Si vous n'aimez ce que devient udev en ce moment, prenez un sachet de pop-corn et lisez la LKML. Perso, j'ai fini mon sachet sans m'en rendre compte!
Quelques perles spéciales Linus:
Maintenant que les news de Microsoft Windows NT sont érites par pasBill pasGates,
que iOS est défendu par pasScott pasForstall,
il ne manque plus qu'un pasLarry pasEllison. Qui se dévoue pour faire une news sur Solaris?
De ce que j'ai appris, SUA est déprécié sous Windows 8. Pourquoi pas après tout? Je ne connais le nombre de clients mais la demande ne devait pas être très forte ; sans compter que le support Unix n'était pas très adapté…
Maintenant, je me pose la question d'un support futur viable d'un environnement POSIX sous Windows NT.
Il y a bien sûr Cygwin… mais comme d'habitude, il y a toujours un problème: l'appel à fork().
Il n'existe pas de correspondance un à un entre un appel fork() et une fonction quelqueconque dans l'API win32. Il y a bien l'appel CreateProcess que Cygwin utilise pour son implémentation de fork, mais ça "sucks" grave au niveau performance sans compter d'autres problèmes.
Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?
Si je parle de ça, c'est que Corinna Vinschen essaie d'améliorer les choses avec le fork() de Cygwin… mais qu’apparemment la barrière de dialogue est assez difficile.
Est-ce que Microsoft a une alternative à proposer pour SUA?
Pourquoi il manque une documentation pour la Native API? Interix utilise cette Api, il a une implémentation de fork() très correct et c'est très probablement par l'utilisation d'appel se rapprochant des fonctionnalités d'un fork() qui n'est documenté nulle part.
Microsoft conseille, pour le portage d'une appli Unix vers NT, d'adapter fork/exec par autres choses comme CreateProcess de l'Api Win32; s'il existe un appel plus efficace, pourquoi ne pas le déclarer, documenter?
De plus et c'est valable pour beaucoup de véhicules aux normes Euro 3 et plus, la consommation est énormément lissée par les systèmes d'injection/allumage modernes, comprendre la plage entre la plage entre la consommation mini et maxi est très resserrée, beaucoup plus qu'avant
Les normes EurosN concernent les émissions à gaz "toxiques" et polluant ( ne prend pas en compte l'émission de dioxyde de carbone). Peux-tu me dire comment tu fais pour passer de la quantité d’émission de ces gaz aux km (ou aux kWh) à la consommation d'un véhicule?
le plus 20 à 30 % est totalement faux.
Sources?
Pour donner des chiffres, sur un 650 kawa (Versys même moteur que l'ER-6) sur 50 000 km la consommation mini a été de 4,2 litres et la maxi 6.5 litres (Journée circuit) et la moyenne à 5 litres.
Une source que je peux lire?
Journée circuit, que cela veut-il dire? test sur circuit? y-a-t-il des phases d'accélération douces et rapides sur au moins 2km ( compter une bonne vingtaine de fois) ?
Enfin, le marché du 2 roues est devenu un marché de mobilité urbaine, les chiffres des ventes sont disponibles et ils sont très clair, les scooters dominent de la tête et des épaules le marché des 125 et commencent à se tailler une très belle part dans le marché gros cube.
Ta source signale une baisse globale du marché…avec une augmentation pour les gros cube pour la période estivale!( été, vacance, plaisir, toussa,…)
J'ai une source de 2008 venant du ministère du développement durable concernant Localisation des ménages et usage de l’automobile.
On y apprend comment suivant les contextes, les personnes utilisent un véhicule motorisé (2 roues compris) en zone urbaine. Les personnes utilisant la moto/scooters sont négligeables par rapport à celle avec la voiture.
La moto reste un plaisir, il suffit de comparer d'une part le prix, le prix de l'assurance, de la commodité de l'appareil, de la possibilité de transport de personnes, et les vols, la consommation.
Les derniers comptages effectués en région parisienne font état de pics à 40% de deux roues en périodes de pointe. Ce n'est pas pour se faire plaisir, mais pour répondre à un réel besoin de mobilité que les transports en communs, bus compris, n'offrent pour l'instant pas; indépendamment de l'aspect économie d’énergie.
Source pour le pic à 40%? d'ailleurs un pic de quoi? sur la durée de l'accélération? Combien dure ce pic? Combien y-a-t-il de pics sur un parcours urbain à trafic dense?
Et si la moto c'est pour se faire plaisir ( même le lien que tu me donnes confirme cela)!
Je ne dis pas non plus que l'on ne peut pas améliorer l'efficacité du transport commun… mais ce que l'on constate c'est surtout que les gens en ville préfère utiliser un engin motorisé pour faire en gros 2 km ( 33% de déplacement pour la source que je donne); sachant que dans la zone dense, il y a un transport en commun à moins de 100m.
Un bus en consommation par personne fera toujours moins (en tout cas en période dense).
Les constructeurs se plaignent du calendrier de mise en vigueur des normes EurosN (trop dur) et demandent des reports. La R&D coute également bonbon…
Si on veut mutualiser le cout de la consommation en essence, je dis que l'aménagement du territoire, et l'optimisation des moyens de transport ( qui sont pas trop trop mal en moyenne)
sont plus profitables que de forcer et espérer que les constructeurs améliorent les engins.
Relativement si. Les 600/650 font maintenant dans les 5/5.5 litres voire moins pour les plus modernes et hormis quelques motos particulières dont l’usage urbain n'est pas des plus agréable, la conso des gros cubes a très largement chuté entre 6 et 7 litres (au cent bien sur). Les normes Euro y sont pour beaucoup.
Enfin les scooters archi majoritaire en zone urbaine sont de petites cylindrées avec des consommation tournant plutôt du coté des 4 à 5 litres, voire moins pour les 125 (environ 35% du marché).
Je parlais bien d'utilisation en milieu urbain.
Sinon, je me suis fendu d'un moto magazine (fevrier 2012) de ma meuf. Avec la comparaison de quelques 600/650cm3 (à part la ducati qui frôle les 700):
Ducati 696 Monster
Honda CBF 600N
Kawazaki ER-6N
Suzuki 650 Gladius
Yamaha XJ6 N
Pour leur test la consommation moyenne tourne entre 5.5 et 6L (à part pour la suzuki à 5.L)
Leur essai, je ne sais pas où ils les ont fait mais c'est surement pas en ville ( ils ont testé les reprises et les consommations à 130km/h).
En ville, la consommation peut facilement monter entre 15 et 20% ( certain estiment même à 30%) de la consommation moyenne.
Je ne pense pas déconner avec mes chiffres (et je ne parle pas des bonnes grosses cylindrée).
Je n'avais pas effectivement regardé les scooters:
Pour les scooters, j'ai regardé les tests (motomag sur le net) d'un X-max yamaha 125cm3, ils affirment 4L en ville (de même pour les piaggo 125).
Au final, ça ne change en rien à l'argumentation.
on prend la trentaine de passagers d'un bus qui consomme en gros 30L au 100 (et je ne parle pas d'un bus optimisé en consommation, je donne juste un ordre de grandeur), et on les met tous en scooters… la conso totale en scooter restera supérieure à celle d'un bus (pour un même circuit urbain).
J'ai rien contre les motards, mais leur véhicule reste quand même un objet pour se faire plaisir.
Avec les progrès technologiques, il doit être possible de créer des véhicules destinés à l'usage urbain faisant dans les 500 kg et ne consommant que 1 ou 2 l aux 100 km, ce qui correspond au concept de la 2CV pour la technologie de l'époque.
Pour le milieu urbain, le véhicule léger est le problème pour la consommation. D'ailleurs, si on cherche vraiment à quantifier, on devrait plutôt parler de consommation moyenne par personne ( l /(km. personne)).
La meilleur façon de diminuer la consommation en ville, c'est de densifier celle-ci en habitats et de développer le transport type poids "lourds" (genre bus).
Le problème en ville pour un moteur thermique à explosion, c'est les phases d’accélération, et de freinage répétitifs. Ces phases augmentent d'autant que le trafic est dense.
Si on cherche à quantifier un peu:
En moyenne, une moto consommerait 7l au 100 ( je ne suis pas motard mais mon amie l'est). Bien sûr, ça dépend du type de moteur, du type de conduite, etc… En gros ça peut monter bien jusqu'à 10l au 100 suivant le motard et la moto; prendre 7l au 100 c'est pas trop déconnant…tout ce là pour 1 personne (rarement des motards en ville avec un passager).
En moyenne, une voiture en ville peut consommer jusqu'à 5 à 6l au 100, suivant les modèles et le type du conducteur on peut monter facile jusqu'à 12l au 100km.
En moyenne, la consommation par personne varie entre 6l et 1.4l ( 1personne et 4 personnes).
La consommation d'un bus (75 places à une dizaine de places) varie en ville entre 30l et 50l au 100 km. Comme d'habitude, ça dépend du chauffeur, du modèle de bus, etc…
On remarque que, pour un bus prenant en moyenne une dizaine de personnes, on passe de 3 à 5l au 100km par personne. Si on augmente la quantité de passagers, cette valeur diminue d'autant…
Pour un transporteur en ville, son but c'est de minimiser sa consommation et le cout total de son parc de bus ( c'est à dire le moins de bus possible utilisés efficacement ).
Cela étant dit, on pourrait adapter le type de bus en fonction de horaires: heures de pointe, bus 75 places et heures creuses bus 10 places consommant moins. Mais le problème de cette méthode, c'est l'investissement couteuse pour le transporteur dans son parc (qu'il faudra rentabiliser).
Le mieux serait d'adapter une fréquence de bus suivant les heures pleines ou creuses ( un bus tous les 5 minutes en heures pleines et tous les quarts/demi heures en heures creuses). C'est ce qui se fait à l'heure actuelle.
Si on diminue le trafic urbain, il y aura moins de véhicule ayant une forte consommation (donc globalement moins de consommation) et donc moins de phases d'accélération et de freinages (donc une diminution de la consommation).
On si densifie l'habitation, les lieux de travail, etc… on augmente la possibilité d'avoir plus de personnes montant dans un bus.
C'est mon opinion, mais je pense que l'optimisation de la consommation ne passe forcément à l’amélioration systématique de la techno automobile. On pourrait avoir des améliorations plus rapide autrement.
Vraiment ? Si on a mélangé des métaux pour faire des alliages, c'est qu'on a une utilisé pour ces alliages : ne peut-on pas les utiliser tels quels ? Genre, fondre un vieux clou en laiton pour en faire… un autre machin en laiton ?
Pour faire un alliage en laiton il faut un four chauffant au moins à 1000°C.
Les fonderies, en ce moment des personnes se battent pour ne pas les éteindre…
Il y a les fours à arc… mais bon, ce n'est pas la même échelle.
Ensuite, le laiton c'est un alliage entre du cuivre et du zinc en proportion variable (avec parfois d'autres éléments), si tu mets tous "les clous" et autres objets en laiton pour recycler ( avec des impuretés) dans le creuset… tu auras un alliage "batard" qui ne trouvera pas forcément preneur (dureté, usinage, etc…)
[^] # Re: Une version binaire de Gentoo
Posté par wolowizard . En réponse au journal Ma Gentoo... je t'adore mais.... Évalué à 6.
Avant de me farcir du supra négatif:
1/ on est trolldi
2/ le changement de gentoo d'arch n'est pas forcément ce qu'il y a de plus doux.
# 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. Dernière modification le 12 octobre 2012 à 08:37.
Il peut rester simple… par contre le /etc/portage/package.use commence à grossir … je l'ai donc changé en répertoire pour m'y retrouver.
ça arrive… mon dernier en date fut avec wine. C'est clairement un bug, faut le remonter.
Tu viens de toucher du doigt le problème actuel de toute distribution qui ne dépend pas d'une entreprise: le manque de main d’œuvre… mais tu peux te proposer et rapporter les bugs :)
Il est très difficile de tester chaque option de compilation d'un ensemble d'ebuild sans compter l'environnement de chacun… ça fait énormément de tests!
idem… manque de main d’œuvre. Mais va du côte du forum français, ils sont plusieurs qui tentent de remettre à jour et d'améliorer les pages.
Tu peux proposer ton aide aussi… je pense qu'ils ne refuseront pas.
ça faut voir, ça peut venir de plusieurs choses et probablement de python aussi.
quel USE flag pour portage? quel version de portage as-tu?
Si python3 … il n'y a plus le module cpickle et portage utilise des fichiers pickle pour les métadonnées.
ensuite si tu es en version 2.2, probablement qu'un downgrade en2.1 pourrait améliorer les choses… faut voir.
[^] # Re: Une version binaire de Gentoo
Posté par wolowizard . En réponse au journal Ma Gentoo... je t'adore mais.... Évalué à 5.
Ho non…
Sabayon ou bien Calculate-Linux….
[^] # Re: Transmission de code
Posté par wolowizard . En réponse au journal [TOI AUSSI] Viens prendre un cours de programmation système. Évalué à 2.
Vu ce qu'ils ont changé: des parties dans le vfs, dans l'ordonnanceur,… ça va être trop chaud de récupérer, ce n'est pas un driver là.
Par contre ce qui m'inquiète c'est que Net s'effondre avec un critical temperature shuttting down…
[^] # Re: bench complet
Posté par wolowizard . En réponse au journal [TOI AUSSI] Viens prendre un cours de programmation système. Évalué à 3. Dernière modification le 11 octobre 2012 à 09:05.
Je l'avais lu sur la mailing list… mais Matt n'avait pas posté le bench.
C'est une superbe nouvelle!
De très belles choses avec peu de moyen!
# Et pendant ce temps là chez gentoo...
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 6. Dernière modification le 10 octobre 2012 à 23:48.
…il y a une poignée "d'irréductible" qui essaient une critique constructive.
Il y a un étudiant gsoc (Xu Benda) qui a bossé sur OpenRC et une meilleure intégration avec un autre projet très sympa: Gentoo Prefix.
Ca permet d'installer l'arbre portage en mode "unprivileged" sur différente plateforme ( comme à la pkgsrc de NetBSD):http://www.gentoo.org/proj/en/gentoo-alt/prefix/
Bien sur, ça ne s'est pas arrêté là puisque Debian s’intéresse fortement à OpenRC: http://wiki.debian.org/OpenRC
Résultat:
Mais ce n'est pas fini!
Benda "s'amuse" à brancher openrc (qui n'est pas un init) à runit! http://www.awa.tohoku.ac.jp/~benda/projects/runit.html
Mais qu'est-ce que runit? http://smarden.org/runit
Mais le plus drôle c'est s6 ! http://www.skarnet.org/software/s6/why.html
mais qu'est-ce que s6?
C'est en discussion pour une intégration avec openrc.
Concernant des actions événementielles?
Openrc a du code hotplug qu'il reste à fixer avec udev…
… le problème reste udev:
Il y encore des dev Gentoo qui déjà soignaient les scripts (pas de "bashism", "POSIX", utilisation de dash)
et qui couple OpenRC avec busybox tout en limitant les dépendances et rendre le tout "light":
blog.flameeyes.eu/2010/08/polishing-init-scripts
http://blog.flameeyes.eu/2012/03/how-down-can-you-strip-a-gentoo-system
Certains essaient de convaincre chez FreeBSD
Il y a de quoi s'amuser, tester … puis comparer.
[^] # Re: Tu n'es pas le centre du monde
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 3.
C'est dans le bac:
http://gentooexperimental.org/~patrick/weblog/archives/2011-10.html
http://blog.flameeyes.eu/2011/11/the-infamous-run-migration
le git
Pour les debianeux:
http://lwn.net/Articles/513224/
[^] # Re: Tu n'es pas le centre du monde
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 2. Dernière modification le 10 octobre 2012 à 13:26.
Non…
1/ il se veut portable. C'était le but du développeur initial. Il y a Robbins qui démarche chez Freebsd pour openrc . Je crois Debian se pose aussi la question d'un port.
2/ openrc n'est pas un init (c'est sysvinit ici)
3/ on utilise des scripts… chose sur quoi le débat a lieu ici.
Mais on peut pendre les scripts init rc de FreeBSD ou de NetBSD aussi … ils ne feront pas beaucoup de lignes non plus. ( haveged n'est pas pkgsrc mais l'écriture du script sera simple).
[^] # Re: Tu n'es pas le centre du monde
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 7.
C'est intéressant comme comparaison (vraiment). Je me suis donc demandé si c'était vraiment un problème inhérent au système de scripts que systemd pourrait "solutionner". J'ai donc regardé sur la distro gentoo avec ton exemple. Gentoo utilise openrc sysvinit et un ensemble de script pour l'init donc c'est tout trouvé comme exemple alternative.
haveged est dans l'arbre portage. Pour le démon il y a 2 fichiers conf:
celui du service: /etc/init.d/haveged
celui de la config du démon: /etc/conf.d/haveged
En dehors des commentaires, autant de lignes effectives que dans l'exemple avec systemd.
La doc. est faite aussi ici.
Le problème, est-ce vraiment la logique du script ou bien la "rigueur" dans la lisibilité qui pose problème?
Je comprends le point de vue de totof2000 ( et j'ai aussi lu le linux mag sur systemd (enfin pas tout encore)).
[^] # Re: Et tu remplaces Arch Linux par quoi ?
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 2.
Comme troller sur les init ?
c'est par là, je crois --------------> [ ]
[^] # Re: Deb & Ian
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 2. Dernière modification le 09 octobre 2012 à 14:30.
Mais je n'ai pas dit le contraire… tu rajoutes une condition supplémentaire qui n'a rien à voir avec un boot à froid.
Je te dis que si tu utilises le critère de vitesse de boot comme avantage de systemd par rapport à d'autres solutions et/ou optimisations, tu vas droit dans les choux. Ce qui fait le "succès" de systemd pour ses supporters est ailleurs.
Attends, attends… je ne comprends pas ton deal. Tu es en train de me dire que tu bootes tes serveurs en séries (6*500/60), l'un après l'autre, c'est ça?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 1.
souplesse,administration simplifiée
Pouquoi /usr et pas une sous-arborescence (si j'anticipe)?
* pourquoi pas? on laisse le choix, c'est flexible: si tu as envie tu peux, si tu veux rester simple tu peux aussi.
* 1 ligne sur le fstab
* migration plus simple aussi
* partage entre machine virtuelle simplifée
* mise à jour plus simple
[^] # Re: Deb & Ian
Posté par wolowizard . En réponse au journal Archlinux est morte…. Évalué à 2.
C'est mou ! :)
En des temps reculés où la révolution systemd n'existait pas… une bande de geek bootaient en 5 secondes.
Techno: une fedora/Moblin modifiée avec upstart, HAL sur un EEEPC.
Il y a même eu un article du coin fait par patrick_g:
http://linuxfr.org/users/patrick_g/journaux/booter-en-5-secondes
Si systemd devait avoir une qualité, je ne mettrais pas en avant la vitesse de boot…
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 4.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 7. Dernière modification le 08 octobre 2012 à 17:45.
J'ai des /usr sur du lvm2, raid et pour certains montages en nfs…avec la racine en dehors de ces technos… mais tout cela importe peu…
Personnellement, ceux que je ne comprends pas, ce sont "les détracteurs" d'un /usr séparé de la racine, qui prennent l'argument historique pour assoir leur affirmations.
L'objectif suivant Fedora c'est de déplacer /bin /sbin /lib en les plaçant dans /usr sous prétexte qu''historiquement l'ensemble /lib, /bin /sbin étaient là pour bootstrapper le système par manque d'espace.
En effet, sur le pdp11, Unix fonctionnait sur une paire de disque RK05 de 1.5Mo chacun.
Un seul était insuffisant pour contenir tout le système. Le 2ème disque contenait "/usr" mais /usr à cette époque contenait les données utilisateurs et les binaires utilisateurs:
"It is common for the totality of user files to be too voluminous
for a given device. It is then impossible for the directories of
all users to be members of the same directory, say /usr. Instead
they must be split into groups, say /usr1 and /usr2;" D.Ritchie p.1953-1954 Bell System Technical Journal (juillet-Août) 1978 UNIX Time-Sharing System: A Retrospective.
Il y a également des indices dans le papier de Bourne UNIX Time-Sharing System: The UNIX Shell même époque où le PATH de l'utilisateur s'écrit comme PATH=:/usr/fred/bin:/bin:/usr/bin
/usr à commencer à perdre son sens ( d'ailleurs personne ne comprends à l'heure actuelle la signification de usr: Unix ressources, User ressources…) à partir du moment où /home est apparu (données utilisateurs) et qu'on a commencer à mettre des applis systèmes dedans:
/usr n'a plus de sens, pourquoi le garder? En plus si c'est pour dire http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken:
"The duty of the minimal boot system that consisted of /bin, /sbin and /lib on traditional Unix, has been taken over by the initramfs of modern Linux."
Ha bah! alors, mettons tout le sytème de boot et la racine dans une initramfs alors, puisque c'était le but initial de /lib /sbin /bin … pour au final ne garder que /boot avec le noyau et l'initramfs et /others pour tout le reste sur un disque!
et enfin arrêtons d'appeler systemd/udev un system d'init dans ce cas ( l'init c'est initramfs qui va se charger du montage) mais plutôt un controlleur de démons: "An initramfs that supports mounting /usr on top of / before it starts 'init'"
La plupart des systèmes comme OpenBSD, NetBSD, Freebsd (hier(7)) definissent ce qu'on attend dans /usr "Contains the majority of user utilities and applications." Ca marche, c'est pratique, c'est rodé et le système boot sans initramfs! Je peux mettre n'importe quel filesystem dans /usr. En quoi c'est plus chiant à faire sur linux?
D'ailleurs, comment est l'arborescence dans Plan 9?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 3.
C'est Tanenbaum qui va être content… :)
Moi j'ai un truc que je ne comprends pas… il n'est pas possible de faire quelque chose de modulaire avec udev? Si on respecte "un modèle en couche" propre, a priori c'est udev qui fournit un service à init, systemd, etc… pourquoi absolument privilégier une dépendance forte?
D'ailleurs, Kaane, comme tu touches souvent du FreeBSD… il y a devd pour le remplissage à chaud de nouveau noeuds de périphériques. Tu as regardé le code? C'est une interface stable, non?
De ce que j'ai regardé, c'est simple, propre (mais c'est mon avis), ça fait son travail et ça semble stable sur le temps… c'est quoi le problème avec udev? Ce serait vraiment Sievers/Lennart?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 4.
reboot=bios ne marche que pour des archi. bien spécifiques et notamment x86. [1]
D'ailleurs, ce shutdown est un gros hack pour les machines Dell comme tu le dis [2]
Il n'y a pas ce hack dans le code x86_64… apparemment, il faut repasser en mode 32 bit pour l'activer.[3]
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 3. Dernière modification le 06 octobre 2012 à 16:34.
Salut,
Personnellement je ne suis pas Archiste. J'ai personnellement rien contre systemd à la condition que l'on ne me l'impose pas. Je suis sous OpenRC (Gentoo) et ça me convient… Le truc que je n'aime pas particulièrement ces derniers temps est udev, car le nouveau truc à la mode c'est de considérer que /usr doit être sur la même partoche que / sinon ça boote pas! ( ou bien avec une initramfs)
Maintenant que udev est mergé avec systemd… on peut considérer que c'est un même projet.
Pour l'instant on n'a pas vu Lennart mais je doute qu'il passe…
Il y en a des très croustillants:
Yes, doing it in the kernel is "more robust". But don't play games,
and stop the lying. It's more robust because we have maintainers that
care, and because we know that regressions are not something we can
play fast and loose with. If something breaks, and we don't know what
the right fix for that breakage is, we revert the thing that broke..
Le meilleur reste Nix
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 10. Dernière modification le 06 octobre 2012 à 16:05.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
L'histoire se tient à propos du chargement des firmwares dans le noyau. Udev avec les nouvelles versions est très lent à les charger et ça fout la merde…
Depuis le mois d’août, il y a eu des patchs mais Kay n'en tient pas compte, limite il s'en fout…
Le pire, il accuse le noyau d'avoir des bugs … et ça gonfle clairement Linus.
Résultat des comptes, pour le chargement des firmwares et probablement des modules, le noyau risque de complètement outrepasser udev. La raison? Des mainteneurs qui en font qu'à leurs têtes et inefficaces.
Si vous n'aimez ce que devient udev en ce moment, prenez un sachet de pop-corn et lisez la LKML. Perso, j'ai fini mon sachet sans m'en rendre compte!
Quelques perles spéciales Linus:
Le meilleur reste celui de nix qui résume bien ce que devient udev.
# Il manque un dernier larron
Posté par wolowizard . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 3. Dernière modification le 05 octobre 2012 à 15:01.
Maintenant que les news de Microsoft Windows NT sont érites par pasBill pasGates,
que iOS est défendu par pasScott pasForstall,
il ne manque plus qu'un pasLarry pasEllison. Qui se dévoue pour faire une news sur Solaris?
# SUA/Interix documentation API NT
Posté par wolowizard . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 6. Dernière modification le 05 octobre 2012 à 10:06.
Bonjour,
De ce que j'ai appris, SUA est déprécié sous Windows 8. Pourquoi pas après tout? Je ne connais le nombre de clients mais la demande ne devait pas être très forte ; sans compter que le support Unix n'était pas très adapté…
Maintenant, je me pose la question d'un support futur viable d'un environnement POSIX sous Windows NT.
Il y a bien sûr Cygwin… mais comme d'habitude, il y a toujours un problème: l'appel à fork().
Il n'existe pas de correspondance un à un entre un appel fork() et une fonction quelqueconque dans l'API win32. Il y a bien l'appel CreateProcess que Cygwin utilise pour son implémentation de fork, mais ça "sucks" grave au niveau performance sans compter d'autres problèmes.
Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?
Si je parle de ça, c'est que Corinna Vinschen essaie d'améliorer les choses avec le fork() de Cygwin… mais qu’apparemment la barrière de dialogue est assez difficile.
Est-ce que Microsoft a une alternative à proposer pour SUA?
Pourquoi il manque une documentation pour la Native API? Interix utilise cette Api, il a une implémentation de fork() très correct et c'est très probablement par l'utilisation d'appel se rapprochant des fonctionnalités d'un fork() qui n'est documenté nulle part.
Microsoft conseille, pour le portage d'une appli Unix vers NT, d'adapter fork/exec par autres choses comme CreateProcess de l'Api Win32; s'il existe un appel plus efficace, pourquoi ne pas le déclarer, documenter?
[^] # Re: des véhicules légers (type 2CV)
Posté par wolowizard . En réponse au sondage Question gestion de l'énergie. Évalué à 2. Dernière modification le 03 octobre 2012 à 16:42.
Les normes EurosN concernent les émissions à gaz "toxiques" et polluant ( ne prend pas en compte l'émission de dioxyde de carbone). Peux-tu me dire comment tu fais pour passer de la quantité d’émission de ces gaz aux km (ou aux kWh) à la consommation d'un véhicule?
Sources?
Une source que je peux lire?
Journée circuit, que cela veut-il dire? test sur circuit? y-a-t-il des phases d'accélération douces et rapides sur au moins 2km ( compter une bonne vingtaine de fois) ?
Ta source signale une baisse globale du marché…avec une augmentation pour les gros cube pour la période estivale!( été, vacance, plaisir, toussa,…)
J'ai une source de 2008 venant du ministère du développement durable concernant
Localisation des ménages et usage de l’automobile.
On y apprend comment suivant les contextes, les personnes utilisent un véhicule motorisé (2 roues compris) en zone urbaine. Les personnes utilisant la moto/scooters sont négligeables par rapport à celle avec la voiture.
La moto reste un plaisir, il suffit de comparer d'une part le prix, le prix de l'assurance, de la commodité de l'appareil, de la possibilité de transport de personnes, et les vols, la consommation.
Source pour le pic à 40%? d'ailleurs un pic de quoi? sur la durée de l'accélération? Combien dure ce pic? Combien y-a-t-il de pics sur un parcours urbain à trafic dense?
Et si la moto c'est pour se faire plaisir ( même le lien que tu me donnes confirme cela)!
Je ne dis pas non plus que l'on ne peut pas améliorer l'efficacité du transport commun… mais ce que l'on constate c'est surtout que les gens en ville préfère utiliser un engin motorisé pour faire en gros 2 km ( 33% de déplacement pour la source que je donne); sachant que dans la zone dense, il y a un transport en commun à moins de 100m.
Un bus en consommation par personne fera toujours moins (en tout cas en période dense).
Les constructeurs se plaignent du calendrier de mise en vigueur des normes EurosN (trop dur) et demandent des reports. La R&D coute également bonbon…
Si on veut mutualiser le cout de la consommation en essence, je dis que l'aménagement du territoire, et l'optimisation des moyens de transport ( qui sont pas trop trop mal en moyenne)
sont plus profitables que de forcer et espérer que les constructeurs améliorent les engins.
[^] # Re: des véhicules légers (type 2CV)
Posté par wolowizard . En réponse au sondage Question gestion de l'énergie. Évalué à 1.
Pour leur test la consommation moyenne tourne entre 5.5 et 6L (à part pour la suzuki à 5.L)
Leur essai, je ne sais pas où ils les ont fait mais c'est surement pas en ville ( ils ont testé les reprises et les consommations à 130km/h).
En ville, la consommation peut facilement monter entre 15 et 20% ( certain estiment même à 30%) de la consommation moyenne.
Je ne pense pas déconner avec mes chiffres (et je ne parle pas des bonnes grosses cylindrée).
Je n'avais pas effectivement regardé les scooters:
Pour les scooters, j'ai regardé les tests (motomag sur le net) d'un X-max yamaha 125cm3, ils affirment 4L en ville (de même pour les piaggo 125).
Au final, ça ne change en rien à l'argumentation.
on prend la trentaine de passagers d'un bus qui consomme en gros 30L au 100 (et je ne parle pas d'un bus optimisé en consommation, je donne juste un ordre de grandeur), et on les met tous en scooters… la conso totale en scooter restera supérieure à celle d'un bus (pour un même circuit urbain).
J'ai rien contre les motards, mais leur véhicule reste quand même un objet pour se faire plaisir.
[^] # Re: des véhicules légers (type 2CV)
Posté par wolowizard . En réponse au sondage Question gestion de l'énergie. Évalué à 4.
Pour le milieu urbain, le véhicule léger est le problème pour la consommation. D'ailleurs, si on cherche vraiment à quantifier, on devrait plutôt parler de consommation moyenne par personne ( l /(km. personne)).
La meilleur façon de diminuer la consommation en ville, c'est de densifier celle-ci en habitats et de développer le transport type poids "lourds" (genre bus).
Le problème en ville pour un moteur thermique à explosion, c'est les phases d’accélération, et de freinage répétitifs. Ces phases augmentent d'autant que le trafic est dense.
Si on cherche à quantifier un peu:
En moyenne, une moto consommerait 7l au 100 ( je ne suis pas motard mais mon amie l'est). Bien sûr, ça dépend du type de moteur, du type de conduite, etc… En gros ça peut monter bien jusqu'à 10l au 100 suivant le motard et la moto; prendre 7l au 100 c'est pas trop déconnant…tout ce là pour 1 personne (rarement des motards en ville avec un passager).
En moyenne, une voiture en ville peut consommer jusqu'à 5 à 6l au 100, suivant les modèles et le type du conducteur on peut monter facile jusqu'à 12l au 100km.
En moyenne, la consommation par personne varie entre 6l et 1.4l ( 1personne et 4 personnes).
La consommation d'un bus (75 places à une dizaine de places) varie en ville entre 30l et 50l au 100 km. Comme d'habitude, ça dépend du chauffeur, du modèle de bus, etc…
On remarque que, pour un bus prenant en moyenne une dizaine de personnes, on passe de 3 à 5l au 100km par personne. Si on augmente la quantité de passagers, cette valeur diminue d'autant…
Pour un transporteur en ville, son but c'est de minimiser sa consommation et le cout total de son parc de bus ( c'est à dire le moins de bus possible utilisés efficacement ).
Cela étant dit, on pourrait adapter le type de bus en fonction de horaires: heures de pointe, bus 75 places et heures creuses bus 10 places consommant moins. Mais le problème de cette méthode, c'est l'investissement couteuse pour le transporteur dans son parc (qu'il faudra rentabiliser).
Le mieux serait d'adapter une fréquence de bus suivant les heures pleines ou creuses ( un bus tous les 5 minutes en heures pleines et tous les quarts/demi heures en heures creuses). C'est ce qui se fait à l'heure actuelle.
Si on diminue le trafic urbain, il y aura moins de véhicule ayant une forte consommation (donc globalement moins de consommation) et donc moins de phases d'accélération et de freinages (donc une diminution de la consommation).
On si densifie l'habitation, les lieux de travail, etc… on augmente la possibilité d'avoir plus de personnes montant dans un bus.
C'est mon opinion, mais je pense que l'optimisation de la consommation ne passe forcément à l’amélioration systématique de la techno automobile. On pourrait avoir des améliorations plus rapide autrement.
[^] # Re: [X] je change de machine moins souvent
Posté par wolowizard . En réponse au sondage Question gestion de l'énergie. Évalué à 2. Dernière modification le 03 octobre 2012 à 08:08.
Pour faire un alliage en laiton il faut un four chauffant au moins à 1000°C.
Les fonderies, en ce moment des personnes se battent pour ne pas les éteindre…
Il y a les fours à arc… mais bon, ce n'est pas la même échelle.
Ensuite, le laiton c'est un alliage entre du cuivre et du zinc en proportion variable (avec parfois d'autres éléments), si tu mets tous "les clous" et autres objets en laiton pour recycler ( avec des impuretés) dans le creuset… tu auras un alliage "batard" qui ne trouvera pas forcément preneur (dureté, usinage, etc…)