sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne…
Tout au début il n'y avait pas le support AHCI/SATA natif dans Linux pour de nombreux chipsets. On devait donc régler le bus en mode compatibilité ou legacy - grosso-modo une émulation du PATA. Donc le disque était reconnu comme PATA par le noyau.
Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…
Ben Honnêtement pas tant que ça. Il y a bien sur tout ce qui dépend des linux-headers qui est à recompiler à la main et Xorg est une cause perdue si il y a plus de 9/10 mois de différence entre les deux noyaux. Mais pour le reste ca passe pas mal du tout. Honnêtement en environnement serveur entreprise (qui est à mon sens le seul genre d'environnement ou il y a un interet à se livrer à ce genre de pratiques) ca se fait. La période horrible à ce genre de jeux là ca a été le passage de GCC 4.2 à GCC 4.4 et une liste d'incompatibilités longue comme le bras. Là oui quand tu veux migrer ton kernel et les outils liés à ce kernel dans une version récente, tout en gardant tout le reste sur des versions obsolètes mais en ayant quand même les nouvelles bibliothèques systèmes qui sont linkables par les vieux paquets. Là tu douilles.
Ceci dit quand tu fais ça c'est que tu cherche à préserver un ou deux logiciels (généralement proprios) pas toute une distrib fonctionnelle donc tu fini par y arriver quand même.
Perdu, là en l'occurence c'était Christophe Chapuis.
_ Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet._
Si il y avait dans le GIT systemd une seule autre branche que master, je serais presque tenté d'être d'accord avec toi. Mais trunk ca veut dire tronc, et quand il n'y a pas de branches à l'arbre ça décrit parfaitement l'endroit ou se trouve le code source.
et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
J'ai peut être fait une faute dans un grep, ou été perdu par le va et vient des connections udev et de sd-bus, mais j'aimerai également te rappeler que c'est la position officielle de Lennart :
To make this clear, we expect that systemd and kernels are updated in
lockstep. We explicitly do not support really old kernels with really
new systemd. So far we had the focus to support up to 2y old kernels
(which means 3.4 right now), but even that should be taken with a grain
of salt, as we already made clear that soon after kdbus is merged into
the kernel we'll probably make a hard requirement on it from the systemd
side.
I am tempted to say that we should merge the firmware loader removal
patch at the same time as the kdbus requirement is made. As that would
be a clean cut anyway…
Also note that at that point we intend to move udev onto kdbus as
transport, and get rid of the userspace-to-userspace netlink-based
tranport udev used so far. Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call.
Lennart
Donc niveau conclusion à la va-vite, c'est pas franchement ça. Il s'agit du point de vue officiel de la personne en charge du projet systemd.
Jamais il va pointer vers du code, ou ce genre de choses
Non mais je pointe vers des project leader qui suivent le code de très près, ce qui permet a) d'éviter de mauvaises interpretations du code, b) de ne pas mélanger mon opinion personnelle avec cette interprétation et c) de rendre le truc compréhensible par des gens qui ne lisent pas le C système (dont j'avoue volontiers faire partie).
car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.
Le comportement qui consiste à traiter sans distinction toutes les personnes qui ne sont pas intéressées par systemd d'ignorants nocifs est elle beaucoup plus constructive. Il y a des histoires de pailles et de poutres sur le sujet je crois.
Exemple, udev avant que ça devienne part au projet systemd : http://lwn.net/Articles/193603/
( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".
Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.
Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts.
hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.
Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.
Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste… Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.
Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.
Euh.. Tu m'accuses de FUDer, je prend le seul truc qui pourrait éventuellement correspondre à tes accusations et j'étaye. J'y peux rien si le seul truc qui ressemble vaguement de loin, de nuit et dans le brouillard au FUD dont tu m'accuses porte sur systemd/udev.
Je me défend contre ce sur quoi tu m'attaques, donc je ne vois absolument pas en quoi je pourrais être hors sujet.
Plusieurs, à commencer par le fait que je ne sais pas à quelle version de commit correspond systemd-git 217.443.g895b3a7-1 (mais bon c'est accessoire). Ensuite le problème de liaison netlink ne se pose que sur les machines ne disposant pas de libsystemd. C'est systemd/udev qui est cassé niveau expérience utilisateur, pas systemd intégralement.
Donc avant soit on utilisait libsystemd avec tout le reste de l'environnement systemd derrière, soit on utilisait netlink.
Dans l'état actuel du trunk (et je suis prêt à parier que ca va rester en place) soit on utilise libsystemd, soit il faut se rabattre sur kdbus (et donc coder toute une API userspace pour interfacer kdbus). L'option netlink n'existe plus.
Si tu préfères il n'est absolument plus possible d'utiliser la nouvelle version de udev en l'état sans systemd complet sur un kernel sans kdbus.
Pour finir il ne s'agit pas d'un délire personnel, mais bien d'une position 100% assumée par Lennart, pour laquelle j'ai donné et le lien et la traduction.
Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.
Bonjour,
N'hésite surtout pas à dénoncer mes "FUD" dans la dépêche en cours de rédaction. Pour information le "FUD" doit faire référence à ce texte :
Soyons clair, on s'attend à ce que systemd et le noyau soient mis à jour simultanément. On ne prend pas du tout en charge le mélange d'un noyau vraiment vieux avec un systemd vraiment récent. Jusqu'ici, on s'est concentré sur la prise en charge par systemd du noyau, jusqu'à une version antérieure de 2 ans (ce qui veut dire la 3.4 actuellement), mais même cela devrait être considéré avec précaution.
Qui est un post de Lennart Pottering. cf Post Original
Donc a) merci de ne pas appeler FUD ou déni chacun de mes posts b) si vous avez quelque chose à me dire n'hésitez pas, je n'ai jamais mordu personne et c) n'hésitez pas non plus à me ridiculiser, par exemple en postant des sources crédibles qui me contredisent.
Pour le problème du jour : Lennart a annoncé dans le post déjà cité plu haut :
Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far.
Ce qui se traduit par, "Veuillez aussi prendre note qu'à partir de maintenant nous avons l'intention d'utiliser kdbus comme protocole de communication pour udev, et de nous débarrasser de la liaison userspace vers userpace basé sur netlink que nous utilisions jusque là".
Dont acte dans le source trunk du dernier udev il n'y a plus de liaison netlink. Donc le prochain systemd/udev (sauf revirement) ne sera compatible qu'avec les kernel ayant kdbus.
C'est quoi le premier kernel avec kdbus déjà ?
Tu es au courant que sur la recherche que tu me donnes, les 2 premières pages sont exclusivement dues à des mises à jour du script d'init qui ne marche plus ?
Ça clairement ça arrive souvent, tu veux rajouter une option ou corriger un bug dans un script d'init et ça casse quelque chose ailleurs. Mais c'est juste un bug dans le script. Et là c'est pour des scripts génériques qui font 12 000 tests et doivent prendre en compte 200 configurations.
Mais le comportement inverse, I.E je fais une mise à jour du système et mon ancien script d'init ne marche plus sur un binaire qui n'a pas été mise à jour, est rarissime.
J'ai fait des centaines de script d'init et sur des versions early alpha, sur des pull CVS compilés à la mano avec des options bizarres, et même sur du matos pas encore commercialisé avec des pilotes constructeurs à peine sortis du labo. J'ai du avoir peut-être trois ou quatre fois le coup ou après une mise à jour j'ai du modifier le système d'init. Une fois à cause de udisk2 (qu'on a bazardé depuis), une fois suite à une modification de bash (c'était il y a 7 ou 8 ans de mémoire, et encore c'est plutôt de ma faute, j'aurai pas du écrire un script en bash au lieu de sh) et encore une fois parce qu'était passé de DHCPv6 à NDP (donc là encore c'est plutôt de ma faute).
Mais un script d'init qui casse trois fois suite à trois mises à jour Debian sur un binaire qui ne bouge pas, j'ai jamais vu. Donc là je vais me sentir obligé de dire BULLSHIT.
J'ai un peu souvenir de trolls Waylands entre toi et Misc ou il réfutait entièrement un post "argumenté" de toi
Sur Wayland ? J'ai toujours eu plutôt de la sympathie pour ce projet, à part peut être tout au début. Quand à Misc on s'est frité plusieurs fois sur systemd, mais généralement je répondais à ses arguments.
Je viens rapidement de regarder mes commentaires (En tant que Kaane, phxonx ou khane). J'ai souvenir de m'être fait démonté point par point sur OpenGL et sur Erlang principalement, mais sur wayland ? Franchement si tu retrouves la source je veux bien (ceci dit sans aucune arrière pensée)
Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.
Ah non au contraire. J'ai hâte de voir cette interface non stable qui fait qu'après une mise à jour de Debian le script d'init casse. Je suis même vraiment curieux. J'ai même filé une porte de sortie en parlant de udisk2 qui a changé son format de nommage du jour au lendemain (Bon ça fait un cassage, il y en aura encore deux autres à expliquer).
FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).
En ce qui concerne le "cassage" avec les logiciels d'avant (à savoir les API kernel, udev et rsyslog), ça s'est produit (rarement), je m'en suis rendu compte (assez vite je pense - c'est quand même vital ces choses là) - j'ai ouvert des bugs et ça a été corrigé. Je n'ai jamais eu de commentaires du type "Dans 2 mois on casse le truc qu'on a mis en place il y a trois mois, mettez à jour tout de suite ou ne venez pas pleurer plus tard". Et ça tombe bien d'ailleurs, parce que deux mois pour faire les tests de régression sur une archi, c'est quand même très court.
Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.
Il font du support développement chez RH et Suse ? Genre si je décide de créer une appli basé sur une fonctionnalité systemd et que cette fonctionnalité disparait ils me filent un billet ? Genre si j'ai des connexions avec udev en netlink ils me filent combien ?
Non mais sérieusement, évidemment que RH et Suse sont capable d'adapter leur distrib aux modifs systemd, c'est leur métier - mais toi si tu n'as pas une équipe de 30 devs et les machines de tests qui vont bien en 24/24 je continue franchement à te déconseiller de te baser sur une API systemd pour quoi que ce soit de non trivial.
Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne
Ben vu que notre matériel ne peut pas fonctionner avec systemd, c'est ce qui se passe. Par contre tu fais bien de dire qu'ils se font chier, les pauvres ils n'ont quasiment rien à faire.
Lennart ne te dérange aucunement. Alors pourquoi le détester
Il ne m'impacte pas, mais il me dérange dans son attitude que ce soit vis à vis du noyau, des divers mainteneurs extérieurs, des utilisateurs etc.
C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement…
C'est triste les gens bornés. Es-tu tellement sur que la seule raison au monde que pourrait avoir une personne de ne pas vouloir utiliser systemd c'est d'être un vieux schnock aigri, mythomane et réactionnaire ? Si oui je ne peux plus rien pour toi.
Là je veux bien que tu détailles. Parce que honnêtement sur Debian même la structure de fichiers est super stable, donc à moins que tu ne sois victime de udisk2 (qui a décidé de jouer les Lennart niveau pérennité) je vois pas trop ce qui peut provoquer ça.
Alors pour faire rapide, "casser" l'expérience utilisateur ça veut dire faire qu'un truc qui fonctionnait avant ne fonctionne plus maintenant. C'est parfois nécessaire (mais c'est rare) et c'est parfois même souhaitable (virus et compagnie).
Le fait d'apporter quelque chose de nouveau c'est "enrichir" l'expérience utilisateur. Donc Oui Lennart enrichit ET casse l'expérience utilisateur.
Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion. Le problème avec ce genre de direction de projet c'est que du coup une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet. Parce que rien ne garanti que la version N+1 sera encore compatible avec tout ce qui a été mis en place. Donc on s'en passe.
Aucun non. C'est très simple un système d'init quand c'est pour tes besoins à toi.
Ou est le problème avec systemd
Une fois de plus je n'ai aucun problème avec systemd.
A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.
J'ai plutôt le problème inverse, ni Red hat ni Suse n'ont accepté de garantir une maintenance quelconque de nos systèmes si on passait sous systemd.
Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…
Est-ce que tu peux pointer une contradiction s'il te plait ?
Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.
Tu es madame Irma en plus d'être psychanaliste ? Enfin bon avec les contrats que l'on a avec IBM d'un coté et Intel de l'autre je ne me fais pas trop de soucis pour mon métier. Et une fois de plus j'en ai rien à cirer de systemd, vu que je ne l'utilise pas.
soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant
Une dernière fois je ne suis pas contre systemd. Je ne peux matériellement pas me servir de systemd même si je le voulais, et en plus je ne veux pas.
La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne
Oh mon dieu tu as raison. Je ne m'en rendais pas compte parce que j'avais un blocage psydhologique, que lui même a déclaré que la poursuite d'un environnement pérenne était idiot et que Kay Sievers ET Greg KH l'ont appuyé dans cette décision. Je ne m'en rendais pas compte non plus parceque jusqu'à présent j'avais un environnement pérenne et que donc au moment ou je l'ai gardé ca a fait un tel choc que j'ai fait un rejet.
Je te félicite pour tes talents de psychanaliste, et d'ailleurs je te conseille vivement d'aller également élever des chèvres dans le Larzac, ce serait dommage que tu fasses usage de ce talent sur une personne sensible - là pour le coup vu tes capacités il pourrait y avoir des victimes.
on attend toujours ta solution alternative
Tu vas attendre longtemps, comme déjà dit plusieurs fois, y compris à toi
a) Je n'ai aucun problèmes avec les solutions existantes
b) Ecrire une alternative à systemd nécessite quasiment de devoir recréer toute une distribution
c) Je suis AdminSys/architecte pas développeur système.
Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart.
Euh non, j'ai juste dit que l'inviter à élever des chèvres dans le Larzac ne me choquait pas outre mesure. Si il faut détailler :
a) Je ne considère pas que d'inviter quelqu'un à élever des chèvres dans el Larzac n'est pas une menace ou une agression telle qu'elle devrait faire l'objet de l'opprobe populaire
b) Je ne considère pas non plus que ce serait une perte pour Linux, ou l'Open Source en général si L.Pottering en venait à se détourner de l'écriture du code pour Linux.
Je ne souhaite ni sa mort ni sa mutilation, mais très honnêtement son retrait partiel ou total du monde Linux ne me touchera pas. Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.
Houlà attention, je suis anti-Lennart - mais je n'ai absolument rien contre systemd. C'est un produit qui ne me concerne pas et dont je n'ai pas (et n'aurai probablement jamais) l'usage. Ceci dit je comprend parfaitement qu'il puisse servir - juste pas du tout pour mes besoins.
Autant les menaces de mort ou les injures je suis contre, autant les invitations à considérer l'élevage de chèvre ou le tricot comme reconversion professionnelle je suis tout à fait pour.
La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.
Attention - Il y a le mot "nègre" dans la chanson - bien que ce soit utilisé dans un contexte de mépris vis à vis d'une certaine bourgeoisie bien pensante et blanche de peau, je préfère préciser. Certains linuxfriens ayant le deuxième degré délicat.
Pas nécessairement, mais le protocole est tellement foireux que le concept de "validation indépendante" est risible.
Clairement, il y a pleins de choses qui ne vont pas. J'espère quand même vu les sommités dans l'équipe de validation qu'ils ne se font pas avoir comme des bleus. Mais restons sobres, il y a quand même 90% des chances pour que ce soit de l'enfumage.
Il faut néanmoins faire la part des choses, Rossi est un ingénieur, qui est tombé sur sa machine par accident. Il n'a pas la moindre idée de comment elle fonctionne. L'ensemble des améliorations et optimisations qui ont été faites sont dues à des tests empiriques. Il est aujourd'hui dans l'incapacité totale de déposer un brevet, il se défend donc contre toute personne qui pourrait comprendre son invention mieux que lui et lui damer le pion.
Au niveau des tests le labo a été monté par une équipe américaine et le système de mesure de la consommation électrique a été reporté très en amont de la machine. Il est donc complexe de tricher sur la consommation électrique réelle (on lui avait reproché la dernière fois de faire un double bypass ou d'avoir mis un bras mort dans son montage). Cependant à la lecture des résultats un autre scientifique a évoqué la possibilité d'un très fort cos phi qui fausserait toutes les mesures (avec cos phi à 0.28, typiquement un très grosse bobine ou un montage électronique niveau 4eme, on obtient automagiquement un rendement de 3.6) Et le contenu des poudres résiduelles après combustion est très très suspect - et c'est pas la première fois que c'est le cas.
En ce qui concerne la contradiction de toutes les lois de la physique, on va rester calme. En Physique en ce moment on collectionne les états bizarres de la matière, à commencer par le pseudo-état supra-conducteur (Bonjour on est une paire d'électron qui se déplace de façon continue dans la zone interdite - ramasse ta physique mon gars on vient de violer 4 lois fondamentales). Donc oui le sieur Rossi a peut-être réussi à créer les conditions nécessaire à l'apparition d'un nouvel état de la matière.
Ceci étant je n'y crois pas vraiment, mais même si c'est très certainement un canular, il y a quand même un minimum de respect à avoir vis à vis des personnes qui font la vérification. Personnes qui ne sont pas vraiment des débutants ou des néophytes dans leurs domaines respectifs.
Qu'il y ait des allumés capables de monter des gros canulars
Et il est doué l'allumé en question. Par exemple il a réussi à faire croire que son appareil pesait 420g et qu'il dégageait une chaleur de 1400°C pendant 32 jours, et ce alors qu'il (l'appareil) était dans un labo américain à être testé par des scientifiques indépendants.
Gérard Majax peut aller se rhabiller sur ce coup là.
Il y a un truc de certain, un objet de 420g, dont plus de 350g d'habillage a émit 1,5MWH d'énergie sans émettre de radiations tout en étant sous moniteur constant, ce qui rend toute substitution difficile.
A moins que tu ne penses que tous les scientifiques présent soient complices, ca va être compliqué d'expliquer comment un carburant a été 2000 fois plus efficace que de l'essence rafinée sans faire intervenir à un moment ou un autre les energies de cohesion interne des atomes.
Voilà c'est tout ce que les gens raisonables ont à comprendre. Quelques grammes de carburant dans E-Cat dégagent autant d'énergie que des centaines de litre de kerosene. Même si on additionne toute l'énergie électrique envoyée à la machine de controle et que l'on considère que l'ensemble des 420g du dispositif sont en fait du combustible on est quand même dans des résultats incompréhensibles au regard de la théorie physique actuelle.
Donc les brevets Microsoft doivent être solides juridiquement si les autres compagnies se sentent ainsi obligées de cracher au bassinet.
Il y a du vrai et du faux. D'un coté tous les brevets Microsoft ne sont pas triviaux, et d'un autre coté quand une compagnie non américaine (au hasard Nokia qui a juste inventé le GSM) attente un procès à une société américaine (au hasard Apple qui a presque inventé le bord rond) ils se font démonter devant les tribunaux américains.
Si tu veux être vendu aux US tu es quasiment obligé de raquer, totalement indépendamment du caractère innovant de ton produit et du caractère trivial et/ou absurde du produit américain concurrent.
Non pas du tout j’ai un serveur dédié avec un distro tout à fait standard (le serveur ne fait pas que ça sinon c’est sûr que c’est cher pour de la simple redirection :p).
Je parlais du serveur qui reçoit les mails, pas le serveur transitaire.
De ce que je comprend, ta seule solution va être SBL+filtre baysien+développer une interface pour que le client vienne récupérer ses spams en cas de faux positif. Lourd donc.
Tu fais comme tu veux, mais l'excuse "je ne suis que le transitaire, et je dois transmettre les mails aux clients que me payent" est l'excuse numéro un des spammeurs pro. Donc tu risques clairement de retrouver le problème ailleurs.
Cher journal, as-tu une solution (technique ou non technique) à ce problème ?
La première chose à faire est d'ajouter des black-list sur ton serveur mail. Je ne saurais que trop te recommander les sbl de spamhaus. Vérifie également que tu n'es pas inscrit sur certaines base de données de spammeurs/abuser connus. La éthode la plus simple est simplement de se rendre ici http://www.anti-abuse.org/multi-rbl-check-results.
Ensuite vu ce que tu décris, j'imagine que tu as une solution clef en main chez OVH (i.e soit les adresses mails fournies avec un domaine, soit un pack hosting exchange, mais en tout cas OVH administre le système mail).
Si ce n'est pas le cas, il te suffit effectivement d'ouvrir un port non standard avec chiffrement ssl (par exemple avec du starttls) sur ton serveur mail terminal. Ton serveur transitaire utilisera cette voie pour acheminer le mail. Le certificat n'a pas besoin d'être validé par une entité reconnue vu que seul ton serveur transitaire s'en servira, donc unc ertificat auto-signé suffira.
Si c'est bien OVH qui administre le système mail, ca va être plus compliqué. Déjà il va falloir ajouter un filtre de ton coté pour rejeter tout ce qui est manifestement du spam. Normalement ca devrait augmenter ton ratio ham/spam suffisament pour que tu ne sois plus embetté par les filtres OVH. Le SPF, DKIM et autres peuvent aider à apaiser les filtres ennervés. Si par contre tu sers de transitaire pour un groupe de spécialiste des dysfonctionnements érectiles chez l'homme (ie leurs mails contiennent en moyenne trois fois les mots errection, viagra ou cialis) là il va falloir négocier d'arrache pied.
J'ai été transitaire pour une institution bancaire Africaine, je te raconte pas le bazar pour faire passer chaque mail.
La première chose à faire est de réussir à démontrer que tu as fait tout ce qui était en ton pouvoir pour limiter le nombre de spam qui transitent par chez toi, la seconde chose est de réussir à convaincre un admin qui a franchement autre chose à faire de créer une règle que pour toi, pour limiter les faux positifs. Et là laisse moi te dire que ce sera nettement plus simple à faire chez OVH que chez (au hasard) Orange.
N'hésite pas à te présenter, à donner ton nom, ton addresse, ton tel perso. Un spammer ne fournirait pas ces informations facilement.
Il me semble que dans ce cas précis, il ne s'agit pas de besoin différent, puisque le script en question pourrait tout à fait utiliser ufw
Le fait que l'exemple qui soit donné puisse utiliser ufw, ne veut pas dire qu'il est pertinent d'utiliser ufw plutôt que iptables comme parseur pour le fichier de config système du firewall.
Dans la configuration actuelle de Frugalware je peux mettre dans /etc/sysconfig/firewall
- Du tagging
- Du queuing
- Des règles VPN
- Des pseudos-vlans
- Du QOS
etc.
Avec ufw comme parser, je ne pourrais pas (à ma connaissance). Donc utiliser iptables plutôt que ufw a du sens.
Mais même si ca n'en avait pas, c'est à dire même si ufw était en tout point supérieur à iptables (ce qui n'est pas le cas), on aurait quand même la situation avec un outil de base, très répandu et très connu face à un outil beaucoup plus neuf et sur lequel l'auteur n'a peut être pas les mêmes facilités. Sans compter qu'il y a des centaines de personnes qui ont déjà leurs règles iptables écrites et qui n'ont pour ainsi dire qu'à les coller dans /etc/sysconfig/firewall pour que ca fonctionne.
Tu n'as pas l'impression de généraliser à outrance ?
Pas dout tout. Il se trouve juste que toutes les personnes qui ne sont pas d'accord avec moi sont des idiots imbus d'eux-même. Une coincidence sans doute, mais c'est un vrai calvaire pour moi.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne…
Tout au début il n'y avait pas le support AHCI/SATA natif dans Linux pour de nombreux chipsets. On devait donc régler le bus en mode compatibilité ou legacy - grosso-modo une émulation du PATA. Donc le disque était reconnu comme PATA par le noyau.
Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…
Ben Honnêtement pas tant que ça. Il y a bien sur tout ce qui dépend des linux-headers qui est à recompiler à la main et Xorg est une cause perdue si il y a plus de 9/10 mois de différence entre les deux noyaux. Mais pour le reste ca passe pas mal du tout. Honnêtement en environnement serveur entreprise (qui est à mon sens le seul genre d'environnement ou il y a un interet à se livrer à ce genre de pratiques) ca se fait. La période horrible à ce genre de jeux là ca a été le passage de GCC 4.2 à GCC 4.4 et une liste d'incompatibilités longue comme le bras. Là oui quand tu veux migrer ton kernel et les outils liés à ce kernel dans une version récente, tout en gardant tout le reste sur des versions obsolètes mais en ayant quand même les nouvelles bibliothèques systèmes qui sont linkables par les vieux paquets. Là tu douilles.
Ceci dit quand tu fais ça c'est que tu cherche à préserver un ou deux logiciels (généralement proprios) pas toute une distrib fonctionnelle donc tu fini par y arriver quand même.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Nan mais c'est Kaane aussi.
Perdu, là en l'occurence c'était Christophe Chapuis.
_ Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet._
Si il y avait dans le GIT systemd une seule autre branche que master, je serais presque tenté d'être d'accord avec toi. Mais trunk ca veut dire tronc, et quand il n'y a pas de branches à l'arbre ça décrit parfaitement l'endroit ou se trouve le code source.
et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
J'ai peut être fait une faute dans un grep, ou été perdu par le va et vient des connections udev et de sd-bus, mais j'aimerai également te rappeler que c'est la position officielle de Lennart :
Donc niveau conclusion à la va-vite, c'est pas franchement ça. Il s'agit du point de vue officiel de la personne en charge du projet systemd.
Non mais je pointe vers des project leader qui suivent le code de très près, ce qui permet a) d'éviter de mauvaises interpretations du code, b) de ne pas mélanger mon opinion personnelle avec cette interprétation et c) de rendre le truc compréhensible par des gens qui ne lisent pas le C système (dont j'avoue volontiers faire partie).
Le comportement qui consiste à traiter sans distinction toutes les personnes qui ne sont pas intéressées par systemd d'ignorants nocifs est elle beaucoup plus constructive. Il y a des histoires de pailles et de poutres sur le sujet je crois.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
On est parti
Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.
hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.
Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste… Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.
Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 0.
Donc en gros t'es un peu hors sujet
Euh.. Tu m'accuses de FUDer, je prend le seul truc qui pourrait éventuellement correspondre à tes accusations et j'étaye. J'y peux rien si le seul truc qui ressemble vaguement de loin, de nuit et dans le brouillard au FUD dont tu m'accuses porte sur systemd/udev.
Je me défend contre ce sur quoi tu m'attaques, donc je ne vois absolument pas en quoi je pourrais être hors sujet.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Bref, quel est le problème ?
Plusieurs, à commencer par le fait que je ne sais pas à quelle version de commit correspond systemd-git 217.443.g895b3a7-1 (mais bon c'est accessoire). Ensuite le problème de liaison netlink ne se pose que sur les machines ne disposant pas de libsystemd. C'est systemd/udev qui est cassé niveau expérience utilisateur, pas systemd intégralement.
Donc avant soit on utilisait libsystemd avec tout le reste de l'environnement systemd derrière, soit on utilisait netlink.
Dans l'état actuel du trunk (et je suis prêt à parier que ca va rester en place) soit on utilise libsystemd, soit il faut se rabattre sur kdbus (et donc coder toute une API userspace pour interfacer kdbus). L'option netlink n'existe plus.
Si tu préfères il n'est absolument plus possible d'utiliser la nouvelle version de udev en l'état sans systemd complet sur un kernel sans kdbus.
Pour finir il ne s'agit pas d'un délire personnel, mais bien d'une position 100% assumée par Lennart, pour laquelle j'ai donné et le lien et la traduction.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7.
Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.
Bonjour,
N'hésite surtout pas à dénoncer mes "FUD" dans la dépêche en cours de rédaction. Pour information le "FUD" doit faire référence à ce texte :
Qui est un post de Lennart Pottering. cf Post Original
Donc a) merci de ne pas appeler FUD ou déni chacun de mes posts b) si vous avez quelque chose à me dire n'hésitez pas, je n'ai jamais mordu personne et c) n'hésitez pas non plus à me ridiculiser, par exemple en postant des sources crédibles qui me contredisent.
Pour le problème du jour : Lennart a annoncé dans le post déjà cité plu haut :
Ce qui se traduit par, "Veuillez aussi prendre note qu'à partir de maintenant nous avons l'intention d'utiliser kdbus comme protocole de communication pour udev, et de nous débarrasser de la liaison userspace vers userpace basé sur netlink que nous utilisions jusque là".
Dont acte dans le source trunk du dernier udev il n'y a plus de liaison netlink. Donc le prochain systemd/udev (sauf revirement) ne sera compatible qu'avec les kernel ayant kdbus.
C'est quoi le premier kernel avec kdbus déjà ?
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7.
Tu es au courant que sur la recherche que tu me donnes, les 2 premières pages sont exclusivement dues à des mises à jour du script d'init qui ne marche plus ?
Ça clairement ça arrive souvent, tu veux rajouter une option ou corriger un bug dans un script d'init et ça casse quelque chose ailleurs. Mais c'est juste un bug dans le script. Et là c'est pour des scripts génériques qui font 12 000 tests et doivent prendre en compte 200 configurations.
Mais le comportement inverse, I.E je fais une mise à jour du système et mon ancien script d'init ne marche plus sur un binaire qui n'a pas été mise à jour, est rarissime.
J'ai fait des centaines de script d'init et sur des versions early alpha, sur des pull CVS compilés à la mano avec des options bizarres, et même sur du matos pas encore commercialisé avec des pilotes constructeurs à peine sortis du labo. J'ai du avoir peut-être trois ou quatre fois le coup ou après une mise à jour j'ai du modifier le système d'init. Une fois à cause de udisk2 (qu'on a bazardé depuis), une fois suite à une modification de bash (c'était il y a 7 ou 8 ans de mémoire, et encore c'est plutôt de ma faute, j'aurai pas du écrire un script en bash au lieu de sh) et encore une fois parce qu'était passé de DHCPv6 à NDP (donc là encore c'est plutôt de ma faute).
Mais un script d'init qui casse trois fois suite à trois mises à jour Debian sur un binaire qui ne bouge pas, j'ai jamais vu. Donc là je vais me sentir obligé de dire BULLSHIT.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
J'ai un peu souvenir de trolls Waylands entre toi et Misc ou il réfutait entièrement un post "argumenté" de toi
Sur Wayland ? J'ai toujours eu plutôt de la sympathie pour ce projet, à part peut être tout au début. Quand à Misc on s'est frité plusieurs fois sur systemd, mais généralement je répondais à ses arguments.
Je viens rapidement de regarder mes commentaires (En tant que Kaane, phxonx ou khane). J'ai souvenir de m'être fait démonté point par point sur OpenGL et sur Erlang principalement, mais sur wayland ? Franchement si tu retrouves la source je veux bien (ceci dit sans aucune arrière pensée)
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.
Ah non au contraire. J'ai hâte de voir cette interface non stable qui fait qu'après une mise à jour de Debian le script d'init casse. Je suis même vraiment curieux. J'ai même filé une porte de sortie en parlant de udisk2 qui a changé son format de nommage du jour au lendemain (Bon ça fait un cassage, il y en aura encore deux autres à expliquer).
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).
Je t'invite vivement à lire The Linux Way et également Bashage de Linus
On peut aussi citer Ca sert à rien d’espérer que les chose soient différentes de la réalité
En ce qui concerne le "cassage" avec les logiciels d'avant (à savoir les API kernel, udev et rsyslog), ça s'est produit (rarement), je m'en suis rendu compte (assez vite je pense - c'est quand même vital ces choses là) - j'ai ouvert des bugs et ça a été corrigé. Je n'ai jamais eu de commentaires du type "Dans 2 mois on casse le truc qu'on a mis en place il y a trois mois, mettez à jour tout de suite ou ne venez pas pleurer plus tard". Et ça tombe bien d'ailleurs, parce que deux mois pour faire les tests de régression sur une archi, c'est quand même très court.
Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.
Il font du support développement chez RH et Suse ? Genre si je décide de créer une appli basé sur une fonctionnalité systemd et que cette fonctionnalité disparait ils me filent un billet ? Genre si j'ai des connexions avec udev en netlink ils me filent combien ?
Non mais sérieusement, évidemment que RH et Suse sont capable d'adapter leur distrib aux modifs systemd, c'est leur métier - mais toi si tu n'as pas une équipe de 30 devs et les machines de tests qui vont bien en 24/24 je continue franchement à te déconseiller de te baser sur une API systemd pour quoi que ce soit de non trivial.
Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne
Ben vu que notre matériel ne peut pas fonctionner avec systemd, c'est ce qui se passe. Par contre tu fais bien de dire qu'ils se font chier, les pauvres ils n'ont quasiment rien à faire.
Lennart ne te dérange aucunement. Alors pourquoi le détester
Il ne m'impacte pas, mais il me dérange dans son attitude que ce soit vis à vis du noyau, des divers mainteneurs extérieurs, des utilisateurs etc.
C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement…
C'est triste les gens bornés. Es-tu tellement sur que la seule raison au monde que pourrait avoir une personne de ne pas vouloir utiliser systemd c'est d'être un vieux schnock aigri, mythomane et réactionnaire ? Si oui je ne peux plus rien pour toi.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 4.
Là je veux bien que tu détailles. Parce que honnêtement sur Debian même la structure de fichiers est super stable, donc à moins que tu ne sois victime de udisk2 (qui a décidé de jouer les Lennart niveau pérennité) je vois pas trop ce qui peut provoquer ça.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Alors pour faire rapide, "casser" l'expérience utilisateur ça veut dire faire qu'un truc qui fonctionnait avant ne fonctionne plus maintenant. C'est parfois nécessaire (mais c'est rare) et c'est parfois même souhaitable (virus et compagnie).
Le fait d'apporter quelque chose de nouveau c'est "enrichir" l'expérience utilisateur. Donc Oui Lennart enrichit ET casse l'expérience utilisateur.
Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion. Le problème avec ce genre de direction de projet c'est que du coup une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet. Parce que rien ne garanti que la version N+1 sera encore compatible avec tout ce qui a été mis en place. Donc on s'en passe.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Donc tu n'auras aucun problème à les maintenir.
Aucun non. C'est très simple un système d'init quand c'est pour tes besoins à toi.
Ou est le problème avec systemd
Une fois de plus je n'ai aucun problème avec systemd.
A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.
J'ai plutôt le problème inverse, ni Red hat ni Suse n'ont accepté de garantir une maintenance quelconque de nos systèmes si on passait sous systemd.
Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…
Est-ce que tu peux pointer une contradiction s'il te plait ?
Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.
Tu es madame Irma en plus d'être psychanaliste ? Enfin bon avec les contrats que l'on a avec IBM d'un coté et Intel de l'autre je ne me fais pas trop de soucis pour mon métier. Et une fois de plus j'en ai rien à cirer de systemd, vu que je ne l'utilise pas.
soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant
Une dernière fois je ne suis pas contre systemd. Je ne peux matériellement pas me servir de systemd même si je le voulais, et en plus je ne veux pas.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne
Oh mon dieu tu as raison. Je ne m'en rendais pas compte parce que j'avais un blocage psydhologique, que lui même a déclaré que la poursuite d'un environnement pérenne était idiot et que Kay Sievers ET Greg KH l'ont appuyé dans cette décision. Je ne m'en rendais pas compte non plus parceque jusqu'à présent j'avais un environnement pérenne et que donc au moment ou je l'ai gardé ca a fait un tel choc que j'ai fait un rejet.
Je te félicite pour tes talents de psychanaliste, et d'ailleurs je te conseille vivement d'aller également élever des chèvres dans le Larzac, ce serait dommage que tu fasses usage de ce talent sur une personne sensible - là pour le coup vu tes capacités il pourrait y avoir des victimes.
on attend toujours ta solution alternative
Tu vas attendre longtemps, comme déjà dit plusieurs fois, y compris à toi
a) Je n'ai aucun problèmes avec les solutions existantes
b) Ecrire une alternative à systemd nécessite quasiment de devoir recréer toute une distribution
c) Je suis AdminSys/architecte pas développeur système.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6.
Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart.
Euh non, j'ai juste dit que l'inviter à élever des chèvres dans le Larzac ne me choquait pas outre mesure. Si il faut détailler :
a) Je ne considère pas que d'inviter quelqu'un à élever des chèvres dans el Larzac n'est pas une menace ou une agression telle qu'elle devrait faire l'objet de l'opprobe populaire
b) Je ne considère pas non plus que ce serait une perte pour Linux, ou l'Open Source en général si L.Pottering en venait à se détourner de l'écriture du code pour Linux.
Je ne souhaite ni sa mort ni sa mutilation, mais très honnêtement son retrait partiel ou total du monde Linux ne me touchera pas. Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
de la manière de (non) penser des anti-systemd
Houlà attention, je suis anti-Lennart - mais je n'ai absolument rien contre systemd. C'est un produit qui ne me concerne pas et dont je n'ai pas (et n'aurai probablement jamais) l'usage. Ceci dit je comprend parfaitement qu'il puisse servir - juste pas du tout pour mes besoins.
[^] # Re: Mwai
Posté par Kaane . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -10.
Bref, ça va un peu trop loin.
Autant les menaces de mort ou les injures je suis contre, autant les invitations à considérer l'élevage de chèvre ou le tricot comme reconversion professionnelle je suis tout à fait pour.
La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.
[^] # Re: Je n’aime pas les gosses…
Posté par Kaane . En réponse au sondage Quel système de «contrôle parental» utilisez-vous ?. Évalué à 3.
Dans le genre d'attaque frontale je préfère :
http://www.youtube.com/watch?v=Bis1zHq_Krk (Henri Tachan - Je ne veux pas d'enfant).
Attention - Il y a le mot "nègre" dans la chanson - bien que ce soit utilisé dans un contexte de mépris vis à vis d'une certaine bourgeoisie bien pensante et blanche de peau, je préfère préciser. Certains linuxfriens ayant le deuxième degré délicat.
[^] # Re: Magic happens.
Posté par Kaane . En réponse au journal Douche froide pour la fusion. Évalué à 4.
Pas nécessairement, mais le protocole est tellement foireux que le concept de "validation indépendante" est risible.
Clairement, il y a pleins de choses qui ne vont pas. J'espère quand même vu les sommités dans l'équipe de validation qu'ils ne se font pas avoir comme des bleus. Mais restons sobres, il y a quand même 90% des chances pour que ce soit de l'enfumage.
Il faut néanmoins faire la part des choses, Rossi est un ingénieur, qui est tombé sur sa machine par accident. Il n'a pas la moindre idée de comment elle fonctionne. L'ensemble des améliorations et optimisations qui ont été faites sont dues à des tests empiriques. Il est aujourd'hui dans l'incapacité totale de déposer un brevet, il se défend donc contre toute personne qui pourrait comprendre son invention mieux que lui et lui damer le pion.
Au niveau des tests le labo a été monté par une équipe américaine et le système de mesure de la consommation électrique a été reporté très en amont de la machine. Il est donc complexe de tricher sur la consommation électrique réelle (on lui avait reproché la dernière fois de faire un double bypass ou d'avoir mis un bras mort dans son montage). Cependant à la lecture des résultats un autre scientifique a évoqué la possibilité d'un très fort cos phi qui fausserait toutes les mesures (avec cos phi à 0.28, typiquement un très grosse bobine ou un montage électronique niveau 4eme, on obtient automagiquement un rendement de 3.6) Et le contenu des poudres résiduelles après combustion est très très suspect - et c'est pas la première fois que c'est le cas.
En ce qui concerne la contradiction de toutes les lois de la physique, on va rester calme. En Physique en ce moment on collectionne les états bizarres de la matière, à commencer par le pseudo-état supra-conducteur (Bonjour on est une paire d'électron qui se déplace de façon continue dans la zone interdite - ramasse ta physique mon gars on vient de violer 4 lois fondamentales). Donc oui le sieur Rossi a peut-être réussi à créer les conditions nécessaire à l'apparition d'un nouvel état de la matière.
Ceci étant je n'y crois pas vraiment, mais même si c'est très certainement un canular, il y a quand même un minimum de respect à avoir vis à vis des personnes qui font la vérification. Personnes qui ne sont pas vraiment des débutants ou des néophytes dans leurs domaines respectifs.
[^] # Re: Magic happens.
Posté par Kaane . En réponse au journal Douche froide pour la fusion. Évalué à 9.
Qu'il y ait des allumés capables de monter des gros canulars
Et il est doué l'allumé en question. Par exemple il a réussi à faire croire que son appareil pesait 420g et qu'il dégageait une chaleur de 1400°C pendant 32 jours, et ce alors qu'il (l'appareil) était dans un labo américain à être testé par des scientifiques indépendants.
Gérard Majax peut aller se rhabiller sur ce coup là.
Il y a un truc de certain, un objet de 420g, dont plus de 350g d'habillage a émit 1,5MWH d'énergie sans émettre de radiations tout en étant sous moniteur constant, ce qui rend toute substitution difficile.
A moins que tu ne penses que tous les scientifiques présent soient complices, ca va être compliqué d'expliquer comment un carburant a été 2000 fois plus efficace que de l'essence rafinée sans faire intervenir à un moment ou un autre les energies de cohesion interne des atomes.
Voilà c'est tout ce que les gens raisonables ont à comprendre. Quelques grammes de carburant dans E-Cat dégagent autant d'énergie que des centaines de litre de kerosene. Même si on additionne toute l'énergie électrique envoyée à la machine de controle et que l'on considère que l'ensemble des 420g du dispositif sont en fait du combustible on est quand même dans des résultats incompréhensibles au regard de la théorie physique actuelle.
[^] # XKCD 1174
Posté par Kaane . En réponse au journal Marre des popups qui obligent à accepter les cookies. Évalué à 10.
http://xkcd.com/1174/
[^] # Re: Patent troll ?
Posté par Kaane . En réponse au journal Samsung a donné plus d'1 000 000 000 $ à Microsoft pour la période du 1 juillet 2012 au 30 juin 2013. Évalué à 10.
Donc les brevets Microsoft doivent être solides juridiquement si les autres compagnies se sentent ainsi obligées de cracher au bassinet.
Il y a du vrai et du faux. D'un coté tous les brevets Microsoft ne sont pas triviaux, et d'un autre coté quand une compagnie non américaine (au hasard Nokia qui a juste inventé le GSM) attente un procès à une société américaine (au hasard Apple qui a presque inventé le bord rond) ils se font démonter devant les tribunaux américains.
Si tu veux être vendu aux US tu es quasiment obligé de raquer, totalement indépendamment du caractère innovant de ton produit et du caractère trivial et/ou absurde du produit américain concurrent.
[^] # Re: Plusieurs choses à fair et à voir.
Posté par Kaane . En réponse au journal OVH et le DPI, ou comment se faire débrancher son serveur mail parce qu’on reçoit du spam. Évalué à 6.
Je parlais du serveur qui reçoit les mails, pas le serveur transitaire.
De ce que je comprend, ta seule solution va être SBL+filtre baysien+développer une interface pour que le client vienne récupérer ses spams en cas de faux positif. Lourd donc.
# Plusieurs choses à fair et à voir.
Posté par Kaane . En réponse au journal OVH et le DPI, ou comment se faire débrancher son serveur mail parce qu’on reçoit du spam. Évalué à 10.
Tu fais comme tu veux, mais l'excuse "je ne suis que le transitaire, et je dois transmettre les mails aux clients que me payent" est l'excuse numéro un des spammeurs pro. Donc tu risques clairement de retrouver le problème ailleurs.
La première chose à faire est d'ajouter des black-list sur ton serveur mail. Je ne saurais que trop te recommander les sbl de spamhaus. Vérifie également que tu n'es pas inscrit sur certaines base de données de spammeurs/abuser connus. La éthode la plus simple est simplement de se rendre ici
http://www.anti-abuse.org/multi-rbl-check-results.
Ensuite vu ce que tu décris, j'imagine que tu as une solution clef en main chez OVH (i.e soit les adresses mails fournies avec un domaine, soit un pack hosting exchange, mais en tout cas OVH administre le système mail).
Si ce n'est pas le cas, il te suffit effectivement d'ouvrir un port non standard avec chiffrement ssl (par exemple avec du starttls) sur ton serveur mail terminal. Ton serveur transitaire utilisera cette voie pour acheminer le mail. Le certificat n'a pas besoin d'être validé par une entité reconnue vu que seul ton serveur transitaire s'en servira, donc unc ertificat auto-signé suffira.
Si c'est bien OVH qui administre le système mail, ca va être plus compliqué. Déjà il va falloir ajouter un filtre de ton coté pour rejeter tout ce qui est manifestement du spam. Normalement ca devrait augmenter ton ratio ham/spam suffisament pour que tu ne sois plus embetté par les filtres OVH. Le SPF, DKIM et autres peuvent aider à apaiser les filtres ennervés. Si par contre tu sers de transitaire pour un groupe de spécialiste des dysfonctionnements érectiles chez l'homme (ie leurs mails contiennent en moyenne trois fois les mots errection, viagra ou cialis) là il va falloir négocier d'arrache pied.
J'ai été transitaire pour une institution bancaire Africaine, je te raconte pas le bazar pour faire passer chaque mail.
La première chose à faire est de réussir à démontrer que tu as fait tout ce qui était en ton pouvoir pour limiter le nombre de spam qui transitent par chez toi, la seconde chose est de réussir à convaincre un admin qui a franchement autre chose à faire de créer une règle que pour toi, pour limiter les faux positifs. Et là laisse moi te dire que ce sera nettement plus simple à faire chez OVH que chez (au hasard) Orange.
N'hésite pas à te présenter, à donner ton nom, ton addresse, ton tel perso. Un spammer ne fournirait pas ces informations facilement.
[^] # Re: Bienvenue en 1995 !
Posté par Kaane . En réponse au journal Frugalware: Configuration du parefeu . Évalué à 6.
Le fait que l'exemple qui soit donné puisse utiliser ufw, ne veut pas dire qu'il est pertinent d'utiliser ufw plutôt que iptables comme parseur pour le fichier de config système du firewall.
Dans la configuration actuelle de Frugalware je peux mettre dans /etc/sysconfig/firewall
- Du tagging
- Du queuing
- Des règles VPN
- Des pseudos-vlans
- Du QOS
etc.
Avec ufw comme parser, je ne pourrais pas (à ma connaissance). Donc utiliser iptables plutôt que ufw a du sens.
Mais même si ca n'en avait pas, c'est à dire même si ufw était en tout point supérieur à iptables (ce qui n'est pas le cas), on aurait quand même la situation avec un outil de base, très répandu et très connu face à un outil beaucoup plus neuf et sur lequel l'auteur n'a peut être pas les mêmes facilités. Sans compter qu'il y a des centaines de personnes qui ont déjà leurs règles iptables écrites et qui n'ont pour ainsi dire qu'à les coller dans /etc/sysconfig/firewall pour que ca fonctionne.
Pas dout tout. Il se trouve juste que toutes les personnes qui ne sont pas d'accord avec moi sont des idiots imbus d'eux-même. Une coincidence sans doute, mais c'est un vrai calvaire pour moi.