Systemd a plein de switch pour son script configure. Et d’après les archives, le projet accepte assez facilement ce qui permet de désactiver certains requirements comme par exemple, selinux, pam, gcrypt, etc.
Ceci dit, de ce que je lit du code, c'est systemd qui va demander à monter de force 4/5 fs ( cf ./src/core/mount-setup.c tableau mount_table ), et qu'en effet, le logiciel requiert d'avoir /dev/ en devtmpfs. Je suis pas assez expert pour savoir si ça fait plus qu'un simple tmpfs, mais c'est vrai que c'est discutable, même si je peux comprendre l'envie de pas avoir des milliers de cas au vue de tout ce que le noyau supporte ou pas.
Ensuite, oui, le fait de dépendre d'un certain nombre d'option noyau est gênante. Par exemple, feu mes 2 RPS n'avaient pas de support de cgroups, j'ai jamais pu mettre à jour la mageia dessus. Et c'est le même souci que j'ai avec divers appareils embarqués ( téléphone, routeur ) avec des pilotes proprios ou des patchs qui sont pas upstreams dans le kernel, je peux pas mettre à jour, ou mettre à jour, c'est chiant.
Systemd, de part sa place centrale, requiert quand même un minimum d'intégration et de travail, et du coup, tu peux pas juste "je boote avec n'importe ou et ça passe" :/
Personne n'a pensé que SVN aurait des concurrents sérieux…
Perforce avait une bonne part des parts de marché. Google est parti sur perforce tout au début et il y a en ce moment une migration lente sur les dépots internes vers git ( en ne faisant que des dépots git pour les nouveaux projets ), Perl a longtemps continué à utilisé perforce, freebsd aussi. Svn avait des concurrents sérieux depuis le début. Et bitkeeper est plus vieux que subversion de quelques mois, donc même le concept de Subversion n'était pas le plus novateur à l'époque. Avant git/hg, tu as eu tla, dont l'idée était séduisante, mais l’implémentation catastrophique.
Git est arrivé et n'a pas apparemment de plus pour une entreprise.
Sauf que Kernel.org a décidé de s'en servir…
Cette pub involontaire a permis à git de se faire connaître.
Git a des avantages pour une entreprise.
D'une part, git a des avantages vis à vis de svn sur le point de vue techniques. Il est plus rapide, permet de faire des git bisect efficaces, ce qui permet de chercher des bugs de façon plus rapide.
Ensuite, le fait que tout clone d'un dépôt git soit un clone complet permet de régler des souis d'ordre opérationnel, comme le fait d'avoir une liaison lente dans certains pays vis à vis de l'Europe. Exemple, le brésil, l'australie ont des liens internets limités. Et si donc tu as des bureaux la bas, pouvoir faire un miroir complet sans magouille est un avantage. ( ie, miroir en lecture ecriture ).
Ensuite, non, une entreprise qui développe a autant besoin de pouvoir faire des branches qu'un groupe comme kernel.org. Si tu fait un site de ecommerce, tu as ta version en production, ta version en dev, etc, et tu fait passer les commits de façon fluides d'un depot à l'autre. Faire des merges sous svn, c'est pourri, avec git, ça passe correctement.
D'ailleurs, la preuve que git apporte des choses, c'est qu'il y a plein de boites qui utilisent git. C'est que Google lache perforce pour git.
Et ensuite, git a été écrit par Linus Torvalds car les outils existants n'étaient pas adaptés. Donc c'est pas "kernel.org a fait de la pub involontaire". C'était très volontaire, d'une part, et avant, Linus utilisait bitkeeper, qui n'a pas lui pris le monde d'assaut, prouvant bien que la pub de kernel.org n'est pas une condition suffisante, ou même nécessaire.
Donc oui, git s'est imposé par ses qualités, pas parce que Linus a décidé de l'écrire ou de le faire. Si un outil réponds aux besoins des gens, les gens l'utilisent. Git réponds à ce besoin, c'est utilisé. Systemd réponds, c'est utilisé. Mercurial réponds aussi et permet d’expérimenter autrement, des gens l'utilisent, pareil pour upstart.
"Ce qui n’est pas falsifié, fraudé, de ce qui est loyal, consciencieux sans être de la première qualité. "
j'aurais tendance à dire que mon intervention n'est pas falsifié ou fraudé, donc ça, ça colle
"Qui est conforme à la raison, bienséant, convenable à la profession et à l’âge des personnes. "
j'aurais tendance à ne pas trouver mon intervention contraire à la bienséance, donc pareil, ça colle
"Qui est conforme à la vertu, à la probité, à l’honneur. "
Je ne vois pas en quoi je ne suis pas conforme à la probité ou à l'honneur, donc je pense que ça colle.
"Qui est civil, poli. "
Et comme je vois pas d'impolitesse, je dirait aussi que mes propos sont honnêtes.
Donc non, il n'est pas évident en quoi mes contre exemples ne sont pas honnêtes. Sauf à avoir une définition qui n'est pas la définition couramment admise, ce qui ne serait pas la première fois.
OSEF: ça ne change en rien ce que je dis
ça confirme juste que tu ne sais pas de quoi tu parles et que tes exemples sont pas frais. J'aurais bien dit que ça remets en cause ta crédibilité, mais comme elle est inexistante…
Nous avons sur linuxFR des gens suffisamment intelligent pour comprendre ce que je dis.
Mais c'est dommage ue tu fasses pas partie de ce groupe de gens assez intelligents pour te comprendre.
La fondation apache n'a pas de codeurs employés à temps plein ou de sous traitant. Le travail est fait par des gens externes à la dite fondation, sans avoir de lien financier avec la fondation. Et par fondation, je parle de apache.org, pour être bien clair.
Une des règles pour obtenir l’accès en tant que projet de la fondation, c'est d'avoir des développeurs de plusieurs employeurs différents, afin de s'assurer que le projet est pérenne.
init V et systemd n'ont jamais eu pour but de remplacer LSB ou l'intégration des mainteneurs.
init V non. Par contre, systemd a pour but aussi d'unifier les services entre distributions. Par exemple, en offrant une API documenté pour changer la locale ou le nom d'hote, et pas des détails purement historique comme le fait d'avoir un fichier avec un chemin différent pour le nom d'hôte. De la même façon, un fichier .service va marcher de la même façon partout. un service a besoin de charger un module va pouvoir le faire de la même façon en posant le fichier dans /etc/modules.d/ avec une syntaxe défini.
Et du coup, tu peux pousser ça upstream tout comme tu peux pousser upstream le fichier .desktop pour que tout le monde s'en serve.
tu vas me dire que systemd va deviner tout seul quand le service à gérer est dans /opt plutot que le /usr/ classique ?
Les autotools et grosso modo tout les trucs du monde ont de quoi faire des templates. C'est déja ce qui fait pour les .desktop justement.
Pour les process zombie ok, mais d'un point de vue hierarchique c'est le seul qui peut le faire aussi.
bien sur j'ai jamais dit qu'il n'y avait pas de raison à ça. Juste que l'image d'un init qui lance juste les services est un chouia incomplète, init fait grosso modo 4 fois plus que ça.
sur ctrl+alt+del, et les powerwait/… tu ne peux pas me dire que ça n'a pas de lien avec l'arrêt/démarrage des services, même si je suis
d'accord que d'un point de vue modulaire, ça devrait faire l'objet de services à part.
Mais justement, ça fait déjà l'objet de service à part comme acpid.
Et à ce moment la, se charger de lancer de façon propre un service ( ie, mettre les namespaces si besoin, faire le setuid si besoin ), ça rentre aussi dans l'arrêt/démarrage des services. Mais pourtant, quand systemd le fait, c'est bloated, quand c'est init, ç'est normal.
Ensuite si tu trouves que systemd fait trop, la question est de savoir si le binaire de systemd fait trop, ou si le fait d'avoir tout dans le même git est un souci. Si c'est le second, on te dira que les BSDs font ça aussi, et personne ne trouve que c'est bloated de mettre tout dans un seul cvs/svn. Si c'est le premier, peut être que comme pour l'ancien init, ça a un sens techniquement de faire ça de façon unifié ?
Et quand on voit tout ce que fait le noyau qui peut être fait en userspace ( par exemple, le nat est fait via natd sur FreeBSD en userspace ) et le nombre de gens qui se jette sur le hurd pour aider, j'aurais tendance à dire que "trop faire" n'est pas une si grande tare. Et je peux même pas dire que c'est la personnalité du développeur initial, vu que Linus est vachement moins diplomate que Lennart.
On est jamais trop prudent, suffit juste d'une fuite mémoire, d'une barette de ram défectueuse, ou d'avoir des machines dans des versions de développement, par exemple pour que les gens puissent faire des tests de compilation.
On attend toujours les besoins « modernes » auxquels FreeBSD ne peut pas répondre
Si tu parles de façon général, et sans vouloir dire du mal de FreeBSD, je pense que la pile de virtualisation de l'OS est pas encore mature. Soit tu prends bhyve ( toujours en dev ), soit tu prends VirtualBox ( donc un module externe ).
Pareil, niveau module de sécurité MAC, je pense que FreeBSD est un chouia en retard sur une distribution comme RHEL en terme d'architecutre proche de FLASK, malgré la présence de nombreux modules des plus intéressants (http://www.freebsd.org/doc/en/books/handbook/mac.html) et d'une architecture correct pour ça. Mais c'est pas un besoin "moderne", c'est vrai.
FreeBSD note que son module Fuse n'est pas production ready, (https://wiki.freebsd.org/FuseFilesystem), donc si c'est encore vrai, ça exclue globalement le déploiement de choses comme Ceph ou Glusterfs, qui sont utilisés pour notamment des déploiement d'openstack et ou du big data.
Ensuite, parmi les besoins modernes, je pense qu'il y a des choses comme le fait d'augmenter la densité des containers, en lançant tout à la demande (http://0pointer.de/blog/projects/socket-activated-containers.html). Je ne pense pas que les jails permettent ça pour le moment.
(et ce besoin est directement corrélé avec des outils de PaaS comme Openshift, et le besoin croissant de faire du "self-service" et d'offrir des services aux départements de ta société.
Et je pense pas que les devs de FreeBSD soit des abrutis de pas avoir ça, c'est juste une question de ressources. On voit bien qu'il y a chaque fois des gens qui bossent sur des projets, on sait aussi qu'on peut pas être partout à la foi. Il y a une différence entre dire "je pense que j'ai pas besoin" ou "je pense que la complexité induite ne vaut pas le coup" et "je pense que personne n'a besoin de ça".
Par exemple supposons qu'on a assigné quelqu'un à UN projet de son (sound). Il ne connaît que ça.
Un beau jour PulseAudio s'impose, mais l'autre il n'y connaît que dalle. On gros on sera obligé de le virer.
Parce que c'est bien connu, les développeurs ne sont pas capables d'apprendre ou de transposer ses compétences sur autre chose. Si le mec connait un systéme de son, il n'a aucune chance d'en connaitre un autre, surtout si du jour au lendemain, san sprevenir, le truc change. Car c'est aussi comme ça que ça marche, un jour, y a rien, le lendemain, sans avoir le temps de regarder u voir les choses bouger, paf, y a pulseaudio.
( je précise que c'est du sarcasme pour me moquer des idées délirantes de kadalka )
Des personnes qui passent d'un produit à un autre, on en trouve souvent. par exemple, Apple et Ivan Krstic (qui a bossé sur le système de sécurité de l'OLPC avant d'aller faire pareil chez Apple), Luke Kanies qui bossé sur cfengine avant de faire Puppet, les mecs de Chef qui ont fait pareil vis à vis de Puppet, Michael DeHaan le fondateur de ansibleWorks qui a écrit func avant de bosser sur ansible. Des exemples comme ça, je peux en sortir des tonnes, et ça, c'est juste la partie visible de l'iceberg, car c'est exactement pareil dans le proprio.
Si tu veux quelqu'un pour bosser sur un produit, tu va pas prendre quelqu'un qui n'a jamais touché à ce produit, tu va prendre quelqu'un qui a l'expérience dans le domaine. Donc par exemple, tu va prendre une personne qui a déjà codé sur mysql pour bosser sur postgresql, etc. Ou sur un cms en php comme wordpress pour bosser sur drupal.
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.
[^] # 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.
Systemd a plein de switch pour son script configure. Et d’après les archives, le projet accepte assez facilement ce qui permet de désactiver certains requirements comme par exemple, selinux, pam, gcrypt, etc.
Ceci dit, de ce que je lit du code, c'est systemd qui va demander à monter de force 4/5 fs ( cf ./src/core/mount-setup.c tableau mount_table ), et qu'en effet, le logiciel requiert d'avoir /dev/ en devtmpfs. Je suis pas assez expert pour savoir si ça fait plus qu'un simple tmpfs, mais c'est vrai que c'est discutable, même si je peux comprendre l'envie de pas avoir des milliers de cas au vue de tout ce que le noyau supporte ou pas.
Ensuite, oui, le fait de dépendre d'un certain nombre d'option noyau est gênante. Par exemple, feu mes 2 RPS n'avaient pas de support de cgroups, j'ai jamais pu mettre à jour la mageia dessus. Et c'est le même souci que j'ai avec divers appareils embarqués ( téléphone, routeur ) avec des pilotes proprios ou des patchs qui sont pas upstreams dans le kernel, je peux pas mettre à jour, ou mettre à jour, c'est chiant.
Systemd, de part sa place centrale, requiert quand même un minimum d'intégration et de travail, et du coup, tu peux pas juste "je boote avec n'importe ou et ça passe" :/
[^] # 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.
Perforce avait une bonne part des parts de marché. Google est parti sur perforce tout au début et il y a en ce moment une migration lente sur les dépots internes vers git ( en ne faisant que des dépots git pour les nouveaux projets ), Perl a longtemps continué à utilisé perforce, freebsd aussi. Svn avait des concurrents sérieux depuis le début. Et bitkeeper est plus vieux que subversion de quelques mois, donc même le concept de Subversion n'était pas le plus novateur à l'époque. Avant git/hg, tu as eu tla, dont l'idée était séduisante, mais l’implémentation catastrophique.
Git a des avantages pour une entreprise.
D'une part, git a des avantages vis à vis de svn sur le point de vue techniques. Il est plus rapide, permet de faire des git bisect efficaces, ce qui permet de chercher des bugs de façon plus rapide.
Ensuite, le fait que tout clone d'un dépôt git soit un clone complet permet de régler des souis d'ordre opérationnel, comme le fait d'avoir une liaison lente dans certains pays vis à vis de l'Europe. Exemple, le brésil, l'australie ont des liens internets limités. Et si donc tu as des bureaux la bas, pouvoir faire un miroir complet sans magouille est un avantage. ( ie, miroir en lecture ecriture ).
Ensuite, non, une entreprise qui développe a autant besoin de pouvoir faire des branches qu'un groupe comme kernel.org. Si tu fait un site de ecommerce, tu as ta version en production, ta version en dev, etc, et tu fait passer les commits de façon fluides d'un depot à l'autre. Faire des merges sous svn, c'est pourri, avec git, ça passe correctement.
D'ailleurs, la preuve que git apporte des choses, c'est qu'il y a plein de boites qui utilisent git. C'est que Google lache perforce pour git.
Et ensuite, git a été écrit par Linus Torvalds car les outils existants n'étaient pas adaptés. Donc c'est pas "kernel.org a fait de la pub involontaire". C'était très volontaire, d'une part, et avant, Linus utilisait bitkeeper, qui n'a pas lui pris le monde d'assaut, prouvant bien que la pub de kernel.org n'est pas une condition suffisante, ou même nécessaire.
Donc oui, git s'est imposé par ses qualités, pas parce que Linus a décidé de l'écrire ou de le faire. Si un outil réponds aux besoins des gens, les gens l'utilisent. Git réponds à ce besoin, c'est utilisé. Systemd réponds, c'est utilisé. Mercurial réponds aussi et permet d’expérimenter autrement, des gens l'utilisent, pareil pour upstart.
[^] # 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é à 6.
ah oui, quand je dit "des startups", je cite des grosses structures…
Alors, c'est une affirmation à l'emporte piéce, voyons la définition du mot honnête :
https://fr.wiktionary.org/wiki/honn%C3%AAte
"Ce qui n’est pas falsifié, fraudé, de ce qui est loyal, consciencieux sans être de la première qualité. "
j'aurais tendance à dire que mon intervention n'est pas falsifié ou fraudé, donc ça, ça colle
"Qui est conforme à la raison, bienséant, convenable à la profession et à l’âge des personnes. "
j'aurais tendance à ne pas trouver mon intervention contraire à la bienséance, donc pareil, ça colle
"Qui est conforme à la vertu, à la probité, à l’honneur. "
Je ne vois pas en quoi je ne suis pas conforme à la probité ou à l'honneur, donc je pense que ça colle.
"Qui est civil, poli. "
Et comme je vois pas d'impolitesse, je dirait aussi que mes propos sont honnêtes.
Donc non, il n'est pas évident en quoi mes contre exemples ne sont pas honnêtes. Sauf à avoir une définition qui n'est pas la définition couramment admise, ce qui ne serait pas la première fois.
ça confirme juste que tu ne sais pas de quoi tu parles et que tes exemples sont pas frais. J'aurais bien dit que ça remets en cause ta crédibilité, mais comme elle est inexistante…
Mais c'est dommage ue tu fasses pas partie de ce groupe de gens assez intelligents pour te comprendre.
La fondation apache n'a pas de codeurs employés à temps plein ou de sous traitant. Le travail est fait par des gens externes à la dite fondation, sans avoir de lien financier avec la fondation. Et par fondation, je parle de apache.org, pour être bien clair.
Une des règles pour obtenir l’accès en tant que projet de la fondation, c'est d'avoir des développeurs de plusieurs employeurs différents, afin de s'assurer que le projet est pérenne.
[^] # Re: Argument bidon!
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 2.
Pour toi, y a ça :
http://sta.li/
Et ça :
http://statifier.sourceforge.net/
si ça marche encore. Je suis sur qu'ils cherchent tout les 2 des testeurs.
[^] # 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.
Mais ça ne réponds que au besoin de "cgroups" pour les ressources, pas à cgroups pour grouper les processus ( ce qui est qur quoi systemd s'appuie ).
Et les jails ne sont pas non plus un équivalent comme lu plus tot, vu qu'un jail, c'est un container ( ie, linux namespace, lxc ).
Ceci dit, rctl a l'air très bien, je pense que ça mériterais un article dans GLMF pour que les gens connaissent un peu plus.
[^] # 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.
init V non. Par contre, systemd a pour but aussi d'unifier les services entre distributions. Par exemple, en offrant une API documenté pour changer la locale ou le nom d'hote, et pas des détails purement historique comme le fait d'avoir un fichier avec un chemin différent pour le nom d'hôte. De la même façon, un fichier .service va marcher de la même façon partout. un service a besoin de charger un module va pouvoir le faire de la même façon en posant le fichier dans /etc/modules.d/ avec une syntaxe défini.
Et du coup, tu peux pousser ça upstream tout comme tu peux pousser upstream le fichier .desktop pour que tout le monde s'en serve.
Les autotools et grosso modo tout les trucs du monde ont de quoi faire des templates. C'est déja ce qui fait pour les .desktop justement.
bien sur j'ai jamais dit qu'il n'y avait pas de raison à ça. Juste que l'image d'un init qui lance juste les services est un chouia incomplète, init fait grosso modo 4 fois plus que ça.
Mais justement, ça fait déjà l'objet de service à part comme acpid.
Et à ce moment la, se charger de lancer de façon propre un service ( ie, mettre les namespaces si besoin, faire le setuid si besoin ), ça rentre aussi dans l'arrêt/démarrage des services. Mais pourtant, quand systemd le fait, c'est bloated, quand c'est init, ç'est normal.
Ensuite si tu trouves que systemd fait trop, la question est de savoir si le binaire de systemd fait trop, ou si le fait d'avoir tout dans le même git est un souci. Si c'est le second, on te dira que les BSDs font ça aussi, et personne ne trouve que c'est bloated de mettre tout dans un seul cvs/svn. Si c'est le premier, peut être que comme pour l'ancien init, ça a un sens techniquement de faire ça de façon unifié ?
Et quand on voit tout ce que fait le noyau qui peut être fait en userspace ( par exemple, le nat est fait via natd sur FreeBSD en userspace ) et le nombre de gens qui se jette sur le hurd pour aider, j'aurais tendance à dire que "trop faire" n'est pas une si grande tare. Et je peux même pas dire que c'est la personnalité du développeur initial, vu que Linus est vachement moins diplomate que Lennart.
[^] # 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.
On est jamais trop prudent, suffit juste d'une fuite mémoire, d'une barette de ram défectueuse, ou d'avoir des machines dans des versions de développement, par exemple pour que les gens puissent faire des tests de compilation.
[^] # 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é à 8.
Si tu parles de façon général, et sans vouloir dire du mal de FreeBSD, je pense que la pile de virtualisation de l'OS est pas encore mature. Soit tu prends bhyve ( toujours en dev ), soit tu prends VirtualBox ( donc un module externe ).
Pareil, niveau module de sécurité MAC, je pense que FreeBSD est un chouia en retard sur une distribution comme RHEL en terme d'architecutre proche de FLASK, malgré la présence de nombreux modules des plus intéressants (http://www.freebsd.org/doc/en/books/handbook/mac.html) et d'une architecture correct pour ça. Mais c'est pas un besoin "moderne", c'est vrai.
FreeBSD note que son module Fuse n'est pas production ready, (https://wiki.freebsd.org/FuseFilesystem), donc si c'est encore vrai, ça exclue globalement le déploiement de choses comme Ceph ou Glusterfs, qui sont utilisés pour notamment des déploiement d'openstack et ou du big data.
Ensuite, parmi les besoins modernes, je pense qu'il y a des choses comme le fait d'augmenter la densité des containers, en lançant tout à la demande (http://0pointer.de/blog/projects/socket-activated-containers.html). Je ne pense pas que les jails permettent ça pour le moment.
(et ce besoin est directement corrélé avec des outils de PaaS comme Openshift, et le besoin croissant de faire du "self-service" et d'offrir des services aux départements de ta société.
Et je pense pas que les devs de FreeBSD soit des abrutis de pas avoir ça, c'est juste une question de ressources. On voit bien qu'il y a chaque fois des gens qui bossent sur des projets, on sait aussi qu'on peut pas être partout à la foi. Il y a une différence entre dire "je pense que j'ai pas besoin" ou "je pense que la complexité induite ne vaut pas le coup" et "je pense que personne n'a besoin de ça".
[^] # 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é à 8.
Parce que c'est bien connu, les développeurs ne sont pas capables d'apprendre ou de transposer ses compétences sur autre chose. Si le mec connait un systéme de son, il n'a aucune chance d'en connaitre un autre, surtout si du jour au lendemain, san sprevenir, le truc change. Car c'est aussi comme ça que ça marche, un jour, y a rien, le lendemain, sans avoir le temps de regarder u voir les choses bouger, paf, y a pulseaudio.
( je précise que c'est du sarcasme pour me moquer des idées délirantes de kadalka )
Des personnes qui passent d'un produit à un autre, on en trouve souvent. par exemple, Apple et Ivan Krstic (qui a bossé sur le système de sécurité de l'OLPC avant d'aller faire pareil chez Apple), Luke Kanies qui bossé sur cfengine avant de faire Puppet, les mecs de Chef qui ont fait pareil vis à vis de Puppet, Michael DeHaan le fondateur de ansibleWorks qui a écrit func avant de bosser sur ansible. Des exemples comme ça, je peux en sortir des tonnes, et ça, c'est juste la partie visible de l'iceberg, car c'est exactement pareil dans le proprio.
Si tu veux quelqu'un pour bosser sur un produit, tu va pas prendre quelqu'un qui n'a jamais touché à ce produit, tu va prendre quelqu'un qui a l'expérience dans le domaine. Donc par exemple, tu va prendre une personne qui a déjà codé sur mysql pour bosser sur postgresql, etc. Ou sur un cms en php comme wordpress pour bosser sur drupal.
Donc non, tu va pas être obligé de le virer.
[^] # 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.