eingrossfilou a écrit 90 commentaires

Ici tu aura une idée de formules alambiquées:
https://stackoverflow.com/questions/949098/python-split-a-list-based-on-a-condition

Par contre, je te mets en garde de ne pas tomber dans le travers des gens qui font du python: passer son temps à trouver une manière plus élégant d'écrire 2 lignes de code sans rien gagner à côté

La version "pythonic" tendrait plus vers ça

list_a = [s for s in some_list if s.startswith('a')]
list_b = [s for s in some_list if s.startswith('b')]

Je suis d'accord qu'il faut un peu changer sa façon de penser.

Note: il y a certainement une formule alambiquée pour ne passer qu'une seule fois dans some_list tout en restant "pythonic"

Sur les clusters de calcul, c'est plutôt singularity qui est utilisé pour faire du docker rootless.
https://sylabs.io/docs/

Comme c'est du rootless, les mécanisme de redirection de port ne sont pas disponibles.

J'ai loué un serveur perso chez Digicube de 2012 à 2018 (ou 2017 - je ne sais plus) et je ne suis pas étonné de leur fin.

Digicube a toujours eu des problèmes récurrents au niveau de la communication. Je ne suis pas étonné d'un mail une semaine avant la fin.

Je me tâtais depuis un moment déjà à partir de chez eux pour plusieurs raisons [1], et je me suis décidé quand je n'arrivais plus à avoir de réponse par email (ou avec un délai de 1 à 2 mois quand il s’agissait de réaliser un paiement).

Je n'ai jamais eu de réponse de leur part à mes courriers de résiliation (LRAR) ni leur relance où je demandais en-autre une facture de clôture, sachant que je leur devais de l'argent.
Je me suis dis que ça puait vraiment à ce moment là et que je faisais bien de partir.
L'accès au serveur que je louais chez eu a été coupé plusieurs mois plus tard.

[1]

• impossibilité de retirer des moyens de paiement enregistrés sur leur site
• pas d'avertissement pour payer le renouvellement du serveur
• impression que les investissements étaient stoppés: les offres présentées sur le site web n'ont pas bougé depuis plusieurs années, ce qui ne facilite pas la conquête de nouveaux clients

Euh, je pense que je me suis mal exprimé.

Manjaro permet d'installer plusieurs version de noyaux côte à côte, mais tu ne peux pas avoir plusieurs révisions d'une même version du noyau (du moins dans le config par défaut). Si une nouvelle révision du noyau que tu utilises casse quelque chose, tu peux ne pas pouvoir démarrer. C'est pour ça que j'ai toujours au moins 2 versions de noyau installées sur mon système (dont au moins une lts).

Sinon, bien que j'ai un système en mode EFI, j'ai un /boot séparé pour pouvoir déchiffrer mon système via ssh lorsque je le démarre à distance (https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Remote_unlocking_of_the_root_(or_other)_partition).

J'ai aussi laissé tomber btrfs sur mon disque système manjaro. Les outils de récupération btrfs après corruption ne sont pas encore au point. La mise à jour du noyau qui efface la révision précédente en cours d'utilisation n'a pas fait bon ménage avec mon vga-passthrough d'une vega56 mal supportée à l'époque (reset du gpu foireux). Ça a fait un beau kernel panic à l'extinction et a bien corrompu mon fs.
J'ai vraiment du écumer le web pour trouver une manière de récupérer les données, la majorité des méthodes de récupération proposées échouant. Peut-être que cela fonctionne mieux maintenant, mais je reste très frileux sur le mariage btfrs, Manjaro et vga-passthrough.

C'est dommage, parce que j'aime bien les aspects compression et déduplication. Je n'ai aucun soucis avec mon serveur proxmox avec le / en btfrs et incluant le /boot.

Salut,

Je suis aussi sous Manjaro, et j'ai deux pb avec ton /boot. Je n'ai pas regardé exactement comment fonctionne timeshift, donc ces problèmes sont peut-être non existants.

/boot hors snapshot ?

Je préfère indiquer une nouvelle fois que je n'ai pas regardé comment timshite traite le /boot.

Ton /boot est une partition ext4 qui ne permet pas de snapshot.
Si ta mise à jour installe un noyau cassé (parce que ça arrive), ton snapshot btrf ne te permet pas d'utiliser la version précédente de ton \boot. Tu seras obligé de booter sur un autre système et faire un chroot pour faire ton rollback et regénérer une image de boot avec mkinitcpio

/boot trop petit

Seulement 200M pour le /boot de Manjaro, ça me semble vraiment juste. Tu ne peux pas avoir plus d'une version de noyau installé. Un noyau + sont fallback, c'est ~85Mo en .xz (~125Mo en .gzip), et tu dois avoir au moins cet espace de libre sur ton /boot pour mettre à jour ton noyau. Je dirai plutôt un minimum de 300M.
Pour ma part, je garde toujours un noyau LTS en plus du dernier stable en cas de problème. Mais si partir du principe que s'il y a un snapshot des noyaux, alors, ce n'est peut-être pas nécessaire.

Alternative

Je pense qu'une solution pour éviter ces pb, c'est de simplement ne pas faire un partition dédié pour /boot, mais de le laisser sur / ou de le mettre dans un sous-volume btrfs. Grub sait booter sur du btrfs du quelques temps déjà.

Je t'aurais dit de regarder ce que ça donne avec Wine(-staging), mais ça semble pas encore ça niveau perf et compatibilité, même si wine évolue vite et bien dernièrement
https://appdb.winehq.org/objectManager.php?sClass=version&iId=36468&iTestingId=108262

D'autant plus que tu as peu de chance que ta carte graphique intégrée intel supporte vulkan, qui minimiserait les pertes de performance 3D avec dxvk.
https://fr.wikipedia.org/wiki/Vulkan_(API)

Malgré ça, tu peux toujours essayer.
Playonlinux est une bonne piste pour tester avec plusieurs versions de Wine (staging ou non).

Si tu as possibilité (i.e. si c'est un pc fixe), envisage de rajouter une carte graphique dédiée (en occasion à pas cher) et de la RAM. Ça ramera moins et c'est accessible en occasion.

J'ai tendance à utiliser zip dans une situation comme ça:

numbers1 = [1, 2, 3]
numbers2 = [4, 5, 6]

result = [x + y for x, y in zip(numbers1, numbers2)] 
print(result)

Ce qui donne le même résultat

En python, le type array (enfin vecteur pour moi) n'existe pas en tant que tel. Il faut utiliser des listes et elles sont non typées. D'une manière générale, python est un langage non typé, même si tu peux préciser les types attendu dans tes fonctions depuis pytho 3.7 il me semble.

Si tu veux quelque chose de plus efficace et typé, utilise la bibliothèque numpy.

Bon c'est une ressource en anglais, mais ça permet de beaucoup progresser

https://www.shellcheck.net/

La version en ligne permet de faire des tests rapides, mais le must est d'installer shellckeck sur son poste de travail et de mettre en place le linter correspondant dans son éditeur de texte favori:

https://github.com/koalaman/shellcheck#user-content-in-your-editor

J'ai fais exactement ce qui est écrit. Résultat : ça ma planté mon OS.
Au redémarrage : écran noir.

Alors j'aurai du apporter une précision quand j'ai mis le liens. La doc est prévue pour arch linux. Il faut parfois adapter un peu.
Ici cela ne m'a pas semblé nécessaire, car la solution me semblait assez universelle, mais j'ai eu tort.

C'est la dernière fois que j’achète un PC portable sans me renseigner sur sa parfaite comptabilité Linux. Je vais surement acheter DELL la prochaine fois.

Alors, c'est vrai que Dell fait des efforts pour que linux fonctionne sur ses Laptops, mais c'est pas encore ça non plus. Le plus gros bloquage est toujours optimus.

À titre personnel, j'ai un xps9560 acheté avec windows qui a été remplacé par Manjaro (dérivée d'arch) après un dd en cas de réparation et retour en garantie. Il qui fonctionne sans trop de pb. Il a fallu que j'attende quelques noyaux pour ne pas bidouiller grub au niveau des option de l'acpi et des maj de pilotes wifi (le killer wifi - carte vendu comme la meilleur qui marche moins bien que le reste, même sous Windows).

À titre professionnel, j'ai un precision 5530 depuis presque 1 an qui a été acheté avec windows 10 pro en non ubuntu dès fois qu'il faille le donner à quelqu'un de non informaticien. Là j'ai bien galéré pour avoir un truc fonctionnel. J'étais parti sur un xubundu 18.04 et si tu n'as pas l'iso de Dell, ben tu y arrives pas (et c'est pas une histoire de bien paramétrer le bios là, mais bien de faire des modif de config en profondeur pour la gestion de l'acpi).
Résultat, il tourne aussi sous Manjaro, où j'ai eu assez de doc pour le configurer a peu près comme il faut, juste encore des problèmes de stabilité après l'avoir connecté à une station d’accueil WD19 usb 3.1 (en particulier le paramétrage du touchpad et de la souris usb qui saute)

Le mieux si tu veux linux sur un laptop, c'est de prendre de truc avec une unique carte graphique. (sauf cas exceptionnel ou tu as besoin de truc comme cuda)

Le wiki de arch linnux répertorie ton problème pour ton modèle et propose une solution ici:

https://wiki.archlinux.org/index.php/MSI_GS65#Video

Salut,

Le site de Kali fourni une documentation pour créer une clé avec une partition persistante:
https://www.kali.org/docs/usb/kali-linux-live-usb-persistence/

Vu comment tu essaies de déployer ton live usb, je n'ai pas l'impression que tu l'aies lu…
Bon, c'est en anglais, mais le principe consiste à créer un live usb normal, puis d'ajouter une partition de donnée sur l'espace restant. Les auteurs recommandent d'utiliser soit etcher, soit dd pour l'installation du live normal, et ensuite d'utiliser parted pour rajouter la partition persistante.

Si j'ai proposé de testé de changer le câble, c'est que j'ai eu des symptômes similaires avec mon casque en terme de fréquences non restituées (c-à-d musique OK, mais pas les paroles). En trifouillant le câble, cela réglait le pb temporairement, et en le remplaçant, plus de pb. J'en suis au 3e câble sur ce casque en 5 ans. Il faudrait peut-être que je mette un câble de section plus importante la prochaine fois.

Chez moi, le symptôme "mais sur certains films ou vidéo sur internet, j'ai la musique, mais pas les paroles qu'on entend faiblement et hachées" indique que le câble de mon casque audio s'est détérioré. Comme c'est un casque à câble interchangeable, c'est facile à réparer.

Si ce n'est pas ça car tu utilises un casque/hp usb, ou que tu as testé avec plusieurs périphériques audio, mais que tu utilises pulseaudio comme serveur audio, tu peux regarder de ce côté:

https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Audio_quality

De mon côté j'ai eu le problème de son haché avec certains jeux que j'ai résolu avec les sous-sections
- Laggy sound
- Choppy/distorted sound

C'est plutôt le modèle RB962UiGS-5HacT2HnT qui me fait de l'oeil chez Mikrotik
https://mikrotik.com/product/RB962UiGS-5HacT2HnT

A la base surtout pour son form-factor compact qui passerai nickel dans la partie communication exiguë de mon armoire électrique, mais aussi pour cette bonne surprise qui semble prometteuse:
https://forum.openwrt.org/t/installing-lede-on-mikrotik-rb962uigs-5hact2hnt/5117

Si tu veux des fichiers images, tu peux toujours prendre ceux-ci:
http://garmin.openstreetmap.nl/

Bon vu l'autonomie annoncée du pro, si quelqu'un as des info sur la version kde, je suis preneur aussi.

Je ne connaissais pas les Slimbooks, et ils ont l'air intéressants. Le slimbook pro 13" me fait particulièrement de l'oeil.

Quelqu'un ici serait capable d'en faire un retour ici? En particulier sur sa solidité, son évolutivité (mémoire soudée ou non et bricoles du genre), et son confort général (écran mat?, touchpad, clavier, …)

Au passage si quelqu'un sait s'il y a des revendeurs en France, je suis preneur (mais j'en doute).

Merci à celles et ceux qui répondront

J'utilise la même méthode avec un script de détection un peu plus évolué piqué ici:

https://askubuntu.com/questions/53443/how-do-i-ignore-a-proxy-if-not-available

Le problème des parcages des têtes des disques WD ne concernait qu'une sorte de disques, bien large, des green et des black. WD n'a sorti des patch que pour les blacks, mais heureusement applicables sur les green (je trouve ça discutable de ne pas fournir de patch pour tous les disques concernés).

J'ai un black, mais pas de problème avec. Je ne sais plus si j'ai du réglé un problème de parcage avec ou s'il est suffisamment récent pour ne pas avoir le problème.

Le problème des parkages des têtes des disques WD ne concernait qu'une sorte de disques, bien large, des green et des black. WD n'a sorti des patch que pour les blacks, mais heureusement applicables sur les green (je trouve ça discutable de ne pas fournir de patch pour tous les disques concernés).

Comme Nicolas R., j'ai eu des Red dont j'ai dû régler le parcage.

Le problème n'apparaissait que sous Linux, parce que Linux n'est pas tout le temps en train de toucher aux disques, comme le fait Windows.

J'ai aussi eu le pb sous FreeNAS avec des Green. Le problème du parcage des têtes est lié à une optimisation pour réduire la consommation du disque, mais elle n'a été pensée qu'en considérant le cas où l'utilisateur utilise Windows. J'ai aussi lu que c'était lié au fait que Linux (et autres Unix) vérifie régulièrement que le matériel est toujours connecté, ce qui provoque de déparcage des têtes à chaque solicitation (mais je n'ai jamais vérifié si c'était bien ça)

Pour couronner le tout, le patch n'était applicable que sous windows ou avec une clef USB spécialement préparée pour ça.

D'un autre côté tu ne bidouilles le firmware de ton disque tout les jours. Tu le fais un fois et c'est bon.
idle3-tool est un outil DOS et il fonctionne avec FreeDOS d'après mes souvenirs.
J'ai pas assez confiance en Windows ou Linux pour flasher directement depuis lui-même. Un système simple et mono-tâche me parait plus sûr pour mettre à jour un firmware de disque dur ou carte mère.

Bref, WD à fait de la merde à une époque (2012 de mémoire), et je ne sais pas ce qu'il est est actuellement. Mais, pour moi, c'est fini.

C'est vrai qu'à l'époque ils sont entêtés à ne rien changer alors que cela pouvait provoquer une usure prématurée du disque et peut-être rendre la garantie inapplicable (nombre de parcage trop important - même pas sûr qu'il aurait vraiment pu vu que c'est plus ou moins un vice de conception). Mais ils ont quand même changé leur fusil d'épaule. Peut-être la démocratisation des NAS sous base Linux et peut-être une pression de leur constructeur les a fait réfléchir.
Bouder WD pour autant, c'est pas forcément malin. Toutes les marques font de la merde à un moment ou un autre. L'exemple le plus récent est le Seagate ST3000DM001 (3To) qui n'est toujours pas fiable alors que ça fait des années qu'il est fabriqué.

Certains vont peut être me dire que les problèmes de disques que j'ai actuellement avec mes WD est causé par l'application d'un patch qui n'était pas spécialement prévu pour ce type de disques… mais WD ne fournissait pas d'autres patchs.

D'un autre côté, tu tente le diable.

Je regrette que Samsung ne fasse plus de disques durs.

Je regrette que le marché du disque dur soit consolidé, et j'attends avec impatience le moment où le cout du SSD au €/Go deviendra inférieur à celui du disque mécanique.

Depuis 1 ou 2 ans, le parcage des têtes sur les disques WD est réglé par défaut à 300s (5min) au lieu de 8s. C'est un délais suffisant pour ne plus avoir le parcage des têtes incessant sous linux. Néanmoins, c'est toujours bien de vérifier si le parcage est bien configuré.

il y a les chiffres de hardware.fr

argh, je l'avais oublié mais aussi très bonne source, +1.

C'est une très bonne source, sauf au niveau des disques durs. En effet, la méthode de comptage de hardware.fr est basée sur le nombre de retour (pour quelque raison que ce soit) auprès de leur partenaire (LDLC). Les retours des disques durs défectueux/en panne se font directement auprès des constructeurs de disques eux-même (sauf Toshiba) et ne peuvent pas être comptés dans les stats de hardware.fr

De mon point de vue, pour un particulier, tous les disques se valent niveau fiabilité jusqu'à preuve du contraire (IBM DeathStar, Seagate ST3000DM001, …) Le prix et la durée de garantie sont les première chose que je regarde. Les sauvegardes sont là pour faire face aux pannes.

Salut,

Le test long teste l'électronique du disque et fait un test de surface du disque.
C'est assez long (2h/To sur un disque récent).

Pour la commande, c'est bien à taper dans ton terminal en tant que super utilisateur (donc soit avec un sudo avant la commande, soit en passant en root):
smartctl -t long /dev/sdX
avec X à ajuster en fonction de ton disque.

Tu peux faire un test rapide (<5 min) en utilisant 'smartctl -t short /dev/sdX', mais tu n'auras pas le test de surface.

Le test est autonome et te rend la main tout de suite dans le terminal. Tu auras un message du temps estimé pour l'analyse et tu pourras consulter la progression et le résultat du test en faisant un :
smartctl -a /dev/sdX

En espérant que ça te dépanne bien.