jihele a écrit 1238 commentaires

Essaye en ligne de commande:

dpkg -i le_nom_du_paquet
et voit ce que ça dit.

Dans v42, tu peux activer l'ancienne interface avec une préférence. Dans v43 tu ne peux plus.

OK. Je pensais l'avoir fait avec une extension (Classic Theme Restorer) mais peut-être que c'était avec l'option de config.

Pour ce qui est du moteur par défaut, tu peux toujours le changer dans les paramètres, facilement accessibles dans l'interface.

Oui, bien sûr, mais ce qui m'ennuie c'est que chaque nouvelle recherche utilise le moteur par défaut et pas le dernier moteur utilisé. A la réflexion, les deux valeurs (moteur par défaut ou moteur précédent) se défendent, et je suis même pas sûr de savoir laquelle occasionne chez moi le plus de clics. Peut-être que c'est mieux avec le moteur par défaut.

Quand j'explore les paquets debian, j'utilise plein de fois le moteur Debian packages à la suite, donc j'aime bien qu'il reste sélectionné. Pour un cas comme ça, c'était mieux avant.

Je suis pas sûr de comprendre ce qui va changer dans la v43.

Sur une machine, j'ai la v38 sans modification, donc le nouveau comportement par défaut. C'est vrai que ça marche pas si mal. Je regrette l'absence des noms en face des icônes, c'est un peu nul si tu as Wikipedia EN et FR et les icônes sont identiques. Des fois je mélange même avec Wiktionary. Sur la capture d'écran, on dirait qu'au moins quand une icône est sélectionnée, le nom du moteur apparait au-dessus. C'est pas idéal mais c'est un moindre mal. Sur ma v38, c'est pas le cas.

En contrepartie, dans l'ancien modèle, je m'emmêle un peu les pinceaux entre la navigation dans les suggestions de recherche et la sélection du moteur, alors que dans le nouveau, on peut s'en sortir avec la flèches haut/bas pour les suggestions et la touche tab pour le moteur. De ce point de vue, c'est un progrès.

Finalement, ce que je regrette, c'est surtout le retour systématique au moteur par défaut. C'est dommage de pas pouvoir supprimer ça, ne serait-ce qu'avec une clé dans about:config. Je pense que je vais me mettre aux mots-clés, et au final, j'aurais peut-être une utilisation aussi bien sinon meilleure qu'avant.

Ça marche toujours chez moi.

Il dit que c'est à partir de la v43 que ça marchera plus :

À partir de la version 43, il ne sera plus possible de garder l’ancienne façon d’accéder aux moteurs

Je pense jamais à Alt+Entrée, merci pour la piqûre de rappel.

Je suis assez d'accord avec le commentaire. Avec l'ancienne version, je peux faire mes recherches sans toucher la souris :

Ctrl+T
Ctrl+K
Entrer les termes à rechercher
Alt+Flèche Haut/Bas pour sélectionner le moteur

Le dernier moteur utiliser reste actif pour la recherche suivante.

Ça m'embête que ce fonctionnement soit cassé.

Je crois que gksudo c'est mieux, mais je ne suis pas le mieux placé pour expliquer la différence.

http://askubuntu.com/questions/11760/what-is-the-difference-between-gksudo-nautilus-and-sudo-nautilus

https://help.ubuntu.com/community/RootSudo#Graphical_sudo

On retrouve également de l'ADN de Denisovien chez les asiatiques.

Ah ouais, j'avais jamais remarqué les yeux bridés.

Je ne crois pas avoir vu passer le lien.

Liste plus complète d'organisations : http://soutenonslesbienscommuns.org/

Leurs contributions : http://soutenonslesbienscommuns.org/contributions/

Ouais, je sais que j'abuse du terme, c'est pour ça que j'ai précisé. Mais ça reste du dédié, mon courrier est pas dans les serveurs de courriel de Gandi et encore moins chez Google (sauf celui que j'envoie ou reçoit de qqn chez gmail…). Bien sûr, un admin de chez Gandi peut aller le lire s'il a du temps à perdre.

Ça reste plus simple pour la NSA d'aller lire le courrier chez Google que de se taper tous les petits serveurs à gérer, avec leurs différentes configs.

C'est mon compromis entre sécurité et fiabilité/conso énergétique.

En tout cas pour le reste du propos, ça changeait pas grand chose, donc j'ai cité mon exemple pour réagir sur l'invitation à l'auto-hébergement.

Installer sur un dédié, c'est pas auto-héberger, mais c'est déjà décentraliser, c'est une part du boulot de fait. Je le verrais peut-être différemment si j'hébergeais ça dans un VM chez Amazon.

Franchement, mettre mon courriel principal et unique chez moi, j'oserais pas. Entre la box de merde, la potentielle coupure de courant pendant les vacances, les déménagements de temps en temps, et tout… Trop chiant.

Et puis il y aurait des choses à dire sur l'auto-hébergement. Chacun son serveur chez soi, bonjour le coût énergétique. Il faudrait trouver un niveau intermédiaire de localisation. A l'échelle d'une petite communauté avec un gars qui s'y connaît, c'est bien. Quand je plaquerai tout, j'irai faire sysadmin dans le Larzac.

GitLab, par exemple, je vois pas de paquet Debian, même expérimental.

Au boulot, j'ai installé Gitolite et Redmine. J'ai pas encore essayé le lien entre les deux, mais j'espère que ça fera le boulot (et que Redmine se cassera pas trop à la prochaine grosse MàJ).

Dans mon précédente message, je yakafokone un peu, et j'oublie de dire merci pour le boulot de Framasoft.

L'auto-hébergement, c'est bien. En fait, c'est peut-être même Le Bien. Mais c'est chiant.

J'auto-héberge (chez Gandi, pas chez moi) ma messagerie, mes listes, mon web, depuis quelques années.

• A installer, c'était du boulot (cf. les dépêches tuto sur DLFP), et pas du boulot simple, en tout cas pour la messagerie, du boulot pour geek qui avait le temps.

• Au quotidien, ça marche plutôt bien.

• A maintenir, ça peut être lourd. Typiquement, le passage à Jessie, on le repousse parce que ça va être du boulot, donc du temps, et que maintenant, on est toujours des geeks mais on a plus le temps. (Et Roundcube a disparu des dépôts…)

De même, je mettrais bien en place du Frama* au boulot pour remplacer le WeTransfer, le Doodle, etc. Mais je veux pas me rajouter une dépendance de plus. Je peux mettre en place un truc vite fait, dire à tout le monde de l'utiliser parce que c'est bien (voire Le Bien) et parce que c'est plus la classe pour la boîte d'avoir un truc personnalisé. Mais je peux pas justifier de passer trop de temps dessus pour la maintenance alors qu'il y a des trucs gratuits "kivonbien".

Si je dois surveiller les releases et faire les MàJ à la main, c'est pas jouable.

Bref, tout ça pour dire que pour installer ça sur mon serveur ou celui du boulot, la condition, c'est le paquet Debian. Ça change tout. Si le paquet est présent (et bien fait), l'administration, ça revient à "aptitude install" une fois et c'est fini. Et là, c'est vraiment royal, ça rend le truc auto-hébergeable par Kevin sur son RaspberryPi.

Et ça évite que dans quelques mois on ait plein d'instances en ligne avec une faille de sécurité parce que personne a mis à jour depuis l'installation.

Au début de chaque heure, un géant tire sur la corde et celle-ci s'allonge de façon élastique. À chaque fois la corde s'allonge de 100m de façon homogène.

À l'issue de la première heure, l'escargot à parcouru 1m, le géant tire sur la corde, celle-ci passe à 200m. Puisque la déformation est homogène, l'escargot se trouve maintenant à 2m du point de départ.

Donc c'est à la fin de chaque heure, que le géant tire. Et c'est l'escargot qui joue en premier.

Demander aux utilisateurs de comprendre les tenants et aboutissants de ça, c'est ridicule. Demander aux admins de virer les polices emmerdantes, ça me semble plus accessible, déjà. Ou donner des templates avec les bonnes polices. Ou oser demander à la boîte qui reçoit pour des millions d'euros annuels d'argent public de faire une petite adaptation pour simplifier la vie de ses usagers…

Pour les demandes de certificat d'immatriculation, j'ai constaté la même chose, mais en cherchant sur internet la référence CERFA tu trouves des .pdf que tu peux ouvrir avec ton logiciel habituel, imprimer, et remplir à la main.

J'ai peut-être mal cherché parce que j'ai imprimé la version 01 au lieu de la 02. J'ose croire que ça ira quand même.

Moi aussi j'ai un peu souri en lisant ça :

L'objectif de ce CMS est d'être simple à utiliser, avec un maximum de fonctionnalités utiles, le back-office est simple et son utilisation fluide.

Ça fait un peu copier-coller des dernières annonces de sortie de CMS.

Avec un tout petit peu de recul (j'ai une expérience limitée des CMS), un de mes critères de choix concernerait la maintenance :
- est-ce que le développement va suivre dans le temps ?
- est-ce que les mises à jour sont fréquentes ? difficiles ?

J'aurais tendance à privilégier un "gros" par sécurité, quitte à ce que ça soit un poil plus lourd à configurer, si ça me garantit mieux l'avenir.

Sur un serveur Debian, je serais même tenté d'utiliser un logiciel disponible dans les dépôts, mais je crois que les développeurs ne le recommandent pas parce que c'est vite obsolète et pas forcément backporté.

Merci.

Une recherche rapide m'a amené à cette page qui donne quelques détails.

Pour des backups incrémentaux chiffrés, je te conseille duplicity.

Super. Merci pour le tuto que je me bookmarke derrière l'oreille pour plus tard.

Si tu es seul utilisateur sur le pc, tu peux chiffrer le disque dur et désactiver la demande du mot de passe au login (tu devras alors uniquement donner la passphrase pour déchiffrer le disque).

Oui, c'est vrai. J'aurais pu faire comme ça. J'ai fait dans l'urgence et mal préparé, et j'ai déjà tenté quelques trucs nouveaux (Raid 5 + LVM), donc j'ai pas souhaité compliquer.

OK, pour être honnête j'ai pas lu les détails du journal, mais je mentionnais HandBrake car il peut intéresser qqn qui a été intéressé par le thème du journal.

J'ai commencé à mettre ça en place au boulot, et je ne m'attend(ai)s pas à avoir de problèmes d'UID.

J'ai un serveur sur lequel on va bosser à plusieurs, et donc plusieurs utilisateurs ont accès rwx à un répertoire.

Je pensais le monter localement sur ma machine avec sshfs pour pouvoir travailler dessus graphiquement plutôt que me limiter à vi dans un terminal.

Dois-je m'attendre à des problèmes ?

A quels problèmes fais-tu référence avec les UID ?

J'envisage à long terme (le jour où j'aurai le temps) de mettre en place des sauvegardes croisées entre mon ordi et celui d'un copain distant (plus robuste qu'un NAS en cas d'incendie).

Pas vraiment d'enjeu de sécurité, il s'agirait principalement de mes photos persos, peut-être de la musique, et j'ai confiance en le copain distant sus-mentionné, mais pour le principe, ça m'intéresse de savoir comment faire en sorte que ça soit crypté de son côté (qu'il ne puisse pas lire les fichiers).

Je n'ai pas essayé de chercher comment faire, la paresse me pousse à demander avant de chercher.

Est-ce possible simplement ?

Le fait que mes partitions locales ne soient pas encryptées a-t-il une incidence ? Je pense que non, car j'agis au niveau fichier (copie de sous-répertoires de ma partition). Peut-être que si je copiais une partition cryptée dans son intégralité ça serait différent ?

Je n'ai pas crypté mes partitions à l'installation car j'ai supposé que ça me demanderait un mot de passe supplémentaire à chaque démarrage, ce que je ne souhaitais pas. Peut-être que là aussi je me trompe, mais c'est une autre histoire.

Notez que mon utilisation indifférente des mots crypté/encrypté traduit un peu mon incompétence, en tout cas ma paresse intellectuelle. En contrepartie, je n'attends pas une réponse détaillée, juste une pointeur vers un tuto pertinent et à jour.

Merci !

J'ai voulu faire pareil pour partager des vidéos prises avec un téléphone, en les ré-encondant pour diminuer la tailler et les rendre compatibles. Comme j'aime bien comprendre ce que je fais, j'ai lu la partie correspondante de Dive into HTML5 pour trouver les bonnes lignes de commande pour ffmpeg et j'avais un alias pour tout encoder comme il faut.

Depuis, j'ai voulu faire pareil avec les vidéos de mon nouvel appareil photo, ça marchait pas bien (autre format de départ, je suppose). J'avais pas trop de temps, donc j'ai installé HandBbrake. Il y a plein de pré-réglages pour mâcher le boulot. J'ai pas testé si ça fonctionnait avec toutes les plateformes (en fait, j'ai juste partagé le fichier en demandant à mon destinataire de venir le chercher chez moi avec WinSCP, puis il l'a lu avec VLC…), mais je crois que c'est prévu pour.

Bref, HandBrake ça a l'air pas mal pour

• diminuer la taille d'une vidéo
• l'encoder dans un format qui va bien (ou plusieurs)
• rendre tout ça accessible à Mme Michu

En tout cas, la restriction d'accès par mot de passe fonctionne bien. Un fichier .htaccess est un poil chiant mais pas hyper compliqué à faire (cf. les multiples tutos sur internet). Donc ça répond à la problématique de la vie privée (évidemment, Google peut aussi lire le mail et y trouver les identifiants, mais bon, il a qu'à choisir un mot de passe que le destinataire doit deviner au lieu de l'écrire en clair, par exemple "le prénom de ma fille" si jamais Google ne connait pas encore sa fille).

J'ai volontairement écrit ça de façon péremptoire dans le sondage.

Il y a des tas d'argumentaires contre, mais ça peut faire débat, et ce qui était vrai il y a 10 ans ne l'est peut-être plus maintenant. C'est pourquoi j'ai voulu savoir où "on" en était chez les (plus ou moins) barbus.

Ce qui me vient à l'esprit.

1/ Pas fiable : hormis des formatages simples, on ne sait pas comment ça va s'afficher

2/ Difficile à faire suivre sans tout casser

3/ Porte ouvert à l'agression publicitaire et au mauvais goût

4/ Poids des messages : beaucoup plus lourd pour un message de trois mots, c'est ridicule.

5/ Sécurité : possibilité d'embarquer des contenus extérieurs

6/ Illisible par les gens dont le logiciel ne le prends pas en charge

Mais on peut répondre :

1/ Si on se limite aux formatages simples, c'est pas si mal : gras, souligné, etc. (Et certains parsers HTML -> plain text remplacent le gras par un encadrement par des *, etc, ou alors c'est le logiciel émetteur qui le fait dans la version plain text.

2/ Idem, avec du formatage simple, ça doit marcher, et avec un message complexe, c'est la merde

3/ Ici aussi, on critique le mésusage, pas la technique

4/ Juste, mais quand on commence à envoyer des photos de 4 Mo, ça devient négligeable

5/ Les logiciels savent en général désactiver ces contenus

6/ Il faut vivre avec son temps

Reste qu'avec du texte brut on peut déjà faire des choses claires, donc il faut peser le rapport gain/emmerdement à introduire un truc mal normé qui est sympa parfois, chiant d'autres fois.

Ma (triste) vie :

Au boulot, je force MS Outlook en texte brut (et ça a pas été simple !), sinon c'est la honte pour écrire sur une liste sérieuse, dans un environnement où tout le monde est en HTML, et je n'insère pas la signature HTML qui est fournie par la comm'.

Les limites :

• J'écris en texte simple mais la police d'affichage par défaut n'est pas monospace, donc c'est nul, notamment pour souligner les titres

• Je dois cliquer sur "afficher en HTML" pour lire les tableaux embarqués ou même voir les images qui sont embarquées et n'apparaissent pas comme PJ

• Les interlocuteurs, les rares fois où ils répondent dans le corps de texte, utilisent les couleurs pour séparer leurs contributions, car le préfixage avec > ne se fait pas par défaut.

Bref, merci MS, merci Outlook. Encore, en interne, je pourrais me plier au HTML, mais pour dialoguer avec l'extérieur, ça m'embête.

claws-mail a un éditeur de texte assez bon qui gère le wrapping.

Le seul truc un peu pénible, c'est qu'il ne le fait que lorsqu'une ligné dépasse. Si on modifie un paragraphe pour ajouter un mot au milieu, il refait les lignes de tout le paragraphe. Si c'est pour enlever un mot, il faut ruser et le forcer à avoir une ligne trop longue (typiquement en supprimant un retour chariot) pour qu'il refasse le boulot.

Il permet aussi d'indenter un peu : si le paragraphe commence par le symbole - ou *, il aligne la ligne d'en dessous et tout le paragraphe après le symbole

au lieu de

rm -fr .config
fais plutôt un

mv .config .config_bak
Comme ça tu mets de côté tes fichiers de config, mais tu pourras toujours aller piocher ceux dont tu as besoin s'ils n'étaient pas en cause.