C'est une question de leadership, s'il n'y a pas d'alternative ou que personne n'imagine te remettre en cause alors tu peut te permettre des
dérapages et autre sans perdre tout d'un coup. Pour Linus personne n'imagine sereinement reprendre ce qu'il fait, il est le seul légitime
actuel.
En même temps, le noyau est un logiciel les plus forkés. Toute les distros ont des patches qui changent le comportement, certaines dépendent même de module qui n'ont pas été admis upstream ( genre les livecds ), d'autres font leur beurre sur ça ( genre openvz ), voir rajoute des API qui font des noyaux impacompatible ( khof android khof )
Je vais pas défendre Ulrich Drepper car je pense qu'il avait un comportement de merde, mais on a évité le même genre de souci sur la glibc en partie grâce à lui.
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 )
[^] # Re: artillerie
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 2.
C'était pas non plus ultra rapide, la virtualisation sans instruction prévu pour. En tout cas sur qemu et bochs à l'époque.
[^] # Re: Conservatisme
Posté par Misc (site web personnel) . En réponse à la dépêche Debian : Épisode VII. Évalué à 5.
En même temps, le noyau est un logiciel les plus forkés. Toute les distros ont des patches qui changent le comportement, certaines dépendent même de module qui n'ont pas été admis upstream ( genre les livecds ), d'autres font leur beurre sur ça ( genre openvz ), voir rajoute des API qui font des noyaux impacompatible ( khof android khof )
Je vais pas défendre Ulrich Drepper car je pense qu'il avait un comportement de merde, mais on a évité le même genre de souci sur la glibc en partie grâce à lui.
[^] # Re: Conservatisme
Posté par Misc (site web personnel) . En réponse à la dépêche Debian : Épisode VII. Évalué à 2.
s/utilisateurs/empaqueteurs/
la plupart des utilisateurs savent à peine que la glibc existe.
( et puis, en matière de tête de lard, y a linus, y a theo de raadt, mais bon, pour eux, c'est normal d'être colérique alors on accepte )
[^] # 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 )