Beh oui je réponds pas à ce qui est pertinant car j'estime qu'il n'y à rien à rajouter. Ce que j'essaie de faire comprendre c'est que c'est pas parce que je ne suis pas d'accord avec vous que je ne prend pas en compte votre avis, au contraire. Je sais très bien que Arch t'es pas obligé d'update souvent, mais je préfère. Si tu veux, je vais avancer un argument personnel valable :

J'ai une mauvaise connexion internet. Non seulement je ne télécharge pas vite, mais en plus, si je télécharge, une grosse partie de ma bande passante est monopolisée et je ne peux pas faire grand chose d'autre car la moindre page internet se charge très lentement en plus de ralentir les téléchargement en cours.

Je préfère donc doser par petites updates fréquentes de 15Mo qui durent deux minutes plutôt que des updates plus éspacées qui font 200Mo et qui mettront une demi-heure à télécharger.

De plus, il est plus facile de contrôler ce qui est mis a jour quand il y a 12 paquets à télécharger que 184, par éxemple.

Je ne souhaite pas downgrader car j'ai imprimé dans ma tête que plus un paquet est récent, mieux seront ses performances (et c'est apparemment le cas pour le kernel 3.16), et encore l'histoire du fait que je préfère régler concrètement un problème.

Je n'ai jamais prétendu que j'utilisais Arch mieux que les autres ni même que je l'utilisais de manière correcte. Et j'estime que si je n'ai pas à décider qu'une manière de penser/d'utiliser un soft/whatever est meilleure qu'une autre, ce n'est pas non plus ton rôle, et coller des étiquettes de "nobrain", "fragile", "hipster", "mal-pensant" ou "Jean-Linux" (ui ne veux strictement rien dire, soyons honnêtes) l'est encore moins. Et tu combines ça avec une attitude désagréable et hautaine, à la limite de l'irrespectueux, et c'est pas comme ça que tu vas convaincre ton interlocuteur de faire comme toi.

Donc, je le répète : j'utilise Arch de la façon qui me semble ADAPTÉE, et en aucun cas pour me la péter d'avoir tout le temps mes softs à jour.

Les autres, je suis vraiment désolé de la mauvaise ambiance que je suis en train de foutre. J'estime maintenant que je n'ai plus rien à ajouter donc je vais pas continuer là dessus.

Correction j'ai 1G à DL mais y a sage-mathematics qui fait ~500mo donc ça s'équivaut

@Caletlog https://www.jeuxvideo.com/forums/1-38-7665853-2082-0-1-0-0.htm#message_7818572

« et d'une garantie de non-utilisation des données »

Non. Pour tout service hébergé, t'as aucune garantie, t'as juste confiance. Même si le code est libre, si c'est pas toi qui l'héberges, ça n'a aucune valeur en terme de sécurité et de garanties.

Sauf que ça aujourd'hui y'a peu de gens à l'avoir compris. Autant, rien ne t'empêche de fournir une application centralisée qui contient des données confidentielles, mais une société un minimum éduquée sur le numérique refuserait majoritairement de l'utiliser pour les raisons évoquées plus haut. Actuellement, y'a une foule de gens qui pourraient utiliser inconsciemment ton application et qui te tiendront pour responsable (à juste titre) le jour où une faille permettant de dévoiler des données est trouvée sur ton site (et comme je sens que tu vas faire ça en Ruby, avec Rails, y'a de fortes chances qua la faille en question ne viennent même pas de ton code ).

À ta place je prendrais pas ce risque. Une application web qui manipule des données sensibles, ça peut t'anéantir si tes utilisateurs s'en prennent à toi en cas de problème (et ça arrivera, sois-en sûr). Au lieu de ça, tu fournis juste un logiciel libre que les gens installent chez-eux (ou sur leur serveur si besoin d'accéder à distance à la liste). « The software is provided "as is", without warranty of any kind. » Avec ça tu dors sur tes deux oreilles.

Si quelqu'un veut prendre la responsabilité de proposer d'utiliser cette application sur **son** serveur pour des raisons pratiques pour les utilisateurs (à savoir ne pas avoir à héberger le soft soi-même), tout en offrant des garanties techniquement intenables à ses utilisateurs, c'est **son** problème.

« Du coup, j'implémente une dissociation des données qui permettent d'identifier un contact de celles qui ne le permettent pas, sans stocker tous les outils qui permettent d'y accéder. Seul le propriétaire d'un compte peut mettre un nom sur ses contacts, et pas quelqu'un qui posséderait la base de données ou un compte volé. »

Tu m'expliques ça techniquement ?

La seule solution un peu moins trouée que les autres que je vois pour l'instant (dans le cas d'une application web), c'est de chiffrer les données avec une clé connue uniquement de l'utilisateur (générée côté client à la création du compte), qui est systématiquement passée en ancre dans l'URL (comme ça pas envoyée au serveur). Ton serveur proposerait alors juste une API pour lire/écrire des blobs, chiffrés et déchiffrés côté client grâce à la clé présente dans l'ancre. À partir du moment où tu rends l'utilisateur responsable de sa clé, si il se la fait piquer c'est son problème, et toi tu possèdes juste des données non exploitable. Une faille majeure de cette architecture reste l'exécution de JavaScript indésirable côté client (typiquement, si un attaquant gagne un accès à ton système de fichiers et modifie/ajoute des scripts), auquel cas tu serais également tenu responsable.

@vava > "Tu m'expliques ça techniquement ? "
C'est exactement ce que tu développe en dessous, j'avais en tête un chiffrement des données nominatives avec une clé par utilisateur, non stockée sur le serveur.

"et comme je sens que tu vas faire ça en Ruby, avec Rails, y'a de fortes chances qua la faille en question ne viennent même pas de ton code )"

Non pas forcément, si j'ai fini mon apprentissage de Node avant la reprise je peux tenter de le faire avec un MEAN stack

"À ta place je prendrais pas ce risque. Une application web qui manipule des données sensibles, ça peut t'anéantir si tes utilisateurs s'en prennent à toi en cas de problème"

Même dans le cas où les données qui servent à identifier les contacts sont chiffrées comme vu plus haut ? Je sais qu'un chiffrement c'est pas infaillible, mais quand même.

Enfin dans tous les cas c'est avant tout un 'prototype' sur une idée qui me plaisait bien, y'a pas vraiment de raisons que ça soit utilisé en dehors des cours si ça me sert de projet de fin de diplôme.

Mais du coup, je rebondis sur les points légaux que tu soulève. Comment les groupes qui stockent des données personnelles gèrent-ils ça ?
Premier exemple récent qui me vient en tête, Project Euler qui s'est fait volé ses bases, et les e-mails ont fuité. Le site est en faute et ça peut lui retomber dessus légalement ?

« Même dans le cas où les données qui servent à identifier les contacts sont chiffrées comme vu plus haut ? Je sais qu'un chiffrement c'est pas infaillible, mais quand même. »

C'est pas le chiffrement qui m'inquiète. C'est ce que j'évoquais déjà dans mon post précédent : l'attaquant acquiert un accès au serveur qui lui permet de modifier le JS envoyé au client, et toute ta sécurité est ruinée.

Ensuite, tu dis chiffrer uniquement le noms des contacts. Les données « en clair » même « anonymes » peuvent dévoiler assez de contexte pour identifier une personne. Ça dépend totalement de ce que l'utilisateur a rentré, rien ne l'empêche de donner des noms ou des informations qui permettent une identification facile dans les « notes » à propos d'une personne. Si t'as déjà une clé et du chiffrement côté client, autant tout chiffrer, ça coûte pas grand chose de plus (et ça ne change rien pour l'utilisateur).

Après faut prendre du recul, la vaste majorité des utilisateurs auxquels tu vas dire « Désolé, une faille a permis de dévoiler les memos à propos de vos contacts à un attaquant. » ne se retourneront pas contre toi, simplement parce qu'ils n'en ont rien à carrer, ou parce que c'est pas réaliste d'aller dans les tribunaux pour une atteinte du genre. Puis pour être vraiment réaliste, tu vas clairement spécifier que tu ne garantis que dalle à tes utilisateurs et qu'ils utilisent ton service à leurs risques et périls (voir Article 7 des CGU de JeuxVideo.com[0]).

[0] https://www.jeuxvideo.com/cgu.htm

Le cas où c'est tendu, c'est quand tu offres un service avec certaines garanties (souvent à des entreprises), par exemple Hegor Homakov qui avait trouvé un moyen d'accéder (et en read/write en plus) à des repos privés sur GitHub. Quand GitHub fait payer des boîtes pour héberger des repos privés, ça la fout mal. Alors le type est un white hat et a signalé la faille à GitHub dans le cadre de leur « bug bounty program », mais si cette faille était tombée entre de mauvaise mains, je pense que ça aurait eu le potentiel de faire couler GitHub en réputation et surtout en dommages et intérêts...

Source de mon dernier paragraphe (à propos de la faille de sécurité sur GitHub) : http://homakov.blogspot.ro/2014/02/how-i-hacked-github-again.html

Je suis en train de regarder les conditions d'utilisation de GitHub du coup, ils disent aussi explicitement qu'ils n'offrent aucune garantie, j'imagine que c'est pareil pour les comptes d'entreprises).

« Your use of the Service is at your sole risk. The service is provided on an "as is" and "as available" basis. »

« GitHub does not warrant that (i) the service will meet your specific requirements, (ii) the service will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of the service will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through the service will meet your expectations, and (v) any errors in the Service will be corrected. »

Bref, tu mets un truc comme ça dans tes conditions d'utilisations et je pense que t'es peinard.

(Je me rend compte au passage que je ne respecte pas les conditions d'utilisation de GitHub (A.7), mais chut. J'essaie de réduire mon utilisation de GitHub au même titre que mon utilisation de Google anyway.)

Dans la mesure ou tu peux héberger ton propre Git c'est pas trop un soucis de se débarasser de GitHub

Google un peu moins

Bon dieu...

As-tu oublier de te M + Z aujourd'hui Jamea ?

http://aboutthebsds.wordpress.com/2013/03/31/bsd-vs-linux/
Troll?

« So therefore, GNU/Linux is more free than the BSDs. »

J'arrête de lire ici.
Pour moi, un article qui commence par remettre sur le tapis cette putain de guerre débile des licences, c'est > /dev/null.
C'est pas pour contourner les arguments ni quoi que ce soit (btw je tourne sous Linux à l'heure actuelle), mais je ne peux plus voir en peinture les mecs qui passent plus de temps à casser les couilles à tout le monde pour des histoires de licences, qu'à écrire et partager du bon code.

Justement c'est pas la meilleure partie de l'article. Je t'invite à essayer de continuer la lecture.

Lehap -> Aucun rapport

dsp, j'ai lu ce post de blog. Et mon avis est que j'ai eu envie d'ajouter "[citation needed]" a quasiment toutes les phrases. Je ne dis pas qu'il est faux, mais il n'y a aucune preuve de rien de ce qu'il dit, juste son avis a lui. Alors que beaucoup des choses dont il parle pourrait etre justifier avec des donnees externe.

Donc en l'occurence, je vote "troll" a moins qu'il rajoute des liens un peu partout pour justifier ce qu'il dit.

DSP Bah écoute je veux bien essayer mais je suis pas 5 lignes plus bas que je lis déjà « The BSDs on the other hand do not get much contribution back due to the BSD license not enforcing it and code that is contributed are poor quality and often broken. » (précédé d'un truc comme « GNU/Linux gets a lot of high quality code contributions back from many developers and companies using Linux. » pour couronner le tout).

Non, j'ai vraiment pas envie de lire. C'est juste un texte qui répond aux critiques habituelles de BSDistes envers Linux en changeant le sens de la critique, mais sans apporter le moindre putain de god damn exemple.
Parce que bon, parler de "broken code" quand on voit toutes les merdes auxquelles on a le droit sous Linux par moments (je parlais de Debian + OpenSSL sur un autre topic, mais c'est loin d'être un cas isolé...), c'est un peu fort. Quant à l'histoire de "Linux au moins il reçoit du bon code et tout!", faut aimer les usines à gaz fournies par Lennart pour dire ça.
« Most of the BSDs growth is done by BSD developers “reinventing the wheel” »
Hum hum. Toujours dans la série "Lennart is watching your kernel", franchement en terme de réinvention de la roue tous les trois ans ya rien d'exemplaire sous Linux (combien de piles audio disponibles pour Linux, déjà?).

Bref, nan, sérieux ya bien des raisons à apprécier Linux et l'utiliser alors qu'on sait que BSD existe mais c'est franchement pas dans cet article qu'on les retrouve. Ça sent juste le mec qui s'est retrouvé en PLS sous son bureau après être tombé sur un (véritable) argumentaire de BSD vs Linux qui ne tournait pas en sa faveur (c'est d'ailleurs grosso merdo ce qu'il explique au début de son pavé, probablement le seul truc honnête de tout l'article).

« dsp, j'ai lu ce post de blog. Et mon avis est que j'ai eu envie d'ajouter "[citation needed]" a quasiment toutes les phrases. Je ne dis pas qu'il est faux, mais il n'y a aucune preuve de rien de ce qu'il dit, juste son avis a lui. »

That's it.
À côté de ça, ici on a des threads comme https://www.jeuxvideo.com/forums/1-38-7709821-1-0-1-0-bsd-a-quoi-de-plus-que-linux.htm qui concentrent beaucoup plus d'exemples concrets en 30 posts que le torchon trollesque dont il est ici question

D'ailleurs, au sujet de BSD, j'ai vraiment l'impression qu'il n'y a qu'OpenBSD et FreeBSD qui sont vraiment supporté. Je sais que je divague un peu mais depuis maintenant quelques semaines, l'installation de Xorg est chose impossible (c'est quand même pas rien !!) sur NetBSD à cause d'une dépendance assez important : libdrm et c'est toujours pas réglé

La grande majorité des avantages de BSD cités sur le topic de G_B sont invisibles pour l'utilisateur lambda. Quel utilisateur a besoin d'une sécurité hors norme? Même sur Linux j'ai pas l'impression que mes serveurs sont pas secure. S'ajoutant à ça le peu de compatibilité ça la fout mal pour un serveur Après il reste juste le fait que BSD est pas victime de l'industrie et que y a quelques bullshit en moins mais je vois que ça.

D'ailleurs on site pf mais j'avais vu des benchs et iptables semblait supérieur en performances brutes tout du moins. Pour l'instant la plus grosse bs c'est systemd, une des plus grosses de l'histoire de Linux à mon sens

Mais sans systemd je vois mal pourquoi quelqu'un se dirigerait vers BSD

cite pf* omfg

https://plus.google.com/115606635748721265446/posts/Pw31EE21BXV

Et bam !

(Martin qui est le mainteneur officiel de Kwin)