nud a écrit 906 commentaires

Le correctif pour ce ticket se trouve ici: https://github.com/nono/linuxfr.org/pull/170

Pourquoi ne pas mettre le journal initial en tant que premier commentaire de la dépêche et relocaliser tous les commentaires initiaux sous celui-ci?

Bref, j'avais vraiment pensé que Shift avait fait une faute de frappe

C'est l'un des problèmes avec les réformes orthographiques, c'est que pour les "vieux", les "jeunes" qui écrivent avec la nouvelle orthographe ont tendance à passer pour des illettrés. Mine de rien, ça peut poser un problème pour les gens qui rédigent des lettres de motivations, etc.

Si mais

• c'est pas libre.
• c'est probablement pas le serveur que programme le gus en question.

Ils vont utiliser linux, mais pas gnu/linux.

J'hésite entre pognon et oignon.

En Belgique une habitation sans raccordement à l'électricité publique est considérée comme insalubre. Ceci ne t'empêche cependant pas d'y habiter je suppose.

Et, accessoirement, tu n'as pas le choix, tu es obligé d'avoir un abonnement à un fournisseur d'électricité.

Et, accessoirement, les cartes rfid sont en passe d'anéantir totalement la capacité qu'a quelqu'un de se déplacer anonymement autrement qu'à pieds.

C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.

Alors, il faut apprendre aux développeurs java le concept de compatibilité ascendente et de stabilité des API/ABI. Enfin, note qu'on matraque déjà ça aux développeurs ruby mais que ça ne veut pas rentrer.

mais c'est quasiment uniquement par l'ajout de nouvelle fonctionnalité, pas en corrigeant les erreurs du passé

C'est parfois même à l'extrême, pour preuve les nouveaux keywords en _Foo parce que on ne veut pas casser la moindre ligne de code pré-existant...

Utiliser certes, mais pas revendre.

Dans ce cas, mon reproche n'a pas lieu d'être, j'avais mal compris, mea culpa.

Tout ça pour ça ?!

C'est aussi l'une des conclusions du post de mjg59 (que j'aurais peut-être dû faire transparaître dans le journal): si vous êtes l'auteur de code important, en particulier dans Linux, répondez à l'appel de la SFC.

Il y a quand même une chose que je ne comprends pas.

Certes la GPL pour les bibliothèques c'est chiant. Au boulot je suis le premier à utiliser du LGPL ou du BSD parce que le GPL, ben je peux pas (et c'est pas moi le boss). Ceci dit je ne vois pas le problème avec la LGPL qui n'"infecte" pas les parties propriétaires du code.

À la limite je peux comprendre aussi pour le kernel car tout qui veut mettre un nouveau driver est obligé de le libérer selon la GPL, encore que les gens du kernel soient volontairement laxistes à ce sujet il me semble.

Mais pour des packages logiciels bien délimités et non extensibles comme busybox, je ne vois même pas l'intérêt que quelqu'un peut avoir à ne pas respecter les termes de la licence.

D'après mjg59, le but est ici avant tout de contourner le fait que les gens derrière busybox soutiennent la SFC. En effet, s'ils n'utilisent plus aucun logiciel écrit par des gens qui la soutiennent, celle-ci perd toute légitimité et ne peut obliger les entreprises à se conformer aux termes des licences des logiciels qu'ils utilisent et revendent. En gros, busybox est un point d'entrée.

C'est toujours un peu la même histoire, comme quand $FAI ou $FABRICANT refuse de donner les sources des logiciels GPL qu'il a utilisé et altéré dans le routeur ou le téléphone qu'il distribue en centaines de milliers d'exemplaires.

Après, dans le cadre du projet GNU, on peut argumenter sur le fait que le projet a également une vocation technique (accès aux sources, etc) et pas juste idéologique.

Si tel est le cas, alors ils ne sont probablement pas plus en tort que Mobistar, SFR, Bouygues et les autres, qui ont tous des logs qui sont (oh horreur) consultables par la police en cas de perquisition.

Le "problème" ici est peut-être juste que Google est une entreprise américaine. Il faut voir si les logs sont soumis à la loi locale ou à la loi américaine.

Faudrait une section goodies en haut à droite, dont les bénéfices seraient intégralement dédiés à la protection des manchots. Ça permettrait de remplir la catégorie "acheteurs".

La différence qui compte c'est quand même la fin de l'obligation de compter les colonnes, qui est quand même un changement important qui a cassé la compatibilité avec tout le code ancien.

Pour les plus jeunes, en Fortran 77, les 6 premiers caractères de la ligne sont utilisés pour les étiquettes, les caractères 7 à 72 servaient pour le code, et le reste était ignoré, donc était utilisé pour mettre des annotations. Cette façon de faire adaptée aux cartes perforées peut provoquer des bugs assez comiques si l'on n'y prend garde...

Dit moi ton besoin, je te dirai comment t'en passer

Tu exagères. Je ne sais pas à quoi correspond ta réalité, mais dire que l'auto-hébergement (pour quelque définition de auto-hébergement qui ne semble pas être partagée par tout le monde de toute façon) ne fonctionne pas est complètement biaisée. Ce n'est peut-être pas la panacée dans certains cas mais la situation d'un endroit à l'autre, d'une société à l'autre, est totalement différente.

Il n'y a pas de solution magique mais l'auto-hébergement fonctionne pour énormément de gens, pour des raisons qui les regardent (que ce soit une question de confidentialité ou bêtement "je ne peux pas faire autrement avec mon Exchange"). Donc dire que tout le monde dit des conneries juste parce que cela ne correspond pas à ta conviction profonde, cela suffit.

Personne n'a suggéré de mettre un datacenter derrière une ligne ADSL. Seulement voilà, un serveur mail pour trois personnes derrière une ligne ADSL, cela fonctionne. Un serveur mail pour 20 personnes derrière une ligne un peu plus costaude, cela fonctionne aussi. Et un serveur mail auto-hébergé pour une boite de 300 personne qui a une fibre (c'est très facile d'avoir une fibre, en tout cas en Belgique) cela fonctionne très bien aussi.

Et pour ce qui est de la fiabilité c'est juste une question de contrat avec ton FAI. Je connais une zone de police en Belgique qui auto-héberge son serveur e-mail. Or ils doivent être accessibles 24/7, et cela fonctionne. Ils ont deux accès internet (dont un en fibre) et tout a été pensé en fonction de la fiabilité en prenant en compte l'impératif de confidentialité. Mais c'est auto-hébergé dans le sens ou le serveur e-mail et le reste sont hébergés sur site.

Après si tu n'as pas besoin de confidentialité ni de contrôle, les diverses solutions "cloud" fonctionnent (gmail ou office 365). Si tu as besoin d'un peu plus de contrôle tu peux avoir un serveur hébergé dans un datacenter. Si tu es sur la dèche tu peux mettre ton serveur mail derrière ta connexion ADSL pourrie et mordre sur ta chique.

Confidentialité, Efficacité, Bas Prix, Simplicité, mais pas tous en même temps.

Oui, après, c'est pas toujours rassurant. Je cite:

At Google we recognize that privacy is important.

En l'occurrence ils se mettent à dire ce qu'ils ne font plus avec GNU/Linux !

Tu te fourvoies mon ami, les serveurs gmail fonctionnent sous linux!

Reste à voir le coût d'une plainte (en temps, en argent et en emmerdement) par rapport à juste aller chez un autre prestataire.

Oui, après, en général, si tu héberges ton serveur dans ta société, 99.9% du temps si quelqu'un doit synchroniser la totalité de ses mails il le fera depuis le bureau. S'il est en déplacement, il ne resynchronisera jamais la totalité de la boite, il se contentera de récupérer les nouveaux mails.

Puis y'a le SDSL aussi.

Ce qui revient à tout acheter en double. Minimum.

Bof. Si tu travailles avec des VM tu as de toute façon au moins deux hosts qui peuvent reprendre la charge au cas où (quitte à éteindre des trucs moins importants). Sinon, tu bosses probablement avec ta marque préférée donc tous tes serveurs sont sans doute relativement proches au niveau hardware. Puis tu as sans doute bien un vieux serveur que tu n'utilises plus et que tu peux utiliser le cas échéant, car je doute que ton serveur mail nécessite la crème de la crème si c'est juste temporaire. De toute façon, le fait d'avoir un peu de spare (ou un contact qui peut en fournir sans délai) est juste un pré-requis si tu veux avoir une informatique fiable en entreprise, et pas juste pour l'e-mail.

Après, oui, les VM, c'est quand même génial pour ça.

Ok, pour rire essaye de faire écrire à ton FAI que tu auras accès au port 5662 en entrant sur ta connexion pour les 3 prochaines années.

Bah dans le contrat y'a écrit que tous les ports TCP et UDP sont accessibles, qu'il n'y a aucun bloquage. Après je ne sais pas ce que ça dit en France, mais généralement tu choisis ton fournisseur en fonction de tes besoins, et ce qu'il garantit, il le garantit, point. Si Vivendi a eu besoin de faire appel à Colt, grand bien leur fasse, mais si l'on suit ton raisonnement, il n'est pas impossible que Colt modifie un jour ses services et bloquent ton fameux port 5662 pour une mauvaise raison ou l'autre.

Oui, et à moins que tu n'envoies et ne reçoivent tous tes mails en connexion directe (MX initial à MX destinataire sans MTA intercallé), et que tu ne passe pas toutes tes connexions via tunnels sécurisé c'est aussi le cas de ton FAI et du peer principal de ton FAI (au moins pour 80% des infos).

C'est d'ailleurs une grande crainte vis à vis de la tendance de ces derniers temps: on envoie n'importe quoi par e-mail, comme par exemple un lien avec "infos de login" pour ne pas devoir mettre son mot de passe quand on clique dans un mail qu'on reçoit, et tout cela passe en clair. Personne ne pense même à utiliser (ou à donner l'option d'utiliser) une technique comme PGP/GPG...