bubar🦥 a écrit 6904 commentaires

& merci pour ton journal

Ah oui, merci. J'étais passé à côté de ce bout de l'annonce officielle.

Je ne comprends pas la phrase suivante, dans l'article de nextimpact :

certaines distributions ne sont pas prises en charge, notamment toutes celles basées sur Fedora.

tl;dr

payer avec quoi, quoi, à qui, et pourquoi ?

En posant ça ici tu participes à transporter une image négative de ACRIMED. Hors sujet pour le site ici, bien que les journaux soient fait pour ça entre autre, tu postes sans questions ni informations, et donnes une idée bien négative des lecteurs et contributeurs à ACRIMED, qui viendraient beugler un peu partout où c'est possible leurs gueulantes.

Que penses tu si un lecteur ou un contributeur de LinuxFR.org allait poster une ralante de ce style à propos des conditions de ré-utilisations, de partages et de transmissions des savoirs, en mode «je pose une bouse, je gueule, et je m'en vais» ? Cela n'aiderait ni l'idée qu'il veux véhiculer, ni le site dont il se sert comme vecteur.

Alors rassures toi, l'image négative que tu transportes icitte reste bien faible, et les dégats que cela pourraient causer à l'image d'ACRIMED resteront bien peu importants, le lectorat icitte (nous) faisant la part des choses en moinssant promptement ton journal (pas toi en tant que personne ni usager, mais ce journal là)

Il y a un groupe de travail qui pourrait t'intéresser : libreassociation dont le but est de «construire des ponts entre le milieu associatif et le milieu logiciel libre» tu devrais peut être y trouver une partie de ce tu sembles chercher : le partage des idées au delà des clivages liées aux spécialisations de chacun pour chaque but.

Reste Zen, ça va bien se passer.
Cordialement. Un lecteur.

ps : toutes mes amitiés à Acrimed, et à PEEK-POKEt en particulier, si tu lis ces lignes, cher Cyril.

Une excellente machine est le ACER ChromeBook C720P.
Nous n'avions jamais eu une machine comme cela.

Grosso modo, et en très résumé qui mériterai d'être étoffé et sourcé : Google fait plus et mieux que tout les autres sur ce sujet. C'est à ire qu'il sécurise mieux cette pile initiale, par défaut. Tout en laissant la possibilité de le faire soi-même. La différence entre les deux se résume à une vis physique. C'est réellement très très bien fait.

Le ACER C720P ne peut pas se passer de l'IME (il s'arrête électriquement au bout de 30mn d'usage sans) mais on peut remplacer la version par défaut (~5Mo) par la version pesant 1,7Mo. Tout le reste, absolument tout, est libre, code source livré et compilable soi-même (y compris le code de contrôle de la puce EC, on peut injecter son propre code avec un bus-pirate ou tout autre matériel destiné à cela) C'est une machine particulièrement agréable à utiliser, avec coreboot, sans perdre aucune fonctionnalité (acpi, S2/S3, tactile, …)

Sur certaines machines tu peux remplacer celui faisant presque 5MO par celui faisant un peu moins de 1,7MO.

Fedora 24 VLC via rpmfusion, le problème est toujours d'actualité

Cela dépend de la carte graphique et de son module noyau, vidiablement, non ? J'ai ce bug, sur Fedora 24 (et précédentes) sur une intel de dernière génération : VLC n'arrive pas à redimensionner la vidéo, celle ci reste à sa dimension réelle même en redimensionnant la fenêtre. Idem s'il est lancé sur le gpu "discret". Je n'ai pas testé, par contre, le filtre "redimensionnement vidéo".

Enfin, si je déplace le lecteur la vidéo ne suit pas : elle reste affiché là où elle a démarré :p Ceci, par contre, fonctionne sur le gpu "discret" : la vidéo a du mal à suivre la fenêtre qui bouge mais elle bouge :-)

Mplayer n'a pas ce soucis, avec les mêmes "sorties" testées. Aucun.

Globalement il y a dix ans lorsque les autres lecteurs n'y arrivaient pas, VLC y arrivait presque toujours. Aujourd'hui j'ai l'impression que c'est un peu (beaucoup) l'inverse. Il y a pas mal de vidéos qui ne passent plus avec VLC. Peut être cela vient il de la compilation par/pour rpmfusion, je ne sais pas.

Faut faire un sondage !

Le bouton -1 est là pour ça.
Il est également possible de venir participer en rédaction.
Enfin ce n'est pas une décision individuelle mais un vote collectif, et les commentaires sont pris en compte pour la suite.

Réponse d' un autre modo : j'ai fait le choix d'attendre pour mon vote celui d'autres avant, ayant vu que Pierre avait voté contre. Une fois d'autres choix tombés, j'ai aussi voté pour.
À vrai dire pas parce-que je suis pour ou contre ce style d'ecriture, mais bien plus simplement pour le style de la dépêche. En effet, globalement j'agis de la sorte. Soit la dépêche est factuelle, non personnalisée et adopte un ton neutre (de qualité style wikipedia) et alors je corrigerai au mieux. Soit la dépêche adopte un ton plus personnel, auquel cas le style ne sera pas retouché.
Ces deux styles de dépêches ont leurs avantages et leurs places.
C'est juste ça qui me fera m'adapter, et non un quelconque jugement personnel.

Pour ce qui est de l'écriture inclusive, il s'agit bien d'un acte militant, il me semble au départ utilisé massivement par Zebda, afin de mettre en lumière un manque de notre langue aux yeux de certains : la masculinisation du langage à n. La langue évolue et on ne dit plus madame le président, par exemple. Zenitram a raison sur ce point : c' est bien un acte militant. Il exagère cependant sur les comparaisons et sa généralisation : cela ne blesse ni n'exclue personne. Pour trouver un équivalent réel il faut plutôt chercher vers le vieux langage employant encore madame le président, malgré les réformes successives.

Globalement il n'y a donc aucun jugement qui entre en ligne de compte autre que celui de savoir si le ton employé est personnel ou impersonnel.

Enfin concernant l'aspect sanguin de certains échanges, outre le fait de se focaliser sur de tels détails (au delà, autre qu'une remarque de désapprobation) on peut juste rappeler que cela conduit souvent vers le xkcd : "Someone has wrong on the internet".. dommage.
Puis employer simplement le même ton pour la réponse, surtout sur le sujet du sexisme, où les remarques perçues comme désobligeantes ou stigmatisantes ne sont en fait souvent qu'une écriture équivalente à une mauvaise blague quasi culturelle accompagnée de son ton sarcastique (ou ironique dans le meilleur des cas). La réponse serait donc meilleure, certainement, si elle employait simplement le même ton et le même mode sans ajouter de couche de moralisation 'someone has wrong', encore moins de violence.

Et puis on passe à autre chose.

Mes deux cents.

Bravo et Merci !
Pour la Belgique, cela permettra à la fameuse ville de Mons (connue pour ses scènes culturelle, musicale et logiciels libres) d'être dans l'AdL.

Signalons aussi que la «Tribue des Gelbes» accueille chaleureusement une méga moulebouffe le week-end du 13 aout.
Seront présents :

• 2petitsverres<
• Alenvers<
• Altor<
• Claudex<
• Krunch<
• Madame_alenvers<
• Seeschloß<
• Tankey<
• et des guests stars de dernière minute

Cela sera aussi l'occasion de visiter cette belle ville de Bruxelles, de jour & de nuit ! Les thèmes évoqués iront du pilotage de satellites à la conception de vaisseaux spatiaux, en passant par FreeBSD, KDE en production, l'imagerie satellite, la bio-informatique, la visualisation pour les big-datas, le domptage de pare-feu poilus, la vie ministérielle, le contrôle qualité avionique, la modélisation mathématique du piano, de GNU, de GNU et encore de GNU, l'avenir des bouchots et des c², le programme de Jean-Luc Mélenchon, ou l'incubation d'excellence en milieu urbain.

Je l'ai utilisé, au quotidien, pendant une dizaine de mois, sur un serveur dédié au DC3 (donc un double xeon avec 16go de ram, la base là bas). CozyCloud fonctionne plutôt bien (une vidéo si tu veux, elle date un peu). Ce qui me déplait :

• le client mail : il ne suit qu'une seule RFC dont pas fichu de fonctionner avec de vieux systèmes (plus les ref en tête, désolé) quant n'importe quel autre (kmail, thunderbird, evolution, celui de nextcloud, et j'en passe) fonctionne avec de vieux systèmes de mails
• l'import google photos : il ne se rends compte d'aucun fail, donc on se retrouve avec une page de miniatures/accueil pleine de trous. Comme il n'y a aucun fonction de synchro disponible, ça restera comme ça. Bizzarement en passant par l'export des données de google, puis l'import dans Cozy à la main, ça fonctionne.
• La lenteur ahurissante pour afficher une page contenant moins de 1000 miniatures d'images, et qui sera rechargé de zéro à chaque fois, surtout ça.
• npm, ce truc me file des boutons.

Donc, amha, c'est du à la jeunesse du projet. Et tout ceci va s'améliorer avec le temps (à part le client mail, j'ai cru comprendre dans les réponses du forum que ça bougera jamais, trop compliqué)

Je viens de passer à NextCloud, il y a tout juste 15 jours. C'est un autre monde, pas comparable. J'avais besoin de pouvoir partager des fichiers et gérer des utilisateurs, en plus nextcloud intègre videojs, c'est vraiment sympa d'avoir du streaming vidéo en deux cliqous pour les gens.

Je reviendrais à n'en pas douter sur CozyCloud. Mais pas maintenant.

M'enfin, ce que j'attends surtout d'un "cloud" ce sont les réplicats faciles sur d'autres serveurs, la synchro et le failover (voir un eq à pacemaker). Sans cela, c'est juste de belles WUI pour des fonctions sommes toutes basiques. Ce qui est drôle c'est que mon "trop vieux serveur de mail tout pourri", lui fait ça en 2 lignes de shell, nativement.

J'ajouterai "à ne poster sur le contexte mais seulement sur le contenu", donc ne pas s'attacher au cheminement qui a suivi la décision, mais seulement à celui qui mené à la décision.
Mes deux cents, pour un exposé clair.

Attention à noter que poster ici peut mettre en porte à faux quelqu'un de précieux pour la communauté. Savoir qu'il ne pourra ni répondre personnellement ni répondre officiellement peut conduire à des situations que personne ne souhaite. Personne (je pense). Donc attention à vous lecteurs de garder la capacité de différenciation. Et merci, Gelnior<, de penser et de porter attention aux autres avant de poster.

mes deux cents (qui ont la chance, eux, de rester indépendant et non impliqués.)

Cette distinction sauvegarde/archivage, c’est une distinction de technicien

Non. Vraiment pas.
Seul l'utilisateur connait sa donnée. C'est le seul en mesure de savoir ce qui doit être archivé.
L'archive relève donc entièrement de la responsabilité de l'utilisateur.
Nous sommes là dans un sujet de conservation et de pérennisation de patrimoine. Ici l'informatique n'intervient que pour mettre à disposition de l'espace et un outil. L'outil d'archivage doit être manipulé par les utilisateurs exclusivement.

Pour la sauvegarde, l'informatique intervient à tout les niveaux : donner le service dans des contraintes mutuellement comprises d'espace et de temps, rendre le service selon les contraintes mutuellement définies (& avoir à disposition de l'espace et de l'outillage.)

Le fait d'avoir du mal à distinguer ce qui doit être archivé de ce qui doit être sauvegardé et de ce qui ne doit pas l'être est un problème humain, et pas technique. Ce problème est certes commun et partagé par le technicien et l'usager, oui :-)) Mais cela n'en fait pas une raison pour que l'usager délègue la responsabilité du choix de ce qui doit être archivé au technicien.

C'est vraiment primordial cette histoire.
Les sauvegardes sont décidées initialement par l'usager. Puis le service est rendu par le technicien informatique.
L'archivage doit être maintenu par l'utilisateur.

Si tu n'as pas ce problème, alors tu n'as pas de question d'archivage. Tu as juste un problème de dates à tes sauvegardes ;-)

Avec une référence :
https://lwn.net/Articles/416494/

QNAP TS-509 Pro (..) relié en NFS à mon réseau local ( …) un autre NAS (…) fait le rsync sur un disque relié en e-sata.

C'est pas si compliqué que ça :-)

une sorte de dico des inodes en mémoire.

Ce sont les dentries, qui n'existent que pour ça. Et c'est sur ça que joue les liens. La dentry référence donc un nom de fichier à un numéro d'inode et à son dossier parent. Le fait de stocker à part les noms remonte à l'invention des hardlinks (c'est aujourd'hui critiqué, il me semble amha toussa) d'avoir séparé les deux, et la notion même de hardlink est critiquée (du moins, à ce niveau là) Les inodes, quant à elles, contiennent des méta-données (permissions bases par exemple, bref, "l'index du noeud")

Le débit est effectivement très faible… Ce n’est pas du débit pur, sachant que pour les hardkinks il faut stocker une sorte de dico des inodes en mémoire. En fait, j’ai l’impression qu’il diminue fortement avec le temps (sans doute dès qu’il utilise le swap ???) (…) Hélas, je ne me souviens pas de tout ce que j’ai essayé !

Tu devrais essayer un bon vieux logiciel tel que cpdup qui est fait pour ça :

The cpdup utility makes an exact mirror copy of the source in the destination, creating and deleting files and directories as necessary. utimes, hardlinks, softlinks, devices, permissions, and flags are mirrored

à priori il rencontre la même difficulté que toutes autres solutions lorsqu'il s'agit de créer des hardlinks : maintenir la table est couteux en ressources. Mais il n'a pas ce problème lorsqu'il s'agit de copier une structure existante, avec de nombreux hardlinks déjà présents. Si ceci, après tes tests, se confirme, alors tu as une réponse à ta question initiale « mon backup de backup »

La différenciation sauvegarde/archivage est super saine… Mais elle ne résiste pas à l’UX des personnes pour lesquelles je fais cette sauvegarde.

C'est parce qu'ils n'ont pas compris la différence.
C'est très courant, les utilisateurs (même scientifiques) ne voient pas, ne veulent pas voir, le "côté informatique". Et perso je ne leur jette pas la pierre puisque mon expérience fait que je vois des architecctes qui eux mêmes n'ont aucune conscience des outils et organisation qu'ils inventent, aujourd'hui des gens sont propulsés architectes sans aucune expérience technique de terrain. Bon revenons à nos moutons, ce n'est pas le sujet, il s'agissait juste d'illustrer le fait qu'il est difficile de reprocher quoi que ce soit aux utilisateurs lorsque nos propres collègues ne comprennent pas les enjeux techniques et financiers de leur solutions. Ajoutons à cela bon nombre de gens du métier qui voudraient faire comprendre les tenants et aboutissants de chaque contrainte et solution technique à leurs utilisateurs. Au final, c'est pas gagné :)

Pour faire comprendre il faut illustrer. Pour illustrer il faut des chiffres. Pour faire parler des chiffres il faut parler du besoin. Pour faire parler les utilisateurs de leur besoin il faut poser les bases et leur donner les bons outils d'expression :
a) retour en service
b) quantité
c) durée de conservation

Ça a l'air con comme ça, mais c'est bien le centre de la question : exprimer les contraintes techniques pour ajuster la réponse au besoin. Lorsqu'on annonce clairement que le temps de restauration sera de cinq jours, il faut bien que les utilisateurs comprennent que c'est cinq jours de service sans données disponibles … Et ça, en général, ils comprennent bien.

Cela permet de poser ensemble le problème mais selon leur vision à eux, qui est générale binaire :
La donnée qui doit être disponible le plus vite possible en cas de restauration.
La donnée qui n'est pas indispensable à un retour rapide de service.

Voilà, on a nos deux ensembles, les deux seuls réellement indispensables. Tout le reste, dessous, c'est du métier, de la tambouille interne.

Au final je dirais bien humblement qu'il faut distinguer non pas deux mais trois différences. Pas seulement la distinction sauvegarde / archivage, mais des différences en terme de date : retour rapide / restauration partielle / restauration complète.

il y a plusieurs cas avec récupération de données assez anciennes.

C'est (je trouve aussi, toujours amha) le second point, une fois le premier correctement posé et expliqué. C'est la date limite de conservation du produit, au delà de laquelle il sera périmé. Et cela permet d'illustrer parfaitement la différence en terme de temps à retour de service.

Au final, cela fait un tableau de ce genre :
les temps à retour attendu de services (retour rapide / restauration partielle / restauration complète)
les estimations de poids nécessaires à ces services.

elles ne le feront pas elles-mêmes

Non, car ce n'est ni leur job ni une nécessité pour eux.
Par contre la gestion de l'archivage est de leur responsabilité. Au final ils doivent faire deux choses :
Désigner initialement ce qui sera sauvegardé (à faire une seule fois au début, puis rarement en cas de modif).
Et gérer ce qui devra être archivé (à faire de manière régulière)
On ne bascule pas une sauvegarde en archive, et on ne sert pas d'un archivage pour des sauvegardes. Les seules personnes à même de savoir ce qui doit être archivé ce sont les utilisateurs. Qu'ils dérapent et que ça ne soit pas parfait n'est pas ton problème, et rien n'est jamais parfait. La sauvegarde c'est toi, l'archivage tu te contente de leur fournir de l'espace et un outil.

tl;dr, un peu blabla, désolé.
et on va laisser de côté le vocabulaire bingoloto du genre "dé-duplication / ré-hydratation de la donnée" …

Oupss, désolé Albert, ai répondu au premier commentaire avant de voir le tiens. Cela aurait été mieux de rebondir sur le tiens vu qu'on expose deux avis différents avec deux argumentations différentes.

Skype fonctionnait merveilleusement bien au début et au milieu des années 2000. Et bien intégré en plus.
Cela fonctionnait tellement bien, et par ailleurs assez "respecté" par des experts en sécurité, que de nombreuses personnes ont adopté Skype, même sur Linux. S'en suivit le bouche à oreille, le fameux cercle vertueux était lancé, les utilisateurs toujours plus nombreux. Bref, Skype was everywhere. Logiquement Skype est devenue attrayant, autant pour les investisseurs que les fossoyeurs.
Et parfois, il arrive que l'investisseur devienne le fossoyeur.

Skype est découpé en tranches (techniques ou de services, peu importe) entre Lync pour les entreprises et Facebook messenger pour les particuliers. Est ce une volonté ou simplement un état de fait qui mène à ce semblant d'indécision actuelle (qui ressemble à un "laissons le mourir de sa belle mort") ? Aucune idée, me gardant bien de juger sur une hypothèse. Ce qui semble sûr c'est que Skype se meurt.

Et un petit bot des Romulans pour discuter entre eux sera disponible demain à tout les membres de la Fédération.

Pareil, obligé de remplir ce type de formulaire, il m'a fallu passer par playonlinux/wine + adobe reader.
C'est désolant qu'après toutes ces années de "référentiel d'interopérabilité" et de consignes ministérielles, certains formulaires n'aient toujours pas été mis à jour.

C'est à cause des petits gris qui orbitent à 1M km de la terre en héliosynchrone. Les petits gris sont très exigents. [:zino]