briaeros007 a écrit 9441 commentaires

tu pratique la méthode coué et l'évangélisme ?

Je n'ai juste fait qu'extraire les infos du mail cité, et un mail d'une personne légèrement plus compétente que moi, et excuse moi, bien que je ne te connaisse pas, sans doute de toi aussi.

Ensute perso je m'en fous je n'ai aucun pouvoir de décision. Si ça vous fait tellement de bien de croire que systemd est le sauveur du monde, croyez ce que vous voulez.

si tu lis bien, certains préfère avoir à gérer upstart partout, et essayer de faire quelque chose contre les CLA, que d'avoir à gérer upstart sur !linux, systemd sur linux, et gérer les tentatives pieuvresques de systemd (logind & consors).

je ne dis pas que tout peux être géré par les VMs et que le nuage c'est bon.

Par contre, j'émets des doutes sur le fait que plus de 50% des couts et de l'utilisation de l'infra ne puisse pas être supportée par du "nuage".

Et je ne parle pas du gain en sous sous, popularité et donc utilisation (donc rapport de bug, utilisation sur une plus grande variété de matériel, donation, …) si une telle solution était adoptée.

J'ai pas dis de ne pas developper/tester sur d'autres archis. J'ai du que ceux qui utilisaient les autres archis contribuaient pour ces archis.

Et si c'est vraiment de la détection de bug, amha on a plus vite fait d'étudier une archi vraiment exotique même si très peu puissante, car on aura beaucoup plus de chance de trouver des bugs comme ça. Et de proposer cette archi aux autres distrib linux (hence, des sous en plus:) )

Les tests sont justement lancés dans ce but : faire planter le tout. Il est fort probable qu'un paquet arrive à faire planter le switch.

Donc si tu as un paquet qui te fait tout planter, tu crois que tu t'en fous de savoir que ton bsd tient bien le paquet, vu que toute l'infra est par terre ?

Et puis heureusement que j'ai bien précisé la couche.
Si tu arrives à faire planter un switch vlan avec des données L3, donne moi la conf de ton switch que je ne l'achète pas.

Dans le genre de tests que tu préconises il est impossible de savoir si c'est OpenBSD qui est en défaut ou si c'est l'émulation.
Euh il suffit de voir si le paquet est arrivé au niveau de la VM ou pas …

enfin à t'écouter, théo c'est plus une maison qu'il a, c'est un hangar de 1500 m² avec 2 lignes 20 kv.

Tu dénies le fait que les femmes ou les noirs soient victimes des hommes et des blancs ????

Je troll juste un peu : je suis comme la majorité de la popilation française (enfin je crois), blanc de couleur de peau.
J'ai été victime (comme bon nombre de mes concitoyens) d'une agression à l'arme blanche il y a quelques années.

Et pour ton informations, ce n'était pas des "hommes blancs" mes agresseurs.

Donc toutes les victimes du monde te disent que tu n'a pas le monopoles de la victimisation, et que le monde n'est pas tristement binaire comme tu semble le croire dans tes délires de persécutions.

Ah j'oubliais, ce n'est pas parce que je me suis fait agressé que j'estime que les personnes qui ont la même couleur de peau ou le même sexe sont coupables par transitivité.

J'ai répondu au dessus :)

Les tests réseaux marchent très très bien en VMs.
Les tests de support matériels marchent moins bien, mais comme j'ai écris au dessus : je crois pas que theo ait un exemplaire de chaque carte réseau qui sera utilisée par openbsd …

pour les perfs, ça dépend ce que tu cherches. Si c'est pour valider une optimisation , une architecture virtualisée peut tout à faire convenir. Si c'est pour tester un système au limite effectivement ca ne sert à rien la virtu (overhead toussa). Mais ça ne sert à rien de le faire au niveau OS en avance de phase sur une plateforme qui n'a rien à voir, vu qu'il faut le faire sur la plateforme qui va héberger l'application nécessitant la charge (il y a tellement de paramètres qui rentrent en jeux).

y'a un truc très bien qu'on a inventé qui s'appelle les VMs, les VLANs et la QoS
Ca permet de cloisonner les OS, les réseaux, et les ressources.

Et si tu te débrouille bien, tu fais mumuse sur la couche 3 et au dessus, et tu fous toutes tes VMs dans un seul hyperviseur dédié au test sur un réseau purement interne à l'hyperviseur (donc aucun paquet risque de partir). Tu fais planter que ta VMs, et au pire du pire du pire, tu fait juste planter l'hyperviseur.

Le seul truc où les Vms ne conviennent pas c'est dans tout ce qui est gestion du matos. Mais j'ai comme un doute que openbsd a des machines avec chaque type de carte réseau, chaque type de carte mère, … pour tester et valider les drivers

z'avaient qu'a faire du gpl.

Poussez pas --> [|]

J'aime ces approches constructives qui, plutôt que d'essayer de faire avancer une idée, cherche à tout pris tous les raisonnement pour ne pas avancer (mais ne propose rien à coté).

Est-ce impossible d'envisager une cross compile pour l'ensemble de tes environnements, et ne garder qu'une machine de chaque archi pour faire tourner les tests de non régressions en batch ?
Est-ce impossible d'envisager que ceux qui utilisent openbsd contribue à minima?

Et si une archi n'est plus utilisée, ben désolé, mais ça sert à rien de faire survivre un truc qui n'est pas utilisé (dis autrement, si elle est utilisée, il faut que les gens qui l'utilise assument aussi)

Moi j'utilise pas openbsd mais je serais prêt à prêter de mon temps CPU, même ARM si ça les amusent (j'ai un soc marvell qui me sert de serveur d'infra) car j'estime qu'openbsd est un projet sympa.

Mais bon c'est sur que si il faut essayer de voir que les cotés négatifs et pas voir comment on pourrait travailler autour, je comprend mieux pourquoi le monsieur veut bien qu'on lui paie tout, mais surtout pas jouer la transparence.

Moi ce qui me fait le plus peur, c'est quand tu installe certificate patrol, et que tu vois que les gros sites arrêtent pas de changer de CA et que tu ne sais jamais si c'est normal ou pas …
effectivement pour https everywhere je l'avais oublié.

Pour le reste soit je connaissais pas, soit je n'y ai pas pensé.
Bon ça fait une liste d'extension digne d'un sapin de noel :'( . Bizarre que ces options ne soient pas intégrés à firefox.
(J'attends toujours le support de dnssec de base dans firefox).

je rappelle le but initial : limiter et controler les informations récupérée par les sociétés diverses et variées.

Faire de la fragmentation est un bon début.

Ensuite si tu cherche à te protéger d'un "attaquant" qui a les moyens de positionner des sniffs sur les dorsales du net, de déchiffrer du RSA (ou en tout cas bien supposé), de construire ses popres asic pour son propre datacenter ,et d'envoyer des équipes dans les ambassades piquer les livres de codes.

Je pense que l'OPSEC que tu cherches tu ne la trouveras pas sur linuxfr ou les sites civils :)

d'où l'idée de faire un cloud chiffrée.
La personne prête du temps cpu, stockage et mémoire. Si elle part, éteint son serveur , c'est suffisament redondée pour qu'il n'y a pas de perte. Au pire tu as perdu la tache qui était en train de tourner et elle se relance autre part.

C'est un peu comme un darknet sur internet, sauf que là c'est avec des machines :)

Vu le nombre de personne qui font tourner du bitcoin, du seti@home, amha il y a la possibilité de demaner aux gens d'hébeger une partie de l'infra.

Certes les latences serait importances, mais tout serait répartie et redondée (et chiffrée bien sur).

On arrête pas de ressaser "cloud par ci, cloud par là". Ca serait justement une super démonstration du fonctionnement , et donc non seulement tu résouds ton problème de serveurs (avec un boulot considérable de mise en place, je l'accorde), mais tu te fais une superbe pub.

Par contre, OpenBSD ne souhaite ne pas changer de modèle même si ils ont un problème avec ce modèle.

The OpenBSD project uses a lot of electricity for running the
development and build machines. A number of logistical reasons
prevents us from moving the machines to another location which might
offer space/power for free, so let's not allow the conversation to go
that way.

J'ai envie de dire "tant pis".

De plus supposons que certains veulent donner :

I am not going to disclose the actual numbers here. Please contact me
for details if serious.

Ca va vachement pousser les gens à aider

"J'ai besoin d'aide, mais j'ai pas envie de vous filer les infos pour pousser le bébé. Il faut me les demander uniquement à moi".

Pour avoir participer das des groupes (qui n'ont rien à voir avec les LL mais qui dépendent des serveurs), je sais que les dons ne contribuent que peux aux serveurs (de tête dans notre cas ça contribuait même pas pour le quart d'un kimsufi).

Il me semble que ta façon de juger un système d'init est un peu foireuse…

Je pense qu'il y a méprise. Je ne jugeais pas le système d'init avec cette phrase.
Je jugeais "l'espoir" qui si on a qu'un nombre restreint de système d'init, alors les developpeurs feront de "beau scripts d'init" pour ce pool restreint.

Et pour confirmer ce point j'indiquais une anecdote personelle montrant que même pour un système d'init (sysV sauce redhat) les devs n'ont pas la volontée/connaissance/expérience/temps/… pour faire un script d'init "correct". Alors pour plus de un, je te laisse imaginer.

Je ne vois vraiment pas comment à partir de ma citation tu as réussi à partir sur systemd.
Eusse-tu pris la fin de mon post j'aurais pu comprendre et argumenter, mais là j'avoue que je ne te suis pas.

En plus, le gros avantage que j'y vois est que le fichier de conf de systemd étant upstream[…]

Même chose avec trois scripts (ou même un seul) dans le projets. On sait tous les tenants et les aboutissants quand c'est upstream ou pas.
Ca c'est la théorie.
La pratique je l'ai eu avec jboss (entre autre) et force est de constater qu'il y a un léger delta entre la théorie et la pratique.
(et avant que tu pose la question : non je n'ai pas fait un bug report pour mes problèmes avec jboss. J'aurais sans doute due … si j'avais un compte kivabien et le temps, mais comme je n'ai eu ni l'un ni l'autre, ben j'ai mes scripts "jalousement gardé" faute de temps.)

Il me semble qu'améliorer une documentation est bien plus facile qu'améliorer l'architecture foireuse d'un logiciel, non?

Améliorer la documentation ne remplace pas de mauvais choix d'architecture ;)

Bon je parle de google,mais c'est vrai pour tout prestataire extérieur un peu trop "envahissant" (comme facebook ou autre)

• mettre un proxy bloquant les pubs (perso j'utilise squidguard, mais tu as privoxy qui peut être sympa)
• utilser noscript
• utiliser ghostery (qui permet de limiter les trucs de tracking)
• cocher le "donottrack" (même si de mon point de vue, ça change rien du tout, au moins tu indiques ta volontée de ne pas être tracké).
• limiter ses cookies de sessions (j'avais un truc sous android, faudrait que je le retrouve sur mon pc principal, c'est cookie self destructor)
• utiliser duckduckgo par défaut
• limiter son compte gmail pour des infos "publiques" (mailing list), et/ou quelques infos privées mais certainement pas tout en privée. Essayer de migrer progressivement ses comptes/données à une autre boite (voir une boite autogérée).
• sous android, ne pas utiliser le playstore ni renseigner de compte (c'est un peu une galère au début, mais une fois qu'on a notre lot d'applis gpl (avec fdroid) ça passe sans trop de soucis).
• vérifier régulièrement les infos qu'a google chez toi (ils vont un rapport et un dashboard permettant de voir ça. C'est sympa, au moins ils ont ça).

Par contre j'ai toujours plein de googlapis dans lightbeam (anciennement diaspora), faudrait que je vérifie à quoi ça correspond.

Bref, avec ces étapes, tu ne donnes pas de fausses infos. Tu n'as pas des pubs idiotes. Google a un profil à peu près correcte … avec les informations que tu veux bien lui donner et que tu as conscience de lui donner.
(et cerise sur le gateau, ton accès à internet fonctionne mieux, tu consomme moins de ressource, et donc tu es plus eco-friendly)

Ce qui fait qu'un développeur pourra bientôt fournir lui-même deux ou trois fichiers d'init pour les quelques solutions majeures,

Ahahah. J'ai eu à installer un jboss il y a peu. Le fichier d'init pour redhat est fournis dans les sources (pas une version packagée par une distrib … de toute façon à part redhat, et encore même pas sur, il y a vraiment peu de distrib qui package des jboss récents).

C'était sur une redhat. Bon le fichier d'init fournis ne marchait tout simplement pas (ou plus exactement très mal).(et même chose sur debian).

Donc je serais toi, je ne m'attendrais pas à des miracles. Si déjà dans le cadre de jboss (qui est poussé par redhat & tutti quanti) les devs sont pas foutu de faire un fichier d'init à peu près propre pour leur propre distrib, que dire d'un dev lambda qui devra gérer trois système d'init différent.

/me espère que ce ne sera pas systemd. J'ai lu le lien vers redhat pour approfondir ma méconnaissance de l'outil vu que tout le monde l'encense. La doc décrit en 15 pages ce qu'un simple --help suffit. On apprend que le mode "rescue" et le mode "emergency"* demande tous le mdp root (pratique si tu n'a pas celui de la bécane et que tu passes en rescue pour le péter. La ça sera à coup de bin/sh ou de livecd).
*Et on apprend aussi qu'en mode rescue il démarre des trucs qui seraient suceptible de pas trop bien démarrer donc ils ont mis aussi un mode qui démarre encore moins de chose : le "emergency".
Par contre aucune info sur la création d'un service, la modification d'un service, …
Soit la doc de redhat est vraiment pas finalisée, soit redhat se microsoftifient de plus en plus avec des docs au kilomètres, mais un rapport "intérêt/nombre de mots" qui diminue.

pbpg qui dis que c'est moins marrant linuxfr parce qu'il y a plus de troll ^{^}

On c'est tapé des bons trolls quand même avec toi (OOXML plus mieux qu'odf est le dernier qui me reviens en tête :) )

la bonne soluce c'est d'enlever le droit root à ceux qui n'en ont pas besoin, et de le remplacer par su, qui permet de controler plus finement ce que les gens ont le droit ou non de faire.

L'autre solution c'est de partir sur les MAC (selinux, tomoyo, apparmor) et de restreindre les droits à root sur ce genre d'opérations lors qu'il est appelé dans un certain contexte.

euh non c'est pas énorme.
Et en plus par défaut, il ne chope que les 68 premiers octets et donc tu n'as que les metadata des paquets et pas trop les data, donc pas trop de soucis.

Au boulot, on a fait des traces de 5Go (avec que les metadata), sur un problème un peu comme le tiens (on savait pas trop quand il arrivais).Ben tu recherches des trucs dedans sans trop de soucis.

essaye de flasher l'ECU de ta voiture, tu me diras des nouvelles.
(ta voiture devient interdite à conduire sur la voie publique légalement)

je rajouterais, que si je ne m'abuse, Antoine aurais très bien pu la corriger lors de la rédaction de la dépêche vu que linuxfr permet un mode collaboratif (mais j'avoue ne jamais avoir prêté une forte attention).

Dans un manga, il y avait une "citation" que j'aime beaucoup
"Je n'ai vu personne se plaindre pendant, alors venez pas me faire chier après".
ou dit autrement, "ce qui font, ils ont le mérite de faire, même si ce n'est pas parfait."

j'ai même pas la télé.

Tu perd pas grand chose , peut être un peu arte le mardi soir de temps en temps, et quelques polars pour passer une soirée tranquille. Mais à part ça ….
(et puis tu as pluzz pour arte,/france5 , et certainement la même chose si un polar passe et t'intéresse).

pour l'iDCT, ce n'est pas aussi utilisé dans l'encodage vidéo ?
Si oui, je pense qu'il doit déjà y avoir des instructions dédié.

Le problème des instructions dédiés, c'est qu'il faut coder pour. Soit le compilo est capable de le gérer, soit le dev de la lib/logiciel doit le gérer.