rictus a écrit 389 commentaires

J'ai le même SOC MT7986A sur mon Xiaomi AX6000 et il n'est pas ventilé.

Sur le BPI-R3 le radiateur/ventilo est une option, sans doute pour éviter du throttle en cas d'usage intensif. De base, il est vendu avec de tout petits radiateurs : https://fr.aliexpress.com/item/1005005885775108.html

Sinon, la rotation ou du non du ventilateur est pilotable via une commande :
echo > /sys/devices/platform/pwm-fan/hwmon/hwmon1/pwm1

On peut souligner que globalement, ce sont les routeurs à base de SOC Mediatek qui sont de bons candidats pour fonctionner sous OpenWRT.

Pour mon usage, je me contente d'un Xiaomi AX6000 passé sous OpenWRT deux fois moins cher :
https://openwrt.org/toh/xiaomi/redmi_ax6000

Certes, il faut au départ mettre un tout petit peu les mains dans le camboui (vive les failles logicielles du firmware d'origine).
En étant un peu expérimenté (à l'aise en anglais pour consulter les documentations et les forums), il n'y a pas de briquage irréversible: Voir la section "Debriking" sur le lien OpenWRT.

Notamment, on touche rarement au bootloader et celui-ci tente au boot sur le LAN une requête DHCP pour télécharger en TFTP un firmware de récupération (s'il a un réponse bien sûr).

Et si vraiment on a tué le bootloader, avec un fer à souder on connecte 3 fils au port série (3 pads faciles à souder) et les SOC Mediatek Filologic permettent également de charger un firmware de debug via ce port série.

Si rien précédemment n'a fonctionné, il est possible d'avoir accès au port JTAG pour reprogrammer directement la mémoire flash…

(je n'ai pas eu à le faire, globalement ça ne ne se brique pas comme ça, on touche rarement au bootloader).

Du coup, pour moi, l'OpenWRT One s'adresse plutôt aux grands débutants, peu à l'aise avec l'anglais (pour les docs, les forums) ou la ligne de commande et linux…
Si ce n'est pas votre cas, je vous encourage plutôt à regarder un autre routeur à base de SOC Mediatek, qui sera moins cher et/ou plus performant (voir le Bananapi R3 que j'ai cité dans un commentaire plus haut).

Le Banana PI-R3 est quasi au même prix que le Banana PI OpenWrt One, tout en offrant des specs bien plus intéressantes :
https://fr.aliexpress.com/item/1005005827004033.html
- 2 Go de RAM vs 1 Go
- 8 Go de flash intégrée vs 256 Mo
- 1 slot M.2 pour un SSD
- 2 ports SFP 2,5 Ghz
- 1 switch 4 ports 1 Ghz intégré
- Wifi6 4x4 Mimo intégré

Il est parfaitement supporté par OpenWRT : https://openwrt.org/toh/sinovoip/bananapi_bpi-r3
En pratique, il est aussi imbriquable vue l'accès à l'interface JTAG via des pins du connecteurs GPIO, même si un poil moins simple qu'un switch comme sur le One.

Bref le seul intérêt pour moi du Banana PI OpenWrt One, c'est que le projet a négocié une petite commission sur chaque vente. Mais si l'on veut contribuer financièrement, autant faire un don directement.

Sinon, pour les achats sur Aliexpress, j'en fait régulièrement, et cela se passe très bien dans 99% des cas…

Au passage, merci encore à HP d'avoir autorisé, il y a déjà pas mal d'années, la diffusion des firmwares des HP4x. Ca simplifie la préservation d'un certain "patrimoine".

Je connaissais pas SwissMicros, mais cela me semble être (en tout cas visuellement) des clones des calculatrices HP des années 90.
Ça a l'air d'être tout de même très confidentiel et pas facile à trouver un revendeur…

La commande shred fait partie de coreutils et se trouve disponible sur tout live cd (ex: system rescue). Tu n'as qu'a faire shred -v /dev/sdX, ça fonctionne…

J'évite ce genre de commande sur un SSD où il est préférable de faire un blkdiscard -f /dev/sdX et de faire confiance à son contrôleur pour gérer ses badblocks.

Liquid Prompt a longtemps eu ma préférence, déjà par son ancienneté et ensuite car du écrit en pure shell (bash ?).

Puis j'ai découvert byobu (https://www.byobu.org/), qui est un peu plus qu'un prompt, mais en reprend quand même selon moi des fonctionnalités.
C'est un frontend à tmux, et ça gère une barre d'état assez sympathique à votre terminal… et bien sûr des terminaux virtuels tmux.

Curieux donc de ne pas être passé à 2.2.1 d'autant que c'est une révision mineure ?

ah ! ah !
Pas du tout d'accord : tu pars trop du postulat que tous les votants soient techniquement pertinents. Et je dirais même que les votants ayant un avis éclairé seraient même minoritaires.
La démocratie a aussi ses limites.

Je pense que dans tous les cas, la contextualisation de la faille est nécessaire, notamment par rapport aux fonctionnalités utilisées ou non d'un équipement.

Je vois dans mon entreprise, on s'alarme rapidement dès qu'il y a une CVE et avec un CVSS un peu élevé qui concerne un équipement réseau. Or celui-ci a généralement beaucoup de fonctionnalités, et la CVE ne concerne qu'une seule d'entre elles qu'on sait ne pas utiliser et donc avoir désactivé. Donc pas d'urgence à patcher et c'est des fois compliquer à faire comprendre !

Bref CVE/CVSS a l'avantage d'alerter, mais je pense qu'on ne coupe pas à devoir être un peu technique et à faire une analyse d'impact (ou non impact) de la faille dans son environnement.

A une époque où j'avais un ampli sans entrée hdmi, et où je souhaitais avec du son 5.1 pour des films lus avec xmbc (kodi) bien sûr ayant une piste ac3 ou dts, j'utilisais une carte son usb à pas cher (moins de 30€) avec sortie spdif et alsa en passthrough : c'était très satisfaisant pour les sources avec une piste ac3 ou dts…

Actuellement j'ai un AV avec HDMI qui supporte sans problème le PCM 5.1 (et même 7.1) et tous les formats existants (dolby atmos…) mais en video pas la 4K… ce qui fait que je préfère relier mon player directement à la TV. Celle-ci est reliée à l'ampli via un retour ARC sur de l'HDMI… ce qui me fait retomber dans le travers que ce mode de retour ne supporte en 5.1 que de l'ac3 ou du DTS.
La solution la plus simple pour moi est désormais que plutôt que d'essayer de faire de décodage / réencodage à la volée des sources 5.1 qui ne sont pas en ac3 ou dts, je rajoute ou substitue rapidement une piste ac3 5.1 avec ffmpeg à mon .mkv.

Cela donne par exemple la commande suivante :
ffmpeg -nostdin -i mkv_source.mkv -strict -2 -c:v copy -c:a eac3 -b:a 640k -c:s copy -map 0 new_mkv_with_ac3.mkv


C'est un peu ironique, mais la méfiance qui visait Oracle aurait dû concerner aussi IBM.

Oracle, on est d'accord, a fait plein de coups plus ou moins pourris. Mais dans le cadre d'Oracle Linux, je trouve que depuis plus de 15 ans, ils font finalement un boulot plutôt pas mal… J'apprécie notamment leur kernels UEK, qui permet notamment :
- d'avoir un kernel plus récent que la distrib' RHEL initiale;
- un kernel signé compatible sans aucun effort avec secure boot;
- réintroduit des drivers supprimés par Red Hat en RHEL8 (je pense aux contrôleurs SAS Fusion MPT).

Même en DOCSIS 3.0, on peut atteindre techniquement 200 Mb/s, mais commercialement on se retrouve bridé à 60 Mb/s…

Je crois que les ONT sont en voie de disparition au profit d'un port SFP directement intégré dans les dernières box…

De loin proxmox ressemble à Esxi, mais pour une utilisation personnelle, je trouve proxmox très supérieure :

• Déjà c'est une base debian, et on n'est pas obligé de partir de l'iso fournie par proxmox : on peut partir d'une debian et ajouter le dépot proxmox. Ou a l'inverse on peut partir de l'iso, et ajouter n'importe quel paquet de debian via apt (autant dire qu'on a du choix et que c'est bien supporté). Aussi, la machine n'est donc pas obligatoirement dédiée à faire de la virtualisation : on peut s'en servir en même temps comme workstation, NAS (merci le support natif de ZFS par le kernel fourni par proxmox), HTPC… sans bidouille infâme que certains font avec ESXi pour faire du passthrough du hardware à une VM.

• Ensuite pour moi le gros intérêt de proxmox, c'est de ne pas se limiter à de la full virtualisation, mais surtout du conteneur (openVZ autrefois, LXC maintenant) : c'est beaucoup plus léger et ça tourne bien sur une petite machine (par exemple les fameux HP microserveur, donc aussi très bien en NAS et HTPC en rajoutant une carte video…)

gvim … + un gestionnaire de fenêtres bien configuré, etc…
Je ne suis non plus, pas prêt à changer.

Mais comme suggéré déjà dans un commentaire plus haut : c'est bien d'avoir l'embarras du choix, non ?
Alors à tester… quand ça sera packagé dans un dépôt de ma distrib' préférée ;-)

Il me semble que proxmox fait pareil : le module zfs.ko est distribué en binaire avec leur noyau pve-kernel. Le modinfo indique "author: OpenZFS on Linux" "License: CDDL"

[réaction primaire et troll inside]
Cette histoire de licence plus le mélange du fs avec des fonctions que je suis habitué à avoir par LVM et mdadm, ou le fait que zfs soit gourmand en ressources, le fait que certaines de ses fonctionnalités sont certes très intéressantes, mais que pour des usages spécifiques (qui a vraiment besoin de dédup' chez soi, vous hébergez des dizaines de VM ou des tonnes de choses redondantes ?…). Bref tout cela fait que je ne suis pas fan de ZFS.
[/réaction primaire et troll inside]

J'exprime juste mon avis par rapport à mes besoins et mes usages : je ne prétends pas avoir la vérité absolue et les défenseurs de ZFS ont surement de très bonnes raisons… pour eux ! ;-)

J'ai commencé également en 1994, mais cette réponse n'est pas possible dans le sondage : c'est soit AVANT 1994, soit à partir de 1995…

TP-Link WDR 3600 (cpu Atheros MIPS à 560 Mhz et 128 Mo RAM) ou TP-Link WR1043ND V2 (cpu Atheros à 720 Mhz et 64 Mo RAM).
Ok, pour les deux, il y a moins de RAM que ce que tu voudrais, mais pour le reste, ils sont au top pour openwrt : openwrt s'installe via l'interface web du firmware d'origine comme si tu faisais une upgrade de ce dernier. WIFI(s), USB, Gigabits sont bien supportés.
Et tu peux les trouver à environ 50€.

Après je ne sais pas si c'est beaucoup plus puissant que ta FON (Un Atheros autour de 400 Mhz et 64 Mo de RAM ?).

Personnellement, j'ai été TRES déçu par la GURU PLUG à base d'un Marvell Kirkwood 1,2 Ghz…
Alors que sur le papier ça semblait super (512 Mo RAM, 2 interfaces Gigabits), le produit était assez cher (> 120 €). Il s'est révélé tout simplement pas utilisable (instabilité à cause de surchauffe, même au repos), et en pratique peu performant. De plus bien sûr, pas de possibilité d'installer une distribution linux classique et sa version de debian modifiée n'a jamais eu de suivi…
Pour une micro-machine, je préfère de loin l'expérience du raspberry pi… et malgré les griefs souvent justifiés qui lui sont faits en terme cpu et IO, une sheevaplug ne fait pas mieux… Le rpi a l'avantage d'usage (on copie l'OS sur la SD via un simple dd), peu cher, bénéficie d'une grosse communauté et sa distribution linux raspbian est bien maintenue…

Précise de quelle(s) accélération(s) matérielle(s) tu parles.

J'ai un TP-link WDR4300 qui ne coûte qu'une 60taine d'€ pour du Gigabit Ethernet et 2 Wifi n simultanés (2,4 et 5 Ghz), 128 Mo de RAM…
Le chipset a effectivement une accélération matériel du NAT qui n'est volontairement pas supporté car implémenté dans le firmware d'origine via un mauvais hack de la pile réseau plus, je crois, un blob binaire. De plus il ne permet pas l'utilisation des vlan.
Le nat géré par le cpu via le kernel (comme sur un linux standard…) offre des performances moindre (ok, environ 2 fois), mais tout de même d'environ 300 Mbit/s :
Test perfs WDR4300

Les 2 wifi sont gérés par un pilote entièrement libre, stable et performant.

Ah oui, en plus pour ce routeur, le firmware du constructeur a une grosse faille de sécurité, non corrigée depuis plus d'un an…

C'est à mon sens ce qui manque un peu à la dépêche : elle est centrée exclusivement sur ZFS, laissant un peu penser qu'il a tout inventé…
La plupart des fonctionnalités de ZFS sont déjà implantées via d'autres mécanismes sous linux (mdadm, lvm …).
L'article gagnerait (et ferait moins parti pris) à comparer les solutions.

C'est un bon workaround effectivement.

Merci !

J'ai lu rapidement la doc, mais sur ma centOS 6.5 en bash version 4.1.2, une fois que j'ai sourcé liquidprompt, mon prompt ressemble à ça (avec les guillemets "" pas beaux au début) :
""[rictus:~] $

c'est quoi que j'ai manqué ? :(

la commande aptitude est un bon frontal à apt-get et apt-cache :
aptitude update (~ yum check-update)
aptitude upgrade (~ yum upgrade)
aptitude install (etc…)
aptitude search…
aptitude était d'ailleurs préconisée au moins à partir de debian squeeze…