Anonyme a écrit 62265 commentaires

GMX en france est géré par 1&1 via feu-caramail, et se finance par la pub sur son webmail. Le support en cas de problème est comme partout ailleurs, automatisé donc inexistant. Et si tu passes par leur webmail, ils modifient les liens externes sous prétexte de protéger leurs utilisateurs du référencement des sites cibles, mais en pratique cela veut dire que tes emails subissent des traitements non désirés: est ce qu'on peut leur faire confiance pour dire que cela se limite au déréférencement des liens externes ou bien font ils autre chose de tes données ? je ne saurai le dire … ce qui est sur c'est que le lien n'est pas simplement passé à un script qui le nettoie, mais qu'il est stocké dans une base de données puisqu'il est remplacé par un identifiant unique dans le mail que tu consultes.

Si c'est pour de la mailing list ou des échanges publics, ca reste acceptable.

Sinon, tu trouveras 3 solutions ici, certainement plus fiables que GMX.
Ce n'est pas beaucoup mais c'est un début.

Comme deja dit je sais pas combien de fois ca n'a rien à voir avec apt-get ou le gestionnaire de packages. Utiliser apt-rpm (version d'apt-get pour rpm) va pas magiquement rendre la procedure d'upgrade testée, debugguée et supportée. Et yum/rpm ont deja toutes les fonctionnalités qu'il faut pour permettre de gerer une upgrade. Utiliser apt-get va pas corriger automatiquement les bugs de packaging ou autre qui peuvent faire qu'une upgrade peut mal se passer.

Ton raisonnement de "j'ai eu des pb d'upgrade sur des distro à base de rpm et ca fonctionnait bien sur une Debian donc rpm ne permet pas les upgrades de distro contrairement à deb" est juste completement cretin.

Le package X dont j'ai besoin est disponible dans les depots de Debian mais pas ceux de RHEL => mon experience montre qu'il est impossible de packager X en rpm alors que c'est possible en deb (en remplacant X par le nom d'un logiciel quelconque). Voila, c'est le meme genre de raisonnement.

C'est lié à yum, aptitude, apt, …

Non, plutot au fait que les packagers testent l'upgrade et corrigent les problemes sur l'une des distributions, et sur l'autre ne le supportent pas donc ne font peu etre pas particulierements d'efforts la dessus.

Je pense que yum a autant que aptitude / apt les fonctionnalités qu'il faut pour permettre un upgrade.

Ton experience te permet peu etre de conclure que l'upgrade d'une version à l'autre se passe mieux sur une Debian que sur une Red Hat, mais rien n'indique que ca soit lié au format de package.

C'est à peu près aussi intelligent que de dire "en plus de 15 ans d'utilisation de linux j'ai toujours eu des problemes lors d'upgrade avec des distributions dont le nom commence par R, alors que cela a ete rarement le cas avec celles dont le nom commence par D. Maintenant je ne me fatigue meme plus a faire un upgrade avec une distribution dont le nom commence par R, etc …". Ou alors en remplacant "rpm-like" et "deb-like" par la license utilisée, la version de bash, l'age moyen des developeurs ou le modulo de la taille de l'ISO.

Avant de conclure que le fait d'etre basé sur rpm implique que l'upgrade va poser problème il faudrait voir exactement d'ou vient le problème.

A mon avis le format rpm supporte aussi bien les upgrades que le format deb, et les problèmes ne viennent pas du format du package. Les developeurs de certaines distributions décident de passer du temps à résoudre le plus de problèmes liés à l'upgrade, tandis que d'autres estiment que ca n'est pas leur priorité et donc ne le supportent pas. Mais ca n'a rien à voir avec le format de package.

Il fut un temps où coder une démo signifiait maitriser les arcanes du matériel sur lequel on développait, et coder des algorithmes inédits se basant sur cette connaissance, avec une prime à ceux qui savaient y distiller leur talents d'artistes graphiques et musicaux.

Aujourd'hui, cela signifie coder des algorithmes originaux en utilisant les API OpenGL et DirectX, la différence se faisant, à mon sens, surtout sur le graphisme et les musiques.

En ce qui me concerne, l'effet WAOW en est amoindri.

Dans le cas de Timeless, on se rapproche de ce que j'attendais (parce qu'il y a longtemps que je ne suis plus de manière assidue ce qu'il se passe dans ce monde là) d'une intro du fait du tout généré à la volée, mais l'utilisation de l'API pilotant une carte graphique qui fait tout le boulot diminue malheureusement mon plaisir.

Maintenant, comme je le disais je ne suis plus assidument ce petit monde, donc si vous avez des liens vers de jolies choses à partager, je suis preneur !

Quel est l'intérêt de screen?

À éviter de te retrouver comme un con parce que ta connexion avec le serveur à été coupé en plein milieu du dist-upgrade.

Je viens de tenter une installation qui s'est malheureusement soldée par un échec.

Le script d'installation (make bootstrap) fait des choses étranges, y a-t-il une méthode d'installation plus simplifié (voir moins automatisée) qui ne soit pas aussi intrusive (qui ne demanderait pas de changer les règles sudo par exemple) et qui permette d'obtenir un service fonctionnel ?

voici un exemple à suivre.

• Changement de distribution dans les sources ;
• apt-get update ;
• apt-get install screen ;
• dans screen :
  • apt-get dist-upgrade ;
  • apt-get --purge autoremove $(deborphan) (relancer autant de fois que nécessaire) ;
• reboot.

Peut-être une question de locale ?

Attend, il faut cliquer ?

Je veux installer Deubianne moi, pas faire de l'Internet.

C'est moi ou ça va faire de la concurrence aux taxi et autres VTC ?
Sans compter l'exploitation possible par les réseaux de prostitution: c'est pas moi m'sieur l'agent, je faisais du stop !

Personnellement, ça me paraît correct, mais je ne suis pas forcément le plus calé sur la question. D'autres avis ?

J'aurais plus confiance si ils s'étaient basés sur un protocole deja existant et connu pour etre fiable (ssh, tls ou autre) plutot que réimplementer leur truc.

Avoir réussis à convaincre ces societés et annoncer ca tout juste 2 semaines après Heartbleed, moi je trouve qu'ils sont plutot réactifs.

Et meme si ca prenait 6 mois pour commencer à financer réellement OpenSSL, ca ne me semblerait pas non plus incroyablement long.

Tu t'attendais à quoi, que l'argent soit deja sur le compte des dev OpenSSL depuis une semaine, qu'un nouvel audit soit terminé ?

Microsoft paie pour securiser Linux, alors qu'ils n'etaient pas affectes par la faille OpenSSL vu qu'ils ne l'utilisent pas…

Il ont sans doute un interet à le faire, ils font pas ca juste pour rire.

Faudrait que certains ici pensent a aller leur payer une biere plutot que leur casser du sucre sur le dos constamment !

Ben non, c'est pas par ce qu'une societé fait des trucs bien dans certains cas qu'il faut s'interdire de la critiquer sur d'autres sujets.

Par exemple: c'est pas par ce que Google organise le Google Summer of Code qu'on doit s'empecher de critiquer certaines actions de Google.

Ca serait trop facile, tu paies $100k et tu fais tout ce que tu veux, on a plus le droit de te critiquer.

Quels éléments autres disent que la vitesse n'était pas l'objectif premier ?

Je crois que l'objectif premier supposé de lennart quand il a crée systemd, on s'en fou. Le résultat c'est que systemd a plein d'avantages autres que la vitesse de boot. Donc résumer systemd à un boot plus rapide c'est ne pas avoir compris grand chose à ce qu'est systemd.

Parler d'audit de code comme d'un truc binaire c'est completement stupide. Des projets qui acceptent des patchs sans les lire (donc sans les auditer un minimum), j'en connais pas. Je pense qu'on peut dire que environ 100% des projets sont audités. Ca veut pas dire qu'ils le sont tous de la meme facon.

Et puis la complexité de OpenSSL a pas grand chose à voir avec celle de systemd.

Cool, 5 entreprises PRISM compliant pour auditer une bibliothéque critique. Ayez confiance, ayez confiance, braves petits :)

Non, pour donner de l'argent qui va servir à paier des developeurs / audits. Et je doute qu'il y aura des conditions du genre "on vous donne de l'argent, mais vous laissez une backdoor", et si c'était le cas les projets sont de toute facon libres de refuser l'argent. Et si on leur fait pas confiance pour refuser ce genre de clause, on peut aussi imaginer qu'ils sont deja payés en secret par la NSA qui n'a pas besoin de passer par la linux foundation pour paier des developeurs.

Effectivement, pas besoin de serveur pour utiliser git-annex. Moi je l'utilise pour stocker mes données sur des disques USB, avec pour les données importantes une copie sur au moins 2 disques, sans utiliser de serveur.

Tu ne me feras pas croire qu'aucun développeur d'OpenSSL n'est payé pour travailler dessus.

Il n'y a que 24h dans une journée. A moins d'etre Chuck Norris, c'est pas par ce que t'es payé que t'as le temps de maintenir correctement un truc comme OpenSSL tout seul.

Au passage, se targuer de développper un outil de sécurité soit-disant robuste et de niveau commercial (c'est pas moi qui le dit, c'est sur la page d'accueil) et ne pas auditer le code au fil des commits, c'est quand même assez moyen.

Bien sur que le code est audité avant d'etre commité. C'est pas "on a recu un patch, on le commit, on verra bien si ca compile, et si oui alors c'est OK". Simplement il suffit pas d'auditer le code tout seul pour voir tous les problèmes tout le temps.

Mais pour ça, il est vrai qu'il est d'abord nécessaire d'enlever les lunettes du fanboy qui pense qu'il ne peut pas y avoir de problème structurel dans le modèle qu'il défend…

Je dis pas qu'il n'y a pas de problème ou de choses à ameliorer. Je dis qu'il n'y a pas PLUS de problème que sous Windows, et que MS n'a pas une solution miracle pour résoudre ce problème.

À côté de ça, sous Windows, tu fais un binaire pour XP et il marche toujours sous les OS les plus récents. Mais non, insiste le fanboy linuxien, il n'y a pas de différence entre Linux et Windows de ce point de vue, non non !

Non il n'y a pas de difference. Tu fais un binaire sur une distrib de 2002 il fonctionnera toujours sur une distrib d'aujourd'hui.

En somme, le fork était inutile. Ce n’est pas comme si la branche principale refusait les propositions/patchs comme, au hasard, Nagios.

Le couplage fort entre le système et les applications est un problème sous Linux, pas avec les autres OS grand public.

Il n'y a pas plus de couplage que sous Windows et OS X. Les developeurs de VLC et subsurface pourraient fournir des versions binaires de leurs logiciels. Si ils ne le font pas c'est peu etre qu'il y a trop peu de demande par rapport au travail necessaire pour le faire.

Parceque c'est compliqué pour l'auteur du logiciel de fournir (et tester) des binaires pour la myriade de distributions et formats de package.

C'est compliqué, mais pas plus compliqué que sous Windows. Si les gens le font rarement sous Linux, et très souvent sous Windows, c'est que sous Windows c'est un travail obligatoire pour avoir des utilisateurs, alors que sous Linux il existe des packages dans les distributions, donc c'est un travail qui a moins d'interet.

Un bon début serait de standardiser et populariser un seul format de package et ensuite de pousser cette standardisation au delà.

Non, le format de package n'est pas le principal problème, et il existe deja des outils comme alien pour résoudre ca. Le problème c'est les dépendances qui sont differentes sur chaque distribution.

Une solution ca serait un format de package qui permet de distribuer le logiciel avec toutes ses dependances. Par exemple docker, et quelquechose comme subuser pourrait etre une solution:
https://github.com/subuser-security/subuser

Ca ne remplace pas les packages classiques, mais c'est pratique pour installer des trucs d'une autre distro sans tout casser.

En tout cas ca me semble une bien meilleure solution que la solution donnée par pBpG qui est "utilisez aucune autre dependance que la lib de base qui n'evolue pas pour garder la compatibilité".