Misc a écrit 6331 commentaires

Ce qui est aussi en cours de test :
https://blog.torproject.org/category/tags/deterministic-builds
https://wiki.debian.org/ReproducibleBuilds
https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/

Et facebook emploie 2 commiteurs de mercurial, et sans doute plus pour les taches tout aussi importantes comme la QA, etc.

Je pense que le souci dans le cas de Centos, c'est l'ordre du rebuild, et les soucis de bootstrapping.

Par exemple, tu as des dépendances circulaires parfois, donc il faut noter ce que t doit retire, puis remettre ça, etc. C'est pas mortel, mais c'est laborieux.

Et scientific linux, je crois que c'était 2 personnes ( dont une qui bosse maintenant sur openshift chez RH )

Sarge est sorti en juin 2005, etch en avril 2007. Dans mon souvenir, la durée de vie, c'est temps entre release + 1 an. Donc c'est woody qui a été supporté 4 ans ( 3 ans de dev + 1 an ).

Je sais pas d'ou tu sors tes 5 ans :/

binairement compatible, ça implique de recompiler dans le même ordre tout, et c'est AMHA non documenté et fait de façon organique. Donc il y a déjà des divergences à la base.

Et sinon, il y a ça :
http://crunchtools.com/centos-post-mortem-analysis/

Les distributions n'ont pas les mêmes communautés. Fedora est une distribution pour l'innovation au niveau de la distribution même, alors que la, l'idée pour Centos, c'est pour l'innovation au dessus de la distribution ( ie, les plateformes qui s'appuient sur une plateforme stable qui ne bouge pas trop ).

Tu peux pas tout faire bouger en même temps.

je suis pas sur du 100% binary compatible.

Je pense que tu peux demander une inclusion dans epel pour knot. Visiblement, c'était prévu d’après les branches dans git, mais pas fait. Au vue du paquet, il manque ragel pour epel6, et je viens de tester, ça compile sans souci.

Donc, je pense que le seul souci va être d'écrire un initscript pour epel6, donc rien d'insurmontable.

Perso, j'ai nsd et c'est assez simple. Ma config fait 15 lignes pour 2 zones et 2 slaves ( en comptant les lignes vides ). Ça prends directement en compte les zones bind, ç'est dispo sur centos, fedora, debian.

On peut quand même voir sur la page sur "nightstand" que ça utilise une Fedora core 3 sur un pc. Autant dire que Linux est prêt sur le desktop avec un tel example.

mais bon, le catalogue date d'il y a 5 ans, peut être qu'ils ont pris unity ?

Au contraire une distribution qui se veut early adopter
remplies de techno hyper récentes voire trop récente devrait
mettre un point d'honneur à soigner son processus de mise à
jour pour que les utilisateurs puissent au plus tôt bénéficier
des dernières versions

En fait, toutes les distributions devraient viser la qualité à tout niveau. Personne ne veut avoir de soucis, ça me semble assez logique.

Et bien que tu dises que les efforts de Fedora ne sont pas suffisant, il faut quand même voir qu'ils existent.
Par exemple, pour les mises à jours dans la stable, il y a tout un système complet pour la vérification via bodhi, tu peux laisser du karma pour dire "ça passe" et "ça passe pas" pour les paquets mis à jour.

Il y a des matrices de tests complètes comme ici :
https://fedoraproject.org/wiki/Category:Installation_validation_testing

Il y a de la document sur quoi et comment tester ( genre tout ça : https://fedoraproject.org/wiki/Category:Test_Cases )

Il y a des réunions, des revues des bugs bloquants, etc.

Le seul point bloquant de tout ça, c'est que ça requiert des humains. À contrario, Debian a l'air d'avoir beaucoup plus de tests automatisés ( piuparts, lintian, etc ) que de tests structurés par des humains. À coté, la taille de la communauté fait aussi que ça passe de façon "organique", surtout vu qu'il y a largement le temps de voir et revoir les choses.

Et pour Fedora, il y a sans doute des choses à mettre en place ( genre finir Autoqa https://fedoraproject.org/wiki/AutoQA ), ou se brancher sur le bus de message pour tester ce qu'on veut, etc.
Faut juste coder.

Disons qu'il faut pas juste retirer les emplois, mais repenser tout ça dans un cadre de redistribution des richesses, et revoir les fondements du travail.

Bien sur qu'il faut supprimer les taches qu'on trouve moins nobles ( bien que ça soit culturellement dépendant ), mais il faut aussi voir que ça donne un sens dans la société à certaines personnes, que ça leur donne un revenu, etc.

Donc si on veut remplacer ça, il faut en effet compenser le revenu manquant d'une manière ou d'une autre ( et éviter les travers égoistes et hypocrites à la Ayn Rand ), et éviter de fustiger les gens qui travaillent moins, voir pas. Sinon, c'est juste faire preuve de violence envers eux en leur infligeant la pauvreté, l'exclusion et le tout sous le couvert d'une avancée sociale qui n'en est pas forcément une

Je sais ce que Fedora est: une version de test.

non, ça, c'est ce que tu crois. Et ça veut rien dire "version de test". Est ce que Arch est une version de test ? Non.

Mais bon elle est aussi "vendu" par certains comme etant la
distribution RH desktop.

RH a une offre desktop à son catalogue :
http://fr.redhat.com/products/enterprise-linux/desktop/

Tu peux donc donné ça à ton travail.

Et sinon, moi, j'arrive à avoir des upgrades. Peut être qu'il faut des admins avec un peu plus de bouteille pour ça ?

J'ose croire que tu peux avoir plus de tracabilité à ce niveau. C'est pas la solution miracle, mais ça doit aider.

C'est quand même plus difficile de corrompre la personne qui manœuvre le robot ( si c'est pas automatique ) et ses logs si ils sont ailleurs. Et les dits logs sont sans doute plus exploitable que 300 000 heures de caméras de surveillance.

Mais encore une fois, c'est juste une hypothèse.

En même temps, vu le cycle de vie de Debian, Fedora sert aussi de test pour eux, tu devrais quand même reconaitre ça ( car aprés tout, un bug découvert dans le dernier kernel est un bug qui n'arriveras pas dans la version stable de Debian 1 ou 2 ans plus tard dans le cas le plus rapide )

Et même si ça semble évident, RH a des équipes QA conséquente pour RHEL. Le temps qu'une version de RHEL sorte, Fedora est déjà bien en avant donc autant dire que si tu veux un produit stable, il faut pas se dire "bon, y a eu des gens qui ont tentés des trucs sur du matos totalement différent de la majorité de nos clients avec des workloads qui n'ont rien à voir, on peut faire un truc vite fait et voila".

Et je parle même pas du fait que les tests se font sur les erratas et correctifs pendant la durée de vie du produit ( ie, du 10 à 15 ans suivant le paquet ), autant dire qu'à ce moment la, les utilisateurs Fedora n'aident pas grandement.

Donc l'assertion "oui, la distribution est pensé comme un test à RHEL", c'est quand même bien du bullshit simpliste de mec n'ayant aucune idée du cycle de création d'une distribution ou des interactions entre les gens de la communauté.

http://www.happyassassin.net/2013/12/17/psa-use-fedup-0-8-for-fedora-20-upgrades/

Peut être c'est le souci que tu as vu ?

( et je confirme, fedup a marché pour moi à l'époque de la beta et/ou de l'alpha )

Facilement, j'ai pas tenté, mais graphiquement, il semble que oui, j'ai une option "pont" quand je fait "ajouter une connexion"

On peut supposer que Google ayant décidé de s'attaquer frontalement à Amazon ( le cloud Google, google play, etc ), les robots sont juste une manière d'éviter les soucis qui plombent le dit libraire dématérialisé US en Allemagne ?

( oui, c'est moins sexy de se dire ça ). Voir même pour améliorer la production de Motorola, ou de ses potentielles voitures sans chauffeurs. Voir, chose folle, de ses datacenters géants ( car un robot, ça va pas aller poser des fibres pour la NSA en douce par la magie de la corruption )

Le système est libre, sauf les parties non libres, tout comme la chine est démocratique, sauf la partie ou c'est une dictature ?

Il y a plein de bonnes distributions basées sur Debian

Mais ça ne te gène pas que tant de projet ne cherche pas à contribuer à Debian plutôt ?

Ou est ce que le travail d'intégrer plus de personnes est inférieur à celle d'intégrer 2 noyau totalement différent ?

Alors que maintenant, y a non-free directement proposé par le projet parce que le consensus de la communauté est que le logiciel libre n'est pas suffisant, donc le souci de QT n'arriveras plus si il devait se reproduire. je suppose que Debian, comme pour d'autres softs proprios, va proposer son infrastructure ( bugs, miroirs ) pour que le runtime de Valve soit disponible pour tous pour encore mieux défendre le libre via Steam et les DRMs.

( attention, un troll pas subtile se cache dans ce commentaire, je me permet au vue du thread suggérant de tout migrer sur Debian )

pfff, difficile de troller, ton journal est trop neutre et
factuel…

tu sais pas t'y prendre, si tu trouves pas l'info, faut la sortir des liens. Moi, j'identifie 3 axes de troll :

• visiblement, l'équipe de steam os ne choisit pas Ubuntu. est ce qu'il s'agit d'éviter de dépendre des choix de Canonical ( ie, indépendance vis à vis d'un concurent ), ou justement des choix annoncés ( ie, upstart, mir, unity ), voir de la volatilité de l'éditeur ?

• enchainons sur le fait que prendre Debian comme base, ça n'utilise pas systemd, mais un bon vieux sysvinit. est ce que ça veut dire que Valve va investir pour maintenance de la plateforme et de ses trucs vieillissants, est ce que Valve va maintenir xorg, etc, etc ?

• partir sur la conclusion "Néanmoins, je pense que par effet de bord, cette guerre économique nous est profitable". La, on peut commencer par dire "pourquoi ?", par exemple, est ce que android a été profitable à Linux, comment, etc, etc; j'ai pas vraiment vu des changements radicaux en terme d'userspace, et je ne vois rien dans mes cas d'usage.

Donc je suis pas sur qu'une appliance de steam change vraiment beaucoup la donne, surtout si le but est de s'appuyer sur les drivers proprios ( drivers proprios qui sont aussi un frein vers certains nettoyages et la maintenance ).

Donc voila, si avec ça, on arrive pas à trouver de quoi débattre, c'est qu'il y a un souci.

Le pays basque, la savoie et l'alsace.

et tu as peur qu'on tombe sur un pépin ?