bubar🦥 a écrit 6932 commentaires

Ha, tiens ?
C'est quoi le modèle ? Perso, sur mon Acer (V3 771G, avec la particularité d'avoir un optimus amputé car sans lien direct écran - seconde carte gfx), le LiveCD KDE passe nickel (il boot et donne accès immédiatement à toutes les fonctions en graphiques) tandisque les installations se passent ainsi :

• netinstall bugg si on choisit fr_fr, il ne faut pas changer la map clavier ni la localisation, sinon anaconda pète un bug fatal
• dvd install nécessite "basic graphics mode" + "nomodeset" , reboot nécessite ajout de "acpi_backlight=vendor" sur le kernel fedora
• cd install nécessite "basic graphics mode" + "nomodeset", reboot nécessite ajout de "acpi_backlight=vendor" sur le kernel fedora

Voilà, une fois installé, je compile le kernel vanille et tout va bien (sans utiliser le backlight=vendor, qui créeait des freeze aléatoires faisant penser à un pb de ram, alors que c'est un pb d'acpi). Tout va bien, avec un i915 seul, ou avec nouveau… ou les deux à la fois.

Bonsoir,

Pendant longtemps j'ai suivi les docs, et les résultats de mes tests, pour faire des montées de version. Quelque soit la distribution utilisée, cela a bien fonctionné (cependant c'était sur Mandrake, et ensuite uniquement avec yum, je n'ai essayé preupgrade qu'une fois et c'est un mauvais souvenir). Je mettais même un point d'honneur à utiliser kexec, afin de minimiser le temps d'interruption (ayant une workstation dell avec 6 disques scsi, avec une carte nvidia, vers ~2005, et la grande chance que tout fonctionne dessus pour kexec malgré le handicap nvidia). Puis je suis passé à la préparation des montées de versions : dès l'installation la prévision de la montée de version par réservation d'une partition dédiée à accueillir une copie du système sur lequel la mise à jour est appliquée par chroot, puis on boot sur l'autre racine : ça passe et la racine initiale devient la préparation, sinon on revient sur la racine initiale.

Un jour j'ai essayé la sauvegarde et l'installation. Je ne suis plus jamais revenu en arrière. Parceque je suis feignant et je n'aime pas me casser la tête, enfin le gain de temps est considérable.

quant à

à placer dans une soirée mondaine le mercredi.

j peux pas j'ai piscine
désolé

On peut ajouter que le fichier FreeDesktop présenté ici peut être amélioré avec un :
Type=Service
X-DBUS-StartupType=Unique

voir en plus :
X-KDE-StartupNotify=true
X-KDE-autostart-phase=BaseDesktop

Puis placer le tout dans son ~/.kde/share/autostart (non, pas .kde/Autostart, pas non plus .config/autostart, mais bien .kde/share/autostart lol)

ps : le & dans Exec c'est sale

Dans les techno citées, pas une ne remplace le liquide…
Qui par définition est « liquide »… Pourtant ça ne serait pas dur de faire un terminal de stockage et d'encaissement. Tu "sors" 500€ de ta banque, que tu déposes sur ton terminal, et tu transfères ce "liquide" sur le terminal du marchand. Ceci sans aucune empreinte de plus que le liquide. Et dans les mêmes limites avec ton service bancaire (quantité, droit de retrait, etc)…

Mais non, toutes ces technos visent à enregistrer même les transactions les plus banales et minimes, même pour une baguette de pain ou un échange entre amis. Tout, tout tout ils sauront tout … C'est ça qui gène à la fois le développement de méthode de paiement, sur le net et de mains-àmains, vraiment -réellement- alternatives au billets et pièces.

L'avenir est tout tracé.
L'argent liquide coûtera plus cher que l'argent électronique. L'abandon se fera petit à petit à cause de ça. Et nous, nous perdrons la dernière parcelle de liberté : celle de l'échange direct et sans trace.

+1 sur Gentoo.
Gentoo, what's else ?

Parmi conseils prodigués par Mr Bortzmeyer lors de ses conférences, il recommande de mettre en place un serveur de test (ayant dnssec) sur une période de 6 mois. 6 mois /o\

Parmi les interrogations légitimes face à dnssec, à laquelle il n'y a pas de réponse, il reste l'abandon des politiques de coupures de flux au delà d'une certaine taille de paquet, dnssec demande de gros paquet, et du coup facilite le dns2tcp. Dnssec c'est un peu le haut débit du dns2tcp…

DNSSEC me semble (humblement, hein) un "yeux plus gros que le ventre" : améliorons d'abord le fonctionnement des DNS actuels, et des équipements autour, avant de s'attaquer à un tel morceau.

tl;dr dirait on, mais l'intro est tellement bonne que j'ai lu jusqu'au bout :-)

Sciences naturelles VS sciences humaines, ça me plait assez, adopté.
Merci.

L'enseignement de la matière, est inexistant voire très sommaire

+1 C'est regrettable de n'avoir que peu de cours sur le sujet.
Pas d'histoire de l'économie, peu de champs, en fait l'économie (en dehors des filières spécialisées sur le sujet ou un sujet proche) se servent des quelques cours disponibles pour survoler la situation. +1 car en théorie c'est toujours mieux d'avoir un minimum de repères, mais la spécialisation à marche forcée d'un côté, et la quantité de données d'un autre côté, font qu'il est difficile d'aborder tout les sujets. Et perso, s'il y avait encore des cases de libres, je préfèrerai les consacrer à la culture scientifique.

en plus, comme on va le voir plus loin, ne fait pas forcément passer le bon message.

L'enseignement n'a pas "à faire passer de message", mais à donner des repères culturels puis les outils permettant de construire un regard critique. (" Faire passer un message" se fait très à la marge, quelque soit la matière enseignée )

Si ce que tu veux c'est faire du bourrage de crâne avec une telle quantité de données que les seuls choix finaux, sur l'orientation du futur citoyen/décideur/whatever, sont des ajustements à la marge d'une idéologie dominante, alors ce n'est plus de l'enseignement.

/* mode troll, topix troll :-)

parce qu'il ne voit plus la librairie qu'a à le gérer

Je ne suis pas sûr d'avoir bien compris cette phrase, et la "perte de librairies" (non, pas de bibliothèques) je n'ai 'jamais vu/entendu parler' de ça. Par contre lors de (re)boot sur des Redhat 6, TiNa perd ses librairies lorsqu'elles sont distantes sur des baies, parceque le noyau refait dynamiquement l'attribution des devices alors que TiNa veut des wwn. Refaire à la main ces attributions lors des reboot, pour avoir un tina fonctionnel, c'est pas terrible. Mais les prochaines versions auront intégrés un patch (sic, juste une conf udev) pour permettre de faire du persistant binding quelque soit la techno sous-jacente. Sinon, refaire à la main les wwn pour que TiNa retrouve ses petits, à chaque boot, c'est pas terrible.

installe en cochant tout ce qui était dispo dans anaconda

Il faut le pendre haut et court.
Même si l'impact est nul, avec des mises à jour aux petits oignions, c'est crade. Là c'est probablement une amélioration si tu proposes un kickstart « voilà ce qu'est "redhat pour serveur autonome" ici, et tu t'y tiens » à ton intégrateur/installeur.

je trouve yum lent

On parle de machines de guerre qui hébergent souvent les informations du coeur de métier, et vous parlez de savoir si toto prend une seconde de moins que titi pour réaliser une proposition de mises à jour ? Non mais … LOL Et puis, celui gérant les mises à jour avec yum, faut le pendre aussi, hein :p

puppet n'est pas dispo dans les dépots

Et OpenShift & OpenStack, ça n'existe pas ? Sérieux, là, dire "n'existe pas chez redhat" c'est faux. Puppet n'existe pas pour les versions serveurs de base, et il y a des raisons à cela. Et si tu en as besoin parceque tu a choisi Puppet pour une partie de l'administration de ton parc, ben c'est ton choix pas celui de l'éditeur.

je refuse de faire l'administration de ce truc, pour moi, c'est une verrue sur mon réseau.

ça a du sens, l'homogénéité facilite tout.
[EDIT : fai indique ne pas supporter officiellement redhat] Pour Puppet, je ne rejoins pas le commentaire plus bas disant d'utiliser le dépôt fourni par le projet. Ton approche est la même que celle décrite plus haut : prudents, on prends la version de l'éditeur, pour toi, Debian. Heureusement l'intérêt de Puppet sur des serveurs de sauvegardes tina est très faible …

Correctif : pour cette mauvaise aventure, qui a générée ce troll fort sur Novell SuSE, Novell n'est pas absolument pas en cause (c'est l'intégrateur qui a bidouillé à l'arrache ce qui a entrainé des incohérences)

Je fais amende honorable sur ce troll là, et présente mes excuses à la communauté OpenSUSE présente sur ce site.

Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell… Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)

Tu as raison, alors voici de la doc en sup :

http://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-June/008395.html

http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm

Vous en aviez rêvé ?

C'est plutôt un cauchemar …

Les contre-sens sont simplement là pour illustrer son avis personnel, dans un texte couvrant relativement bien le sujet. C'est comme ça que je l'ai lu, du moins, et ça ne m'a pas semblé problématique pour la compréhension.

Les faits sont suffisamment vus et compris par tous pour qu'on puisse se permettre de sortir d'un texte neutre et objectif. Non ? Il n'y a rien d'autre à faire que d'en rigoler ensemble. En attendant de payer les impôts d'autonomes…

hint: halloween.
ça ressemble surtout à un bel ensemble de POCs disparates, rassemblés pour une belle occasion.

Alors j'pense (bien humblement) que tu devrais essayer ceci :

net.ipv4.tcp_workaround_signed_windows = 1
net.ipv4.tcp_base_mss = 1056
net.ipv4.tcp_tso_win_divisor = 1
net.ipv4.tcp_window_scaling = 1

Pourquoi ? On force la division minimale de paquet à 1 (3 par défaut & gso c'est le mal ). Puis on colle une base pour mss à la valeur voulue (1096 donc, pour toi : Ici, sur la Fibre, j'ai une perte de débit en forçant la mtu et le mss comme cela, forcément : c'est juste pour ton exemple) enfin on s"assure que les wmem & rmem sont correctement positionnées, genre 4096 16384 4194304 (et puis on ajoute le workaround pour considérer que l'autre bout est tout cassé et qu'il traite mal la fenêtre). Je continue d'utiliser CUBIC pour les apps non privilégiées, et la plupart des autres paramètres tcp sont restés par défaut (ce qui ne le sont pas n'entrent pas en ligne de compte ici). Enfin, on fixe la mtu avec ip/ifconfig/sysconfig à 1096. Un tit coup de sysctl -w .net.ipv4.route_flush=1 & de sysctl -f /etc/sysctl.conf. La Nimage :

Et je vois la vie en 1044
1044
1044
1044
LOL

02:01:04.822588 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24167556, win 32767, options [nop,nop,TS val 7889144 ecr 656051175], length 0
02:01:04.822592 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24167556:24168600, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822598 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24168600:24169644, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822603 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24169644, win 32767, options [nop,nop,TS val 7889144 ecr 656051175], length 0
02:01:04.822613 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24169644:24170688, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822617 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24170688:24171732, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822623 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24171732, win 32767, options [nop,nop,TS val 7889145 ecr 656051175], length 0
02:01:04.822624 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24171732:24172776, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822916 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24172776:24173820, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
02:01:04.822952 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24173820, win 32767, options [nop,nop,TS val 7889145 ecr 656051175], length 0
02:01:04.822957 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24173820:24174864, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044

Le paramètre essentiel est de commencer avec le retrait des options de la carte réseau. Lorsque cette dernière se charge de la fragmentation alors le noyau va segmenter tes ko en paquets (de 1460 octets par exemple).

Tandisque si on laisse faire la carte réseau, le noyau va envoyer un gros paquet, et c'est la carte qui va segmenter.

Donc on ne peux pas faire joujou avec ces valeurs sans au préalable désactiver ces fonctions de la carte : il faut laisser faire le noyau.

En continuant sur le ton du début de commentaire, c'est un comportement de looser, de windows et autres TOE joyeusetés qui ont essayé de rentrer dans le noyau : retirer cette possibilité au noyau sous le fallacieux prétexte que "ip c'est touchy", alors on colle toute la pile ip dans le firmware de la carte rzo… Non mais ils sont FOUS. Donc, on commence par retirer un maximum de possibilités à la carte réseau, et on va laisser le noyau gérer cela à la place, hein

Là où ça devient rigolo, c'est qu'avec TCPDUMP tu ne verra pas la même chose, si tu le lances sur le même serveur. Si tu laisses faire la carte, tu verra un gros paquet. Si tu laisses faire le noyau tu verra les paquets fragmentés. Mais pourtant, même en voyant un seul gros paquet, c'est bien des fragments qui seront envoyés sur le réseau.

Il te faut envoyer tes paquets de tests avec ton application cible. Et aucune autre, au cas les autres feraient bien les choses, c'est souvent le cas sur gnu/linux : tu dois ajuster ces paramètres en fonction de ton application, par touche si besoin. Et sans te fier à un autre type d'envoi pour ces réglages, et en ayant un tcpdump à l'autre bout. Ce sont les deux conditions essentielles. Enfin, il y a perte de débit mais tu t'en fous puisque cette machine ne sert qu'à cette app là.

En résumé pour ton besoin :

net.ipv4.tcp_workaround_signed_windows = 1
net.ipv4.tcp_tso_win_divisor = 1
net.ipv4.tcp_base_mss = 1056

ifconfig enp15s0 mtu 1096

Mes deux cents.
(j'me coucherai moins con ce soir)

Salut JuD Jean-Clume,

Je dirais qu'il faut faire fermer sa cacahouète à la carte réseau (à toutes les cartes réseaux, puisque tu utilises une vieille technique japonaise de ligotage). Enéfé, les cartes ont toutes plus ou moins d'accélérations matérielles pour plus ou moins de couches … Ouhaaaaa c'te découverte :-) Et pour cela on va utiliser l'omniscience de EthTool (noooon pas mii, jete tes cartes!). Dans son vocabulaire à lui de rzoters, il cause avec plein de gros mots :

• TCP Offload Engine = Moteur de déchargement TCP
• rx-checksumming /rx (on|off) = Déchargement de la somme de contrôle en réception
• tx-checksumming / tx (on|off) = Déchargement de la somme de contrôle en émission
• scatter-gather / sg (on|off) = comme DMA : Entrées et/ou sorties de la carte réseau : transfert direct vers la mémoire principale de la machine, sans intervention du microprocesseur (si ce n'est pour lancer et conclure le transfert).
• tcp-segmentation-offload / tso (on|off) = Déchargement de la segmentation d'un gros paquet TCP en plusieurs petits (en émission)
• udp-fragmentation-offload / ufo (on|off) = Déchargement de la fragmentation d'un gros paquet UDP en plusieurs petits (en émission)
• generic-segmentation-offload / gso on|off) = Déchargement de la segmentation d'un gros paquet TCP en plusieurs petits (en émission)
• generic-receive-offload / gro (on|off) = Déchargement en fusionnant des petits paquets TCP reçus en un gros paquet pour le système (réception)
• large-receive-offload / lro (on|off) = Déchargement important à la réception
• rx-vlan-offload / rxvlan (on|off) = Déchargement de la gestion des Vlan en réception
• tx-vlan-offload / txvlan (on|off) = Déchargement de la gestion des Vlan en émission
• ntuple-filters / ntuple (on|off) =
• receive-hashing / rxhash (on|off) = receive hashing offload

Ce qui nous intéresse à priori c'est de faire sauter la frag et la seg. Mais allons y gaiement, et ne faisant aucune confiance dans le firmware de la carte réseau, tel de preux chevaliers caquis fasse à l'envahisseur de l'intérieur :

ethtool -K enp15s0 rx off tx off sg off tso off gso off gro off lro off rxvlan off txvlan off ntuple off rxhash off

Normalement, c'est sans erreur. Plonquée, blam dans la gueule du firmware de la carte rzo, gourdin et massue. Bon maintenant, on va faire chauffer un peu ce processeur… La carte est bien dans cet état :

[root@transportable log]# ethtool -k
Features for enp15s0:
rx-checksumming: off [fixed]
tx-checksumming: off
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: off
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off [fixed]
rx-vlan-offload: off
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]

débilt-test version commerciale Et aussi :
 
42 secondes pour télécharger ~357M & 35 secondes pour envoyer les mêmes données. ça va.

Concernant la charge CPU pour les opérations réseaux qui étaient auparavant fait par la carte réseau, les experts estiment que 1 Mb/s prend 1 Hz de CPU (donc ~mettons un traffic permanent de ~1Gb/s : il consommera ~1Mhz du premier cpu [sans gso donc]), ça devrait aller tu ne fera pas pédaler dans la semoule ton Quadrandeux cores…

Bon, zallons y n0w appliquons le paramètre que tu donnes, et seulement lui :

Dans sysctl.conf (ou systcl.conf.d/myapp.conf)

net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_rmem = 512 1392 4092

Et là, c'est LE DRAME : mon débit plafonne à 50ko/s comme si mon O.N.T. s'était muté en antique modem.

Alors, quoi ? On continue ? :-)

La question de l'objectif reviens plusieurs fois, et c'est bien à mes yeux aussi la question centrale. Objectif des gens qui viennent de servir des machines, et objectif de l'association via à vis de son public. Personne ne pourra te donner des idées valables (ie : précises, détaillées et immédiatement applicables) sans ces éléments. Il ne faut pas confondre curiosité et volonté, si ton idée de proposer une diversité (de bureaux, d'environnement) semble bonne à priori, pour plusieurs publics, et pour plusieurs raisons, il n'est pas sûr qu'elle soit adaptée au contexte. Ce qui sépare souvent la curiosité de la volonté c'est l'envie.

Ensuite il y a les relations inter-personnelles. Le public ne change pas parce que l'outil change, et si l'outil cherche à faire cela alors le choix n'était pas bon. Pour ceux ayant besoin, qu'elle qu'en soit la raison, d'avoir des échanges, il est fort probable que rien ne change. Mais pour ceux qui souhaitent utiliser sans contact social, il convient de disposer d'un environnement simple. Note qu'on ne parle pas d'autonomie, c'est autre chose : certaines personnes ayant l'habitude de nouer des contacts sont autonomes devant l'outil, et les questions / échanges ne sont que des vecteurs de communication. De la même manière pour ceux n'utilisant que le service : il se peut que leur autonomie face à l'outil soit limitée à la tâche qui les a amenée au centre ( je ne vais pas à "la poste" pour parler timbres )

Enfin il y a les personnes tenant ce service. Si l'outil leur demande un surplus de travail, à cause d'une augmentation des échanges avec les utilisateurs, selon l'objectif de l'association cela peut être considéré comme un échec. Si de plus les intervenants se retrouvent avec un ressenti, même s'il ne s'exprime pas ou maladroitement verbalement, d'être dépassés, alors c'est un autre échec. Il te faut, là, mesurer le type de relations qu'ils ont l'habitude d'établir. Avoir le sentiment de ne pas maîtriser peut engendrer un sentiment d'être débordé, qu'il soit réel en terme de charge, ou passant pour illusoire car liée à une absence d'adaptation. Le personnel peut perdre pied sans l'avoir vu venir, se retrouver en situation de ressenti d'absence de maîtrise, petite touche après petite touche, pour finir par être démotivé.

Enfin ne te fais pas d'illusion, si la personne que tu as rencontré s'est ouverte à la possibilité de changer l'outil, c'est parce qu'elle voit en toi une ressource supplémentaire, plus probablement que pour tes beaux yeux ou la philosophie gnu.

En conclusion, il y a trois étapes. Tu as déjà fait la première. Et avant de toucher à la dernière je te conseille de réfléchir à ton objectif à toi.

Voici ce que je ferai : je présenterai cela comme un service professionnel, je ferai choisir le nouvel outil par les intervenants, puis je proposerai un cadre d'intervention. Ceci se décline en étape claires, posées et factuelles, et nécessite que tu fasses des choix préalables, et que tu t'y tiennes dans la durée. Pour tenir dans la durée, il faut des outils qui tiennent dans la durée… exit donc les choix ésotériques, et raouste les bureaux changeant, idem pour les distributions peu pérennes. Dans ce qui reste, tu choisis et tu présentes ce choix à cette personne et/ou aux intervenants (à tous s'ils sont plusieurs). Ce sont eux qui feront le choix final, tu ne dois en aucun cas intervenir à ce moment là. L'appropriation de l'outil par l'équipe est primordiale. Et fois cette étape passée, c'est la plus longue, la plus chronophage, il te reste à poser le cadre d'intervention : par exemple "intervention deux fois par mois, tel jour de telle heure à telle heure. afin de faire les mises à jour et/ou re-masterisation". Point barre. Tu n'interviens pas à la demande, tu n'interviens pas non plus auprès du public. Tu es le garant fonctionnel d'un choix technique. Ce n'est pas la partie la plus longue à mettre en place, mais elle dure à faire comprendre, et parfois dure à être tenue… Pense pro, reste à cette place.

Laisse filer quelques mois comme ça. Ça roule ? Tu n'es pas intervenant de l'association auprès du public. Tu es intervenant au service de l'association, afin d'assurer le suivi de leur choix, qu'il continue à être fonctionnel. Ça va mieux en le disant, non ? Maintenant que ces quelques mois sont passés, tu as eu le temps de la réflexion : souhaites tu intervenir aussi auprès du public ? Si oui, dans quel -autre- cadre ? (informations, formations, échanges, …) Quel est ce second projet ? Comment se décline t il concrètement ? Et comment s'articule t il avec celui de l'association ?

Procède par étape, une réussite après une autre, sans emballement, sans mélanger les rôles, sans que cela bouscule l'association, tout en rentrant dans tes clous en terme de temps.

mes deux cents.
Cdlt.

La différence se situe dans la diffusion : de nombreuses organisations (et associations, en France) avaient d'ores et déjà montés des serveurs relais Wikileaks. Toutes les données étaient accessibles, et les journalistes faisaient alors leur travail, livrant une analyse détaillée (et choisie) de certains points. Mais les données brutes étaient (et sont toujours) accessibles à tous.
Ce n'est pas le cas ici.

Notre approche n'est pas de prôner, ni de pratiquer, la transparence absolue, qui consisterait à publier en bloc et de manière irresponsable toutes les données sur tout.

Voilà, Le Monde est devenu un journal de peigne-culs. Pourquoi l'emploi de cette grossièreté ?
Parce qu'ils n'ont pas le courage de dire simplement « nous ne nous mouillons pas à tout publier » ? Pas seulement. Parce que, en tant que citoyen, j'ai mille fois plus confiance dans les services d'état que dans les journalistes. Ils se placent, de part cette décision de ne pas tout publier mais d'effectuer un "filtrage responsable" (sic), de facto dans une sale position. Qui sont ces gens qui se considèrent "responsables" pour être détenteurs de secrets d'états ? Des journalistes du monde ? Autoproclamés "responsable et possiblement détenteurs de secrets d'état" ? Laissez moi rire, et doublement :

1) cela va à l'encontre, totalement, du but recherché par la publication : informer.
2) aucune base n'unit citoyens & journalistes, privés par définition.

Soit ils publient TOUT (ie : tout à disposition et ils apportent leurs plus-values de tri et d'analyse), soient ils ne collaborent pas avec Geenwald. En l'état, ils s'autoproclament capables de choisir ce que le public doit savoir ou pas. Ils ajoutent une couche, imperméable au public, et sans légitimité d'état.

Finalement, c'est la pire des situations : les citoyens ne savent que ce que quelques journalistes veulent bien qu'ils sachent, et en échange la nation n'a aucune assurance quant à leur probité.

Snowden & Assange doivent se retourner dans leurs cages :-/

alpha ? bien beta en tout cas.

Tout le svn/git de Kde ? :-)

Tu codes quoi pour avoir besoin de plus de 16Go ?? :-)) Pour les films, vidéos, musiques, toussa, une petite clef usb3 suffit, en terme de vitesse d'accès, de place dessus, et de transport. Non ? En plus, ça se partage plus facilement.

Il me semble que tu cherches la machine impossible …
Pour l'avoir cherché moi aussi, le Dell XPS 13 est vraiment un excellent choix rapport qualité/prix (même les machines de chez ldlc s'alignent difficilement). A part la perle rare en fin de stock dans un supermarché (mais en payant Microsoft), je n'ai jamais trouvé.
Ajoute un grand écran chez toi, et tu as le meilleur.
Ou alors ajoute une énorme batterie à un gros transportable pour avoir ce que tu veux + l'autonomie demandée.

Non ?