niclone a écrit 349 commentaires

Si par "pas de binaires obscurs à utiliser", tu compte le firmware qui doit être upload sur la carte, alors tu peux oublier la plupart des cartes (sinon toute).

Pour intel par exemple, une petite liste ici : https://www.intel.com/content/www/us/en/support/articles/000005511/wireless.html

C'est le firmware utilisé par la carte, son code n'est pas supposé s’exécuter sur ton CPU, mais sur la carte wifi directement.

Bonjour,

Cela dépend de quel plateforme…

Si c'est un chipset intel entre 6eme et 8eme génération, c'est probablement lié a cette version d'ubuntu, il semble que pas mal de monde soit concerné. Il n'y a pas vraiment eu de résolution de ce bug depuis sa sortie, sauf peut être très récemment :

Voici un des ticket de suivi :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2062951

En gros, ce serait corrigé depuis peu dans la version 6.11 du noyau linux.

Le plus simple est encore d'attendre quelques jours :

• la version 24.10 d'ubuntu est en train de sortir
• la version 24.04.2 LTS va aussi inclure ce noyeau.

il suffira donc juste de mettre à jour vers une de ces deux version

Je vais pas revenir sur le fait d'utiliser le fer à souder sur ce type de batterie (abîme la batterie, voir pire…).

Une autre chose à vérifier aussi : l'électronique fait parfois le choix de se bloquer volontairement (en cas de trop grand déséquilibre des cellules par exemple), et dans ce cas, il est impossible de reset le circuit propriétaire… il faut alors le changer aussi. (j'ai eu le cas sur un dyson v8)

Le mélange de vieilles cellules avec des nouvelles est aussi à proscrire, particulièrement ici, ou les courants sont aux limites de ce qu'elles peuvent produire.

Ici l'auteur semble utiliser le SSD en disque root, monté en r/w.
Il est tout a fait probable que le SSD soit sollicité en écriture pendant les tests hdparm.

Sur un SSD sans DRAM, avec plus aucun bloc libre (dont le SSD à connaissance via trim), pour écrire le moindre octet sur le SSD, il doit d'abord aller lire un bloc entier, l'effacer, modifier le bloc avec l'octet en question, et ré-écrire tout le bloc.

Cela amène à un comportement exactement comme décrit (gros lags, etc.), qui arrivent à un moment ou le SSD à été suffisamment utilisé pour que plus aucun bloc ne soit libre du fait de l'absence de trim fonctionnel.

C'est un mauvais SSD on est bien d'accord. Mais je vérifirai quand même que le trim est bien fonctionnel :

Vérifier que le ssd est soit :

• monté avec "discard" comme option de montage :

mount | grep discard

• soit que fstrim.timer est bien activé :

systemctl status fstrim.timer

Tenter un

fstrim -av

Pour voir

Peut être essaye un

fstrim /point/de/montage


Ces chiffres me semblent vraiment anormaux, même pour un BX500.
Le manque de DRAM et/ou le QLC ne peuvent pas suffir à expliquer une aussi basse performance en lecture.
Je dirais plutot soit le SSD à un problème, soit c'est un fake chinois, soit un problème software/bios…

ATMEGA328-PU (2 ou 3€), ou plus petit, mais ils coûteront pas forcément moins cher.

Certains thinkcentre tiny sont en intel vpro
Si c'est le cas de celui-la, il y a peut être un truc à faire avec ça (accès distant au boot/bios, kvm, …)

Sinon, faire F12, et coller ça dans le debugger js :

    /* We define our function 🕹 */
    function replaceVerticalScrollByHorizontal(event) {
        if (event.deltaY != 0) {
        // manually scroll horizonally instead
        window.scroll(window.scrollX + event.deltaY, window.scrollY);

        // prevent vertical scroll
        event.preventDefault();
      }
      return;
    }

    /* Listener on window once we start scrolling, we run our function 💨 */
    window.addEventListener('wheel', replaceVerticalScrollByHorizontal);

Oui on est bien d'accord, les pi(s) ont leur utilité. Bien que je trouve que le pi4 perd de son charme avec son prix bien trop élevé a mon goût.

Mon propo était bien de dire que si l'on doit l'acheter, et dans le contexte de mini serveur pur (sans besoin particulier d'I/Os, etc.), il me semble beaucoup plus pertinent de recycler un vieux laptop dont la conso est généralement comparable, avec en prime une batterie qui peut permettre de se passer d'un onduleur (si on a pas de disque 3.5 externe par exemple…)

Moi aussi j'ai eu le même genre de problématique, j'ai aussi trouvé un thinkcentre (celui-la : https://www.afbshop.at/pcs/30061/lenovo-thinkcentre-m93p-usff-core-i5-4570t-at-2-9-ghz-8gb-ram-500gb-hdd-win10home ) il y en a d'autres pour ceux que ça peut intéresser.

Autre avantage, vu que c'est du vPro, il y a possibilité d'avoir le contrôle à distance (reboot, console série, etc.)

Le pi4 est pour moi devenu beaucoup trop cher, et puis tant qu'a faire, si on peut recycler du vieux matériel plutôt que d'en construire encore, c'est aussi une bonne chose.

Une autre solution aussi est de recycler un vieux laptop, on trouve plein de thinkpad qui sont de bonne qualité pour une centaine d'euros. Il faut juste s'assurer d'avoir de l'ethernet gigabit, de l'USB 3.0 mini pour éventuellement y brancher des disques 3.5 externe.

Enfin, avec la gestion de l'énergie de ces bettes la, il est possible de très peu consommer au final.

+1, merci !

On peut aussi ajouter :

browser.fixup.fallback-to-https -> false


pour pas aller vers "https://" quand on lui a clairement dit "http://"
(pour utilisateurs avertis)

Il existait pas mal de carte à base de BTTV (BTTV 848 ou 878), certaines sont listées ici :

https://www.linuxtv.org/wiki/index.php/Bttv_devices_(bt848,_bt878)

Ici, une solution pour virer macrovision semble exister pour ce driver :

http://www.ksep.org/colby/bttv.html

Il faudra un port PCI…

J'ai pas mal galéré il y a dix ou quinze ans avec eux, avec des mails provenant d'un nom de domaine m'appartenant qui ne leur plaisait semble-t-il pas. Les mails étaient accepté par leur SMTP, mais les utilisateurs ne les recevaient pas, même pas en SPAM (de souvenir). Je leur avais bien sur écris un paquet de fois, sans jamais de réponse.

J'avais fini par remarquer qu'en fait, ce n'était même pas le nom de domaine qui était blacklisté, mais le mot "blabla" (contenu dans mon nom de domaine), et ce, quelque soit l'entête (from, subject, etc.). Autant dire que ça filtrait pas mal, et ce pendant des années. Sur cette découverte, je leur avait donc écris à nouveau, curieusement, le filtre à été retiré juste après, mais on ne m'a quand même jamais répondu.

xkcd

Peut être en le lançant avec ulimit, genre :

ulimit -d 2000000 && firefox

ou avec -v (virtual memory size), voir les deux…

Je plussoie, à lui aussi de présenter son statut officiel, n°SIRET, etc., et en tant que particulier, ça part mal.

Tu peux maintenant lui envoyer l'identité de Pierre Tramo ou Charles Bronson, afin de connaître la suite de l'arnaque, ça devrait pas tarder ;)

Excellente comparaison, merci ;)
Par contre, tu oublies aussi l'accès en RAM (DDR4 ..) non ?

Edit: Ah pardon, c'est les banques mémoires du bureau de juste à coté ! lu trop vite, désolé ;)

Au pire, n'importe quel AP wifi / "dongle wifi ethernet" / pi / … configuré en client fera l'affaire, branché sur le rj45 du serveur.
Le wake-on-lan n'est ensuite qu'un paquet ethernet envoyé a l'adresse MAC de la carte réseau du serveur.

J'ai pas de solution toute faite, mais un intermédiaire peut être, ce que propose la marque "sonoff". De base, ca tourne avec appli android, leur serveurs, etc. Mais leur produits sont basé sur des microcontrolleurs espressif esp8266, qui sont assez connu et facilement reprogrammable.

Un projet existe qui permet de faire un peu tout sans trop se casser la tête :

https://github.com/arendst/Sonoff-Tasmota

Très utile avec colorpaint ;)
Thomson TO7, 1982-1984

Salut,

Fouille du coté de "delogo" qui permet de faire disparaitre par exemple le logo d'une chaine TV, ca marche assez bien.
Il y a ca pour ffmpeg, avidemux, etc.

Juste une idée comme ca, vu que l'onduleur peut être réglé sur une tension entre 220 et 240V, celui-ci est bien réglé sur 230V ?
Peut être il compense alors qu'il ne devrait pas ? T'a essayé de mesurer la tension en sortie de l'onduleur ? a comparer avec celle en entrée…

Le disque dur ne ré-alloue pas un secteur qu'il n'arrive pas a lire. Ça te laisse une (petite) chance de récupérer tes données en insistant.
Il serait aussi bon de préciser que "hdparm --write-sector" va écrire des 0 a la place du secteur défectueux. Donc adieu les données qui sont dessus !.
Au final, si le disque doit être reformaté, plutôt que d'essayer de lire tout le disque pour ensuite ré-écrire chaque secteur défectueux, autant écrire sur l'intégralité du disque, (a coupler éventuellement avec "smartctl -t long" avant et après pour vérification)