rahan a écrit 138 commentaires

Tu as testé de faire tourner llama.cpp (ou autre) sur openCL/ROCm ? Parce que toutes mes tentatives ont été infructueuses. Je ne sais pas si c'est lié à ma distribution (Debian testing), ma carte vieillotte ou les drivers qui hésitent entre libre et propriétaires…

Je suis preneur d'un retour positif d'utilisation d'openCL sur AMD. Il y a quelques années, j'avais réussi à utiliser ma carte avec Blender, mais tout est cassé chez moi depuis environ 2 ans en ce qui concerne openCL sur GPU (ça marche sur CPU, mais il y a peu d'intérêt).

Je serais curieux de savoir comment tu arrives à faire tourner ces modèles avec un GPU AMD. J'avais essayé de voir si ma vénérable Radeon RX 570 pouvait être utile mais visiblement, en dehors de CUDA (NVIDIA propriétaire), point de salut…

Je vais dans Aliases, puis + Ajouter un alias.

Là, dans le champ Alias d'adresse(s), je lis:

Adresse(s) courriel complète(s) ou @example.com, pour capturer tous les messages d'un domaine (séparées par des virgules). Seulement des domaines Mailcow.

Qu'est-ce qui t'empêche d'avoir des alias * dans Mailcow ? Pour mes mails perso, j'utilise Mailcow et j'ai un alias *. Cela fonctionne sans soucis.

Je me réponds, j'ai testé hier pour une présentation simple. La conclusion est : Ce n'est pas sec.

J'ai utilisé ce template : https://github.com/andreasKroepelin/typst-slides. Rapidement je me suis rendu compte que les tables de base de typst ne supportent les cellules fusionnées, j'ai donc rajouté le module : https://github.com/PgBiel/typst-tablex.

C'est là que les ennuis ont commencés. tablex n'est visiblement pas compatible avec les animations de slides. Il faut choisir : une jolie table statique ou une table plus simple qui ne peut pas s'animer.

Et puis soudainement typst plante aléatoirement. Visiblement c'est un bug connu : https://github.com/typst/typst/issues/1370. Par contre ma distribution n'a pas la bonne version de Rust pour recompiler typst.

J'ai finalement copié mon fichier sur https://typst.app/ pour terminer le boulot rapidement. Cela n'a pas fonctionné longtemps : pour une raison inconnue, impossible de rajouter une quatrième page.

Au final, j'ai passé 2 heures à essayer de faire 4 diapos que j'ai finalement fait salement avec le PowerPoint du boulot…

Sur ma TODO list de ma transition de LaTeX à typst:

• https://github.com/andreasKroepelin/typst-slides
• https://github.com/lvignoli/diapo

Merci pour ces explications et pour permettre de mieux comprendre les modes de fonctionnement des éoliennes. En fait ce que je n'avais pas bien compris c'est l'échelle de la courbe de puissance ; je la voyais plus raide. Je pensais que les éoliennes étaient plus souvent à puissance nominale alors que dans les faits, elle ne le sont que 2 % du temps.

Je crois que tu te trompes dans ton calcul de facteur de charge.

1.3 MW de production moyenne totale
1.3 ÷ 4 = 325 kW de production moyenne par éolienne
2 MW de puissance nominale (voir première colonne des graphiques)
325 ÷ 2000 = 16 % de facteur de charge moyen.

Justement, c'est ce qui m'interpelle : ce sont des éoliennes de plus de 10 ans. Elles auraient dû être installées sur un site rentable. Et là, elles ne semblent qu'atteindre 15-19 % de la puissance max.

D'après ce que je lis des graphs, le facteur de charge de ces éoliennes est entre 15 et 19 %. (Si on considère la puissance nominale de chaque éolienne à 2 MW comme le laisse supposer la première courbe; une énergie fournie sur 5 ans de 13 à 17 MWh). On est donc bien en-dessous de la moyenne européenne.

Les données interrogent sur la rentabilité d'un tel site. La production a l'air vraiment sous-optimale. Tu es sûr des données ?

Je ne comprends pas comment un tel site a pu être construit. Il y a peut-être un paramètre fiscal/subventions que j'ignore…

C'est d'autant plus étonnant que c'est l'unique site mis en open-data par Engie. Ce n'est pas la meilleure pub pour l'éolien…

Mon seul regret de cette version de Debian c'est l'absence de FreeIPA-client. Toutes mes machines s'authentifient sur 2 serveurs FreeIPA. Je vais devoir attendre que le paquet apparaisse dans les backports avant de faire la mises à jour…

Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…

Pour la partie SQL, tu peux faire un truc du genre :

TMPDIR=`mktemp -d`

echo "  Backup MySQL..."
docker-compose exec -T maria sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > $TMPDIR/dump.sql

RESULT="$?"
if [ "$RESULT" != "0" ]; then
   echo "Error in MySQL dump."
   exit $RESULT
fi

echo "  Running your backup software...."
rm -rf $TMPDIR

Après, il faut que tu gères la sauvegarde des données (et aussi du php). Perso, j'utilise Burp.

Tu as aussi un peu de doc sur le site de Nextcloud.

Désolé d'être rabat-joie mais les bonnes pratiques te disent qu'en cas de compromission, il faut tout effacer pour repartir sur des bases saines. Tu t'assures que tu as sauvegardé les données puis tu formates et tu réinstalles tout proprement en t'assurant d'utiliser des sources sûres et à jour.

Une fois qu'un système a été compromis, il est très difficile de s'assurer qu'aucune porte dérobée n'a été laissée.

Une autre chose : tu changes tous les mots de passe. Tu peux considérer que tous le mots de passe utilisés sur les services de cette machine sont compromis. Il faut donc les changer ainsi que ceux que tu aurais réutiliser sur d'autres services.

Bon courage.

Je recommande BURP. Je m'en sers depuis des années pour sauvegarder des serveurs linux, des PC linux, des portables linux et des portables Windows. C'est packagé dans Debian donc il n'y a pas grand chose à faire pour l'installer. Il y a aussi un installateur Windows. Ça marche très bien et se laisse oublier. En cas de souci, le développeur est très réactif sur la mailing list.

SQL est sûrement beaucoup plus adaptée à mon usage mais je crains de devoir réinventer la roue pour chaque fonction déjà prévue par sssd. Mon idée était de s'ennuyer un petit peu avec la partie serveur pour pouvoir utiliser coté client des procédures simples et déjà intégrées dans les distributions.

Merci pour ce retour. Je vais essayer FreeIPA sur une machine virtuelle (CentOS) ou dans un container (docker).

Toutes mes configurations sont déjà gérées par Ansible dans un dépot git. C'est très pratique quand on a tendance à réinstaller régulièrement de vielles machine.

C'est une des solutions que j'avais testé (avec GoSA qui ne semble plus développé). Je ne l'avais pas retenu car une partie des modules que je voulais utiliser à terme (sudo, Kerberos) n'est disponible que dans la version propriétaire : https://www.ldap-account-manager.org/lamcms/featureMatrix

Je me trompe peut-être mais j'avais l'impression que LemonLDAP::NG est un fait une solution pour faire du SSO pour des application web. Il utilise ensuite un serveur LDAP qu'il faut lui fournir. Ca ne répond pas à ma problématique de gérer de manière "conviviale" les utilisateurs.

Je ne connaissais pas. Merci pour le tuyau. Par contre, il y a pas mal de truc que je ne pourrais pas faire avec (hosts, sudo, autofs…). La documentation a l'air pas mal en retard sur le code (les backends ne semblent pas documentés) et je n'ai pas compris comment les changement de mot de passe sont gérés (tout semble stocké en dur). Par contre c'est intéressant pour tester ou pour des gérer des services web avec un ou deux utilisateurs.

En fait mon problème vient du fait que je voulais rester sur une solution installée sur une Debian. J'ai testé 389DS et l'interface graphique ne m'a pas semblé très intéressante pour mon usage. J'ai bien compris que les fonctions que je recherche sont intégrées dans FreeIPA mais comme ce n'est pas évident à installer sous Debian, j'ai jeté l'éponge. Au final, je vais sûrement approfondir cette option dans un container docker ou une machine virtuelle CentOS.

Merci pour le retour.

Salut,

Je vais rajouter ma petite pierre à ta description. J'ai aussi un Pinebook Pro depuis décembre. J'ai rapidement installé une debian testing sur une partition chiffrée. Je l'ai utilisée pendant quelques mois sur carte SD puis j'ai basculé sur le disque eMMC. Il y a un script qui permet facilement de préparer un disque pour ceux qui sont fâchés avec debootstrap: https://github.com/daniel-thompson/pinebook-pro-debian-installer

Mon retour est plutôt positif. Je m'en sert comme portable principal (en remplacement d'un Thinkpad T430s plus lourd et à aux batteries mourantes) depuis février. Il convient parfaitement pour mes taches quotidiennes : courriel (mutt), administration système (ssh avec Yubikey, ansible, emacs), développement web (django, docker), glande (firefox, youtube est fluide en 1080p tant qu'on ne prend pas 60 fps). J'ai un PC de bureau bien plus puissant si besoin. J'ai compilé 1 ou 2 fois le noyau dessus et c'est vrai que c'est long malgré les 6 cœurs. Depuis je lance la compilation sur mon PC de bureau.

Par rapport aux paquets debian, j'ai un noyau customisé (voir le script plus haut) et j'ai compilé le paquet mesa depuis la version de développement pour corriger des plantages de X11/Wayland. J'ai installé sway sur Wayland et ça fonctionne très bien.

Les cotés positifs :

• Léger
• Bon clavier (je tape en qwerty-uk depuis des années)
• Bon écran
• Très bonne autonomie (je n'ai jamais mesuré précisément mais il tient 2 jours de travail)
• Le prix
• La variété des architectures (ça ouvre l'esprit)

Les cotés négatifs :

• La veille ne fonctionne pas (ça plante régulièrement quand on le réveille en ouvrant l'écran)
• Le son est très faible (visiblement je n'arrive pas à activer l'amplification) et il y a des sifflements aigus parfois
• U-boot qui nécessite un cable série pour l'utiliser
• Je ne suis pas persuadé de la solidité (un coin est fissuré mais il faut dire qu'il a pas mal voyagé dans mon sac à dos)
• Pas de support "out-of-the-box" de la plupart des distributions

Au final, je le conseille aux habitués de linux qui veulent un portable d'appoint pas cher, léger et à grande autonomie. Pas mal de gens qui l'ont vu voulait le même mais je ne le conseille pas à ceux qui ne connaissent pas linux.

PS: tu peux mapper la touche on/off vers "delete".

L'export HTML5 fonctionne bien. Je joue sans problème avec Firefox avec une vitesse proche de la version lancée depuis Godot (j'ai lancé Godot en X distant à travers ssh donc je ne sais pas quelle est la vitesse escomptée). Je n'ai pas de son sur ma station, donc je ne peux pas te dire si ça passe ou pas. La seule chose qui ne marchait pas était le jeu en réseau : il n'arrivait pas à joindre le serveur.

J'ai fait des jeux en Godot avec mes enfants pendant le confinement et j'ai trouvé que la manière la plus facile de les partager avec leurs copains c'est l'export HTML5. Il est vrai que nous ne sommes pas très exigeants sur la vitesse et la qualité du rendu…

Pourquoi tu ne proposes pas de jouer en ligne ? Godot propose un export vers HTML5. Pas la peine de télécharger des binaires "douteux", on doit pouvoir jouer dans son navigateur.

Je conseille vivement le Pinebook Pro. C'est mon PC principal depuis un mois. J'y ai installé une Debian (testing) sur une partition LUKS. Ça marche plutôt bien pour mon usage (i3, terminal, emacs, mutt et firefox; développement python et django mais aussi compilation C/C++). Le support n'est pas encore parfait (kernel custom + firmware bluetooth exotique + mesa en version git), il ne faut pas avoir peur de mettre les mains dans le camboui.

Je suis très satisfait de l'écran, du clavier et de la batterie (> 10 heures). Par contre le trackpad n'est pas très précis et les hauts-parleurs faiblards. Les processeurs ne sont pas des flèches mais curieusement je ne le remarque pas trop dans les compilations ou sur firefox. Mutt a un peu de mal sur mes gros dossiers.

Ne pas oublier dans le prix, la TVA et les frais de douane (+25 %). La version avec 128 GB de stockage n'est plus disponible. 64 GB peut être un peu juste selon les usages.