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.
Ca existe encore? C'est pas mort, enterré sous 18 pieds de terre?
ce projet, visiblement si. Ensuite, c'est un exemple que les gens connaissent.
Et puis ça ne fait pas de l'analyse protocolaire, ça fait de la reconnaissance d'appli.
ça fait du pattern matching sur les chaines, pour analyser le flux pour reconnaitre les applis, je pensais que ça rentrais dans analyse protocolaire. Ceci dit, à 1h du matin les détails de ce genre m'échappe parfois.
Et sinon, je pense que qosmo a un produit pour toi :)
La pile zrtp en question est vachement utilisé, tu pourrais croire que c'est de la sécurité, ça a été relu, et visiblement, pas trop. Mais bon, à part ça, faut se méfier des LSMs bien sur :)
SELinux est une sécurité « en plus », si vous envisagez qu'une backdoor ait pu y être introduite, il suffit de ne pas l'utiliser
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
On peut dire qu'en effet, j'ai une journée aussi chargé que d'habitude, mais c'est surtout répondre pendant que mes collègues anglophones sont en réunion qui me perturbe.
Pour en revenir au sujet, j'aurais quand même tendance à dire qu'on doit pas voir les entreprises comme des unités parfaitement uniformes, la communication passe en général lentement, donc les choix d'une partie de l'entreprise n'a aucune importance pour une autre partie de la boite, voir la même partie passé ou futur. Sauf à croire que le PDG s'engage fortement sur un produit et qu'il arrive à articuler sa vision tel que tout le monde le suit ( ou qu'il soit ultra autoritaire ), ça n'arrive jamais, surtout pour un conglomérat de la taille de Sony.
Chaque sous groupe a sa propre autonomie, et à l'intérieur, chaque département, chaque équipe, etc, peut faire ses choix technologiques. Donc l'impact est bon pour Freebsd, mais je pense que Freebsd n'avait pas vraiment un grand besoin de crédibilité, étant déjà une solution crédible pour ça, et que ça va pas impacter la popularité de Linux, qui est déjà aussi une solution crédible depuis des années.
Et pour aller plus loin, ceux qui espéraient faire du windows avec SONY, et ils sont légions les windowsiens, ils sont contents d'apprendre qu'il n'y a pas de place pour eux?
Si les mecs pensaient que Sony aller mettre Windows sur sa nouvelle console en étant en concurrence contre Microsoft, je pense qu'ils ont d'autres soucis. Comme par exemple le fait d'avoir des idées à la con.
Tu as compris l'inverse de ce que CHP a dit. Il a dit qu'il y avait, en entreprise, plus de RHEL ou Suse que de Debian ou Fedora parce que justement ces deux premières proposent du support, commercialement,
par opposition à un support communautaire ou par une entreprise tiers.
Je croise plus souvent du Debian en entreprise que du Fedora ceci dit. Debian est vu comme étant pour serveur, ou comme base pour faire une distribution personnalisé, alors que Fedora est vu comme étant pour les hobbyistes, et pour les postes de travail. Ensuite, je pense qu'il y a avec l'arrivée du cloud et de ce que ça implique ( à savoir des machines jetables, du bétail contrairement à des serveurs plus classiques qui sont des animaux de compagnies, pour reprendre l'image d'un admin du CERN ), les choses peuvent changer.
Oui mais je pense que les décideurs en entreprise considèrent, à tort ou à raison, qu'un support proposé directement par l'éditeur c'est mieux.
Ben surtout que personne ne dit "je garantit" sur un produit ou il n'a pas la main.
RH garantit RHEL car c'est contractuellement faisable. Par exemple, Debian ne s'est jamais fatigué à faire les démarches pour l'exportation au niveau de la cryptographie avec le département d'état américain. Bien que le risque de souci soit faible voir nulle, et qu'on s'en fout franchement (au contraire des brevets, ou les risques sont plus gros), je pense qu'il y a des cas ou ça compte. Debian ne se fait pas certifié FIPS, trop cher, trop long. Pareil, il y a des cas ou ça compte. Ou PCI-DSS, ce genre de choses. Des histoires de régulations, y en a dans plein de secteurs, les assurances, les hopitaux et la santé, etc.
Ça semble ridicule pour un particulier ou même pour une PME. Pour une grande entreprise, c'est plus compliqué.
Des trucs tout con comme "j'ai besoin d'avoir des cours sur la technologie pour former les 50 admins", faut avoir déjà une grosse boite pour mettre ça en place. Etc, etc.
C'est pas que Debian soit mauvais ou RHEL meilleur, c'est que RH a mis en place que ce que les clients veulent pour pas perdre de temps sur des détails.
Et que RH a la main d'oeuvre pour faire de la revue de code, pour tout les trucs chiants qu'on a tendance à ne pas voir. Avoir des consultants disponibles, du support.
Et c'est bien parce que Debian et Fedora sont des communautés qu'il y a des produits forkés pour les entreprises ( en l'occurrence, RHEL et Ubuntu ), parce que personne saint d'esprit ne peut donner le même niveau de garantie sur Debian qu'il pourrait donner sur un produit séparé qu'il contrôle.
Le moinsage par principe existe partout, et ici aussi.
des preuves ? (non "ça existe partout, j'ai pas besoin de le prouver" ou variation comme "j'ai déjà expliqué ailleurs", c'est pas une preuve, et se citer soi même quand tout le monde demande plus d'info, c'est juste n'importe quoi )
Dans la vraie vie si tu fais face aux gangs de Los Angeles, tu es mort.
Cool story bro, et le rapport avec Linuxfr ? Quelqu'un t'a menacé physiquement ?
Parce que je cite toi même aujourd'hui ailleurs sur la page :
Si un mot qui s'apparente de près ou de loin à menace apparaît quelque part, j'ai cru comprendre que pour vous c'est une arme sur la tempe…
Si tu compares les gens qui discutent avec toi à des gangs de LA et que tu compares le fait de te faire contredire au fait de risquer ta vie, permet moi de te dire que tu es totalement hors sujet.
Imaginez maintenant la personne normale qui vient sur linuxFR, il voit ça ou pire le vit, vous croyez honnêtement qu'il restera ?
donc les gens qui viennent sur linuxfr en dehors de la personne normale, c'est quoi, des personnes anormales ? Tu te rends pas compte que tu es insultant dans ta façon de présenter les choses ?
Des parents aux USA ont peur pour leur enfant, de même des personnes aiment linux mais ne veulent pas critiquer de peur d'être moinsés et
d'être mis au ban du site par les membres.
Ah oui, tout ces gens qui seront mis au ban par l'élite linuxfrienne qui a droit de vie ou de mort sur tout le web, capable d'un coup de souris de forcer l'usage des fourches caudines de la censure sur le pauvre innocent, qui du coup va … perdre un point de karma, un truc dont il n'avait aucun idée avant de venir ici, qui ne sert à rien à part monter ou pas e commentaire pour une sous partie des quelques utilisateurs du site. Oui, c'est totalement comparable avec les gangs à LA. Risquer sa vie dans une fusillade, perdre un point de karma en disant des trucs, exactement la même chose.
Priez le ciel que ce n'est pas votre ennemi si le karma est important pour vous.
Dieu merci, c'est pas important pour toi. Et pourtant, tu en parles avec une telle conviction qu'on pourrait croire qu'il y a une importance personnelle pour toi.
(Je suis de très près mon tableau de bord)
Encore une preuve que tu t'en fout complétement du karma.
[^] # 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.
[^] # 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é à 3.
ce projet, visiblement si. Ensuite, c'est un exemple que les gens connaissent.
ça fait du pattern matching sur les chaines, pour analyser le flux pour reconnaitre les applis, je pensais que ça rentrais dans analyse protocolaire. Ceci dit, à 1h du matin les détails de ce genre m'échappe parfois.
Et sinon, je pense que qosmo a un produit pour toi :)
# BSD et Confort.
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 9.
Moi, je pense que tu devrais passer à du BSD.
Non pas parce que c'est plus sur, moins sur, ou la licence est meilleur ou pas. Ou parce que la NSA a envoyé un patch sur le kernel.
Non je pense que tu devrais car c'est important de connaitre plus qu'une distribution, plus qu'un système libre.
[^] # Re: Audit
Posté par Misc (site web personnel) . En réponse au journal [non-troll] Faire confiance à (N)S(A)ELinux ou aux *BSD ?. Évalué à 2.
Si tu cherches du code buggué sur du truc peu répandu, c'est tout chaud :
http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html
La pile zrtp en question est vachement utilisé, tu pourrais croire que c'est de la sécurité, ça a été relu, et visiblement, pas trop. Mais bon, à part ça, faut se méfier des LSMs bien sur :)
[^] # 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é à 3.
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 4.
On peut dire qu'en effet, j'ai une journée aussi chargé que d'habitude, mais c'est surtout répondre pendant que mes collègues anglophones sont en réunion qui me perturbe.
Pour en revenir au sujet, j'aurais quand même tendance à dire qu'on doit pas voir les entreprises comme des unités parfaitement uniformes, la communication passe en général lentement, donc les choix d'une partie de l'entreprise n'a aucune importance pour une autre partie de la boite, voir la même partie passé ou futur. Sauf à croire que le PDG s'engage fortement sur un produit et qu'il arrive à articuler sa vision tel que tout le monde le suit ( ou qu'il soit ultra autoritaire ), ça n'arrive jamais, surtout pour un conglomérat de la taille de Sony.
Chaque sous groupe a sa propre autonomie, et à l'intérieur, chaque département, chaque équipe, etc, peut faire ses choix technologiques. Donc l'impact est bon pour Freebsd, mais je pense que Freebsd n'avait pas vraiment un grand besoin de crédibilité, étant déjà une solution crédible pour ça, et que ça va pas impacter la popularité de Linux, qui est déjà aussi une solution crédible depuis des années.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 5.
Si les mecs pensaient que Sony aller mettre Windows sur sa nouvelle console en étant en concurrence contre Microsoft, je pense qu'ils ont d'autres soucis. Comme par exemple le fait d'avoir des idées à la con.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 2.
Je croise plus souvent du Debian en entreprise que du Fedora ceci dit. Debian est vu comme étant pour serveur, ou comme base pour faire une distribution personnalisé, alors que Fedora est vu comme étant pour les hobbyistes, et pour les postes de travail. Ensuite, je pense qu'il y a avec l'arrivée du cloud et de ce que ça implique ( à savoir des machines jetables, du bétail contrairement à des serveurs plus classiques qui sont des animaux de compagnies, pour reprendre l'image d'un admin du CERN ), les choses peuvent changer.
Ben surtout que personne ne dit "je garantit" sur un produit ou il n'a pas la main.
RH garantit RHEL car c'est contractuellement faisable. Par exemple, Debian ne s'est jamais fatigué à faire les démarches pour l'exportation au niveau de la cryptographie avec le département d'état américain. Bien que le risque de souci soit faible voir nulle, et qu'on s'en fout franchement (au contraire des brevets, ou les risques sont plus gros), je pense qu'il y a des cas ou ça compte. Debian ne se fait pas certifié FIPS, trop cher, trop long. Pareil, il y a des cas ou ça compte. Ou PCI-DSS, ce genre de choses. Des histoires de régulations, y en a dans plein de secteurs, les assurances, les hopitaux et la santé, etc.
Ça semble ridicule pour un particulier ou même pour une PME. Pour une grande entreprise, c'est plus compliqué.
Des trucs tout con comme "j'ai besoin d'avoir des cours sur la technologie pour former les 50 admins", faut avoir déjà une grosse boite pour mettre ça en place. Etc, etc.
C'est pas que Debian soit mauvais ou RHEL meilleur, c'est que RH a mis en place que ce que les clients veulent pour pas perdre de temps sur des détails.
Et que RH a la main d'oeuvre pour faire de la revue de code, pour tout les trucs chiants qu'on a tendance à ne pas voir. Avoir des consultants disponibles, du support.
Et c'est bien parce que Debian et Fedora sont des communautés qu'il y a des produits forkés pour les entreprises ( en l'occurrence, RHEL et Ubuntu ), parce que personne saint d'esprit ne peut donner le même niveau de garantie sur Debian qu'il pourrait donner sur un produit séparé qu'il contrôle.
[^] # Re: La vraie question
Posté par Misc (site web personnel) . En réponse au journal Orbis OS le système qui ferait fonctionner la PS4 serait-il un FreeBSD ou un OpenSuse ?. Évalué à 4.
des preuves ? (non "ça existe partout, j'ai pas besoin de le prouver" ou variation comme "j'ai déjà expliqué ailleurs", c'est pas une preuve, et se citer soi même quand tout le monde demande plus d'info, c'est juste n'importe quoi )
Cool story bro, et le rapport avec Linuxfr ? Quelqu'un t'a menacé physiquement ?
Parce que je cite toi même aujourd'hui ailleurs sur la page :
Si tu compares les gens qui discutent avec toi à des gangs de LA et que tu compares le fait de te faire contredire au fait de risquer ta vie, permet moi de te dire que tu es totalement hors sujet.
donc les gens qui viennent sur linuxfr en dehors de la personne normale, c'est quoi, des personnes anormales ? Tu te rends pas compte que tu es insultant dans ta façon de présenter les choses ?
Ah oui, tout ces gens qui seront mis au ban par l'élite linuxfrienne qui a droit de vie ou de mort sur tout le web, capable d'un coup de souris de forcer l'usage des fourches caudines de la censure sur le pauvre innocent, qui du coup va … perdre un point de karma, un truc dont il n'avait aucun idée avant de venir ici, qui ne sert à rien à part monter ou pas e commentaire pour une sous partie des quelques utilisateurs du site. Oui, c'est totalement comparable avec les gangs à LA. Risquer sa vie dans une fusillade, perdre un point de karma en disant des trucs, exactement la même chose.
Dieu merci, c'est pas important pour toi. Et pourtant, tu en parles avec une telle conviction qu'on pourrait croire qu'il y a une importance personnelle pour toi.
Encore une preuve que tu t'en fout complétement du karma.