Pour le moment, je touche du bois, j'ai eu 0 souci de hardware sur les dédiés. Les seules fois ou ç'est parti en vrille, c'est sur des serveurs d'occases qui étaient déjà vieux et torturés à l'époque ou on a chopé ça ( fusion compaq/HP ). Et c'est après des années d'usage.
Le VPS classique ( né VKS ), il a moins de disque, un peu plus de cpu et autant de ram sur les versions kimsufi à 15 euros.
Et il a un kernel custom car basé sur openvz, ce que je veux éviter ( cf mes mésaventures avant, et parce qu'un kernel custom, c'est ni selinux, ni apparmor ). Et ça implique un reboot de temps en temps sans prévenir comme j'ai pu le constater et le confirmer par d'autres.
Ensuite, y a les VPS basé sur une techno VMWare ( vps cloud ). En dehors d'avoir un chouia mal au fondement d'utiliser une techno proprio, ça reste cher. 2G de ram, 2x2ghz et 100g, tu tapes dans les 30 euros par mois. Mais pas de reboot intempestif ( du moins je crois ).
En face, gandi, 2G de ram, ça va dans les 35 euros.
Dreamhost, 100$ par mois.
Si je prends la quantité de ram comme mesure, je pense que le kimsufi ou équivalent reste meilleur marché, avec le risque de souci hardware. Et encore, si ça tombe sur autre chose que le disque, je m'en fout. Et sur le disque, je ressort puppet et les backups. Donc pour moi, c'est un risque acceptable ( vu que je perds 0 euros si j'ai du downtime bien sur ).
Parce que chroot n'est pas prévu pour la sécurité, c'est juste pour changer 1 flag sur le process. Donc je pense que changer la sémantique n'est pas terrible ( en plus de casser posix ). Il suffit de voir le changement sur les hardlinks dans /tmp, qui est activé par défaut sur Ubuntu, Debian wheezy et partout systemd se trouve depuis 2/3 versions ( ie depuis 1/2 mois ). mais toujours bloqué upstream, car 1 personne a eu un souci le jour de la sortie du 3.8.
( et même si c'est pas prévu pour la sécurité, chroot aide un peu, ça dépend de la menace ( genre un verre automatisé qui dépend de ls pour se lancer, il va avoir plus de mal ), mais ça reste pas non plus utile face à un attaquant plus sophistiqué ).
Quand à lxc, il y a des travaux sur ça, cf les liens que j'ai donné pour d'une part, du coté de Canonical, poussé à l'usage d'apparmor avec l'userspace de lxc, et du coté de Red hat, l'usage de selinux avec les namespaces ( donc lxc ), notament virt-sandbox-service, systemd aussi un peu, et tout le travail fait pour openshift.
Freebsd a jail pour remplacer ça, solaris a les zones, etc, etc.
Et le kernel Linux reste super compliqué, et quand tu regardes tout ce que tu peux faire avec les capabilities http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , tu vois que rajouter plus de complexité n'aide pas vraiment.
Une des solutions, ça aurait été de merger grsec ( qui propose un chroot comme celui d'openbsd ), mais Linus n'a pas envie d'arbitrer ( et je le comprends ) des disputes entre les psychopathes moyens que le monde de la sécurité héberge, et je pense donc qu'il y a juste eu une mauvaise volonté des 2 cotés.
une autre, c’était de merger openvz ce qui arrive par petit bout. Quand à vserver, je pense que les devs upstreams rentrent dans la catégorie "mecs opiniatres avec qui je voudrait pas bosser" ( en tout cas, les 2 avec qui j'ai interagi ), donc ça doit être le même genre de souci que pour grsec.
J'ai lu la doc durant les premiers samedis du libre ( honte à moi, au lieu d'aider les gens ), et si j'en crois ça : http://www.freebsd.org/doc/en/books/handbook/jails-application.html , ça reste encore un peu manuel et long :/
Y a en effet plusieurs outils pour aider, dont ezjail, faut voir ce que ça vaut. ( au passage, je pige pas que personne ne s'insurge sur la violation de la FHS qu'est l'usage de /usr/jails au lieu de /var, mais bon, c'est pas lennart qui a codé ezjail, donc ça doit être acceptable ).
Ce qui est techniquement aussi un souci sur les namespaces de linux et pas non plus une surprise mais qui montre qu'il faut bien faire gaffe à tout. Par exemple, mon premier reflexe a été de voir si on peut accéder à un device spécifique, et la réponse "faut faire gaffe". Donc j'ai un peu peur que ça tombe dans le même cas que LXC nu, à savoir que je connais pas assez freebsd pour être sur de pas faire de connerie tôt ou tard.
Quand aux ports qui sont dans plusieurs versions, je pense que ça dépend de l'upstream et ça ne me donne pas d'indication sur la durée de vie des dits ports. Par exemple, si jamais puppet est tout troué, debian/centos vont mettre à jour le paquet en corrigeant la faille et pas en upgradant le paquet. Et c'est ce que je recherche.
J'ai aussi dans la foulée regardé du coté de openbsd, pour voir qu'il y a rien ( car le projet pense que c'est pas utile ), et pour netbsd, je pense qu'il faut magouiller avec rump, mais ça devient plus compliqué.
Vu qu'ils disent avoir 20 m² de salle machine, j'estime qu'il y a grosso modo 4/5 racks à tout casser et je doute du coup que la société possède les locaux.
En gros, le kernel est partagé et tout comme les chroots, tu as des milliers de façon d'en sortir sauf à customiser à fond les capacité et les permissions et bloquer des syscalls ( ce qui est faisable, mais ça reste toujours qu'une question de compromis temps/résultat ), donc je préfère laisser ça à des gens qui ont déjà fait l'effort de chercher :)
Ensuite, c'est un peu les vacances, donc je peux aussi faire l'effort sans doute.
J'avais pris Gentoo surtout pour essayer et pour élargir mes horizons ( d'autres vont dire pour être capable de troller efficacement sur tout ce qui bouge ), mais au final, une rolling release n'est pas ce que je cherche pour la partie php ( et pour puppet que j'utilise ) :
y a toujours le risque de "oops, on a un souci de sécu mais on a aussi cassé la compatibilité" ( ce qui était trop courant avant, et j'ai peur que ça ne soit pas mieux maintenant )
je n'ai pas le sentiment que la personnalisation que Gentoo propose m'apportais grand chose. La facilité de faire des paquets m'a permis de mettre à jour nginx et dns2tcp de maniére propre, et faut reconnaitre que faire des ebuilds est des plus simple. Mais j'ai pas changer les flags ou ce genre de choses.
Mais oui, les BSD, j'ai pensé. Je sais pas à quel point les jails sont suffisamment sécurisé pour ma tranquillité d'esprit, même si je pense qu'on peut supposer que les exploits kernels sont moins exploités sur un FreeBSD, donc peut être moins un souci au niveau de la surface d'attaque.
J'ai des réserves sur le fait d'industrialiser l'installation de nginx et php pour tout ça, mais c'est peut être juste une méconnaissance de ma part. Mais j'ai peur que la séparation en 2 ( ie d'un coté le système de base, de l'autre les ports ou pkgsrc ) soit au final comme une rolling release ( ie, correctif de secu par upgrade de version ), et je veux éviter ça, mais j'ai peut être tort ( pas tort d'éviter, tort de supposer que c'est semblable à une rolling release dans la gestion de la sécurité sur le long terme ( 2/3 ans )).
Idéalement et pour avoir un truc blindé, ça impliquerais pour chaque vhost d'avoir 1 user pour le php, et 1 user pour l'upload des fichiers. L'user qui fait tourner le php ( pour l'instant avec php-fpm ) devrait en effet être blindé ( idéalement, via seccomp, car les attaques sur le kernel sont un risque que j'aimerais évité, mais je ne sais pas comment utiliser seccomp sur un soft arbitraire à part en utilisant systemd ), bloqué au niveau du réseau soit via de l'uid matching dans netfilter ( facile ), soit via un namespace réseau ( moins facile, la doc d'iproute est pas stellaire ) et si possible avec des namespaces fichiers différents ( genre /tmp non partagé, , facile via pam_namespace ) pour rendre la tache plus difficile à un exploit automatique ( car je suis pas en train de me défendre contre les Illuminatis qui controle la NSA, le FSB et le MSS ).
Au final, ça reviendrais pour moi à faire tout le travail de lxc ( lxc qui en soit n'est qu'un set d'outil qui utilise les namespaces ), donc un peu de la duplication d'effort, que je cherche à éviter.
Peut être que tu as raison et que juste des uid différents + bons droits, ça suffit, et qu'il faut que je prenne mes pilules contre la paranoia :)
J'ai pas eu de retour de cette hébergeur, et je soupçonne que ça soit des machines OVH ou dans les DC d'OVH. J'étais tombé dessus, mais j'avais décidé de laisser un peu le temps de voir la solidité de l'hébergeur.
Ceci dit, si tu as des retours sur eux, je suis preneur pour la prochaine fois ( vu que le serveur a à 14e a 2 disques et assez de ram pour faire un petit serveur de virtualisation, contrairement à OVH qui file ni raid, ni VT pour ce prix la )
LE Qatar ne te dira pas si il a acheté du Red Hat ou pas.
C'est une possibilité…
Personnellement, je pense que je serais au courant si le prince du Qatar avait effectué une opération gigantesque de rachat de RH. Et tu te ridiculises de jour en jour en t'acharnant dans ton déni de réalité.
J'ai déjà répondu à la plupart des points que tu réitéres, donc je ne pense pas te convaincre plus en ressortant le même argumentaire, si tu n'es pas d'accord la première fois, tu va pas comprendre la seconde.
Mais quand même :
La plupart des applications modernes utilisent des pages web pour être configurées…
Webmin est un exemple typique.
Exemple typique d'application moderne ? On doit pas parler du même webmin avec du code perl qui continue de suivre les conventions de perl 4 ( à savoir mettre un & pour les fonctions ), et qui continue encore à se baser sur une technologie d'il y a 20 ans comme les cgis.
Et même si l'exemple est mal trouvé, le reste du point est foireux car la plupart des applis avec une interface web intégré sont soit des applications webs ( exemple, jive, sharepoint, nagios, oracle truc, drupal ), soit des applications non webs avec un serveur web en bundle ( exemple : ejabberd, couchdb ), soit des applications webs fournit à part.
Et dans tout les cas, c'est des applications que soit tu n'exposes pas sur le web ( donc hors du pool qui sort de l'étude que tu cites ), soit des applications qui ont globalement besoin de tourner sur apache et qui donc vont tourner globalement sur n'importe quel distro.
Mais ne te fais pas d'illusion dans l'embarqué Ubuntu va très probablement s'imposer notamment grâce aux smartphones…
Tu veux dire que Ubuntu va virer openwrt ou android de leur place ?
J'ai dit que debian est supérieur à RHEL-like/fedora-like.
Si ce n'était pas le cas, alors tous les magazines que j'ai eu à lire ne parleraient pas de linux debian
Alors donc, si une majeur partie des magazines que je vois chez mon buraliste parle d'installer des softs windows, je doit conclure quoi vis à vis de ton raisonnement ? Est ce qu'il ne s'applique que quand il est favorable à ta définition de supériorité ?
Tu ne vois pas MS se tirer la balle dans le pied quand même…
[C'est une entreprise commerciale]
Si les clients payent pour le support, Microsoft peut continuer pendant 50 ans.
Mais un admin compétent se fout du LTS: il fait comme moi, il construit ses propres paquets.
(Je te rappelle encore que je ne suis pas admin et j'ai des tas de paquets que j'ai moi même construits.)
Je suis content de voir que tu ne me classes pas dans "admin compétent" malgré le fait que ça soit mon travail. Parce que moi, je ne me fout pas de la durée de vie, et faire ses paquets, ça va 5 minutes mais faire le suivi des soucis des sécurité et les correctifs de bugs, c'est vite chiant ( encore une fois, je le sais, j'ai fait ça pendant un bout de temps pour des distros sur mon temps libre ). Donc j'aurais tendance à dire qu'un admin a mieux à faire que le travail d'une distribution dans son coin ( ie, faire ses propres paquets ), et qu'il apporte plus de valeur en laissant les autres faire ça, et qu'il se focalise sur les besoins plus direct. Ensuite, c'est vrai qu'il faut être compétent pour faire ses paquets, mais quand même un peu con pour ne pas mutualiser.
Je suis sur que c'est pas ton cas, et que tu peux nous montrer tout tes paquets que tu distribues sans doute ( sauf si tu n'as pas le temps et qu'au lieu d'aider, tu préfères poster sur linuxfr )
Tu te rappelles sûrement de ce que je t'avais dit: "Un admin vient me voir pour se plaindre que probablement on ne va pas investir dans la > bonne techno"
En fait, non, je passe pas mon temps à retenir ta prose incohérente. Y répondre me prends déjà assez de temps libre, et encore, je fait ça uniquement dans un but scientifique, voir à combien tu peux descendre.
A moi personnellement ? Rien. Ils ne connaissent même pas mon existence.
Tu serais peut être surpris de savoir qu'il y a sans doute des salariés RH qui lisent ce site, et peut être même qu'il y en a qui lisent ce que tu dis.
Par contre Fedora a fait planter ma machine alors que l'on m'avait certifié que c'est excellent le Red Hat…
J'avais oublié que Mandrake c'était déjà mieux que Red Hat…
2 choses :
- Fedora n'est pas RH, RHEL n'est pas Fedora. RH paye des gens pour bosser sur Fedora au même titre que RH paye les serveurs de Gnome et des gens pour bosser sur Gnome, ou paye la Linux Foundation et des gens pour bosser sur le kernel. Ou des gens pour bosser sur ovirt.
Mandrake existe plus, c'est devenu Mandriva vers 2006, d'une part, et dans l'état des choses, Mandriva, c'est soit OpenMandriva, soit Mageia ( que Mandriva serveur est basé sur Mageia ). Mais en tant qu'ancien contributeur à Ma(geia)|(ndr(iva|ake))), je suis content de voir que le travail que j'ai fait t'a plu, à défaut d'apprécier mes commentaires.
Quitter RHEL je peux comprendre [prix des licences],
Alors encore un chouia de pinaillage, c'est pas des licences, c'est des souscriptions. Je te laisse l'effort d'aller lire la différence sur le site idoine.
mais quitter Fedora pour entrer chez debian je comprends moins.
L'argent ne fait pas tout dans la vie, tu sais ?
Si des gens veulent des softs moins bleeding edge que ce propose Fedora, n'ont pas de temps à consacrer, sont plus à l'aise avec apt ou n'importe quoi d'autre, c'est leur droit. Moi, ça me choque pas de voir qu'il y a de la place pour tout le monde, et que tout le monde ne peut pas répondre à tout en même temps ( cf les écrits de Durkheim sur le sujet ).
Démontrer que tu es une caricature impliquerais d'avoir un processus scientifique, et je pense pas que ça existe. Par contre, au vue du karma que tu es perdu sur le site, je pense que ça tends à montrer qu'une majeur partie des gens sur le site pense que tes interventions sont totalement inutiles, sinon tu ne serais pas dans le négatif.
Knoppix fonctionne correctement sur le même PC alors que tu affirmais fièrement que c'est un mélange de stable d'instable et
d'expérimentale…
Et ? ç'est pas parce que c'est un mélange que ça va pas marcher, c'est pas parce que debian a déclaré "ce paquet est vu comme étant incorrectement intégré dans debian" qu'il faut conclure "ça ne marcheras nulle part" ou l'inverse.
Par contre, j'attends encore le jour ou tu va faire un apt-get upgrade sur ta knoppix et que ça marche correctement. J'attends le jour ou tu va faire un rapport de bug chez debian ( vu que les paquets sont des paquets debian aprés tout ) et qu'on te dise merde.
Suis-je assez bête pour m'attaquer à Linux notamment Fedora alors que j'aimerais que Linux soit devant windows ? Hmmm…?
Tu peux trés bien vouloir une chose et ne pas être capable de voir que tu fais et dit n'importe quoi.
Si tu veux que Linux soit devant Windows, faut te sortir les doigts du fondement et faut se bouger pour ça. Bien que je soit prêt à laisser le bénéfice du doute, au vue de tes interventions, des préjugés et de ta façon de communiquer le tout lié à un manque flagrant de compréhension technique, je doute que tu rentres dans la catégorie "contributeur productif" à quoi que ce soit d'autres qu'un fichier de fortune linuxfr.
On trouve également la présence de seccomp pour filtrer les appels systèmes, et il y a des efforts fait à ce niveau ( même si depuis la 12.04, j'ai le sentiment que les efforts ralentissent un peu )
Du coté de Fedora, il y a d'abord le travail sur systemd-nspawn ( qui au final utilise les mêmes APIs que l'utilitaire LXC ), et l'intégration avec svirt/libvirt ( http://kernsec.org/files/securelinuxcontainers.pdf ), et l'outil virt-sandbox.
En fait, en regardant hier la video de dan walsh ( mr SElinux ) sur la façon dont la framework de sécurité est utilisé pour confiner les applications dans openshift ( une plateforme de PaaS libre, qui fait de l’hébergement massif de containeurs pour les applications déployés ), il a expliqué que "lxc n'existe pas", c'est juste des utilitaires d'IBM pour tirer parti des fonctions natives du noyau, comme les namespaces, etc. IE, c'est un abus de langage selon lui ( et déplore le fait que libvirt-lxc perpétue le nommage et la confusion si c'est pas exactement compatible )
Il explique également le travail qu'il fait pour justement sécuriser tout ça, via virt-sandbox et l'intégration avec systemd.
Utilisant et allant sur les events en tant que membre du projet Fedora, j'ai largement l'habitude d'entendre dire que oui, ça sert que de bac à sable pour RHEL, avec les sous entendus qui vont avec ( et je suis pas le seul cf http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-04/fedora_board.2013-04-04-18.00.log.html ). Peut être que tu veux pas les faire personnellement, peut être que personne ne veut les faire, et je te crois si tu le dis. Mais il reste que si c'est pas dit clairement, les préjugés habituelles vont rester la, et ensuite, on se retrouve avec des gens comme https://linuxfr.org/users/kadalka/comments , ou ça devient limite de la caricature.
Encore une fois, j'ai bien compris que "oui, mais j'ai pas dit que ça sert que à ça", ce qui est vrai, mais quand quelqu'un ne dit pas autre chose, bah les gens retiennent que ce qu'il as dit sans aller imaginer d'autre trucs qu'il n'as pas dit.
Et je cherche à combattre cette perception et cette image de "bac à sable pour RHEL" ( qui est sous entendu par pas mal de gens ) car au final, c'est dommageable pour la communauté Fedora.
Dommageable car ensuite, les gens voient le projet Fedora comme n'étant qu'une propriété de RH avant d'être celle de la communauté , ce qui implique qu'une part des gens ne sentent pas impliqués. C'est ce qui est arrivé chez Mandriva ( en partie, y a eu d'autre souci ), c'est ce qui arrive chez Ubuntu aussi ( au vue des commentaires via les blogs il y a quelques semaines lors du vUDS ). On a vu ce que ça a donné pour Mandriva.
Et chez certaines personnes, ça mets en place une logique de division entre les gens de RH et le reste du monde, entrainant des théories conspirationnistes usantes, ce qui à leur tour traine des débats techniques loin de la technique ( et je pense pas que le projet en bénéficie ). Donc pour éviter ça, je cherche à combattre le souci à la base. Ça serait mieux avec une entité indépendante du sponsor pour Fedora, mais c'est un chouia plus compliqué à faire ( la dernière fois que j'ai tenté ça avec d'autres, on a mis 5 ans et il a fallu une crise économique, donc éviter une victoire à la pyrhus serait appréciable ce coup ci )
Dommageable car dire que c'est un bac à sable, ça implique que c'est pas stable pour pas mal de gens ( comme dire que "debian unstable plante comme son nom l'indique", ce qui est pas vrai, même si le fait que ça peut arriver ), ce qui ensuite entraine une pénurie de non techniciens et ce qui explique le manque de graphistes et autre contributeurs qui peuvent aider sans pour autant savoir coder son module kernel en asm.
Donc ouais, j'ai vu rouge. J'avais pas le sentiment que mon commentaire serait perçu comme si violent, mais bon, je le referais si j'avais à le refaire.
faire une de fusionner sort, uniq, cat et la gestion des flux pour faire un bon gros mmap des bois
tu veux dire perl ?
ou tu parles de sort -u peut être ?
Ou peut être de busybox ( busybox étant le shell le plus distribué au monde, merci android ) ?
Mais ils seraient tellement moins utiles, tellement moins importants, tellement moins des briques de base et
il faudrait les re-développer pour tous les cas.
Et tout ça pourquoi ? Un peu de perfs.
Et c'est pour ça que tout le monde code en bash/sh/ksh/zsh, car les perfs, ça sert tellement à rien :)
Il parle peut être de carte wifi ( ce qui est une carte réseau aussi ), car en effet, une carte réseau ethernet pour pc non supporté sur linux, j'ai pas vu ça depuis 2004 :/
( mais bon, j'achète sans doute pas assez de matos ).
. J'ai l'impression aussi que certaines avancés noyaux auraient besoin d'application user-space "sérieuse" pour
être correctement exploité (fonctionnalité de btrfs, netfilter, cgroups, etc…).
En fait, le souci, c'est que tout ça, ça implique d'avoir une idée du fonctionnement du système, et donc implique d'avoir un admin pour gérer les choses. Je vois à la rigueur comment on peut utiliser les cgroups et lxc pour lancer une application dans un mode de compatibilité, ça serait peut être utile sur une station bureautique. Mais ça intéresse pas les distributions, et les utilisateurs qui savent faire le font dans leur coin, et les autres savent pas donc font pas. Mais tu veux faire quoi de bureautique avec cgroups, btrfs ou iptables ?
En fait, ça me rappelle aussi alsa et pulseaudio. Une partie des soucis de pulseaudio était due à des bugs alsa non repéré car dans du code non utilisé de cette façon avant.
Donc oui, faudrait des trucs, et pour ça, faut juste se bouger et coder.
En outre, son avenir est certain, par rapport à Java par exemple.
Vu que la plupart des gens que je connais qui font du java disent que java est le nouveau cobol, dans le sens ou il a atteint une masse critique de service critique ( genre banque, assurance, etc ), je doute que java disparaisse. Oracle va pas (hélas) mourir du jour au lendemain.
Et à ma connaissance, Google utilise Python aussi… Ce n'est pas un détail.
chez Google, java aussi est relativement assez utilisé en interne. Il suffit de lire les offres d'emplois pour s'en convaincre.
Et juste sur la base des informations publiques, une rapide recherche montre que l'usage de python dépend grandement des applications et qu'au final, c'est découragé pour des questions de "scale", cf le 2eme mail de Collin Winter dans ce fil : https://groups.google.com/forum/?fromgroups=#!topic/unladen-swallow/TtvEBvVEZD4
( Collin Winter, qui comme son cv l'indique, est dans l'équipe qui bosse sur les compilateurs au QG de Google à Mountain View )
( et il parle des applications serveurs, pas des scripts one shots d'administration écrit par un SRE ou ce genre de choses bien sur )
Y a l’intérêt de reprendre un paradigme connu par ailleurs, donc de réduire la courbe d'apprentissage ( vu que ça réponds comme tu as l'habitude que ça répondes ailleurs ) et la charge cognitive ( vu que tu as pas à choisir entre 2 types de boutons ). On le voit pas parce qu'on a l'habitude, mais je pense pas que ça soit fait "par hasard".
Il faut savoir, soit Ubuntu est une distribution libre, soutenue par sa communauté, dans ce cas c'est à elle de décider quel chemin
Ubuntu prendra, soit c'est un logiciel privateur, appartenant à Canonical, où la communauté n'a pas son mot à dire, dans ce cas, celle-ci
disparaîtra,
La dichotomie est un peu violente. Le souci, c'est pas que Canonical décide. Ils sont parfaitement légitimes pour ça.
Mark et son équipe ont une vision de ce qu'ils voudraient faire pour attendre leur but, et ils pensent qu'aller directement sans chercher le consensus parfait préalable est le meilleur moyen de réussir. On peut ne pas être d'accord, mais c'est leur droit.
Ensuite, le souci pour moi, c'est le double discours. C'est Jono bacon qui va tacler RH et Novell dans son livre pour expliquer comment chez Ubuntu, la communauté est au centre, alors qu'au final, pas autant que ça. C'est le fait d'avoir des procédures à 2 vitesses pour l'intégration des fonctions.
Mais ça, c'est aussi du au fait que "communauté" veut dire tout un tas de choses. Communauté d'utilisateurs, de developpeurs ? Avec un pouvoir décisionnel fort, quid du lien hiérarchique entre le sponsor et des membres ?
Comme dire "on va choisir démocratiquement". Oui, mais qui vote, comment ?
(Toujours en comparaison avec windows, il n'y a pas une communauté qui consacre du temps libre pour développer windows en
collaboration avec microsoft)
Le temps libre n'a rien à voir, il y a des boites qui bossent avec Microsoft pour améliorer Windows par le biais de logiciels externes, car la force du produit est pas autant dans les fonctions de base que dans tout le reste. Il y a un écosystème autour de Windows, il y a des gens qui bossent sur ça, et si les gens n'avaient pas une vision spécifique du mot communauté, j’oserais même dire qu'il y a une communauté dans le sens ou les gens ont en commun quelque chose.
Ensuite, la plupart des gens vont se dire que c'est pas communautaire, car il y a des échanges marchands entre les membres et l’extérieur, ce qui serait faux. Si tu prends l'exemple communautaire par excellence pour tous, Debian, il y a des gens payé pour faire du dev debian. Par exemple, dans mon ancienne boite, notre sysadmin était dev debian sur son temps de travail car notre produit était basé sur debian. L'ancien DPL a participé à des projets de recherches sur Debian, qui ont aidé le projet et la recherche et qui ont permis de pouvoir vivre.
Donc non, la réalité est bien plus nuancé que ce que tu dis.
À propos de Red Hat, ils développent beaucoup, imposent leur vision (les dégâts sur Nautilus),
les "dégats" sur nautilus comme tu dit, ça vient des développeurs de nautilus, et ils ont la totale légitimité de faire ce qu'ils croient bons pour le logiciel. La d'ou vient leur paye n'a en général rien à voir. Il suffit de voir que c'est exactement le même genre de choses qui ont été reproché au projet gnome lors de la sortie de gnome 2 ( en 2002 ) pour voir que l’hypothèse d'un complot ne repose sur rien, vu que 1) Fedora n'existait pas 2) RHEL non plus 3) les devs Gnome étaient plus payé par Helix code ou Eazel que par RH.
balancent dans Fedora, voient les remontées utilisateurs, et quand le machin a atteint un niveau de stabilité
suffisant pour leurs exigences ils l'intègrent à Red Hat.
En fait, tu serais surpris de savoir qu'il y a un département QA chez RH pour RHEL. C'est dingue, je sais, la boite peut faire des tests sans les vastes retours de tout les utilisateurs Fedora.
Et en fait, tu pourrais aussi dire pareil sur Debian.
"Quand le machin a atteint le niveau de stabilité suffisant, c'est intégré dans debian stable". Ou pour SLES. Mais bon, la, c'est différent je suppose, car quand tu mets à dispo un truc pour qu'il soit testé pour toi et tout le monde, c'est mal, mais quand tu attends que d'autres fassent les tests pour toi, c'est légitime, et signe d'une indépendance forte ?
Fedora a beau être une distrib communautaire, Red Hat s'en sert comme bac à sable.
Ah oui, tout ces serveurs sous Fedora qui servent à valider les technos RHEL, tout ces serveurs d'applications JBoss sur des Fedora 17, toutes ces installations d'Openshift, d'Ovirt, de spacewalk qui sont massivement déployé sur Fedora afin de tester les outils pour la version entreprise. Comment est ce qu'on fait pour les louper.
Ah oui, parce qu'ils existent qu'à l'état de trace dans l'imagination enfiévré des utilisateurs manichéens qui n'ont pas réfléchi à la question au delà du niveau de réflexion d'un comptoir de bar.
Car bien entendu, par exemple, les devs du kernels, ils ont pas besoin de tests ou de distro qui poussent les dernières versions, ils trouvent les bugs juste en lisant le code source au petit déjeuner, et pis tant pis si ça prends beaucoup plus de temps, on a pas besoin d'avoir des correctifs rapides, car un kernel dont les bugs sont corrigés que 6 mois aprés, ça inspire tellement confiance, et tout le monde voudrait ça .
L'idée même que la coopération soit une des raisons d'être de Fedora n'est pas une idée si saugrenu pourtant. Les gens qui veulent les dernières technologies ( genre avoir ruby 2.0, le dernier gcc ) en bénéficient, les devs qui veulent des retours rapides sur leur soft en bénéficient, et tout le monde y gagne.Même les gens qui veulent des technos éprouvées en bénéficient indirectement, car plus il y a de tests, plus vite les technos sont éprouvés ( car oui, suffit pas de mettre le code sur un ftp pendant 1 an pour qu'ils soient stable, c'est pas une bouteille de vin, ça se fait pas tout seul ).
Le projet cherche à rester proche des projets upstream ( https://fedoraproject.org/wiki/Staying_close_to_upstream_projects ) justement pour que tout le monde puisse y gagner. Le projet ne veux utiliser que du logiciel libre pour justement permettre à tout un chacun de l'utiliser sans risquer un 2eme procès SCO.
Et ce qu'il y a de bien avec les affirmations non fondées sur la relation RH/Fedora, c'est que ça marche quoi que tu fasses. Quand Fedora ne fait pas de concurrence direct à RHEL, alors on va dire que c'est fait exprès pour pas faire d'ombre au part de marché, donc c'est la main mise de RH sur la distro. Et quand Fedora fait concurrence, c'est encore la main mise de RH pour faire des tests et des expérimentations.
Voir mieux, quand on dit qu'il y a pas de preuves, alors c'est bien le signe qu'il y a quelque chose de caché, donc la main mise secrète de la multinationale.
Donc quoi que la communauté décide, et sans avoir le moindre argument, ça va toujours être la main mise du sponsor principale, donc sous entends "mal". Autant directement dire que c'est mal directement sans lien de cause à effet, ça va faire économiser du temps à tout le monde.
[^] # Re: Ma petite expérience en la matière...
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
Pour le moment, je touche du bois, j'ai eu 0 souci de hardware sur les dédiés. Les seules fois ou ç'est parti en vrille, c'est sur des serveurs d'occases qui étaient déjà vieux et torturés à l'époque ou on a chopé ça ( fusion compaq/HP ). Et c'est après des années d'usage.
Le VPS classique ( né VKS ), il a moins de disque, un peu plus de cpu et autant de ram sur les versions kimsufi à 15 euros.
Et il a un kernel custom car basé sur openvz, ce que je veux éviter ( cf mes mésaventures avant, et parce qu'un kernel custom, c'est ni selinux, ni apparmor ). Et ça implique un reboot de temps en temps sans prévenir comme j'ai pu le constater et le confirmer par d'autres.
Ensuite, y a les VPS basé sur une techno VMWare ( vps cloud ). En dehors d'avoir un chouia mal au fondement d'utiliser une techno proprio, ça reste cher. 2G de ram, 2x2ghz et 100g, tu tapes dans les 30 euros par mois. Mais pas de reboot intempestif ( du moins je crois ).
En face, gandi, 2G de ram, ça va dans les 35 euros.
Dreamhost, 100$ par mois.
Si je prends la quantité de ram comme mesure, je pense que le kimsufi ou équivalent reste meilleur marché, avec le risque de souci hardware. Et encore, si ça tombe sur autre chose que le disque, je m'en fout. Et sur le disque, je ressort puppet et les backups. Donc pour moi, c'est un risque acceptable ( vu que je perds 0 euros si j'ai du downtime bien sur ).
[^] # Re: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 5.
Parce que chroot n'est pas prévu pour la sécurité, c'est juste pour changer 1 flag sur le process. Donc je pense que changer la sémantique n'est pas terrible ( en plus de casser posix ). Il suffit de voir le changement sur les hardlinks dans /tmp, qui est activé par défaut sur Ubuntu, Debian wheezy et partout systemd se trouve depuis 2/3 versions ( ie depuis 1/2 mois ). mais toujours bloqué upstream, car 1 personne a eu un souci le jour de la sortie du 3.8.
( et même si c'est pas prévu pour la sécurité, chroot aide un peu, ça dépend de la menace ( genre un verre automatisé qui dépend de ls pour se lancer, il va avoir plus de mal ), mais ça reste pas non plus utile face à un attaquant plus sophistiqué ).
Quand à lxc, il y a des travaux sur ça, cf les liens que j'ai donné pour d'une part, du coté de Canonical, poussé à l'usage d'apparmor avec l'userspace de lxc, et du coté de Red hat, l'usage de selinux avec les namespaces ( donc lxc ), notament virt-sandbox-service, systemd aussi un peu, et tout le travail fait pour openshift.
Freebsd a jail pour remplacer ça, solaris a les zones, etc, etc.
Et le kernel Linux reste super compliqué, et quand tu regardes tout ce que tu peux faire avec les capabilities
http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , tu vois que rajouter plus de complexité n'aide pas vraiment.
Une des solutions, ça aurait été de merger grsec ( qui propose un chroot comme celui d'openbsd ), mais Linus n'a pas envie d'arbitrer ( et je le comprends ) des disputes entre les psychopathes moyens que le monde de la sécurité héberge, et je pense donc qu'il y a juste eu une mauvaise volonté des 2 cotés.
une autre, c’était de merger openvz ce qui arrive par petit bout. Quand à vserver, je pense que les devs upstreams rentrent dans la catégorie "mecs opiniatres avec qui je voudrait pas bosser" ( en tout cas, les 2 avec qui j'ai interagi ), donc ça doit être le même genre de souci que pour grsec.
[^] # Re: FreeBSD
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 3.
J'ai lu la doc durant les premiers samedis du libre ( honte à moi, au lieu d'aider les gens ), et si j'en crois ça :
http://www.freebsd.org/doc/en/books/handbook/jails-application.html , ça reste encore un peu manuel et long :/
Y a en effet plusieurs outils pour aider, dont ezjail, faut voir ce que ça vaut. ( au passage, je pige pas que personne ne s'insurge sur la violation de la FHS qu'est l'usage de /usr/jails au lieu de /var, mais bon, c'est pas lennart qui a codé ezjail, donc ça doit être acceptable ).
Et en cherchant un peu pour voir le genre de souci qu'il y a, je tombe sur ça :
http://r00tsec.blogspot.fr/2011/05/freebsd-privilege-escalation-using.html
Ce qui est techniquement aussi un souci sur les namespaces de linux et pas non plus une surprise mais qui montre qu'il faut bien faire gaffe à tout. Par exemple, mon premier reflexe a été de voir si on peut accéder à un device spécifique, et la réponse "faut faire gaffe". Donc j'ai un peu peur que ça tombe dans le même cas que LXC nu, à savoir que je connais pas assez freebsd pour être sur de pas faire de connerie tôt ou tard.
Quand aux ports qui sont dans plusieurs versions, je pense que ça dépend de l'upstream et ça ne me donne pas d'indication sur la durée de vie des dits ports. Par exemple, si jamais puppet est tout troué, debian/centos vont mettre à jour le paquet en corrigeant la faille et pas en upgradant le paquet. Et c'est ce que je recherche.
J'ai aussi dans la foulée regardé du coté de openbsd, pour voir qu'il y a rien ( car le projet pense que c'est pas utile ), et pour netbsd, je pense qu'il faut magouiller avec rump, mais ça devient plus compliqué.
[^] # Re: NetworkManager
Posté par Misc (site web personnel) . En réponse au sondage Quel gestionnaire de connexions réseau utilisez-vous ?. Évalué à 5.
NM peut aussi stocker les mots de passes dans gnome-keyring, mais à ce moment, le réseau n'est disponible que si tu es connecté et que pour toi.
[^] # Re: Moinssage
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 3.
Ils opèrent leur propre salle dans un datacenter de quelqu'un d'autre, en fait
http://www.firstheberg.com/infrastructure.php
Vu qu'ils disent avoir 20 m² de salle machine, j'estime qu'il y a grosso modo 4/5 racks à tout casser et je doute du coup que la société possède les locaux.
[^] # Re: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 3.
LXC ne me semble pas suffisant parce que j'ai lu tout ce que les distros font pour le sécuriser :
- https://wiki.ubuntu.com/LxcSecurity
- http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/
- http://www.slideshare.net/dpavlin/security-of-linux-containers-in-the-cloud
En gros, le kernel est partagé et tout comme les chroots, tu as des milliers de façon d'en sortir sauf à customiser à fond les capacité et les permissions et bloquer des syscalls ( ce qui est faisable, mais ça reste toujours qu'une question de compromis temps/résultat ), donc je préfère laisser ça à des gens qui ont déjà fait l'effort de chercher :)
Ensuite, c'est un peu les vacances, donc je peux aussi faire l'effort sans doute.
[^] # Re: FreeBSD
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
J'avais pris Gentoo surtout pour essayer et pour élargir mes horizons ( d'autres vont dire pour être capable de troller efficacement sur tout ce qui bouge ), mais au final, une rolling release n'est pas ce que je cherche pour la partie php ( et pour puppet que j'utilise ) :
y a toujours le risque de "oops, on a un souci de sécu mais on a aussi cassé la compatibilité" ( ce qui était trop courant avant, et j'ai peur que ça ne soit pas mieux maintenant )
je n'ai pas le sentiment que la personnalisation que Gentoo propose m'apportais grand chose. La facilité de faire des paquets m'a permis de mettre à jour nginx et dns2tcp de maniére propre, et faut reconnaitre que faire des ebuilds est des plus simple. Mais j'ai pas changer les flags ou ce genre de choses.
Mais oui, les BSD, j'ai pensé. Je sais pas à quel point les jails sont suffisamment sécurisé pour ma tranquillité d'esprit, même si je pense qu'on peut supposer que les exploits kernels sont moins exploités sur un FreeBSD, donc peut être moins un souci au niveau de la surface d'attaque.
J'ai des réserves sur le fait d'industrialiser l'installation de nginx et php pour tout ça, mais c'est peut être juste une méconnaissance de ma part. Mais j'ai peur que la séparation en 2 ( ie d'un coté le système de base, de l'autre les ports ou pkgsrc ) soit au final comme une rolling release ( ie, correctif de secu par upgrade de version ), et je veux éviter ça, mais j'ai peut être tort ( pas tort d'éviter, tort de supposer que c'est semblable à une rolling release dans la gestion de la sécurité sur le long terme ( 2/3 ans )).
[^] # Re: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
Idéalement et pour avoir un truc blindé, ça impliquerais pour chaque vhost d'avoir 1 user pour le php, et 1 user pour l'upload des fichiers. L'user qui fait tourner le php ( pour l'instant avec php-fpm ) devrait en effet être blindé ( idéalement, via seccomp, car les attaques sur le kernel sont un risque que j'aimerais évité, mais je ne sais pas comment utiliser seccomp sur un soft arbitraire à part en utilisant systemd ), bloqué au niveau du réseau soit via de l'uid matching dans netfilter ( facile ), soit via un namespace réseau ( moins facile, la doc d'iproute est pas stellaire ) et si possible avec des namespaces fichiers différents ( genre /tmp non partagé, , facile via pam_namespace ) pour rendre la tache plus difficile à un exploit automatique ( car je suis pas en train de me défendre contre les Illuminatis qui controle la NSA, le FSB et le MSS ).
Au final, ça reviendrais pour moi à faire tout le travail de lxc ( lxc qui en soit n'est qu'un set d'outil qui utilise les namespaces ), donc un peu de la duplication d'effort, que je cherche à éviter.
Peut être que tu as raison et que juste des uid différents + bons droits, ça suffit, et qu'il faut que je prenne mes pilules contre la paranoia :)
[^] # Re: artillerie
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
Du coté de kvm. Les serveurs les moins chers chez kimsufi sont sans VT donc ça va être lent :/
En fait, rien n'est insoluble, je demande juste quoi sacrifier :)
[^] # Re: Moinssage
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
J'ai pas eu de retour de cette hébergeur, et je soupçonne que ça soit des machines OVH ou dans les DC d'OVH. J'étais tombé dessus, mais j'avais décidé de laisser un peu le temps de voir la solidité de l'hébergeur.
Ceci dit, si tu as des retours sur eux, je suis preneur pour la prochaine fois ( vu que le serveur a à 14e a 2 disques et assez de ram pour faire un petit serveur de virtualisation, contrairement à OVH qui file ni raid, ni VT pour ce prix la )
[^] # Re: NetworkManager
Posté par Misc (site web personnel) . En réponse au sondage Quel gestionnaire de connexions réseau utilisez-vous ?. Évalué à 4.
Et wicd a des bugs amusants :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692417
[^] # Re: "Gnome livre des versions avec des modifications faites à moitié"
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Personnellement, je pense que je serais au courant si le prince du Qatar avait effectué une opération gigantesque de rachat de RH. Et tu te ridiculises de jour en jour en t'acharnant dans ton déni de réalité.
J'ai déjà répondu à la plupart des points que tu réitéres, donc je ne pense pas te convaincre plus en ressortant le même argumentaire, si tu n'es pas d'accord la première fois, tu va pas comprendre la seconde.
Mais quand même :
Exemple typique d'application moderne ? On doit pas parler du même webmin avec du code perl qui continue de suivre les conventions de perl 4 ( à savoir mettre un & pour les fonctions ), et qui continue encore à se baser sur une technologie d'il y a 20 ans comme les cgis.
Et même si l'exemple est mal trouvé, le reste du point est foireux car la plupart des applis avec une interface web intégré sont soit des applications webs ( exemple, jive, sharepoint, nagios, oracle truc, drupal ), soit des applications non webs avec un serveur web en bundle ( exemple : ejabberd, couchdb ), soit des applications webs fournit à part.
Et dans tout les cas, c'est des applications que soit tu n'exposes pas sur le web ( donc hors du pool qui sort de l'étude que tu cites ), soit des applications qui ont globalement besoin de tourner sur apache et qui donc vont tourner globalement sur n'importe quel distro.
Tu veux dire que Ubuntu va virer openwrt ou android de leur place ?
Alors donc, si une majeur partie des magazines que je vois chez mon buraliste parle d'installer des softs windows, je doit conclure quoi vis à vis de ton raisonnement ? Est ce qu'il ne s'applique que quand il est favorable à ta définition de supériorité ?
Si les clients payent pour le support, Microsoft peut continuer pendant 50 ans.
Je suis content de voir que tu ne me classes pas dans "admin compétent" malgré le fait que ça soit mon travail. Parce que moi, je ne me fout pas de la durée de vie, et faire ses paquets, ça va 5 minutes mais faire le suivi des soucis des sécurité et les correctifs de bugs, c'est vite chiant ( encore une fois, je le sais, j'ai fait ça pendant un bout de temps pour des distros sur mon temps libre ). Donc j'aurais tendance à dire qu'un admin a mieux à faire que le travail d'une distribution dans son coin ( ie, faire ses propres paquets ), et qu'il apporte plus de valeur en laissant les autres faire ça, et qu'il se focalise sur les besoins plus direct. Ensuite, c'est vrai qu'il faut être compétent pour faire ses paquets, mais quand même un peu con pour ne pas mutualiser.
Je suis sur que c'est pas ton cas, et que tu peux nous montrer tout tes paquets que tu distribues sans doute ( sauf si tu n'as pas le temps et qu'au lieu d'aider, tu préfères poster sur linuxfr )
En fait, non, je passe pas mon temps à retenir ta prose incohérente. Y répondre me prends déjà assez de temps libre, et encore, je fait ça uniquement dans un but scientifique, voir à combien tu peux descendre.
[^] # Re: Post grognon ;-)
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Tu serais peut être surpris de savoir qu'il y a sans doute des salariés RH qui lisent ce site, et peut être même qu'il y en a qui lisent ce que tu dis.
2 choses :
- Fedora n'est pas RH, RHEL n'est pas Fedora. RH paye des gens pour bosser sur Fedora au même titre que RH paye les serveurs de Gnome et des gens pour bosser sur Gnome, ou paye la Linux Foundation et des gens pour bosser sur le kernel. Ou des gens pour bosser sur ovirt.
Alors encore un chouia de pinaillage, c'est pas des licences, c'est des souscriptions. Je te laisse l'effort d'aller lire la différence sur le site idoine.
L'argent ne fait pas tout dans la vie, tu sais ?
Si des gens veulent des softs moins bleeding edge que ce propose Fedora, n'ont pas de temps à consacrer, sont plus à l'aise avec apt ou n'importe quoi d'autre, c'est leur droit. Moi, ça me choque pas de voir qu'il y a de la place pour tout le monde, et que tout le monde ne peut pas répondre à tout en même temps ( cf les écrits de Durkheim sur le sujet ).
[^] # Re: La caricature de Misc
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Démontrer que tu es une caricature impliquerais d'avoir un processus scientifique, et je pense pas que ça existe. Par contre, au vue du karma que tu es perdu sur le site, je pense que ça tends à montrer qu'une majeur partie des gens sur le site pense que tes interventions sont totalement inutiles, sinon tu ne serais pas dans le négatif.
Et ? ç'est pas parce que c'est un mélange que ça va pas marcher, c'est pas parce que debian a déclaré "ce paquet est vu comme étant incorrectement intégré dans debian" qu'il faut conclure "ça ne marcheras nulle part" ou l'inverse.
Par contre, j'attends encore le jour ou tu va faire un apt-get upgrade sur ta knoppix et que ça marche correctement. J'attends le jour ou tu va faire un rapport de bug chez debian ( vu que les paquets sont des paquets debian aprés tout ) et qu'on te dise merde.
Tu peux trés bien vouloir une chose et ne pas être capable de voir que tu fais et dit n'importe quoi.
Si tu veux que Linux soit devant Windows, faut te sortir les doigts du fondement et faut se bouger pour ça. Bien que je soit prêt à laisser le bénéfice du doute, au vue de tes interventions, des préjugés et de ta façon de communiquer le tout lié à un manque flagrant de compréhension technique, je doute que tu rentres dans la catégorie "contributeur productif" à quoi que ce soit d'autres qu'un fichier de fortune linuxfr.
Vouloir, c'est une chose, mais ça suffit pas.
[^] # Re: LXC
Posté par Misc (site web personnel) . En réponse au journal OpenVZ sur Debian : Que prévoyez-vous avec Wheezy ?. Évalué à 3.
Y a plusieurs projets. Ubuntu a poussé l'intégration avec apparmor d’après la page sur le sujet :
https://wiki.ubuntu.com/LxcSecurity
On trouve également la présence de seccomp pour filtrer les appels systèmes, et il y a des efforts fait à ce niveau ( même si depuis la 12.04, j'ai le sentiment que les efforts ralentissent un peu )
Du coté de Fedora, il y a d'abord le travail sur systemd-nspawn ( qui au final utilise les mêmes APIs que l'utilitaire LXC ), et l'intégration avec svirt/libvirt ( http://kernsec.org/files/securelinuxcontainers.pdf ), et l'outil virt-sandbox.
[^] # Re: On peut espérer...
Posté par Misc (site web personnel) . En réponse au journal OpenVZ sur Debian : Que prévoyez-vous avec Wheezy ?. Évalué à 4.
En fait, en regardant hier la video de dan walsh ( mr SElinux ) sur la façon dont la framework de sécurité est utilisé pour confiner les applications dans openshift ( une plateforme de PaaS libre, qui fait de l’hébergement massif de containeurs pour les applications déployés ), il a expliqué que "lxc n'existe pas", c'est juste des utilitaires d'IBM pour tirer parti des fonctions natives du noyau, comme les namespaces, etc. IE, c'est un abus de langage selon lui ( et déplore le fait que libvirt-lxc perpétue le nommage et la confusion si c'est pas exactement compatible )
Il explique également le travail qu'il fait pour justement sécuriser tout ça, via virt-sandbox et l'intégration avec systemd.
La video est sur http://www.youtube.com/watch?v=VaxkrSpBr6M , dan est pas un mauvais présentateur donc je conseille de la regarder.
[^] # Re: J'ai rigolé !
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 6.
Utilisant et allant sur les events en tant que membre du projet Fedora, j'ai largement l'habitude d'entendre dire que oui, ça sert que de bac à sable pour RHEL, avec les sous entendus qui vont avec ( et je suis pas le seul cf http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-04/fedora_board.2013-04-04-18.00.log.html ). Peut être que tu veux pas les faire personnellement, peut être que personne ne veut les faire, et je te crois si tu le dis. Mais il reste que si c'est pas dit clairement, les préjugés habituelles vont rester la, et ensuite, on se retrouve avec des gens comme https://linuxfr.org/users/kadalka/comments , ou ça devient limite de la caricature.
Encore une fois, j'ai bien compris que "oui, mais j'ai pas dit que ça sert que à ça", ce qui est vrai, mais quand quelqu'un ne dit pas autre chose, bah les gens retiennent que ce qu'il as dit sans aller imaginer d'autre trucs qu'il n'as pas dit.
Et je cherche à combattre cette perception et cette image de "bac à sable pour RHEL" ( qui est sous entendu par pas mal de gens ) car au final, c'est dommageable pour la communauté Fedora.
Dommageable car ensuite, les gens voient le projet Fedora comme n'étant qu'une propriété de RH avant d'être celle de la communauté , ce qui implique qu'une part des gens ne sentent pas impliqués. C'est ce qui est arrivé chez Mandriva ( en partie, y a eu d'autre souci ), c'est ce qui arrive chez Ubuntu aussi ( au vue des commentaires via les blogs il y a quelques semaines lors du vUDS ). On a vu ce que ça a donné pour Mandriva.
Et chez certaines personnes, ça mets en place une logique de division entre les gens de RH et le reste du monde, entrainant des théories conspirationnistes usantes, ce qui à leur tour traine des débats techniques loin de la technique ( et je pense pas que le projet en bénéficie ). Donc pour éviter ça, je cherche à combattre le souci à la base. Ça serait mieux avec une entité indépendante du sponsor pour Fedora, mais c'est un chouia plus compliqué à faire ( la dernière fois que j'ai tenté ça avec d'autres, on a mis 5 ans et il a fallu une crise économique, donc éviter une victoire à la pyrhus serait appréciable ce coup ci )
Dommageable car dire que c'est un bac à sable, ça implique que c'est pas stable pour pas mal de gens ( comme dire que "debian unstable plante comme son nom l'indique", ce qui est pas vrai, même si le fait que ça peut arriver ), ce qui ensuite entraine une pénurie de non techniciens et ce qui explique le manque de graphistes et autre contributeurs qui peuvent aider sans pour autant savoir coder son module kernel en asm.
Donc ouais, j'ai vu rouge. J'avais pas le sentiment que mon commentaire serait perçu comme si violent, mais bon, je le referais si j'avais à le refaire.
[^] # Re: RAID dans BRTFS
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 4.
tu veux dire perl ?
ou tu parles de sort -u peut être ?
Ou peut être de busybox ( busybox étant le shell le plus distribué au monde, merci android ) ?
Et c'est pour ça que tout le monde code en bash/sh/ksh/zsh, car les perfs, ça sert tellement à rien :)
[^] # Re: Liste des matériels supportés
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 5.
Il parle peut être de carte wifi ( ce qui est une carte réseau aussi ), car en effet, une carte réseau ethernet pour pc non supporté sur linux, j'ai pas vu ça depuis 2004 :/
( mais bon, j'achète sans doute pas assez de matos ).
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 3.
Alors btrfs, y a :
https://blogs.oracle.com/wim/entry/btrfs_root_and_yum_update
Cgroups, y a :
- systemd
- lxc ( et genre les gens qui utilisent des lxc pour steam : https://www.stgraber.org/2012/11/16/running-steam-in-a-lxc-container/ )
En fait, le souci, c'est que tout ça, ça implique d'avoir une idée du fonctionnement du système, et donc implique d'avoir un admin pour gérer les choses. Je vois à la rigueur comment on peut utiliser les cgroups et lxc pour lancer une application dans un mode de compatibilité, ça serait peut être utile sur une station bureautique. Mais ça intéresse pas les distributions, et les utilisateurs qui savent faire le font dans leur coin, et les autres savent pas donc font pas. Mais tu veux faire quoi de bureautique avec cgroups, btrfs ou iptables ?
En fait, ça me rappelle aussi alsa et pulseaudio. Une partie des soucis de pulseaudio était due à des bugs alsa non repéré car dans du code non utilisé de cette façon avant.
Donc oui, faudrait des trucs, et pour ça, faut juste se bouger et coder.
[^] # Re: Tu vas t'attirer des foudres...
Posté par Misc (site web personnel) . En réponse au journal L'immobilier, c'était mieux avant !. Évalué à 2.
Stricto sensu, c'est rentable. La question, c'est de savoir si c'est rentable pour l'acheteur ou pour le vendeur :)
[^] # Re: Qtisation
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 3.
Vu que la plupart des gens que je connais qui font du java disent que java est le nouveau cobol, dans le sens ou il a atteint une masse critique de service critique ( genre banque, assurance, etc ), je doute que java disparaisse. Oracle va pas (hélas) mourir du jour au lendemain.
chez Google, java aussi est relativement assez utilisé en interne. Il suffit de lire les offres d'emplois pour s'en convaincre.
Et juste sur la base des informations publiques, une rapide recherche montre que l'usage de python dépend grandement des applications et qu'au final, c'est découragé pour des questions de "scale", cf le 2eme mail de Collin Winter dans ce fil :
https://groups.google.com/forum/?fromgroups=#!topic/unladen-swallow/TtvEBvVEZD4
( Collin Winter, qui comme son cv l'indique, est dans l'équipe qui bosse sur les compilateurs au QG de Google à Mountain View )
( et il parle des applications serveurs, pas des scripts one shots d'administration écrit par un SRE ou ce genre de choses bien sur )
[^] # Re: Widget GtkSwitch (On/Off)
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Y a l’intérêt de reprendre un paradigme connu par ailleurs, donc de réduire la courbe d'apprentissage ( vu que ça réponds comme tu as l'habitude que ça répondes ailleurs ) et la charge cognitive ( vu que tu as pas à choisir entre 2 types de boutons ). On le voit pas parce qu'on a l'habitude, mais je pense pas que ça soit fait "par hasard".
[^] # Re: J'ai rigolé !
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 3.
La dichotomie est un peu violente. Le souci, c'est pas que Canonical décide. Ils sont parfaitement légitimes pour ça.
Mark et son équipe ont une vision de ce qu'ils voudraient faire pour attendre leur but, et ils pensent qu'aller directement sans chercher le consensus parfait préalable est le meilleur moyen de réussir. On peut ne pas être d'accord, mais c'est leur droit.
Ensuite, le souci pour moi, c'est le double discours. C'est Jono bacon qui va tacler RH et Novell dans son livre pour expliquer comment chez Ubuntu, la communauté est au centre, alors qu'au final, pas autant que ça. C'est le fait d'avoir des procédures à 2 vitesses pour l'intégration des fonctions.
Mais ça, c'est aussi du au fait que "communauté" veut dire tout un tas de choses. Communauté d'utilisateurs, de developpeurs ? Avec un pouvoir décisionnel fort, quid du lien hiérarchique entre le sponsor et des membres ?
Comme dire "on va choisir démocratiquement". Oui, mais qui vote, comment ?
Le temps libre n'a rien à voir, il y a des boites qui bossent avec Microsoft pour améliorer Windows par le biais de logiciels externes, car la force du produit est pas autant dans les fonctions de base que dans tout le reste. Il y a un écosystème autour de Windows, il y a des gens qui bossent sur ça, et si les gens n'avaient pas une vision spécifique du mot communauté, j’oserais même dire qu'il y a une communauté dans le sens ou les gens ont en commun quelque chose.
Ensuite, la plupart des gens vont se dire que c'est pas communautaire, car il y a des échanges marchands entre les membres et l’extérieur, ce qui serait faux. Si tu prends l'exemple communautaire par excellence pour tous, Debian, il y a des gens payé pour faire du dev debian. Par exemple, dans mon ancienne boite, notre sysadmin était dev debian sur son temps de travail car notre produit était basé sur debian. L'ancien DPL a participé à des projets de recherches sur Debian, qui ont aidé le projet et la recherche et qui ont permis de pouvoir vivre.
Donc non, la réalité est bien plus nuancé que ce que tu dis.
[^] # Re: J'ai rigolé !
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 9.
les "dégats" sur nautilus comme tu dit, ça vient des développeurs de nautilus, et ils ont la totale légitimité de faire ce qu'ils croient bons pour le logiciel. La d'ou vient leur paye n'a en général rien à voir. Il suffit de voir que c'est exactement le même genre de choses qui ont été reproché au projet gnome lors de la sortie de gnome 2 ( en 2002 ) pour voir que l’hypothèse d'un complot ne repose sur rien, vu que 1) Fedora n'existait pas 2) RHEL non plus 3) les devs Gnome étaient plus payé par Helix code ou Eazel que par RH.
En fait, tu serais surpris de savoir qu'il y a un département QA chez RH pour RHEL. C'est dingue, je sais, la boite peut faire des tests sans les vastes retours de tout les utilisateurs Fedora.
Et en fait, tu pourrais aussi dire pareil sur Debian.
"Quand le machin a atteint le niveau de stabilité suffisant, c'est intégré dans debian stable". Ou pour SLES. Mais bon, la, c'est différent je suppose, car quand tu mets à dispo un truc pour qu'il soit testé pour toi et tout le monde, c'est mal, mais quand tu attends que d'autres fassent les tests pour toi, c'est légitime, et signe d'une indépendance forte ?
Ah oui, tout ces serveurs sous Fedora qui servent à valider les technos RHEL, tout ces serveurs d'applications JBoss sur des Fedora 17, toutes ces installations d'Openshift, d'Ovirt, de spacewalk qui sont massivement déployé sur Fedora afin de tester les outils pour la version entreprise. Comment est ce qu'on fait pour les louper.
Ah oui, parce qu'ils existent qu'à l'état de trace dans l'imagination enfiévré des utilisateurs manichéens qui n'ont pas réfléchi à la question au delà du niveau de réflexion d'un comptoir de bar.
Car bien entendu, par exemple, les devs du kernels, ils ont pas besoin de tests ou de distro qui poussent les dernières versions, ils trouvent les bugs juste en lisant le code source au petit déjeuner, et pis tant pis si ça prends beaucoup plus de temps, on a pas besoin d'avoir des correctifs rapides, car un kernel dont les bugs sont corrigés que 6 mois aprés, ça inspire tellement confiance, et tout le monde voudrait ça .
L'idée même que la coopération soit une des raisons d'être de Fedora n'est pas une idée si saugrenu pourtant. Les gens qui veulent les dernières technologies ( genre avoir ruby 2.0, le dernier gcc ) en bénéficient, les devs qui veulent des retours rapides sur leur soft en bénéficient, et tout le monde y gagne.Même les gens qui veulent des technos éprouvées en bénéficient indirectement, car plus il y a de tests, plus vite les technos sont éprouvés ( car oui, suffit pas de mettre le code sur un ftp pendant 1 an pour qu'ils soient stable, c'est pas une bouteille de vin, ça se fait pas tout seul ).
Le projet cherche à rester proche des projets upstream ( https://fedoraproject.org/wiki/Staying_close_to_upstream_projects ) justement pour que tout le monde puisse y gagner. Le projet ne veux utiliser que du logiciel libre pour justement permettre à tout un chacun de l'utiliser sans risquer un 2eme procès SCO.
Et ce qu'il y a de bien avec les affirmations non fondées sur la relation RH/Fedora, c'est que ça marche quoi que tu fasses. Quand Fedora ne fait pas de concurrence direct à RHEL, alors on va dire que c'est fait exprès pour pas faire d'ombre au part de marché, donc c'est la main mise de RH sur la distro. Et quand Fedora fait concurrence, c'est encore la main mise de RH pour faire des tests et des expérimentations.
Voir mieux, quand on dit qu'il y a pas de preuves, alors c'est bien le signe qu'il y a quelque chose de caché, donc la main mise secrète de la multinationale.
Donc quoi que la communauté décide, et sans avoir le moindre argument, ça va toujours être la main mise du sponsor principale, donc sous entends "mal". Autant directement dire que c'est mal directement sans lien de cause à effet, ça va faire économiser du temps à tout le monde.