Pourtant on se demande bien ce qu'on ferait sans les grosses
boites. S'il faut se battre contre tous les brevets déposés,
elles sont une manne non négligeable d'idées, de main d'œuvre
(combien d'entreprises travaillent aussi pour le libre ?) et de
pognon.
Bien sur, mais quel rapport avec le fait de laisser les boites reprendre sans contribuer en retour ?
Regardons le kernel Linux, qui a beaucoup de retour de grosses boites et qui est sous GPL v2. Ou gcc.
Et des projets sous BSD ( ou assimilés, genre Apache/MIT ) ont aussi des retours.
Donc on peut difficilement dire qu'il y a une corrélation, ne serais que parce que maintenir un fork de code conséquent est couteux en temps, au delà des soucis de licence.
Google fait ça aussi avec Android (si tu veux un peu d'avance
sur les autres, tu te plies aux règles) et c'est un projet qui
marche plutôt pas mal ;-) tout en restant libre au final.
Ça dépend de ton critère pour "qui marche". D'un point de vue de l'input de la communauté sur le projet, je pense pas que ça soit flagrant, ça reste chasse gardé de Google. Ensuite, je pense que Google fait ça avec android juste parce qu'ils ont pas le choix. Si tu va par la, Apple montre rien et ça marche aussi pour eux. Donc on peut dire que "avoir des parts de marché" n'est pas dépendant dans le mobile de "donner le code source avec du retard".
Ca change de d'habitude pour 99% des projets?
Y a pas mal de projet qui font de la relecture, genre tout les gros. Y a aussi pas mal de gens qui font de la relecture pour trouver des failles de sécurité, et donc ton chiffre de 99% est à mon sens trompeur et incorrect. Il y a des boites ( par exemple RH pour RHEL, Canonical pour la partie main ) qui font de l'audit avant d'intégrer ou de proposer quoi que ce soit. Mais oui, ça change rien si personne ne bosse avec toi d'habitude, et si tu n'as finalement aucune communauté de développeurs autour de ton produit, soit parce qu'il s'y prête pas, soit parce que le caractère du codeur ne s'y prête pas.
Juste un bandeau "fonctionnalité dans la version pour
sponsors, libre le X".
Je parle de la production, pas de l'usage. IE, traduire ou écrire de la documentation sans avoir accès au logiciel est un peu plus dur, et ça aboutit au final à avoir quelque chose de moins bonne qualité. Donc il faut prendre en compte le cout de faire soit même la traduction ou la documentation, ou de donner accès à la version aux bénévoles qui vont le faire dans le cadre du projet libre, ou se satisfaire d'une qualité inférieur ou la traduction est pas relu en situation, tout comme la doc.
Et je rajouterais le fait de faire des tests, des betas, etc. Il me semble évident que le nombre de sponsors testeurs est inférieur ou égal à la communauté entière, vu que les dits sponsors font parti de la communauté par définition. Encore une fois, on aboutit à un truc de moins bonne qualité, ou quelque chose qui requiert plus de travail, si la communauté est fonctionnel ( encore une fois, si elle n'existe pas, ça ne change rien ).
C'est pas comme si personne ne maintenait des branches à part > (libres mais refusées upstream, ou non libre etc…)
Rien de neuf au niveau logistique.
Justement, c'est parce qu'on sait que maintenir des branches est un cout que les gens qui ont un peu plus de bouteille poussent les choses upstream. On a vu ce que ça donne justement avec android et le kernel, et qu'au bout d'un temps, avoir tes branches sur un projet dynamique est lourd.
Au jour le jour, avoir 2 branches de dev ( la branche dispo pour tous, et la branche pour le soft sponsorisé ) fait que tu dois faire 2 fois plus de tests, que tu doit backporter les fonctionnalités et les bugfixes de l'une à l'autre. Ou que tu fait tout dans la branche sponsor, ce qui ralentit fortement les contributions externes ( chose que tu n'as peut être pas sur le projet à la base, ou dont tu te fout, mais du coup, ça me semble aller à l'encontre du développement collaboratif ).
Ensuite, ça dépend grandement de la durée du développement, mais comme tu rajoutes quelques semaines de bloquage de façon artificiellement, ça fait toujours ce temps ou tu doit faire des rebases, etc.
Pourquoi "précariser les codeurs" avec ça?
Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI. Si ensuite, toi, ça te va, ça veut pas dire que ça va pour tous.
Comme dans tout contrat et/ou comment dans tout financement
participatif.
Donc tu payes une pénalité, comme dans un contrat bien fait en faveur pour le client, ou le client paye sans avoir de garantie ( comme dans un contrat moins en sa faveur ) ? Ou tu impliques les avocats, comme dans un contrat classique ?
ça ne m’intéresse pas moi le principal codeur de faire sur mon
temps libre et je ne suis pas ton esclave, mais si tu payes je
veux bien m'y mettre (ou un autre si tu veux) à travers un
sponsoring, si tu peux pas seul un financement participatif
est possible.
J'ai du mal à suivre en quoi ça réponds à la question "combien de temps avant que le codeur refuses quelqu'un qui va faire ça sur son temps libre alors qu'il pourrais avoir de l'argent pour le faire ?"
Des exemples de ce genre, tu en trouve autour des communautés de logiciel open-core.
Ensuite, je sais pas pour toi, mais moi, si y a un truc que j'ai pas envie de faire, c'est rarement rajouter de l'argent qui va me le faire faire, sauf si je suis vraiment à l'arrache ou si il y a vraiment beaucoup d'argent. J'ai pas encore une estime de moi si basse que je vais me vendre à pas cher pour coder un truc que je veux pas coder et en plus m'infliger de faire de la paperasse pour ça. Et pas non plus un compte en banque tellement vide que je n'ai pas le choix.
Mais bon, si ça marche pour toi et plein d'autres, tant mieux.
Je cherche pas à te convaincre du contraire, ça serait totalement idiot et ça m'apporterais rien.
Mais je reste persuadé que ça n'est pas une solution très pérenne pour les systèmes libre tel qu'ils sont aujourd'hui.
Je voit bien par contre que c'est une solution pour les développeurs propriétaires :
- moins de piratage, car au final, les gens qui veulent pas payer vont prendre la version libre
- un minimum d'implication de la communauté pour la traduction/documentation/portage, etc, donc des économies, et une qualité supérieure à un logiciel propriétaire équivalent ( vu qu'il y a rarement des traductions pour les plus petits, et souvent des horreurs pour que ça tourne sans le code source sur divers distributions et OS )
- un financement, car filer le soft gratos, ça paye rarement le loyer
- la possibilité de dire "je fait du libre (en partie )", ce qui est quand même plus glorieux et meilleur pour l'ego que "j'ai fait un shareware", du moins de nos jours sur un CV
- un argument de vente auprès des utilisateurs, histoire de dire "c'est libre, c'est bien (tm)", et de surfer sur la vague ( tout comme le crowdfunding ).
ça ne serait plus du logiciel libre du coup. Tu n'aurais pu par exemple l'intégration dans les distributions, tu n'aurais pas la relecture par d'autres codeurs de la communauté, les gens avec la feature en plus auraient moins de chance d'avoir des réponses sur le forum, et les documentations et traductions devraient être geré à part.
D'un point de vue logistique, ça semble une mauvaise idée.
Quand à l'idée de base, ça reste quand même risqué. Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ? Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?
Comment tu repartis ça dans le cas d'un travail en équipe ?
Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.
C'est pas étonnant. Avoir du matériel libre pose des contraintes que je pense Canonical n'a pas le temps de prendre en compte. par exemple, de la négociation avec les fabricants, ce qui reviens à payer plus cher, ou à sortir plus tard. Et le temps et l'argent ne sont pas des ressources qu'ils ont en abondance.
Conserver le même taux, ça implique que le buzz ne fonctionne pas comme les autres et que ça ne s'essouffle pas.
Ceci dit, la question de savoir si ils arrivent ou pas n'est pas importante. Si ils arrivent pas, mark peut compléter, et si ils arrivent, est ce que ça suffiras ou pas ?
Sachant que ça, c'est pour la production de 50000 unités, il faudra remettre plus, voir beaucoup plus pour viser la production de masse. Donc le tout est de savoir si Canonical compte dire "on a réussi à faire du buzz, on a vendu 50000 unités en mettant l'équivalent de notre chiffre d'affaire, donc faut nous filer des thunes", ou est ce que Canonical compte être bénéficiaire dans l'opération, et va financer d'autres produits ?
En fait, l'année dernière, on attendais des partenaires, on a rien eu. On attendais des partenaires pour ubuntu tv, y a rien eu. On pourrait se dire "ouais, mais c'est dur", mais Mozilla, de taille comparable à l'époque à Canonical, a réussi à faire un OS, et à réussi à avoir des partenaires. En fait, même des produits comme le freerunner ont réussi à avoir un fabricant derrière ( en l’occurrence, FIC ).
Ah oui, ça cible tout de suite mieux. Et un écran couleur aussi, pour rester dans la précision renversante :) ?
Ceci dit, prendre une cpu dual core i7, ça donne une bonne histoire pour la convergence, "ubuntu edge permet aussi de cuire votre steak", ça aurait du succès. Tu fait un sponsoring de man vs wild, et voila. D'un coté, GPS, de l'autre, grill.
Le n9 n'a jamais couté 810€, le S4 vaut 513€ maintenant, et même le plus cher des iphone n'est qu'à 900€. D'ailleurs, Canonical a bien vu que c'est trop cher et a revu le tarif à la baisse.
Et Apple et Samsung ont ce prix et ont un os et des équipes rodés, ils ont déja rentabilisé les couts initiaux depuis longtemps. Ils produisent aussi à plusieurs millions d'exemplaires, pas un batch de moins de 100 000. Donc même la, la production de masse est en faveur des concurrents.
je suis pour le fait que Canonical réussisse, mais faut pas se leurrer non plus.
D'une part, ça va pas t'offrir la vrai mobilité que tu espères. Des téléphones avec des sorties hdmi, y en a déjà, et je pense pas que les gens utilisent. Si jamais tu as besoin d'un clavier souris et du dock kivabien, tu va au mieux basculer de chez toi au boulot, mais pas plus. Donc dans l'état et sans une ubiquité du système, je pense pas que ça soit un avantage décisif.
Ensuite, l'expérience d'openmoko montre quand même que faire un téléphone, c'est couteux et complexe. Couteux car tu as les divers certifications à faire, car tu as pas de references dispo pour faire mieux, etc. Complexe car tu as les bugs de dernière minutes dans les drivers videos proprios, parceles devs capables de faire de l'ARM, ça court pas les rues, et ça va encore moins courir bientot avec la montée en puissance de l'architecture. L'arm, ça reste ( sauf erreur de ma part) un truc qui pète au run time sur l'alignement, d'ou l'investissement de Canonical dans les tests auto. Mais tu as aussi les merdes causés par les périphériques mal documentés, par les bugs hardwares à la con, etc.
Et je parle pas du fait que la campagne de crowdfunding se fait sur le monde entier, ce qui fait que Canonical va devoir se taper les taxes et les détails moisis sur toute la planète, ce qui est pas une mince affaire.
Je recommande l'excellente extension Collusion qui permet, à
l'aide d'un joli diagramme amusant, de voir qui nous piste.
Amusant et relativement lent. J'ai fait tourner l'extension depuis 1 ou 2 mois, ça mets 1 minute à afficher tout. Je sais pas si c'est un souci devant les données à afficher ( genre 2000 nœuds ) ou si le code est un peu naif, ou si le js est vraiment lent.
Au lieu de dire que "c'est la faute à l'utilisateur s'il n'est
pas au courant pour le code caché" casé juste après "OS prêt
pour le grand public et facile d'utilisation", on pourrait
peut-être promouvoir ce genre de pratique, non?
aussi longtemps que tu auras un moyen pour l'utilisateur de passer outre, ça ne serviras à rien.
Tu peux mettre rm -i par défaut, si tu as un -f qui surcharge le -i, ça sert à rien.
Et forcer la question ne serais vu que comme une nuisance.
Bien sur, le tutoriel moyen est souvent dans l'optique "on va résoudre sans se soucier du comment", et personne ne pense sur le long terme sur l'éducation des gens.
Par exemple, le modèle windows xp/95 de tout le monde est admin est problématique d'un point de vue sécurité. Mais le modèle vista des popups à tout va est aussi un souci, vu que les gens passent le temps à être ennuyé par ça, et ne lise plus, sont interrompu, etc.
Et toute tentatives de retirer les dits popups une fois qu'ils sont la depuis longtemps ( exemple, ce que packagekit a tenté de faire ) devient tout d'un coup un affront pour les gens qui n'ont pas de souci avec la complexité.
À ce niveau la, on a les mêmes soucis sur les UI Linux que Windows, et quoi qu'on dise, les mêmes types de gens font les UIs, les mêmes types de gens ne sont pas au courant des soucis que ça pose au jour le jour, et donc on abouti aux mêmes oppositions.
Et au final, en ne faisant pas mieux que Windows, on arrive pas à bouger le status quo, et donc windows reste majoritaire.
Donc même si "c'est pas mieux sur windows", ça n'est pas une excuse pour pas penser à faire mieux. Dans le cas précis de cette vulnérabilité, le souci est que ce que l'utilisateur colle ne corresponds pas à ce qu'il voit. Ça contredit totalement le modèle mental qu'on a du copier/coller quand on ne sait pas comment ça marche.
Dans ce cas précis, est ce que firefox devrait prendre que le contenu qui est visible pour le mettre dans le presse papier ? peut être, mais ça reste très complexe à faire, et sans doute facile à contourner. Est ce que faire ça n'aurait pas d'effet de bord ? Peut être aussi.
Est ce qu'il faut interdire à kill de faire ça ( ie, kill -1 ) sans demande express à l'utilisateur ? ( comme rm -Rf / qui pose la question, comme rm sous zsh qui demande confirmation ). L'attaquant rajouterais juste ce qu'il faut pour valider. Et ça n'aiderais pas pour une faille plus subtile de "je rajoute ma clé ssh dans le keyring et je rajoute un cron qui donne l'ip pour que je me fasse pirater la tronche".
On peut imaginer avoir un plugin qui détecte que le fichier est un .txt mais qu'en fait, c'est du html, donc fishy (mais ça aiderais pas beaucoup). On pourrait voir qu'il y a un copier coller qui correspond pas à ce qui s'affiche, et mettre un warning.
Seth ne travaillait plus sur yum depuis longtemps, qui est maintenant maintenu par d'autres. Depuis quelques années, il était dans l'équipe d'admin sys pour l'infrastructure fedora, et il était en train de travailler sur la migration de puppet vers ansible, ou la mise en place de copr, un équivalent aux PPAs de launchpad si j'en croit ses derniers posts de blogs.
Même si j'ai pour ainsi dire jamais interagi avec lui et que j'ai surtout senti la partie "grumpy" de son rôle de sysadmin sur irc, les louanges sur planet fedora pleuvent, et il était très apprécié pour ses qualités humaines. Donc c'est une perte pour la communauté Fedora et pour le libre en général, comme tant d'autres avant lui ( je pense notamment à Eugeni Donodov, mort dans des circonstances similaires à vélo il y a 1 an, ce qui calme fortement mes envies de me remettre à rouler sur mon 2 roues vu que je ne suis pas la prudence incarné dans ce domaine ).
Tu ne dis pas toujours directement ce que tu penses, mais par
contre, j'ai très bien compris tes propos:
Non, tu as montré plus d'une fois que tu ne comprends rien. Je doute que ça soit aujourd'hui que ça commence. Arrête de prétendre le contraire, et arrête de me faire tenir des propos que j'ai pas. Si je dit pas un truc, je le dit pas.
Donc les gars qui font de l'informatique sont trop bêtes pour
comprendre qu'ils doivent apprendre un VCS, sachant qu'une
bonne majorité aime bien coder dans son coin ?
D'une part, tu sors tes chiffres de ton chapeau, des gens qui codent pas sur leur temps libre, y en a beaucoup plus que tu crois, et d'autre part, c'est pas parce que tu dois faire un truc que les gens le font. Par exemple, toi, tu devrais te taire et réfléchir avant de poster, et tu le fait pas.
Mais dis moi, dans ta boîte, dont je ne cherche pas à
connaître le nom,
Tu le connais déjà, mais tu as des doutes.
on n'offre pas la possibilité aux employés de s'autoformer
même quelques minutes ?
Contrairement à toi, j'arrive à voir plus loin que ma boite. Et C'est pas "quelques minutes" qu'il faut, c'est plus "quelques jours". Dans une SSII classique avec un ingé facturé à 500€ la journée pour du dev, ça te coute 2000€/p juste en productivité perdu de faire 4j de formation. Et encore, 500€, c'est des ingés pas trop chers, estimation à la louche pour l'époque ou j’étais encore dans le circuit. Ça te semble sans doute négligeable mais si tu commences à faire ça pour plusieurs ingés, ça te coute le salaire d'un seul, soit 1 mois de travail sur le projet et la, ça deviens vachement plus visible. Et c'est en partant du principe qu'aprés 4j, ils sont parfaitement rodé.
Et la, on parle que de la formation, tu as parfaitement oublié et passer sous le tapis les choses comme les scripts de builds, l'intégration avec le bugtracker, les outils clients side, les possibles hooks du coté du dépôt, le changement de procédure de backups, etc, etc.
1) Beaucoup d'utilisateurs l'utilisent à titre personnel… et
souvent sans connection.
Tu tires ça de ton chapeau
2) SQLite te paraît trop petit ?
ça me parait surtout trop peu.
3) Ce n'est pas juste le plaisir de me contredire qui te
pousse à affirmer ? :D
Non, c'est juste les faits. J'ai jamais eu à me servir de fossil pour le moindre logiciel. Et pourtant, je suis déjà sur p4 ( zimbra ), sur tla, sur monotone, et des trucs qui selon toi serait plus obscure.
4) Fossil est accessible via SSH, il y avait même eu un débat > sur le sujet il y avait quelques mois.
Ah oui, y a un accès ssh donc les gens l'utilisent. Comment ne pas avoir vu ça plus tôt ? Ah oui, parce que ça n'a comme d'hab avec toi aucun rapport.
Principalement. Mais Google fait des appels d'offres, parce
que côté rapport qualité prix c'est moins cher. C'est le cas
de Nexus dont l'appel d'offre a été gagné par LG.
Encore une fois, non. Ou alors démontre le, vu que la charge de la preuve est à celui qui affirme qu'une chose est faite ( ie toi ). Sinon ça reste que des affirmations sans fondement.
Entre temps, ils ont du voir l'engouement pour git. Et comme
je te l'ai dit, ils s'intéressent à l'intérêt stratégique de
se servir de git.
Je pense que l'équipe dirigeante est à 100 lieux des détails d’implémentation de ce genre. C'est Google, pas une de tes PMEs de 3 personnes ou tu va voir le patron. Tout au plus l'équipe en charge de l'infrastructure va avoir un intérêt à se pencher sur la question, vu que le déploiement des sites va leur tomber dessus, la gestion des dépots, les backups, etc.
Le CTO, le CFO, le CEO ? Niet, pas que ça à faire. Si ils embauchent des mecs compétents, c'est pour faire confiance à ce qu'ils font, pas pour aller faire du micro management à la dilbert.
Remarques, si FaceBook fait du mercurial, Google n'ira pas
vers HG… c'est clair ! :D !
Ah oui, et Facebook fait du Linux, donc Google n'ira pas vers Linux ?
Il y a une certaine porosité entre les boites de la Silicon Valley, et une part non négligeable de gens de l'un viennent de l'autre et vice versa.
En dehors du TLBM en vigueur sur VDM ( si l'histoire est vraie, et j'ai d'énormes doutes ), je pense que ce genre de logiciel n'existe pas. Je ne vois pas comment ça pourrait faire sonner un téléphone en particulier sans connaitre le numéro, ou sans embarquer sa propre station de base et sans émettre sur les fréquences que les opérateurs surveillent.
Sans compter le fait que ça ferait sonner plus que les élèves et que la parade est trivial, il suffit juste de mettre ton téléphone en silencieux. Ou de retirer la carte sim. Ou de prendre une calculette.
Si ton but est de perdre du karma, c'est réussi. moins bien que d'autres, mais score honorable quand même.
En même temps, ç'est utiliser que par Oracle, les mêmes qui disent que "btrfs est production ready pour vos serveurs" alors que ça n'a pas vraiment l'air d'être le consensus auprès des autres distributions.
Et Oracle te dit aussi que ça marche que sur son kernel, ce qui laisse quand même entrevoir un truc un chouia fragile à mon sens :/
Bah, si vous continuez à utiliser le pilote nvidia malgré tout les défauts, c'est que soit les jeux sont vraiment bons, soit c'est pas si insupportable que ça.
Et xorg a été créé pour contrer Wayland: je m'en souviens car je pestais aussi
dessus…
Tu te relis avant de poster, ou tu fait exprès pour remplir les fortunes ?
Et si ce que tu voulait dire, c'est que wayland a été fait pour "contrer" xorg, c'est encore une fois un usage incorrect du mot contré. Wayland a été fait car les codeurs de xorg estiment que l'architecture de xorg ne pouvait pas évolué par à coup, et qu'il fallait repartir de 0 pour se débarrasser de tout ce qui avait été accumulé. Les mecs qui bossent sur wayland sont les mêmes que ceux qui bossent sur xorg.
1) Un board of director avec Red Hat dedans.
Comme le kernel.
2) Lorsque RH met plusieurs dev chez Xorg, ce n'est pas de l'influence ça?
Vous connaissez beaucoup d'entreprises qui ont les moyens de mettre même UNE
personne (dev) pour contribuer à Xorg?
Intel a plusieurs codeurs. Google a divers codeurs, notament sur ChromeOS, si tu veux la liste exact. Canonical a 1 personne. Nokia avait des gens sur la partie input, Suse, Collabora. Même Mandriva à l'époque avait 1 personne.
Va regarder les changelogs, tu va voir qu'il y a du monde.
Non, je dis qu'on peut contrôler un serveur quelconque avec Ubuntu, via SSH
(Forward X autorisé par exemple) par exemple, et Zabbix ou Nagios comme
supervision…
Donc un type qui aime ubuntu peut très bien vouloir de l'ubuntu dans SON
bureau pour contrôler un cluster sous RHEL.
Alors la supervision, pour divers raisons, tu installes pas ça sur ton poste personel.
Dans une boite de taille correcte avec assez de serveurs ( genre 4/5 ), tu as un serveur de supervision qui est dans la même zone réseau que tes autres serveurs. La question était aussi si il était logique de le faire, pas si c'était possible. En pratique, tu peux superviser ce que tu veux avec ce que tu veux, et tu peux manager ton serveur windows depuis linux ( vu qu'il y a des clients rdp partout ) et vice versa, car il y a ssh et un serveur X partout. En gros, tu démontres encore ton inutilité en répondant à coté de la plaque.
PulseAudio est le serveur en poupe apparemment donc concrètement il sera
indispensable, notamment selon ubuntu.
Pulse est indispensable car il règle les soucis des développeurs multimédias et qu'il apporte des fonctions. La gestion facile des écouteurs bluetooth, la gestion saine de plusieurs cartes sons ( saines dans le sens ou l'utilisateur n'a rien à faire, car c'est fait par défaut avec des réglages corrects ). Rien que d'autre ne puissent faire, mais pour le moment, les gens se bousculent pas pour le faire. Donc aussi longtemps que personne ne se bougera pour faire un travail aussi bon, je pense que Pulse sera la solution utilisé car la plus adapté à la majeure partie des cas d'utilisation, donc présente par défaut.
Tiens tu me disais fièrement que c'est le patron qui décide…
Tu sembles confondre tes propos avec mes propos. SI j'ai dit ça, je demande une citation et un lien vers le commentaire linuxfr. J'ai marre que mon nom soit cité par un mec qui est incapable de comprendre les trucs basiques.
Et tu sembles diviser une entreprise en 2 groupes totalement distinct, sans imaginer qu'il y a discussion possible, je sai spas dans quel PME est ce que tu as bossé, mais ça devait pas être la joie.
En gros, une VCS de chez IBM ou Microsoft ne vaudrait pas un clou donc ils
veulent du git, pour les perfs uniquement ?
Alors 2 choses :
1) Cite les noms des produits, ça te fera déja moins passer pour un rigolo. EN l’occurrence, tu peux dire clearcase et sourcesafe.
2) Safesource ne tourne que sous windows, ne s'intégre que avec windows, et n'a que des clients windows. Autant dire que si tu as pas déja choisi windows partout, tu peux te brosser.
3) clearcase te force plus ou moins à tirer un serveur d'application webspahre, ce qui requiert d'avoir deja des admins J2EE, ce qui n'est pas forcement le cas ou la voie que tout le monde veux prendre.
Donc non, on est pas dans ton monde binaire ou soit une chose est bien, soit tout pourri. Il y a des contraintes sur ce que tu connais, ce que tu veux faire, ton archi existante, ton équipe existante.
Pour les perfs je ne sais pas, mais pour la stratégie d'une entreprise, elle
prendra ce qui est utilisé par de grand projet comme kernel.org par exemple.
Cool, donc hg est utilisé par python et par mozilla, et bzr est utilisé par Canonical et Ubuntu, mysql, emacs. Fossil est utilisé par rien.
2) Formation: J'ai mal lu ?
Y a plein de chose que tu fait mal, mais lire en fait pas parti. Par contre, il est fort probable que tu penses que "pouf, les codeurs comprennent comment marche git du premier coup", ce qui montre une fois de plus ta déconnexion complète avec le monde réel. Dans le monde réel, tes codeurs peuvent venir d'une SSII ou ils ont pas appris à se servir de git/svn/etc, sortir d'école ou l'idée de gestion de version n'est pas au programme, et donc passer d'un modéle centralisé à un modéle plus complexe requiert des formations. Venant de svn, le rebase est une idée simple mais qui n'etait pas possible. Le cherrypick non plus. La façon de faire un pull propre sans faire des commit de merge aussi. Bref, y a plein de choses que tu connais pas sur git et qu'une formation permet de clarifier.
D'habitude tu me traites d'imbécile, de demeuré, de pitoyable, et je ne sais
quoi…
Je ne pense pas avoir dit que tu es un imbécile, juste que tes propos sont imbéciles. J'ai des mots beaucoup plus dur pour l'ignorance crasse que tu affiches à longeur de temps, mais que je garde tant bien que mal par civilité.
De plus, les super ingénieurs qui me surpassent en intelligence, notamment
certains sur linuxfr, ne seraient pas capable d'apprendre un peu le git, même
les commandes simples comme merger, commiter, brancher… ?
Cf ce que j'ai dit plus haut. Tout le monde n'a pas la chance comme toi d'avoir du temps libre pour le passer en auto formation, et si tu as du te former pour utiliser l'outil, ça prouve bien qu'il faut une formation, cqfd. Sauf à demander aux gens de le faire hors du boulot, ce qui serait au mieux un procédé cavalier, et au pire sans doute un peu illégal.
Je disais que dans le passé il fallait un VCS de qualité. Donc la logique
devrait être, de mon point de vue, faire un appel d'offre sur un VCS dans
lequel on fait savoir quels sont leurs exigences (cahier des charges).
Donc, probablement que Perforce a gagné cet appel d'offre. Mais à titre
personnel je ne connais pas la stratégie de Google dans le domaine de VCS.
Alors une fois de plus, tu emploies des mots pour dire autre chose que le sens officiel. Un appel d'offre, c'est une procédure bien spécifique avec divers parties qui répondent, c'est utilisé principalement pour l'état. Je pense que ce que tu veux dire, c'est sans doute une comparaison.
Par contre, si j'étais Google, pour pouvoir capter les meilleurs, il vaut
mieux se tourner vers le VCS le plus utilisé du moment et qui est
décentralisé: git.
Je peux te garantir que même à l'époque ou Perforce était utilisé par défaut, le VCS n'avait pas d'impact sur les recrutements vu qu'il y a suffisamment d'outils par dessus pour cacher les aspects les plus moches. De plus, vu que tu n'as pas le droit de transférer le code source sur ton portable (pour les applications internes, je parle pas de trucs spéciaux comme go, chromium ou les divers projets libres de la boite) et qu'il faut bosser via ssh sur des serveurs sécurisés, les parties "pas de travail offline" et "trop lent" sont moins ennuyeuses que dans un déploiement classique.
Parce que l'annonce est pourvu, justement. Par exemple, curieusement, l'annonce a disparu, et David Henningsson est arrivé. Je te laisse chercher le reste toi même.
[^] # Re: Conclusion un peu hâtive, non ?
Posté par Misc (site web personnel) . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 4.
Bien sur, mais quel rapport avec le fait de laisser les boites reprendre sans contribuer en retour ?
Regardons le kernel Linux, qui a beaucoup de retour de grosses boites et qui est sous GPL v2. Ou gcc.
Et des projets sous BSD ( ou assimilés, genre Apache/MIT ) ont aussi des retours.
Donc on peut difficilement dire qu'il y a une corrélation, ne serais que parce que maintenir un fork de code conséquent est couteux en temps, au delà des soucis de licence.
[^] # Re: Bien bien !
Posté par Misc (site web personnel) . En réponse au journal Succès de l'extension de mesa en financement participatif. Évalué à 7.
Ça dépend de ton critère pour "qui marche". D'un point de vue de l'input de la communauté sur le projet, je pense pas que ça soit flagrant, ça reste chasse gardé de Google. Ensuite, je pense que Google fait ça avec android juste parce qu'ils ont pas le choix. Si tu va par la, Apple montre rien et ça marche aussi pour eux. Donc on peut dire que "avoir des parts de marché" n'est pas dépendant dans le mobile de "donner le code source avec du retard".
Y a pas mal de projet qui font de la relecture, genre tout les gros. Y a aussi pas mal de gens qui font de la relecture pour trouver des failles de sécurité, et donc ton chiffre de 99% est à mon sens trompeur et incorrect. Il y a des boites ( par exemple RH pour RHEL, Canonical pour la partie main ) qui font de l'audit avant d'intégrer ou de proposer quoi que ce soit. Mais oui, ça change rien si personne ne bosse avec toi d'habitude, et si tu n'as finalement aucune communauté de développeurs autour de ton produit, soit parce qu'il s'y prête pas, soit parce que le caractère du codeur ne s'y prête pas.
Je parle de la production, pas de l'usage. IE, traduire ou écrire de la documentation sans avoir accès au logiciel est un peu plus dur, et ça aboutit au final à avoir quelque chose de moins bonne qualité. Donc il faut prendre en compte le cout de faire soit même la traduction ou la documentation, ou de donner accès à la version aux bénévoles qui vont le faire dans le cadre du projet libre, ou se satisfaire d'une qualité inférieur ou la traduction est pas relu en situation, tout comme la doc.
Et je rajouterais le fait de faire des tests, des betas, etc. Il me semble évident que le nombre de sponsors testeurs est inférieur ou égal à la communauté entière, vu que les dits sponsors font parti de la communauté par définition. Encore une fois, on aboutit à un truc de moins bonne qualité, ou quelque chose qui requiert plus de travail, si la communauté est fonctionnel ( encore une fois, si elle n'existe pas, ça ne change rien ).
Justement, c'est parce qu'on sait que maintenir des branches est un cout que les gens qui ont un peu plus de bouteille poussent les choses upstream. On a vu ce que ça donne justement avec android et le kernel, et qu'au bout d'un temps, avoir tes branches sur un projet dynamique est lourd.
Au jour le jour, avoir 2 branches de dev ( la branche dispo pour tous, et la branche pour le soft sponsorisé ) fait que tu dois faire 2 fois plus de tests, que tu doit backporter les fonctionnalités et les bugfixes de l'une à l'autre. Ou que tu fait tout dans la branche sponsor, ce qui ralentit fortement les contributions externes ( chose que tu n'as peut être pas sur le projet à la base, ou dont tu te fout, mais du coup, ça me semble aller à l'encontre du développement collaboratif ).
Ensuite, ça dépend grandement de la durée du développement, mais comme tu rajoutes quelques semaines de bloquage de façon artificiellement, ça fait toujours ce temps ou tu doit faire des rebases, etc.
Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI. Si ensuite, toi, ça te va, ça veut pas dire que ça va pour tous.
Donc tu payes une pénalité, comme dans un contrat bien fait en faveur pour le client, ou le client paye sans avoir de garantie ( comme dans un contrat moins en sa faveur ) ? Ou tu impliques les avocats, comme dans un contrat classique ?
J'ai du mal à suivre en quoi ça réponds à la question "combien de temps avant que le codeur refuses quelqu'un qui va faire ça sur son temps libre alors qu'il pourrais avoir de l'argent pour le faire ?"
Des exemples de ce genre, tu en trouve autour des communautés de logiciel open-core.
Ensuite, je sais pas pour toi, mais moi, si y a un truc que j'ai pas envie de faire, c'est rarement rajouter de l'argent qui va me le faire faire, sauf si je suis vraiment à l'arrache ou si il y a vraiment beaucoup d'argent. J'ai pas encore une estime de moi si basse que je vais me vendre à pas cher pour coder un truc que je veux pas coder et en plus m'infliger de faire de la paperasse pour ça. Et pas non plus un compte en banque tellement vide que je n'ai pas le choix.
Mais bon, si ça marche pour toi et plein d'autres, tant mieux.
Je cherche pas à te convaincre du contraire, ça serait totalement idiot et ça m'apporterais rien.
Mais je reste persuadé que ça n'est pas une solution très pérenne pour les systèmes libre tel qu'ils sont aujourd'hui.
Je voit bien par contre que c'est une solution pour les développeurs propriétaires :
- moins de piratage, car au final, les gens qui veulent pas payer vont prendre la version libre
- un minimum d'implication de la communauté pour la traduction/documentation/portage, etc, donc des économies, et une qualité supérieure à un logiciel propriétaire équivalent ( vu qu'il y a rarement des traductions pour les plus petits, et souvent des horreurs pour que ça tourne sans le code source sur divers distributions et OS )
- un financement, car filer le soft gratos, ça paye rarement le loyer
- la possibilité de dire "je fait du libre (en partie )", ce qui est quand même plus glorieux et meilleur pour l'ego que "j'ai fait un shareware", du moins de nos jours sur un CV
- un argument de vente auprès des utilisateurs, histoire de dire "c'est libre, c'est bien (tm)", et de surfer sur la vague ( tout comme le crowdfunding ).
[^] # Re: Bien bien !
Posté par Misc (site web personnel) . En réponse au journal Succès de l'extension de mesa en financement participatif. Évalué à 10.
ça ne serait plus du logiciel libre du coup. Tu n'aurais pu par exemple l'intégration dans les distributions, tu n'aurais pas la relecture par d'autres codeurs de la communauté, les gens avec la feature en plus auraient moins de chance d'avoir des réponses sur le forum, et les documentations et traductions devraient être geré à part.
D'un point de vue logistique, ça semble une mauvaise idée.
Quand à l'idée de base, ça reste quand même risqué. Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ? Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?
Comment tu repartis ça dans le cas d'un travail en équipe ?
Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.
# Et pendant ce temps, sur netbsd
Posté par Misc (site web personnel) . En réponse au journal Après Wine, voici Darling pour faire tourner des applications MAC OS X sous Linux. Évalué à 5.
Je sais que des efforts en ce sens ont été fait sur netbsd il y a 10 ans :
http://2004.eurobsdcon.org/uploads/media/EBSD04_21.pdf
[^] # Re: quoi faire
Posté par Misc (site web personnel) . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 2.
Un client IRC planqué sous une table, vu qu'on essaye d'éviter d'avoir des pcs qui traine partout (noble tache qu'on a du mal à accomplir)
[^] # Re: Reddit
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 7.
C'est pas étonnant. Avoir du matériel libre pose des contraintes que je pense Canonical n'a pas le temps de prendre en compte. par exemple, de la négociation avec les fabricants, ce qui reviens à payer plus cher, ou à sortir plus tard. Et le temps et l'argent ne sont pas des ressources qu'ils ont en abondance.
[^] # Re: Précision importante
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 2.
Conserver le même taux, ça implique que le buzz ne fonctionne pas comme les autres et que ça ne s'essouffle pas.
Ceci dit, la question de savoir si ils arrivent ou pas n'est pas importante. Si ils arrivent pas, mark peut compléter, et si ils arrivent, est ce que ça suffiras ou pas ?
Sachant que ça, c'est pour la production de 50000 unités, il faudra remettre plus, voir beaucoup plus pour viser la production de masse. Donc le tout est de savoir si Canonical compte dire "on a réussi à faire du buzz, on a vendu 50000 unités en mettant l'équivalent de notre chiffre d'affaire, donc faut nous filer des thunes", ou est ce que Canonical compte être bénéficiaire dans l'opération, et va financer d'autres produits ?
En fait, l'année dernière, on attendais des partenaires, on a rien eu. On attendais des partenaires pour ubuntu tv, y a rien eu. On pourrait se dire "ouais, mais c'est dur", mais Mozilla, de taille comparable à l'époque à Canonical, a réussi à faire un OS, et à réussi à avoir des partenaires. En fait, même des produits comme le freerunner ont réussi à avoir un fabricant derrière ( en l’occurrence, FIC ).
[^] # Re: soc arm a priori
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 10.
Ah oui, ça cible tout de suite mieux. Et un écran couleur aussi, pour rester dans la précision renversante :) ?
Ceci dit, prendre une cpu dual core i7, ça donne une bonne histoire pour la convergence, "ubuntu edge permet aussi de cuire votre steak", ça aurait du succès. Tu fait un sponsoring de man vs wild, et voila. D'un coté, GPS, de l'autre, grill.
[^] # Re: et l'éthique ?
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 3.
Finalement, c'est plus facile d'avoir une éthique inverse. Tu sais jamais si les gens sont fouettés, mais y a plus de chance que ça arrive.
[^] # Re: Précision importante
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 7.
Si ils chopent 25 millions de $, à 500$ l'unité ( pour des calculs qui tombent rond ), ça va faire 50 milles unités.
Ça ferait grosso modo 150 fois moins que les ventes de Lumia sur le premier trimestre ( http://www.01net.com/editorial/600273/smartphone-les-ventes-de-nokia-lumia-excedent-celles-de-blackberry/ ).
Pour donner une autre comparaison, ça serait l'équivalent des activations android en 18 minutes dans le monde.
Ça me ferait mal au cœur pour Canonical si c'était juste ça.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 2.
Le n9 n'a jamais couté 810€, le S4 vaut 513€ maintenant, et même le plus cher des iphone n'est qu'à 900€. D'ailleurs, Canonical a bien vu que c'est trop cher et a revu le tarif à la baisse.
Et Apple et Samsung ont ce prix et ont un os et des équipes rodés, ils ont déja rentabilisé les couts initiaux depuis longtemps. Ils produisent aussi à plusieurs millions d'exemplaires, pas un batch de moins de 100 000. Donc même la, la production de masse est en faveur des concurrents.
je suis pour le fait que Canonical réussisse, mais faut pas se leurrer non plus.
[^] # Re: Même analyse que l'auteur de l'article
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 5.
J'ai quand même des doutes.
D'une part, ça va pas t'offrir la vrai mobilité que tu espères. Des téléphones avec des sorties hdmi, y en a déjà, et je pense pas que les gens utilisent. Si jamais tu as besoin d'un clavier souris et du dock kivabien, tu va au mieux basculer de chez toi au boulot, mais pas plus. Donc dans l'état et sans une ubiquité du système, je pense pas que ça soit un avantage décisif.
Ensuite, l'expérience d'openmoko montre quand même que faire un téléphone, c'est couteux et complexe. Couteux car tu as les divers certifications à faire, car tu as pas de references dispo pour faire mieux, etc. Complexe car tu as les bugs de dernière minutes dans les drivers videos proprios, parceles devs capables de faire de l'ARM, ça court pas les rues, et ça va encore moins courir bientot avec la montée en puissance de l'architecture. L'arm, ça reste ( sauf erreur de ma part) un truc qui pète au run time sur l'alignement, d'ou l'investissement de Canonical dans les tests auto. Mais tu as aussi les merdes causés par les périphériques mal documentés, par les bugs hardwares à la con, etc.
Et je parle pas du fait que la campagne de crowdfunding se fait sur le monde entier, ce qui fait que Canonical va devoir se taper les taxes et les détails moisis sur toute la planète, ce qui est pas une mince affaire.
[^] # Re: Qui nous observe ?
Posté par Misc (site web personnel) . En réponse au journal Un Firefox qui respecte votre vie privée. Évalué à 4.
Amusant et relativement lent. J'ai fait tourner l'extension depuis 1 ou 2 mois, ça mets 1 minute à afficher tout. Je sais pas si c'est un souci devant les données à afficher ( genre 2000 nœuds ) ou si le code est un peu naif, ou si le js est vraiment lent.
[^] # Re: elle est connue
Posté par Misc (site web personnel) . En réponse au journal Gnu/Linux est une passoire. Évalué à 3.
aussi longtemps que tu auras un moyen pour l'utilisateur de passer outre, ça ne serviras à rien.
Tu peux mettre rm -i par défaut, si tu as un -f qui surcharge le -i, ça sert à rien.
Et forcer la question ne serais vu que comme une nuisance.
[^] # Re: elle est connue
Posté par Misc (site web personnel) . En réponse au journal Gnu/Linux est une passoire. Évalué à 2.
Bien sur, le tutoriel moyen est souvent dans l'optique "on va résoudre sans se soucier du comment", et personne ne pense sur le long terme sur l'éducation des gens.
Par exemple, le modèle windows xp/95 de tout le monde est admin est problématique d'un point de vue sécurité. Mais le modèle vista des popups à tout va est aussi un souci, vu que les gens passent le temps à être ennuyé par ça, et ne lise plus, sont interrompu, etc.
Et toute tentatives de retirer les dits popups une fois qu'ils sont la depuis longtemps ( exemple, ce que packagekit a tenté de faire ) devient tout d'un coup un affront pour les gens qui n'ont pas de souci avec la complexité.
À ce niveau la, on a les mêmes soucis sur les UI Linux que Windows, et quoi qu'on dise, les mêmes types de gens font les UIs, les mêmes types de gens ne sont pas au courant des soucis que ça pose au jour le jour, et donc on abouti aux mêmes oppositions.
Et au final, en ne faisant pas mieux que Windows, on arrive pas à bouger le status quo, et donc windows reste majoritaire.
Donc même si "c'est pas mieux sur windows", ça n'est pas une excuse pour pas penser à faire mieux. Dans le cas précis de cette vulnérabilité, le souci est que ce que l'utilisateur colle ne corresponds pas à ce qu'il voit. Ça contredit totalement le modèle mental qu'on a du copier/coller quand on ne sait pas comment ça marche.
Dans ce cas précis, est ce que firefox devrait prendre que le contenu qui est visible pour le mettre dans le presse papier ? peut être, mais ça reste très complexe à faire, et sans doute facile à contourner. Est ce que faire ça n'aurait pas d'effet de bord ? Peut être aussi.
Est ce qu'il faut interdire à kill de faire ça ( ie, kill -1 ) sans demande express à l'utilisateur ? ( comme rm -Rf / qui pose la question, comme rm sous zsh qui demande confirmation ). L'attaquant rajouterais juste ce qu'il faut pour valider. Et ça n'aiderais pas pour une faille plus subtile de "je rajoute ma clé ssh dans le keyring et je rajoute un cron qui donne l'ip pour que je me fasse pirater la tronche".
On peut imaginer avoir un plugin qui détecte que le fichier est un .txt mais qu'en fait, c'est du html, donc fishy (mais ça aiderais pas beaucoup). On pourrait voir qu'il y a un copier coller qui correspond pas à ce qui s'affiche, et mettre un warning.
# Yum n'est pas orphelin
Posté par Misc (site web personnel) . En réponse au journal Yum est orphelin. Évalué à 10.
Seth ne travaillait plus sur yum depuis longtemps, qui est maintenant maintenu par d'autres. Depuis quelques années, il était dans l'équipe d'admin sys pour l'infrastructure fedora, et il était en train de travailler sur la migration de puppet vers ansible, ou la mise en place de copr, un équivalent aux PPAs de launchpad si j'en croit ses derniers posts de blogs.
Même si j'ai pour ainsi dire jamais interagi avec lui et que j'ai surtout senti la partie "grumpy" de son rôle de sysadmin sur irc, les louanges sur planet fedora pleuvent, et il était très apprécié pour ses qualités humaines. Donc c'est une perte pour la communauté Fedora et pour le libre en général, comme tant d'autres avant lui ( je pense notamment à Eugeni Donodov, mort dans des circonstances similaires à vélo il y a 1 an, ce qui calme fortement mes envies de me remettre à rouler sur mon 2 roues vu que je ne suis pas la prudence incarné dans ce domaine ).
[^] # 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, tu as montré plus d'une fois que tu ne comprends rien. Je doute que ça soit aujourd'hui que ça commence. Arrête de prétendre le contraire, et arrête de me faire tenir des propos que j'ai pas. Si je dit pas un truc, je le dit pas.
D'une part, tu sors tes chiffres de ton chapeau, des gens qui codent pas sur leur temps libre, y en a beaucoup plus que tu crois, et d'autre part, c'est pas parce que tu dois faire un truc que les gens le font. Par exemple, toi, tu devrais te taire et réfléchir avant de poster, et tu le fait pas.
Tu le connais déjà, mais tu as des doutes.
Contrairement à toi, j'arrive à voir plus loin que ma boite. Et C'est pas "quelques minutes" qu'il faut, c'est plus "quelques jours". Dans une SSII classique avec un ingé facturé à 500€ la journée pour du dev, ça te coute 2000€/p juste en productivité perdu de faire 4j de formation. Et encore, 500€, c'est des ingés pas trop chers, estimation à la louche pour l'époque ou j’étais encore dans le circuit. Ça te semble sans doute négligeable mais si tu commences à faire ça pour plusieurs ingés, ça te coute le salaire d'un seul, soit 1 mois de travail sur le projet et la, ça deviens vachement plus visible. Et c'est en partant du principe qu'aprés 4j, ils sont parfaitement rodé.
Et la, on parle que de la formation, tu as parfaitement oublié et passer sous le tapis les choses comme les scripts de builds, l'intégration avec le bugtracker, les outils clients side, les possibles hooks du coté du dépôt, le changement de procédure de backups, etc, etc.
Tu tires ça de ton chapeau
ça me parait surtout trop peu.
Non, c'est juste les faits. J'ai jamais eu à me servir de fossil pour le moindre logiciel. Et pourtant, je suis déjà sur p4 ( zimbra ), sur tla, sur monotone, et des trucs qui selon toi serait plus obscure.
Ah oui, y a un accès ssh donc les gens l'utilisent. Comment ne pas avoir vu ça plus tôt ? Ah oui, parce que ça n'a comme d'hab avec toi aucun rapport.
Encore une fois, non. Ou alors démontre le, vu que la charge de la preuve est à celui qui affirme qu'une chose est faite ( ie toi ). Sinon ça reste que des affirmations sans fondement.
Je pense que l'équipe dirigeante est à 100 lieux des détails d’implémentation de ce genre. C'est Google, pas une de tes PMEs de 3 personnes ou tu va voir le patron. Tout au plus l'équipe en charge de l'infrastructure va avoir un intérêt à se pencher sur la question, vu que le déploiement des sites va leur tomber dessus, la gestion des dépots, les backups, etc.
Le CTO, le CFO, le CEO ? Niet, pas que ça à faire. Si ils embauchent des mecs compétents, c'est pour faire confiance à ce qu'ils font, pas pour aller faire du micro management à la dilbert.
Ah oui, et Facebook fait du Linux, donc Google n'ira pas vers Linux ?
Il y a une certaine porosité entre les boites de la Silicon Valley, et une part non négligeable de gens de l'un viennent de l'autre et vice versa.
# Hum
Posté par Misc (site web personnel) . En réponse au journal Privé de bac à cause d'un logiciel propriétaire. Évalué à 10.
En dehors du TLBM en vigueur sur VDM ( si l'histoire est vraie, et j'ai d'énormes doutes ), je pense que ce genre de logiciel n'existe pas. Je ne vois pas comment ça pourrait faire sonner un téléphone en particulier sans connaitre le numéro, ou sans embarquer sa propre station de base et sans émettre sur les fréquences que les opérateurs surveillent.
Sans compter le fait que ça ferait sonner plus que les élèves et que la parade est trivial, il suffit juste de mettre ton téléphone en silencieux. Ou de retirer la carte sim. Ou de prendre une calculette.
Si ton but est de perdre du karma, c'est réussi. moins bien que d'autres, mais score honorable quand même.
[^] # Re: no reboot
Posté par Misc (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 3.
En même temps, ç'est utiliser que par Oracle, les mêmes qui disent que "btrfs est production ready pour vos serveurs" alors que ça n'a pas vraiment l'air d'être le consensus auprès des autres distributions.
Et Oracle te dit aussi que ça marche que sur son kernel, ce qui laisse quand même entrevoir un truc un chouia fragile à mon sens :/
[^] # Re: Petite erreur
Posté par Misc (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 2.
Si, je me suis aussi fait la remarque.
[^] # Re: LinuxFR
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Ruby on Rails 4.0. Évalué à 5.
https://linuxfr.org/code_source_du_site
=> https://github.com/nono/linuxfr.org
"This git repository is the rails application that run on LinuxFr.org."
[^] # Re: Que du bon
Posté par Misc (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
Bah, si vous continuez à utiliser le pilote nvidia malgré tout les défauts, c'est que soit les jeux sont vraiment bons, soit c'est pas si insupportable que ç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.
Tu te relis avant de poster, ou tu fait exprès pour remplir les fortunes ?
Et si ce que tu voulait dire, c'est que wayland a été fait pour "contrer" xorg, c'est encore une fois un usage incorrect du mot contré. Wayland a été fait car les codeurs de xorg estiment que l'architecture de xorg ne pouvait pas évolué par à coup, et qu'il fallait repartir de 0 pour se débarrasser de tout ce qui avait été accumulé. Les mecs qui bossent sur wayland sont les mêmes que ceux qui bossent sur xorg.
Comme le kernel.
Intel a plusieurs codeurs. Google a divers codeurs, notament sur ChromeOS, si tu veux la liste exact. Canonical a 1 personne. Nokia avait des gens sur la partie input, Suse, Collabora. Même Mandriva à l'époque avait 1 personne.
Va regarder les changelogs, tu va voir qu'il y a du monde.
Alors la supervision, pour divers raisons, tu installes pas ça sur ton poste personel.
Dans une boite de taille correcte avec assez de serveurs ( genre 4/5 ), tu as un serveur de supervision qui est dans la même zone réseau que tes autres serveurs. La question était aussi si il était logique de le faire, pas si c'était possible. En pratique, tu peux superviser ce que tu veux avec ce que tu veux, et tu peux manager ton serveur windows depuis linux ( vu qu'il y a des clients rdp partout ) et vice versa, car il y a ssh et un serveur X partout. En gros, tu démontres encore ton inutilité en répondant à coté de la plaque.
Pulse est indispensable car il règle les soucis des développeurs multimédias et qu'il apporte des fonctions. La gestion facile des écouteurs bluetooth, la gestion saine de plusieurs cartes sons ( saines dans le sens ou l'utilisateur n'a rien à faire, car c'est fait par défaut avec des réglages corrects ). Rien que d'autre ne puissent faire, mais pour le moment, les gens se bousculent pas pour le faire. Donc aussi longtemps que personne ne se bougera pour faire un travail aussi bon, je pense que Pulse sera la solution utilisé car la plus adapté à la majeure partie des cas d'utilisation, donc présente par défaut.
[^] # 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.
Tu sembles confondre tes propos avec mes propos. SI j'ai dit ça, je demande une citation et un lien vers le commentaire linuxfr. J'ai marre que mon nom soit cité par un mec qui est incapable de comprendre les trucs basiques.
Et tu sembles diviser une entreprise en 2 groupes totalement distinct, sans imaginer qu'il y a discussion possible, je sai spas dans quel PME est ce que tu as bossé, mais ça devait pas être la joie.
Alors 2 choses :
1) Cite les noms des produits, ça te fera déja moins passer pour un rigolo. EN l’occurrence, tu peux dire clearcase et sourcesafe.
2) Safesource ne tourne que sous windows, ne s'intégre que avec windows, et n'a que des clients windows. Autant dire que si tu as pas déja choisi windows partout, tu peux te brosser.
3) clearcase te force plus ou moins à tirer un serveur d'application webspahre, ce qui requiert d'avoir deja des admins J2EE, ce qui n'est pas forcement le cas ou la voie que tout le monde veux prendre.
Donc non, on est pas dans ton monde binaire ou soit une chose est bien, soit tout pourri. Il y a des contraintes sur ce que tu connais, ce que tu veux faire, ton archi existante, ton équipe existante.
Cool, donc hg est utilisé par python et par mozilla, et bzr est utilisé par Canonical et Ubuntu, mysql, emacs. Fossil est utilisé par rien.
Y a plein de chose que tu fait mal, mais lire en fait pas parti. Par contre, il est fort probable que tu penses que "pouf, les codeurs comprennent comment marche git du premier coup", ce qui montre une fois de plus ta déconnexion complète avec le monde réel. Dans le monde réel, tes codeurs peuvent venir d'une SSII ou ils ont pas appris à se servir de git/svn/etc, sortir d'école ou l'idée de gestion de version n'est pas au programme, et donc passer d'un modéle centralisé à un modéle plus complexe requiert des formations. Venant de svn, le rebase est une idée simple mais qui n'etait pas possible. Le cherrypick non plus. La façon de faire un pull propre sans faire des commit de merge aussi. Bref, y a plein de choses que tu connais pas sur git et qu'une formation permet de clarifier.
Je ne pense pas avoir dit que tu es un imbécile, juste que tes propos sont imbéciles. J'ai des mots beaucoup plus dur pour l'ignorance crasse que tu affiches à longeur de temps, mais que je garde tant bien que mal par civilité.
Cf ce que j'ai dit plus haut. Tout le monde n'a pas la chance comme toi d'avoir du temps libre pour le passer en auto formation, et si tu as du te former pour utiliser l'outil, ça prouve bien qu'il faut une formation, cqfd. Sauf à demander aux gens de le faire hors du boulot, ce qui serait au mieux un procédé cavalier, et au pire sans doute un peu illégal.
Alors une fois de plus, tu emploies des mots pour dire autre chose que le sens officiel. Un appel d'offre, c'est une procédure bien spécifique avec divers parties qui répondent, c'est utilisé principalement pour l'état. Je pense que ce que tu veux dire, c'est sans doute une comparaison.
Je peux te garantir que même à l'époque ou Perforce était utilisé par défaut, le VCS n'avait pas d'impact sur les recrutements vu qu'il y a suffisamment d'outils par dessus pour cacher les aspects les plus moches. De plus, vu que tu n'as pas le droit de transférer le code source sur ton portable (pour les applications internes, je parle pas de trucs spéciaux comme go, chromium ou les divers projets libres de la boite) et qu'il faut bosser via ssh sur des serveurs sécurisés, les parties "pas de travail offline" et "trop lent" sont moins ennuyeuses que dans un déploiement classique.
[^] # 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.
Parce que l'annonce est pourvu, justement. Par exemple, curieusement, l'annonce a disparu, et David Henningsson est arrivé. Je te laisse chercher le reste toi même.