fredix a écrit 1945 commentaires

Je ne connaissais pas, intéressant, c'est full libre ? Et malgré une interface web sexy ça me parait toujours trop complexe pour le grand public.
Je suis de plus en plus convaincu que pour proposer un service auto-hébergé simple il ne faudrait plus se baser sur les stacks logiciels serveur classique, mais sur un nouvel outil du genre retroshare ultra simplifié.

Parce que la liberté 0 implique de pouvoir exécuter un programme sans restriction ?
Mais je ne conseille de ne plus utiliser leurs logiciels si tu n'as pas confiance, on sait jamais…

ton NAS héberge un serveur mail, DNS, jabber ? c'est quoi le rapport

Perso j'aurais plus confiance en la FSF pour respecter ma vie privée qu'en n'importe quelle entreprise, d'autant plus chez Google, Microsoft, Yahoo, etc.

J'ai testé la démo ca me parait intéressant, mais ca ne propose que des web app, pas possible d'intégrer un serveur mail/jabber/web et le configurer en 1 click je suppose, parce que c'est de cela dont on parle.

Il me semble que l'article de bortzmeyer pose la question comment rendre l'auto hébergement accessible au plus grand nombre. Les réponses d'informaticiens qui le font sont juste hors sujet….

Je crois que la meilleure réponse à ta question est celle de jbfavre dont tu donnes le lien à la fin de ton article L'auto-hébergement, ou le risque de Loto-hébergement ?.
Parce que mis à part les autistes qui vivent dans leur grotte, il est ridicule de vouloir transformer les gens en admin système. Et faire une interface web pour le grand public qui simplifierait la configuration d'un serveur mail, DNS, jabber, c'est à mon avis voué à l'échec quand bien même certains y essayent.

Bref l'hébergement associatif me parait largement plus crédible, d'ailleurs il est à noter que la FSF se décide enfin à "vendre" du service ou du moins à se financer en proposant un compte XMPP à leurs membres. Peut être qu'en 2020 ils auront l'idée de proposer en sus un webmail … ?

Il vient d'atteindre 50$ l'unité : https://mtgox.com

Bravo pour ton

Would you like a hosted version of this software by paying a small fee like $1/month?

Parce qu'il est temps que l'on propose des services en ligne et pas que du logiciel à s'installer, configurer et s'héberger soit même. Et qu'il n'y a pas de raison que ce service en ligne soit forcément gratuit. Le paiement en bitcoin serait top :)

Sinon que pense tu de l'idée de supporter remotestorage ?

Bien sûr ce n'est pas totalement sûr puisque je stocke la configuration de la yubikey pour ne pas me retrouver à nu si je la perd ou si je la casse.

Tu la stocke dans keepassx ?

En effet, d'ailleurs je ne connaissais pas la RPL, on en apprend tous les jours.

Ah en effet que peut être qu'en AGPL le code de la version modifié du service doit être fourni à l'utilisateur et pas obligatoirement à l'auteur. Mais bon rien empêche qu'un utilisateur transmette les modifications à l'auteur.

Si le logiciel en question est utilisé via Internet, comme un site ou un service web, il me semble que la licence AGPL couvre ce problème.

bah suffit d'emballer sa carte dans du papier alu non ? bon ok c'est moche.

Taff avec de l'opensource, quelques technos qui datent de moins de 20 ans, boite, management et projet crédible, pas la lune donc. Sophia c'est souvent pour bosser pour Orange, on a vu mieux, le reste à part quelques exceptions deci delà, c'est Paris, et pour les plus sérieux/envoutant, Londres et les USA.

Ca t'étonne tant que ca que les boites qui font les choses bien cherchent à recruter des gens compétents et pro ?

Ca ne m'étonnes pas, je fais juste un constat.

Mais soyons sérieux deux minutes. Actuellement on est un métier où les gens compétents sont très recherchés, très bien traités et payés. Les portes sont grandes ouvertes contrairement à beaucoup d'autres métiers qui se sont fait entièrement verrouiller.

Oui tout à fait, à la condition de vouloir vivre à Paris, Londres, ou aux USA.

Quel est le problème ? Si on te fait sciemment saborder les projets et perdre ton temps, c'est qu'il est tant d'aller voir ailleurs non ?

Certes, certes, sauf que les 10% de boites sérieuses restante, il y a du bon dev qui fait la queue pour y entrer, bref elles ont le choix … :)

Oui mais ça implique des rapports de force, pas tout le monde a envie ou peu les gérer. Si comme le préconise l'auteur du texte, l'ingénieur était invité dès le départ à la réflexion à la création, il y aurait moins de tensions après coup et plus de réussite.
Perso je remarque juste que les boites qui réussissent vraiment ont intégré dans leur stratégie de management la vision de l'Ingénierie. L'ingénieur n'est pas juste là pour pisser du code, mais influe directement sur les produits voir même en est à l'origine (les 20% de projets perso chez Google par exemple) et ça change tout.
En France, les boucheries sont gérés par des bouchers, les cabinets comptables par des experts comptables, les cabinets dentaires par des chirurgiens dentistes, et les SSII/éditeurs par des commerciaux, tout est dit :)

C'est pas si simple. 90% des devs ont conscience de taffer dans une des boites de merde qui représentent 90% des boites en info… Dans ces boites dire non à un projet c'est dire non à tous les projets de la boite. Le problème n'est pas le projet en lui même mais sur l'organisation de la boite, sur le comment elle manage ses projets et donc ses ingés par des marketeux et/ou commerciaux…
Le "yakafokon argumenter le refus" ça fait un peu bisounours land :) Mais ca marche surement dans quelques boites un peu moins merdique que les autres.

Mais cela m'a appris à refuser.

C'est bien tu as de la chance de pouvoir refuser. Le problème est quand dans la plupart des boites tu es mal barré point de vu carrière si tu refuses ….
Je continue à penser que tu ne vies pas, et c'est tant mieux bien sur, ce que vive la majorité des devs.

Je conteste le fait, notamment, qu'il voit la création d'un logiciel comme une cascade. Ce modèle est trivialement dysfonctionnel et c'est prouvé depuis des décennies.

J'ai plutôt l'impression qu'il dénonce que les décideurs voient le développement de cette manière ce qui amènent aux conséquences qu'il présente. De la à conclure que son texte n'est pas crédible c'est juste une blague. Son texte il doit y avoir 90% de devs qui l'on vécu et le vive.

Il y a un juste milieu entre définir un cahier des charges exhaustif (impossible) et la méthode larache. Désolé mais dans la réalité d'une grande majorité de développeurs c'est cette dernière qui est subie.
Et il préconise d'intégrer les dev dans le processus créatif, il n'y a rien de plus crédible et évident à cela.
Apparemment tu dois vivre sur une autre planète ou bien un de ces rares et chanceux développeur qui n'a jamais vécue ce qu'il démontre.

ok merci pour l'info !

En effet désolé pour le bruit. Par contre cette page indique qu'il y a un toujours un global lock ce qui n'aide pas en perf je présume.

Je ne suis plus l'actu de Ruby notamment de la VM. Elle utilise toujours les green threads ? La 2 ou la 1.9 utilise t-elle une nouvelle implémentation plus efficace ?