la preuve, Canonical a codé des démons qui réimplemente les trucs manquants, cf le début du tableau.
Si demain, les BSD ont un système comme cgroups ( ce qui m'étonnerais, vu que cgroups est déjà mal vu du point de vue de l'API par son mainteneur actuel, alors que je doute que les BSDistes codent ça avant d'avoir vu une ou deux itérations du truc ), alors ils pourront reprendre les unités systemd. Et en fait, même sans avoir ça, un étudiant du google summer of code a réussi à faire un convertisseur pour Debian, donc je me doute bien que si les BSD voulait avoir la compatibilité, ils pourraient. Et si ils ont pas, c'est sans doute que tout le monde s'en fout, ce qui prouve bien qu'on peut se passer de systemd si on veut, tout comme les BSDs se sont passés de upstart, également non portable comme systemd.
1) Non, ce qui tire le marché de linux ce sont les utilisateurs.
Et de ce côté là ubuntu est devant.
Et c'est pour ça que RH fait 1 milliard de chiffres d'affaire, embauche toujours et que Canonical est dans le rouge. Car le marché de Linux est tiré par les utilisateurs ou Ubuntu est devant.
3) Oui, je connais le marché de RH: certif et grand compte (ie banque, assurance, etc.) et probablement les appels d'offres.
Alors c'est pas vraiment que la société défini son marché (cf les rapports de la SEC). Par exemple, RH est sur le stockage (gluster), le cloud (openstack, openshift), la virtualisation (ovirt, kvm, cloudforms), le middleware (jboss) en plus de RHEL.
Et si le futur c'est le cloud, alors RH est le premier contributeur sur openstack, rackstack est un client RH, il y a une expertise interne sur le sujet (kvm, libvirt, ovirt), il y a des produits (cloudforms, intégration d'openstack)
Parce que RH le sait elle commence à tenter de se rapprocher du desktop, sans en faire… (PulseAudio, freedesktop, GNOME 3, Wayland ?)
D'une part, RH fait du desktop sur les stations professionnels (je redonne toujours l'exemple de Pixar car c'est un des rares exemples publiques mais c'est pas le seul). Et d'autre part, c'est pas "tenter de se rapprocher", ça fait des années qu'il y a des gens de RH payés sur les softs desktops.
Mais bon, on en reparleras quand Canonical sera plus en déficit, quand Mandriva sera revenu sur son marché originel et quand Mint gagneras plus qu'une boulangerie de quartier avec ses donations.
RH utilise RHEL 6 pour ses serveurs et que je sache, RHEL6 n'utilise pas systemd, et ne l'utiliseras pas. Il faut attendre RHEL7
Par contre, moi, je fais de la prod, et je pense que lennart a au contraire écouté les admins. Plus besoin de me taper bash pour lancer un truc, y a des directives simples à configurer via un fichier .ini, ce qui est beaucoup plus script friendly les variables bash ( avec tout les cas tordus pour la gestion des guillemets et doubles guillemets, sans compter les usages créatifs de la syntaxe bash pour faire des $() et autre trucs qu'on retrouve parfois), y a des réglages unifiés qui font qu'on peut utiliser les fonctions de Linux sans se prendre la tête ( genre isoler un service du réseau, comme clamav ou spamassassin, le fait de pouvoir faire des instances d'un même service proprement ( genre openvpn, ça règle le souci des softs qui font des trucs dans stderr et dans les logs en mettant tout à un seul endroit.
Et ça aide à régler aussi le fait que tu peux donner à un admin junior la tache d'écrire une unité sans à refaire une imitation du cri d'Edward Munch en lisant le code qu'il a écrit.
Ça pose les bases pour avoir des containers efficaces (virt-sanbox-service), ce qui résous le problème de "je doit faire héberger des tas de trucs en masse, mais j'ai pas le budget pour des tas de machines".
l'employeur a toujours de l'influence sur ses employés
et les clients sur les employeurs, et donc les utilisateurs sur les développements. mais c'est sans doute mal (tm).
Ou alors, c'est le fait que les gens qui payent arrivent à avoir des gens qui codent pour eux indirectement alors que la personne qui ne paye pas et qui ne code pas n'a rien ?
ie, le fait que tout les utilisateurs de logiciels libres sont égaux, mais certains plus que d'autres (ie les devs) ?
Personne n'a ici des intérêts financiers à ce que systemd soit utilisé (et encore moins des distributions comme OpenSuse car c'est la
concurrence qui 'la développé à l'origine)
Au contraire, le fait que ça soit fait par une autre boite, et donc sur les deniers d'un concurrent rends la chose plus intéressante, vu que ça permet de ne pas avoir à faire le travail toi même. Je dirais donc que tout le monde a un intérêt financier à mutualiser entre sociétés et groupes du libre.
(et désolé de sembler te contredire à chaque fois)
Si j'en croit groklaw, il semble que certains attaquent RH pour glusterfs cf http://www.groklaw.net/articlebasic.php?story=20120913073511444 et à vue de nez le truc serait assez vague pour couvrir aussi ceph, par exemple (ceph qui est aussi poussé par Mark Shuttleworth, qui a investi dans inktank après que RH ai racheté Glusterfs)
Tu as des histoires autour de s3tc, ce qui impacte mesa, des drivers, mais aussi de façon surprenante darktable (qui est dans universe sur Ubuntu), cf https://bugzilla.redhat.com/show_bug.cgi?id=972604
Ensuite, il faut voir qu'il s'agit de gestion de risque. Si j'en crois les documents remplis par Red Hat pour la SEC, l'estimation d'une affaire de brevets, c'est de l'ordre de 0.1 à 11 millions de dollars ( cf page 36 du rapport 2010 pour la SEC ). Donc tu sais qu'une boite trop petite ne va pas être attaqué. Mais si tu rentres dans la catégorie "assez grosse pour sortir 1 à 10 millions de dollars sans mourir", alors oui, le risque est la. Par rapport par exemple aux chiffres d'affaires d'une maison d'édition comme Ziff Davis, ça me semble pas irréaliste d'imaginer qu'ils sont vulnérable, par exemple. Mais tu peux aussi imaginer Dell ou un autre OEM.
Mais curieusement, ils se font pas attaqué sur ça, en tout cas pour le moment.
Je passerais sur le grossier « c'est comme dire que sans firewall on est plus en sûreté », non, c'est pas comme.
ben si tu retires selinux, les applications ont des droits en plus, tout comme le fait de retirer le firewall fait que tes applications ont des droits en plus.
Ensuite, si tu part du principe que le soft est vérolé sans raison, ben le soft est vérolé. Mais tu ne supposes pas que tout est vérolé. En pratique, tu supposes même que la plupart des outils sont raisonnablement non vérolés, et tu tires de la une analyse risque/bénéfice.
Le bénéfice de selinux est tangible, tu peux voir que ça bloque une partie des exploits (http://danwalsh.livejournal.com/10131.html), même si ça bloque pas tout comme le rappelle avec aigreur un des dev de grsec ( qu'on a moins entendu le jour ou grsec n'a pas bloqué un truc).
Le risque de faire tourner selinux serait soit que le système de protection ne soit pas étanche à dessein, soit d'avoir une faille bien caché depuis des années. Le 1 serait facheux, mais la solution n'est pas de pas l'utiliser. Personne ne dit que selinux bloque tout, plutôt le contraire. C'est pas parce que tu as selinux que tu peux avoir root/root comme login/mdp.
Si le plus gros problème de quelques chose est de pas être efficace dans certain cas, alors le retirer ne va pas améliorer la chose.
Et si le risque est "y a une faille caché", il faut bien voir qu'il y a déjà des failles ailleurs dans Linux et que personne ne crie à cause de ça. Et de surcroit, mettre une faille visible de tous dans un noyau au code source ouvert, quand tu sais que tout le monde relie ton code 15 fois, c'est un pari audacieux.
Et je commence à me demander si la NSA n'a pas fait exprès de poster ça de façon visible afin de s'assurer que tout le monde relise le code afin de pouvoir avoir une vérification gratos de son code en vue de l'utiliser pour protéger les SI du gouvernement US. Il faut pas déconner, à la NSA comme partout, les budgets coulent pas à flots, ça reste une administration avec sans doute la même lourdeur et lenteur administrative. Si une méthode d'amélioration de l'efficacité de la bureaucratie avait été mise au point, le reste du gouvernement en bénéficierait depuis longtemps.
La stratégie de RH sera d'intégrer systemd de manière à ce qu'il soit incontournable: PulseAudio est la solution pour ça.
Le mainteneur actuel de Pulseaudio, David Henningsson, bosse chez Canonical
Et je vois pas grand chose de RH sur http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/4.0/
Je vois du Intel, du BMW, du Collabora mais pas de gens de RH dans les plus gros committers.
Mais bon, prenons un autre soft au hasard, omni présent ou RH a des codeurs. Tiens, on va dire que gcc va intégrer un demon de build réseau basé sur systemd, et paf. Ou rajouter ça dans openjdk, tout le monde utilise java.
Ils ne veulent pas d'upstart parce qu'à ce que j'ai lu, upstart est trop orienté ubuntu au contraire de systemd
Non, parce que l'architecture d'upstart est moins bien.
Upstart est un gestionnaire d’événement, et il utilise ptrace pour suivre les process pour savoir comment les tuer, ce qui pose des tas de souci vis à vis de l'heuristique utilisé pour déterminer qui est le process principal. Systemd utilise cgroups, ce qui est plus propre et rajoute en plus la gestion des ressources. Encore une fois, upstart a été tenté et adopté par RH dans RHEL, et par la communauté Fedora. Et les autres distributions avaient commencé aussi à regarder, avant que systemd n'arrive et que des gens se disent "c'est vachement plus excitant qu'upstart".
Upstart n'a rien de lié spécifiquement à Ubuntu, c'est juste qu'il y a plus que eux et Chromeos qui continuent à s'en servir.
1) De manière générale l'entreprise ne paye pas quelqu'un à temps plein parce que ce n'est pas rentable.
Pourtant, Canonical paye des gens à temps plein sur Ubuntu, RH sur les divers projets, Google, Intel, IBM, Bull, Rackspace, etc, etc.
Ou des startups aussi ( qui ont globalement pas le choix ), des SSII sur drupal, sur spip, etc, etc. Des boites qui contribuent sur pgsql en france.
Y a des tonnes de contre exemples.
2) Lorsque FB, cas particulier, embauche quelqu'un, ce n'est pas ad vitam eternam non plus.
oui, à un moment, y a l'age de la retraite.
3) Mercurial étant un produit indispensable, je trouve plutôt logique ce que fait FB, car c'est rentable POUR EUX, pas
nécessairement pour les autres.
FB ne va pas financer git (Linus)
c'est plus Linux qui bosse sur Git, faut se tenir au courant.
ou svn (Apache ?), mais un indépendant.
Apache, c'est une fondation, si tu veux des gens qui codent, il faut bien avoir les devs payés ailleurs, ou payé la dite fondation.
5) Si je suis ton exemple, je peux aussi parler…
Je vois pas en quoi c'est suivre mon exemple que de sortir un truc qui n'a rien à voir. Par contre, c'est suivre ton comportement habituel. Donc si tu suis ton propre exemple, tu peux parler de n'importe quoi sans lien logique que ça te choque, ça rendre dans tes capacités sans souci.
Tiens mais RH n'a aucun projet dessus car c'est un marché ultra-concurrentiel ou ils n'ont aucune expérience et de personnes qualifiées
dans le milieu.
C'est peu connu, mais voila, l'équipe ARM de Fedora, c'est aussi des gens qui font ce genre de choses. Donc on peut supposer que si l'avenir, c'est les ordiphones, il y a sans doute une partie de l'avenir qui va tomber sur les gens qui emploient des codeurs de gcc, gdb, du kernel et sur arm ou autres.
On va gérer les services à la windows. "y'a qu'a relancer, pas besoin de savoir pourquoi ca crash et essayer de gérer ce problème avant".
pour des trucs critiques comme openssh, je préfère quand même qu'il se relance tout seul. Systemd garde le core bien au chaud, si je me sens l'envie de chercher la cause en détail. Et si ça se gauffre pendant la nuit, j'aime avoir le moins de downtime possible, parfois, ça coute de l'argent, ça rentre dans tes objectifs, etc.
2) RH a des adversaires particulier comme Hupstream (debian, mageia, etc.), mais il est encore petit.
Ah ah ah. Arrête de parler de ce que tu ne connais pas. Y a autant de salles de réunions dans les bureau du bureau français de RH que de salariés de Hupstream dans le monde ( soit 6 personnes, voir 7 ), pour te donner une idée des écarts de moyens entre les 2.
Et au moins, *buntu reste légale dans les pays où les brevets logiciels sont reconnus (comme les États Unis).
Si tu fait abstraction du fait que le paquet openssl active le support des courbes elliptiques (ECDSA) ( https://bugzilla.redhat.com/show_bug.cgi?id=319901 ) alors que c'est une fonctionnalité jugé problématique du point de vue des brevets logiciels.
Canonical n'a pas la même R&D que Apple, et ne peux pas se permettre de devoir faire ses propres drivers si jamais il y a besoin. Bien que Canonical contribues upstream ( sur pulseaudio, twisted, mailman pour ne citer que 3 exemples ), le kernel n'est pas dans la liste. Donc sauf à imaginer que Canonical recrute beaucoup de codeurs kernels, ils sont dépendant du travail des autres pour les couches basses.
Et puis le support des pilotes proprios, c'est pas encore ça. Si Canonical part sur mir, c'est aussi pour aller à coté des kernels android, pour simplifier la vie des OEMs pour les téléphones. Passer sur BSD ferait perdre tout ça.
On verra quand ça va pêter … C'est pas souvent que ça arrive mais c'est dans ces cas là que tu apprécies les choses simples.
avec les scripts bash, tu as pas besoin d'attendre que ça pete pour être déjà en train d'avoir des emmerdes. Les scripts de 50 lignes pour charger ton service, ça n'a rien de simple ( et encore, je parle pas des horreurs que j'ai vu par des OEMs sur HP-UX, car la production, c'est ça aussi, des vieux trucs moisis ). Gérer des merdes comme bind ( avec rdnc et le fait de devoir faire un sleep parce que tu peux pas savoir de façon race-free que bind est vraiment arrêter ), ça n'a rien de simple.
je peux comprendre que c'est familier, que c'est rassurant, que systemd force à apprendre des nouveaux trucs, voir qu'il y a des nouveaux bugs, mais le système d'init en bash n'a rien de simple. Il est pauvre en fonction, il est lent, il requiert de connaitre un langage de merde qui n'a rien de prévu pour faire du développement sérieux, et un langage des plus non intuitif sur des points comme le calcul décimal, les sockets ( via /dev/tcp ), etc.
autant de doute vis à vis des constructeurs qui installent par défaut un Windows ?
ben faut croire que windows réponds aux besoins des clients de microsoft. Les OEMs ont la certifs, des drivers, et ont l'argument de vente d'avoir une logithèque énorme. Et les clients des OEMs ont pareil, l'accès à la logithèque.
Si la plupart des gens voulaient vraiment du Linux, quelqu'un le proposerait et se ferait des couilles en or. C'est pas faute d'avoir tenté plus d'une fois ( mndrake, suse, RH, lycrosi, corel linux, mint, Ubuntu, entre autres ), et d'avoir à chaque fois fait un pétard mouillé.
Qu'est-ce qui empêche les autres distribs de l'adopter ?
Canonical pense que pour gagner des parts de marché, il faut faire preuve d'agilité et de vitesse. C'est une position comme une autre, ç'est pas déconnant. Ensuite, le souci, c'est que ça implique plusieurs choses :
- des hacks parfois court termes plus que des corrections propres long termes. par exemple, qui se souviens de la controverse autour de xsplash et plymouth.
- ne pas hésiter à refaire tout de 0 si besoin. Il suffit de voir justement l'histoire d'unity, ou les bases sont passés de gtk à qt à compiz ( ou dans un autre ordre ).
- ne pas hésiter à corriger rapidement sur sa distro que de négocier avec upstream. un exemple d'école, c'est android et le kernel, genre les waveocks. Dans le même genre, ubuntu à tendance à patcher pour le support des indicateurs, et tout le monde ne voit pas d'un bon oeil que de rajouter des patchs pour ça un peu partout.
Et on pourrait laisser le bénéfice du doute à Canonical, mais c'est exactement pour ça que Unity est dispo officiellement dans quasiment aucune distro autre que downstream de ubuntu. Debian n'a pas le paquet, la communauté Fedora a tenté 2 fois de l'avoir, etc.
on va pas reprocher à Canonical de foncer, de coder. Ou du moins, moi, je reproche pas ça. Au contraire, qu'ils foncent, qu'ils arrivent à gagner du pognon et à devenir une boite à l'équilibre, pour le bien du libre et de ses salariés.
Par contre, faire ça et se vanter de "bosser upstream" (cf blog de Jono bacon : http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gnome-contributions/ ou il liste tout les softs 'upstreams' qui tourne que sur Unity et qu'ils ont commencés ) et de "consulter la communauté", et de "bosser de maniére ouverte" alors qu'il y a des trucs fait en secret.
Encore une fois, y a rien de mal à tout ça. Si Canonical pense que c'est valable pour faire vivre la boite, parfait, j'ai pas les infos pour juger (autre que "pour le moment, ça marche pas"). Mais c'est le contraste entre ce qu'ils disent et ce qu'ils font en pratique qui énervent une part des gens qui expriment des critiques sur Canonical.
Parce que moi, sur une de mes machines, j’ai un besoin qui est « traitement complexe dans rc.local », et je peux te dire que systemd se
vautre lamentablement là dessus.
Je doute que ton besoin soit stricto sensu "je doit lancer ça dans rc.local". Mais "je doit lancer ça au démarrage". Donc je pense que faire une unité systemd devrait marcher. Quand à dire "il se vautre la dessus", sans plus d'info, c'est difficile de voir si c'est un bug ou une erreur de ta part ( et ça peut être les 2, une doc pas assez claire qui fait que tu fait une erreur parce que ça réagit pas comme tu crois ).
Si le souci est que tu lances une tache longue et que systemd tues la tache, je pense qu'une unité de type "oneshot" est exactement ce que tu veux. Mais sur ma machine, c'est déjà comme ça que rc.local est lancé (et sans timeout). Peut être que le souci, c'est d'être isolé de façon plus drastique qu'avant, c'est difficile de t'aider sans plus d'info.
Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.
Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )
Si c'est l'init, on lui demande juste de démarrer ce qu'il faut, et d'arrêter ce qu'il faut.
/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).
Je veux bien croire que les gens veulent un init minimal, mais ça fait des années que /sbin/init n'est pas aussi minimal et fait des trucs qui ne le regarde pas ( exemple, powerwait, powerfail ) , et bien sur, personne n'a jamais rien dit ni trouver ça anormal. ( et je parle pas de "refaire sa propre implémentation d'un système de message" via un pipe dans /dev, ce qui n'a rien à faire la d'après la FHS, sauf si ça rentre dans "special file" et ça me semble être vraiment tirer par les cheveux comme raison, car "un pipe pour communiquer avec l'userspace", ça n'a rien de spécial ).
je suis favorable à la réutilisation, mais pour un truc de bas niveau comme l'init, je préfère qu'il ne dépende pas des bugs des autres …
en pratique, il va dépendre des bugs dans le kernel, dans le bios, et dans la libc. Et des bugs dans les compilos, bien sur. Soit une somme de code bien plus importante que tout ce que systemd va tirer.
Et toutes les 6 mn il va devoir réitérer son exploit de 0. A mon avis il va être vite dégoûté…
Pas vraiment. quand tu sais que pour exploiter une race condition, il faut faire parfois des tas d'essais, ou parfois pour contourner les canries, pour deviner une adresse, etc, les attaquants ont appris à faire ce qu'il faut, à savoir, des boucles. Si tu rebootes tout les 6 minutes, ç'est pas forcément grave. Sur un téléphone, il faut sans doute moins de 6 minutes pour te faire appeler un numero surtaxé à l'étranger, rendant rentable la chose. Et sur un pc, bah, 6 minutes et ensuite, il reste plus de trace, ça me semble être un bon deal. Voir pire, utiliser chaque cpu pour attaquer les 2 autres pour rester en permanence.
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 6.
Il a dit "le code est fortement lié à Linux, on utilise des tas d'api spécifique du kernel, mais on vous promets de pas toucher à ces APIs, si vous voulez, vous pouvez le refaire", et la liste des APIs est documenté, ainsi que leur niveau de stabilité : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
la preuve, Canonical a codé des démons qui réimplemente les trucs manquants, cf le début du tableau.
Si demain, les BSD ont un système comme cgroups ( ce qui m'étonnerais, vu que cgroups est déjà mal vu du point de vue de l'API par son mainteneur actuel, alors que je doute que les BSDistes codent ça avant d'avoir vu une ou deux itérations du truc ), alors ils pourront reprendre les unités systemd. Et en fait, même sans avoir ça, un étudiant du google summer of code a réussi à faire un convertisseur pour Debian, donc je me doute bien que si les BSD voulait avoir la compatibilité, ils pourraient. Et si ils ont pas, c'est sans doute que tout le monde s'en fout, ce qui prouve bien qu'on peut se passer de systemd si on veut, tout comme les BSDs se sont passés de upstart, également non portable comme systemd.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Et c'est pour ça que RH fait 1 milliard de chiffres d'affaire, embauche toujours et que Canonical est dans le rouge. Car le marché de Linux est tiré par les utilisateurs ou Ubuntu est devant.
Alors c'est pas vraiment que la société défini son marché (cf les rapports de la SEC). Par exemple, RH est sur le stockage (gluster), le cloud (openstack, openshift), la virtualisation (ovirt, kvm, cloudforms), le middleware (jboss) en plus de RHEL.
Et si le futur c'est le cloud, alors RH est le premier contributeur sur openstack, rackstack est un client RH, il y a une expertise interne sur le sujet (kvm, libvirt, ovirt), il y a des produits (cloudforms, intégration d'openstack)
D'une part, RH fait du desktop sur les stations professionnels (je redonne toujours l'exemple de Pixar car c'est un des rares exemples publiques mais c'est pas le seul). Et d'autre part, c'est pas "tenter de se rapprocher", ça fait des années qu'il y a des gens de RH payés sur les softs desktops.
Mais bon, on en reparleras quand Canonical sera plus en déficit, quand Mandriva sera revenu sur son marché originel et quand Mint gagneras plus qu'une boulangerie de quartier avec ses donations.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
RH utilise RHEL 6 pour ses serveurs et que je sache, RHEL6 n'utilise pas systemd, et ne l'utiliseras pas. Il faut attendre RHEL7
Par contre, moi, je fais de la prod, et je pense que lennart a au contraire écouté les admins. Plus besoin de me taper bash pour lancer un truc, y a des directives simples à configurer via un fichier .ini, ce qui est beaucoup plus script friendly les variables bash ( avec tout les cas tordus pour la gestion des guillemets et doubles guillemets, sans compter les usages créatifs de la syntaxe bash pour faire des $() et autre trucs qu'on retrouve parfois), y a des réglages unifiés qui font qu'on peut utiliser les fonctions de Linux sans se prendre la tête ( genre isoler un service du réseau, comme clamav ou spamassassin, le fait de pouvoir faire des instances d'un même service proprement ( genre openvpn, ça règle le souci des softs qui font des trucs dans stderr et dans les logs en mettant tout à un seul endroit.
Et ça aide à régler aussi le fait que tu peux donner à un admin junior la tache d'écrire une unité sans à refaire une imitation du cri d'Edward Munch en lisant le code qu'il a écrit.
Ça pose les bases pour avoir des containers efficaces (virt-sanbox-service), ce qui résous le problème de "je doit faire héberger des tas de trucs en masse, mais j'ai pas le budget pour des tas de machines".
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
et les clients sur les employeurs, et donc les utilisateurs sur les développements. mais c'est sans doute mal (tm).
Ou alors, c'est le fait que les gens qui payent arrivent à avoir des gens qui codent pour eux indirectement alors que la personne qui ne paye pas et qui ne code pas n'a rien ?
ie, le fait que tout les utilisateurs de logiciels libres sont égaux, mais certains plus que d'autres (ie les devs) ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Au contraire, le fait que ça soit fait par une autre boite, et donc sur les deniers d'un concurrent rends la chose plus intéressante, vu que ça permet de ne pas avoir à faire le travail toi même. Je dirais donc que tout le monde a un intérêt financier à mutualiser entre sociétés et groupes du libre.
(et désolé de sembler te contredire à chaque fois)
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Si j'en croit groklaw, il semble que certains attaquent RH pour glusterfs cf http://www.groklaw.net/articlebasic.php?story=20120913073511444 et à vue de nez le truc serait assez vague pour couvrir aussi ceph, par exemple (ceph qui est aussi poussé par Mark Shuttleworth, qui a investi dans inktank après que RH ai racheté Glusterfs)
Tu as des histoires autour de s3tc, ce qui impacte mesa, des drivers, mais aussi de façon surprenante darktable (qui est dans universe sur Ubuntu), cf https://bugzilla.redhat.com/show_bug.cgi?id=972604
Ensuite, il faut voir qu'il s'agit de gestion de risque. Si j'en crois les documents remplis par Red Hat pour la SEC, l'estimation d'une affaire de brevets, c'est de l'ordre de 0.1 à 11 millions de dollars ( cf page 36 du rapport 2010 pour la SEC ). Donc tu sais qu'une boite trop petite ne va pas être attaqué. Mais si tu rentres dans la catégorie "assez grosse pour sortir 1 à 10 millions de dollars sans mourir", alors oui, le risque est la. Par rapport par exemple aux chiffres d'affaires d'une maison d'édition comme Ziff Davis, ça me semble pas irréaliste d'imaginer qu'ils sont vulnérable, par exemple. Mais tu peux aussi imaginer Dell ou un autre OEM.
Mais curieusement, ils se font pas attaqué sur ça, en tout cas pour le moment.
[^] # Re: Deux idées
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 2.
ben si tu retires selinux, les applications ont des droits en plus, tout comme le fait de retirer le firewall fait que tes applications ont des droits en plus.
Ensuite, si tu part du principe que le soft est vérolé sans raison, ben le soft est vérolé. Mais tu ne supposes pas que tout est vérolé. En pratique, tu supposes même que la plupart des outils sont raisonnablement non vérolés, et tu tires de la une analyse risque/bénéfice.
Le bénéfice de selinux est tangible, tu peux voir que ça bloque une partie des exploits (http://danwalsh.livejournal.com/10131.html), même si ça bloque pas tout comme le rappelle avec aigreur un des dev de grsec ( qu'on a moins entendu le jour ou grsec n'a pas bloqué un truc).
Le risque de faire tourner selinux serait soit que le système de protection ne soit pas étanche à dessein, soit d'avoir une faille bien caché depuis des années. Le 1 serait facheux, mais la solution n'est pas de pas l'utiliser. Personne ne dit que selinux bloque tout, plutôt le contraire. C'est pas parce que tu as selinux que tu peux avoir root/root comme login/mdp.
Si le plus gros problème de quelques chose est de pas être efficace dans certain cas, alors le retirer ne va pas améliorer la chose.
Et si le risque est "y a une faille caché", il faut bien voir qu'il y a déjà des failles ailleurs dans Linux et que personne ne crie à cause de ça. Et de surcroit, mettre une faille visible de tous dans un noyau au code source ouvert, quand tu sais que tout le monde relie ton code 15 fois, c'est un pari audacieux.
Et je commence à me demander si la NSA n'a pas fait exprès de poster ça de façon visible afin de s'assurer que tout le monde relise le code afin de pouvoir avoir une vérification gratos de son code en vue de l'utiliser pour protéger les SI du gouvernement US. Il faut pas déconner, à la NSA comme partout, les budgets coulent pas à flots, ça reste une administration avec sans doute la même lourdeur et lenteur administrative. Si une méthode d'amélioration de l'efficacité de la bureaucratie avait été mise au point, le reste du gouvernement en bénéficierait depuis longtemps.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Le mainteneur actuel de Pulseaudio, David Henningsson, bosse chez Canonical
Et je vois pas grand chose de RH sur http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/4.0/
Je vois du Intel, du BMW, du Collabora mais pas de gens de RH dans les plus gros committers.
Mais bon, prenons un autre soft au hasard, omni présent ou RH a des codeurs. Tiens, on va dire que gcc va intégrer un demon de build réseau basé sur systemd, et paf. Ou rajouter ça dans openjdk, tout le monde utilise java.
Non, parce que l'architecture d'upstart est moins bien.
Upstart est un gestionnaire d’événement, et il utilise ptrace pour suivre les process pour savoir comment les tuer, ce qui pose des tas de souci vis à vis de l'heuristique utilisé pour déterminer qui est le process principal. Systemd utilise cgroups, ce qui est plus propre et rajoute en plus la gestion des ressources. Encore une fois, upstart a été tenté et adopté par RH dans RHEL, et par la communauté Fedora. Et les autres distributions avaient commencé aussi à regarder, avant que systemd n'arrive et que des gens se disent "c'est vachement plus excitant qu'upstart".
Upstart n'a rien de lié spécifiquement à Ubuntu, c'est juste qu'il y a plus que eux et Chromeos qui continuent à s'en servir.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Pourtant, Canonical paye des gens à temps plein sur Ubuntu, RH sur les divers projets, Google, Intel, IBM, Bull, Rackspace, etc, etc.
Ou des startups aussi ( qui ont globalement pas le choix ), des SSII sur drupal, sur spip, etc, etc. Des boites qui contribuent sur pgsql en france.
Y a des tonnes de contre exemples.
oui, à un moment, y a l'age de la retraite.
c'est plus Linux qui bosse sur Git, faut se tenir au courant.
Apache, c'est une fondation, si tu veux des gens qui codent, il faut bien avoir les devs payés ailleurs, ou payé la dite fondation.
Je vois pas en quoi c'est suivre mon exemple que de sortir un truc qui n'a rien à voir. Par contre, c'est suivre ton comportement habituel. Donc si tu suis ton propre exemple, tu peux parler de n'importe quoi sans lien logique que ça te choque, ça rendre dans tes capacités sans souci.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Et j'ai oublié aussi ça :
Il y a une activité autour de l'embarqué :
https://www.redhat.com/services/custom/
C'est peu connu, mais voila, l'équipe ARM de Fedora, c'est aussi des gens qui font ce genre de choses. Donc on peut supposer que si l'avenir, c'est les ordiphones, il y a sans doute une partie de l'avenir qui va tomber sur les gens qui emploient des codeurs de gcc, gdb, du kernel et sur arm ou autres.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Non, c'est une cible :
cf https://fr.redhat.com/products/enterprise-linux/desktop/ ( ie, y a un produit )
ou http://www.muktware.com/5536/pixar-animation-studios-uses-red-hat-enterprise-linux et il y a des clients
Au passage, ça explique aussi cette photo :
https://lh4.googleusercontent.com/-cGfmbqOglck/Tm7VnKNAU1I/AAAAAAAAAao/_kRn8RtRFdM/w871-h653-no/11+-+1 ou on voit Lennart visiblement chez Pixar, Lennart à l'époque dans l'équipe "desktop" chez RH, cf https://archive.fosdem.org/2011/interview/lennart-poettering
Mais oui, c'est pas la priorité, et pas vraiment l'activité la plus connu de la société.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Bah, il y a des partenaires chez les ISV :
http://www.canonical.com/partners/isv
et des certifications hardwares :
http://www.canonical.com/engineering-services/certification
En fait, ils ont même du support et une assurance légale (même si j'ai des gros doutes sur elle) :
http://www.ubuntu.com/management
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Ou il est possible que l'auteur de upstart bosse dans l'équipe de chrome et qu'il pousse sa solution ?
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 6.
pour des trucs critiques comme openssh, je préfère quand même qu'il se relance tout seul. Systemd garde le core bien au chaud, si je me sens l'envie de chercher la cause en détail. Et si ça se gauffre pendant la nuit, j'aime avoir le moins de downtime possible, parfois, ça coute de l'argent, ça rentre dans tes objectifs, etc.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
ou en framebuffer directement. Ou via surfaceflinger. Ou Mir, quand il marcheras :)
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Ah ah ah. Arrête de parler de ce que tu ne connais pas. Y a autant de salles de réunions dans les bureau du bureau français de RH que de salariés de Hupstream dans le monde ( soit 6 personnes, voir 7 ), pour te donner une idée des écarts de moyens entre les 2.
[^] # Re: « Vivent les Logiciels Privateurs ! »
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Si tu fait abstraction du fait que le paquet openssl active le support des courbes elliptiques (ECDSA) ( https://bugzilla.redhat.com/show_bug.cgi?id=319901 ) alors que c'est une fonctionnalité jugé problématique du point de vue des brevets logiciels.
[^] # Re: Java Web Start le fait déjà
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Canonical n'a pas la même R&D que Apple, et ne peux pas se permettre de devoir faire ses propres drivers si jamais il y a besoin. Bien que Canonical contribues upstream ( sur pulseaudio, twisted, mailman pour ne citer que 3 exemples ), le kernel n'est pas dans la liste. Donc sauf à imaginer que Canonical recrute beaucoup de codeurs kernels, ils sont dépendant du travail des autres pour les couches basses.
Et puis le support des pilotes proprios, c'est pas encore ça. Si Canonical part sur mir, c'est aussi pour aller à coté des kernels android, pour simplifier la vie des OEMs pour les téléphones. Passer sur BSD ferait perdre tout ça.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
avec les scripts bash, tu as pas besoin d'attendre que ça pete pour être déjà en train d'avoir des emmerdes. Les scripts de 50 lignes pour charger ton service, ça n'a rien de simple ( et encore, je parle pas des horreurs que j'ai vu par des OEMs sur HP-UX, car la production, c'est ça aussi, des vieux trucs moisis ). Gérer des merdes comme bind ( avec rdnc et le fait de devoir faire un sleep parce que tu peux pas savoir de façon race-free que bind est vraiment arrêter ), ça n'a rien de simple.
je peux comprendre que c'est familier, que c'est rassurant, que systemd force à apprendre des nouveaux trucs, voir qu'il y a des nouveaux bugs, mais le système d'init en bash n'a rien de simple. Il est pauvre en fonction, il est lent, il requiert de connaitre un langage de merde qui n'a rien de prévu pour faire du développement sérieux, et un langage des plus non intuitif sur des points comme le calcul décimal, les sockets ( via /dev/tcp ), etc.
ben faut croire que windows réponds aux besoins des clients de microsoft. Les OEMs ont la certifs, des drivers, et ont l'argument de vente d'avoir une logithèque énorme. Et les clients des OEMs ont pareil, l'accès à la logithèque.
Si la plupart des gens voulaient vraiment du Linux, quelqu'un le proposerait et se ferait des couilles en or. C'est pas faute d'avoir tenté plus d'une fois ( mndrake, suse, RH, lycrosi, corel linux, mint, Ubuntu, entre autres ), et d'avoir à chaque fois fait un pétard mouillé.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
c'est libre.
Canonical pense que pour gagner des parts de marché, il faut faire preuve d'agilité et de vitesse. C'est une position comme une autre, ç'est pas déconnant. Ensuite, le souci, c'est que ça implique plusieurs choses :
- des hacks parfois court termes plus que des corrections propres long termes. par exemple, qui se souviens de la controverse autour de xsplash et plymouth.
- ne pas hésiter à refaire tout de 0 si besoin. Il suffit de voir justement l'histoire d'unity, ou les bases sont passés de gtk à qt à compiz ( ou dans un autre ordre ).
- ne pas hésiter à corriger rapidement sur sa distro que de négocier avec upstream. un exemple d'école, c'est android et le kernel, genre les waveocks. Dans le même genre, ubuntu à tendance à patcher pour le support des indicateurs, et tout le monde ne voit pas d'un bon oeil que de rajouter des patchs pour ça un peu partout.
Et on pourrait laisser le bénéfice du doute à Canonical, mais c'est exactement pour ça que Unity est dispo officiellement dans quasiment aucune distro autre que downstream de ubuntu. Debian n'a pas le paquet, la communauté Fedora a tenté 2 fois de l'avoir, etc.
on va pas reprocher à Canonical de foncer, de coder. Ou du moins, moi, je reproche pas ça. Au contraire, qu'ils foncent, qu'ils arrivent à gagner du pognon et à devenir une boite à l'équilibre, pour le bien du libre et de ses salariés.
Par contre, faire ça et se vanter de "bosser upstream" (cf blog de Jono bacon : http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gnome-contributions/ ou il liste tout les softs 'upstreams' qui tourne que sur Unity et qu'ils ont commencés ) et de "consulter la communauté", et de "bosser de maniére ouverte" alors qu'il y a des trucs fait en secret.
Encore une fois, y a rien de mal à tout ça. Si Canonical pense que c'est valable pour faire vivre la boite, parfait, j'ai pas les infos pour juger (autre que "pour le moment, ça marche pas"). Mais c'est le contraste entre ce qu'ils disent et ce qu'ils font en pratique qui énervent une part des gens qui expriment des critiques sur Canonical.
[^] # Re: De l'influence de l'employeur.
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Foutaises.
Facebook paye le développeur principal de mercurial pour bosser sur mercurial à temps plein. Et va bientôt en payer un 2eme.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Je doute que ton besoin soit stricto sensu "je doit lancer ça dans rc.local". Mais "je doit lancer ça au démarrage". Donc je pense que faire une unité systemd devrait marcher. Quand à dire "il se vautre la dessus", sans plus d'info, c'est difficile de voir si c'est un bug ou une erreur de ta part ( et ça peut être les 2, une doc pas assez claire qui fait que tu fait une erreur parce que ça réagit pas comme tu crois ).
Si le souci est que tu lances une tache longue et que systemd tues la tache, je pense qu'une unité de type "oneshot" est exactement ce que tu veux. Mais sur ma machine, c'est déjà comme ça que rc.local est lancé (et sans timeout). Peut être que le souci, c'est d'être isolé de façon plus drastique qu'avant, c'est difficile de t'aider sans plus d'info.
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 7.
Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.
Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )
/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).
Je veux bien croire que les gens veulent un init minimal, mais ça fait des années que /sbin/init n'est pas aussi minimal et fait des trucs qui ne le regarde pas ( exemple, powerwait, powerfail ) , et bien sur, personne n'a jamais rien dit ni trouver ça anormal. ( et je parle pas de "refaire sa propre implémentation d'un système de message" via un pipe dans /dev, ce qui n'a rien à faire la d'après la FHS, sauf si ça rentre dans "special file" et ça me semble être vraiment tirer par les cheveux comme raison, car "un pipe pour communiquer avec l'userspace", ça n'a rien de spécial ).
[^] # Re: C'est plus facile de travailler salement…
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 7.
en pratique, il va dépendre des bugs dans le kernel, dans le bios, et dans la libc. Et des bugs dans les compilos, bien sur. Soit une somme de code bien plus importante que tout ce que systemd va tirer.
[^] # Re: Miam
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 4.
Pas vraiment. quand tu sais que pour exploiter une race condition, il faut faire parfois des tas d'essais, ou parfois pour contourner les canries, pour deviner une adresse, etc, les attaquants ont appris à faire ce qu'il faut, à savoir, des boucles. Si tu rebootes tout les 6 minutes, ç'est pas forcément grave. Sur un téléphone, il faut sans doute moins de 6 minutes pour te faire appeler un numero surtaxé à l'étranger, rendant rentable la chose. Et sur un pc, bah, 6 minutes et ensuite, il reste plus de trace, ça me semble être un bon deal. Voir pire, utiliser chaque cpu pour attaquer les 2 autres pour rester en permanence.
Donc le schema n'a de sécurisé que le fait qu'il soit inhabituel et non courant. Et on peut dire autant de "mettre ton repertoire windows sur D:/win32", qui arrète (ou du moins à l'époque, il y a 10 ans) une bonne part des malwares qui hardcodent des chemins.