Raoul Hecky a écrit 46 commentaires

Perso j'utilise Gittea

C'est un mini Github/Gitlab like. C'est léger, écrit en Go et ca tourne sur tous les OS.
Il faut pas grand chose pour le faire tourner et ca donne tout ce qu'il faut dont des issues, wiki et meme de la CI.

Bref, c'est bien plus simple à gérer qu'un truc à la main je trouve.

Auto hébergé depuis plusieurs années, je suis passé par les phases de gestion manuelle de postfix+antispam+config a la main sur un Proxmox Mail Gateway en frontal (c'est un relais) pour l'envoi et la réception des mails. J'ai mis le Proxmox Mail Gateway sur un petit VPS en ligne et mon serveur de mail chez moi. Depuis que j'ai fait ca, j'ai grandement amélioré la maintenance a faire sur la partie mail. Je peux que conseiller cette solution pour les auto-hébergeurs, c'est un gain de temps indéniable.

Le monde ARM est bien différent de ce qu'on a sur x86. Un SoC ARM c'est pas juste un CPU, mais c'est un SoC (System On Chip) qui embarque pleins de choses (coprocesseurs en tout genre, puce graphique, RAM, etc…).
L'architecture ARM est standardisé et supporté par les compilateurs, mais le support de tout le reste, c'est bien spécifique.

Quand on regarde la presentation d'Apple sur le M1 avec tout ce que ca contient, controlleur ssd, controlleur thunderbolt, encodage/decodage video, etc.., on peut vite comprendre que c'est un énorme boulot de faire marcher un kernel linux la dessus. Ce ne sont pas de simple puces externes avec des specs qu'on peut trouver, voir meme reutiliser des drivers existants car similaire.

Sans parler de la partie pour booter. Sur x86 on a du BIOS ou de l'UEFI, c'est standard, on a rien d'autre. Dans le monde des SoC, c'est open bar, chacun fait ce qu'il veut. Par exemple le bootloader uboot supporte un paquet de systeme, mais il a été porté pour ajouter le support de chaque plateformes/cartes.
Sur l'Apple M1, ils utilisent leur truc proprio de secure boot. J'imagine bien que c'est verouillé jusqu'à la moelle connaissant Apple.

Donc, non c'est pas juste simple :)

Je compatis a la perte de donnée… C'est toujours en cas de panne qu'on se rend compte que notre systeme ultra complexe a une faille quelque part…

Sinon pour ma part je suis entrain de basculer sur Proxmox Backup Server. C'est top ;)

Ca existe deja:

https://snips.ai/

En go tu as tout pour faire des web app dynamiques comme tu dis. Il y a des classes de template, middleware, etc…

Regarde ici par exemple: https://gowebexamples.com

Quel ramassis d'insultes et de betises ce post… Tout ce que je retiens c'est "les utilisateurs de vim sont des cons". Super…

Deja que ca ne vole pas très haut en voulant comparer vim et winscp (oui… winscp le soft clickodrome sous windows!), rajouter des insultes dans tout l'article sur les utilisateurs de vim… c'est du grand n'importe quoi.

Bref, je vais continuer tranquillement a utiliser mon vim qui marche tres bien et fait tres bien son job pour moi. Je risque pas d'installer windows puis winscp pour le remplacer…

T'auras une superbe interface ASCII et sans systemd! Le pied.

Moi je suis passé sur gestionnaire de mot de passe matériel. Vu que la majorité des "password keeper" soft ont déjà connus des soucis de sécu, c'était pour moi bien plus safe.

Mooltipass

• Open source
• Mots de passe stockés dans l'appareil
• Possibilité de syncro avec un autre appareil
• Extension de navigateurs Chrome, FF, Safari pour se connecter sur ses sites
• Possibilité de stocker ses clés SSH et de l'utiliser comme ssh-agent
• Multi utilisateur (plusieurs DB sur un meme appareil)

Perso j'en ai un au boutot, un a la maison, et ca fait bien le job. Dès que j'ai besoin d'un couple identifiants + mot de passe, c'est auto-généré par les outils mooltipass.
Et si l'appareil est cassé, je peux toujours en prendre un neuf et importer ma DB dessus. Les exports de DB sont tous chiffrés donc pas de soucis non plus si la DB se retrouve en libre accès.

C'est pas mal aussi dans son genre: http://netdata.firehol.org/

Exactement! avec un exemple de code dans le language Hoon c'est encore plus clair:

::    project euler 1
::    https://projecteuler.net/problem=1
::  run in dojo with +examples-euler1
::
::::  /hoon/euler1/examples/gen
  ::
:-  %say  |=  *  
:-  %noun
=<  (sum 1.000)
::
::::  ~sivtyv-barnel
  ::
|%
++  three 
  |=  a/@
  =|  b/@
  |-  ^-  @u
  ?:  (lth a b)
    0
  (add b $(b (add 3 b)))

++  five
  |=  a/@
  =|  b/@
  |-  ^-  @
  ?:  (lte a b)
    0
  ?:  =((mod b 3) 0)
    $(b (add b 5))
  (add b $(b (add b 5)))

++  sum
  |=  a/@u
  (add (five a) (three a))
--

Ca a de la gueule!

Les ESP8266 sont sympa, mais perso je trouve que d'utiliser du wifi a tout va, c'est un peu overkill juste pour piloter un relais. Surtout quand on voit la consomation d'un tel chip, faire des nodes sans fils sur piles c'est juste pas possible.

Pour etre un peu plus econome en conso, tu peux regarder du coté des NRF24L01. C'est des puces en 2.4Ghz qui se pilote assez facilement et consomme bien moins. Il y a d'ailleurs un projet open source qui les utilise pour se faire un réseau (avec des nodes relais aussi pour faire du mesh) de capteur ou actionneurs: MySensors.

D'ailleurs ils viennent d'ajouter le support des signatures des messages envoyés sur le reseau pour sécurisé les transactions. Vraiment pas mal techniquement.
D'ailleurs Calaos supporte MySensors nativement, donc c'est plutot simple a mettre en place.

Perso les ESP8266 ont leur utilisation dans des cas précis, comme par ex, tu as un node NRF24L01 qui est dans un endroit bien enfouis (derriere un mur ou autre) et tu as besoin de reflasher le firmware pour le mettre a jour. Dans ce cas de figure ajouter un ESP8266 a coté du NRF24L01 est interessant pour le reprogrammer via le wifi. Tu peux directement utiliser avrdude via un port reseau pour reprogrammer ton arduino+nrf par ex. Et le ESP8266 est alimenté que si ton node est en mode mise a jour…

MySensors
Calaos

Hubic au moins j'aurais plus confiance que mega (le truc bien louche par definition). Et sinon t'as pas essayé avec ce genre d'outils pour monter ton hubic avec fuse?

https://github.com/TurboGit/hubicfuse

Non ca c'est du Qt Quick, pas des EFL.

Pour les clés USB il suffit de régler sa config:

Je comprends pas pourquoi beaucoup de monde ralent sur le prix de cette iwatch, elle est positionné dans la même gamme de tarif que la concurrence. Pour info, une samsung gear s c'est 400€ euros aussi. Et les versions luxes de la iwatch c'est le prix du luxe (bracelet, finition). Et encore, c'est rien comme prix si on connait un peu le monde des montres de luxe ou les tarifs sont clairement bien plus luxueux que 20000$…

Ensuite c'est pénible d'avoir toujours les meme journaux ou ca rale sur la derniere conf de la pomme. On est sur linuxfr, on s'en fout royalement des annonces produits d'apple. On parle pas plus que ca des autres annonces regulieres des autres marques, alors pourquoi apple? Peut etre que finalement leur marketing fait aussi aussi mouche ici…

Il te manque juste Terminology comme terminal :)

Et la je me rends compte que tu n'as pas vraiment pris le temps de tester Calaos ou de voir comment ca marche, donc pour te répondre: non c'est loin d'être raté…

On n'exporte pas le materiel directement. Alors certes ce n'est pas encore aussi souple que ce que tu demandes, mais on est pas loin. Pour reprendre l'exemple du volet, Calaos gere un type d'objet volet, configurable avec des paramètres (Volet simple, volet "intelligent" avec notion de temps, pilotage par impulsion ou maintient d'une sortie, etc…). Ca c'est completement virtuel par rapport au hw derriere. Ensuite on a nos classe en C++ qui expose les interfaces demandées par l'objet, en l'occurence pour le volet c'est comment activer/desactiver la montée ainsi que la descente du volet.

Et ce principe de fonctionnement est valable pour tous les objets, lumiere, variateur, volets, interrupteur, … On a des objets qui sont des WebIO, et ou un WebVolet prends des URL pour piloter la monter ou la descente par exemple, idem pour des GPIO sur une carte. Pour le moment si tu veux ton propre volet avec un truc qu'on fait de base il faudra le dev en C++ et juste hériter de la classe volet. Mais a terme on a prevu de pouvoir se créer se propres objets a base de script LUA ou bien de process externe. De cette maniere tu n'auras plus aucune limite, Calaos gere un volet, et toi tu définit juste comment le piloter derriere.

Je pense qu'on a bien pensé notre coeur, et en prime on a des UI, si ca te convient pas, je suis ouvert aux changements…

MySensors.ogr c'est sympa et c'est libre, mais pas sécurisé. Sinon faut attendre que le 6lowpan soit implementé dans des produits grand public…

C'est quand même vague comme question… Ca dépends de tes besoins, de tes compétences et de ton budget.
T'as pas mal de choses aussi bien en filaire qu'en sans fils, du proprio ou non, etc…

Le zwave c'est bien proprio comme protocole… Et le X10 c'est super vieux, ca marche assez mal et t'as pas de retour d'etat, du coup ca a ete pas mal délaissé depuis des années. Le zwave c'est devenu a la mode, mais ca reste quand meme bien cher et surtout c'est completement proprio.

Ouai ca on a aussi: Wiki Calaos

Pour le KNX, ca marche avec Calaos en utilisant une passerelle KNX/TP1 via un automate Wago. Pour le support directement dans calaos_server via eibd par exemple, il faudrait le faire. Mais on a pas de matos KNX sous la main, donc un contributeur sur cette partie serait le bienvenu :)

Le support de MySensors est déjà plus ou moins terminé (il fonctionne en test chez moi depuis un moment). Le dev est dans des branches séparés pour le moment, on a pas pu le pousser avant la release de la v2 car on etait en feature freeze. Donc oui ca arrive plus que bientot :)

Non, il a été recodé entierement…