Problème de nombre de paquets par seconde pouvant être traité sinon. Les CPU ne sont pas fait pour traiter un grand nombre de paquets d'un coup. C'est pour ca que les switchs ne font pas le routage avec du CPU, mais avec des asic, qui permettent de tenir le débit max en simultané sur tout les ports.
Avec des jarretière faut y aller doucement quand on les tire, y a pas de kevelar (pour pouvoir tirer sur le cable sans casser la fibre) ni de vraie gaine de protection.
T'as aussi des connecteurs qui peuvent être installés au bout des fibres sans soudures, mais la qualité de ce montage peut être aléatoire.
Si une fibre casse, c'est impossible à réparer sans soudeuse, ou alors avec un fiberlock qui va mettre une énorme atténuation sur la ligne.
Puis entre des transreceivers SR et LR, les fibres monomodes et multimodes, monobrin et bibrins et les connecteurs SC, LC FC et ST, c'est un peu moins accessible qu'un bête cable ethernet Cat6.
Plutôt un routeur maison, non ? Il manque la stack d'asic pour faire le switching à faible latence et à faible conso électrique. J'ai d'ailleurs un très gros doute que le CPU puisse tenir la charge pour router du 2.5Gbps en continue, est-ce que tu l'as testé ?
Déjà qu'un PCEngine APU2 ne tient pas la charge pour router du 1Gbps entre seulement 2 ports 2 ports avec autre chose que du Linux.
En switch low cost pour faire du 10Gbps, il y a les Force 10 S55 (L3, 48 ports 1G + possibilité d'ajouter 4 ports 10G, 2Tb de capacité de switching). J'ai pas trouvé de meilleur rapport "quantité"/prix sur ebay, mais c'est forcément un peu plus bruyant qu'un odroid et un peu différent à prendre en main qu'une webui ou qu'un linux.
Sinon il y a aussi Microtiks et Netgear qui ont des switchs manageables pas chers pour faire du 10G, mais ca vaut ce que ca vaut quoi.
C'est surement le genre de commentaire le moins constructif possible à faire lorsqu'on fait de la pub d'un produit ou d'une plateforme. Parce que oui, ce journal est une pub de Mastodon (aucun reproche, c'est le thème du site), et envoyer promener les gens en éludant une critique pertinente, bah c'est leur expliquer que tu viens de leur faire perdre leur temps à lire ta pub. Et c'est comme ca que 10 ans plus tard ca devient une plateforme morte, comme le souligne Zenitram.
Après, rien de nouveau, j'ai pas souvent vu de communauté du LL avoir le sens du marketing pour essayer de faire exister sa plateforme auprès du grand public.
A la place, tu aurais pu par exemple parler du problème d'origine, le partage de loli, ce qui est illégal par ici mais pas forcément partout dans le monde. Et effectivement pour ca, la blocklist partagé n'est pas le plus mauvais moyen d'en empêcher son accès via son instance perso.
Mais ca pose également le problème inverse que toute minorité ne plaisant pas à l'admin de ton instance Mastodon peut disparaitre pour toi, selon son humeur. Au final c'est ni pire ni mieux, c'est juste différent et plus complexe à comprendre pour les gens pas trop intéressés par ces sujets, qui risquent d'appliquer ton conseil à la lettre et rester sur Twitter.
Cette discussion comme celle de l'autre journal est assez instructive, mais je me permets un petit ajustement :
Les banques ne sont pas connes, elles savent que portage salarial = indé en terme de risque, pas CDI, tu auras (si elle accepte de prêter) la grille tarifaire des indés. Donc pas d'argent du beurre avec le portage salarial.
En freelance, faut un ou deux résultats annuels avant de faire un crédit immobilier (voir 3, ca dépend des banques) ; en portage 3 mois suffisent et ils font la moyenne dessus. Quand au tarif, ca dépend totalement des banques : pour la mienne, un portage est assimilé à un CDI.
Les banques sont pas connes, c'est pas parce que t'as un CDI que tu vas pas te faire virer, surtout en ce moment (boite qui coule, vague de licenciement, un RH mal luné qui fait un licenciement abusif (certaines société ont carrément des seuils de budgets ou des quotas internes de procédures aux prud-hommes), une rupture conventionnelle ou de période d'essai, etc). La différence c'est que déjà il n'y a pas de date de fin de l'activité en court (contrairement à un CDD), et qu'il y a des indémnités chomage pour continuer à payer le crédit derrière.
D'ailleurs, de ce point de vu, le statut de porté est même plus intéressant pour les banques. Le porté ne peut pas vraiment se faire virer pour faute grave et se retrouver sans chomage. Si le porté n'a pas de mission de dispo sous le coude, il peut faire une rupture conventionnelle quasi automatiquement (donc avoir le chomage derrière), et en plus il récupère sous forme de prime de départ la réserve légale correspondant à 10% de son salaire net. Pour une rupture conventionnelle en CDI, la prime associée est rarement aussi élevée.
Et concrètement, d'un point de vu risque, c'est exactement pareil. La différence c'est qu'en CDI classique tu vas aller sur les jeudis checker les offres, alors qu'en portage soit tu vas aller sur malt, soit sur les jeudis et annoncer aux RH que t'es intéressé mais en portage. Si le CV suit et le tarif est cohérent, y a de grandes chances que ca passe.
Merci pour ce service qui fonctionne sans db. Sur des petits environnements individuels ca change pas mal de chose (conso de ram de la db en moins, simplicité du backup, accès facile aux données en ligne de commande, etc).
J'aurais beaucoup aimé avoir ce service quand je découvrais l'autohébergement et que je n'avais pas beaucoup de ressources.
J'étais tombé sur un article expliquant que chez Google c'est courant de voir des projets aussitôt abandonnés une fois sorti. En gros, les équipes ont des primes pour chaque projet mis en prod. Du coup, le principe c'est de participer à un projet, et une fois sorti, de le quitter et de passer à un autre en cours de développement. Ceux qui restent ne sont du coup pas les personnes les plus compétentes du projet, qui finira très probablement abandonné.
La solution avec un rpi ne fonctionne que si tu as un USB en façade du linky ou une prise élec tout le coude.
Pour ceux qui ont aucun des deux et qui ne peuvent compter que sur la place de télémétrie, il existe des solutions en Zigbee ou alors pour récupérer les données en wifi il faudra utiliser la clef Atom de total énergie.
Le problème de base est que la prise de télémétrie ne fourni pas assez de courant pour un device qui utilise du wifi. La solution est soit de mettre un lot de condensateurs qui absorbent le pic de conso pendant l'envoie des données en wifi (mais je n'ai pas vu de montage qui permette de tenir un envoie par minute), soit d'utiliser une alim externe, soit de ne pas utiliser de wifi.
Le problème de Matrix c'est la partie serveur qui pèche un peu : matrix-synapse est un énorme consommateur de ressources. Il y a bien une palanquée de serveurs alternatifs, certains en Python (raté pour les perfs), d'autres en Rust, en passant par du Go, mais aucun n'est dispo dans les dépôts de Debian stable. Personnellement, par simplicité, en dehors de quelques rares webapps, je n'utilise pas de services qui ne soient pas disponibles dans les dépôts.
Du coup, finalement, un bon vieux Prosody n'est pas un si mauvais choix pour faire ses passerelles vers d'autres services.
En effet, dans l'absolue ca peut arriver sur n'importe quel système utilisant des dépôts. En pratique, ca n'est pas arrivés sur les dépôts de grosses distributions, par contre ca commence à devenir courant pour certains langages.
Pour avoir utilisé Claws-mail et encore utiliser Sylpheed à côté de Thunderbird (pour des usages différents), je les trouve tout les deux particulièrement pénibles pour leur absence de multi-thread. Quand on a pas mal de boites de courriels, le temps de relève est assez long. Si c'est par hasard juste au moment où on regardait ses boîtes, on a le temps d'aller se faire un thé avant de pouvoir les consulter.
Tout dépend de quoi on parle. Si tu parles du protocole, oui ca n'a aucun rapport. Mais ici, je réponds à un commentaire qui parle de son utilisation en entreprise, ce qui sous-entend qu'on parle de l'implémentation officielle (qui est systématiquement reprise lorsque wireguard est intégré dans un équipement réseau).
Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.
Bah le fait que ca ne soit pas géré dans l'implémentation en fait, soit le sujet du commentaire.
Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.
Bah du coup non, vu que de base il gère une authentification. Et les adresses IP sont bien fixées dans la configuration logicielle, il n'y a pas de possibilité de faire d'adressage dynamique. Ca a d'ailleurs été un gros sujet pour les sociétés de VPN comme Nord ou Proton, qui ont dû faire leurs propres implémentations pour compenser ca, tout en restant compatible avec l'implémentation officielle.
Encore une fois, je ne parle pas du protocole, mais de l'implémentation.
Ah, et si je ne m'abuse, une interface ethernet ou wifi ne serait pas une interface de niveau 2 ? Il ne me semble pas qu'un tun ait une adresse MAC.
Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP
Tu as manqué le point ici. Le but d'intégrer un annuaire dans un premier temps, c'est de gérer l'authentification de façon centralisée.
Ce n'est pas le rôle de WG de faire ça
C'est le rôle de l'implémentation.
D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.
OpenVPN, tout comme IPSec Ikev2, intègre l'assignation d'adresses IP fixes ou dynamiques aux clients, la gestion de l'authentification des utilisateurs depuis un annuaire centrale, et supporte plutôt pas mal la traversée de NAT multiple.
Petit point qui est passé à la trappe, Wireguard supporte mal les traversées multiples de NAT. Après plusieurs tests, quand il y en a plus qu'un, ca devient délicat.
Marrant cette levée de boucliers. Je réponds bien à un commentaire qui parle de son utilisation en entreprise, pas au journal. Donc le propos ici est bien son utilisation en entreprise (et du coup de son implémentation en fait), pas du protocole.
J'entends bien que le but de l'implémentation n'est pas d'être un VPN d'entreprise, mais elle manque d'énormément de choses pour faire autre chose que des setup des plus basiques, d'où sa qualification de jouet, notamment par rapport à un OpenVPN ou un IPSec. En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.
Ce n'est pas directement dû au langage, mais à la gestion de ces dépôts de bibliothèques. Malheureusement les procédures sont beaucoup plus laxistes que pour des dépôts de distributions.
En entreprise c'est mort à tout les niveaux pour l'utiliser :
- pas d'adressage IP dynamique, tout les clients doivent avoir un adressage statique
- pas d'intégrations d'annuaires
- pas de MFA
- pas de traversée de double-NAT
Wireguard, dans son état actuel est juste un jouet. C'est dommage parce qu'à côté il comble les faiblesses de ses 2 concurrents :
- OpenVPN fonctionne en user-space et est donc très consommateur de ressources
- IPSec Ikev2 ne génère pas d'interface réseau par défaut, le routage des flux se fait avec des règles XFRM.
Mais bon, pour la consommation de ressources d'OpenVPN, il "suffit" de fournir suffisement de ressources pour avoir suffisement de débit pour tout le monde. Pour Ikev2, un bon firewall fera un routage correct des flux si on a des besoin complexes, et avec StrongSwan sous Linux il est également possible de lier un tunnel à une interface réseau pour pouvoir faire du routage de flux classiques.
Du coup pour le moment, Wireguard n'a que peu d'intérêts.
Posté par Astaoth .
En réponse au journal Crontab.
Évalué à 3.
$ at
bash: at : commande introuvable
Du coup, ca dépend aussi des situations. Si tu es sur un OS qui n'a pas at, ou pas de dépôts accessibles, et que tu n'as pas non plus de systemd.timer, faut bien trouver un truc quand même.
Quand il fait nuit noire, pas de bruit, peu de circulation, peu de personnes dehors, sauf des personnes qui rentrent chez elles. Donc dès qu'il y a le moindre bruit curieux ça s'entend sur tout le quartier.
Et du coup quand tu entends des cris, tu vas courir dehors pour voir d'où ca vient et aider la personne ?
La sécurité publique, ce n'est pas non plus que les agressions, mais aussi voir où on met les pieds. Ca serait un peu bête de tomber et se faire une fracture crânienne à 15m de sa porte d'entrée parce qu'on a pas vu un nid de poule en marchant.
J'habite dans un quartier avec un éclairage public faible, je ne vous cache pas que s'y balader de nuit peut être assez stressant. Dans le parc juste à côté qui n'a pas d'éclairage, vaut mieux éviter de s'y balader après la tombée de la nuit pour éviter les mauvaises rencontres. Bizarrement, dans les rues bien éclairées, les mauvaises rencontres ont beaucoup moins lieu.
L'éclairage public n'est pas du tout une question de confort, mais de sécurité publique.
Alors une bonne nouvelle pour toi, il y a un petit utilitaire libre qui marche très bien et qui permet de faire du reverse tethering, c'est à dire que c'est l'ordi qui passe la connexion au spyphone par usb. Et du coup ce dernier a un fil à la patte et ne sort plus du bureau que pour sortir de la maison. :-p C'est ici : Gnirehtet.
Comme d'autres, je plussois la backlight avec une couleur chaude bien moins agressive pour les yeux.
Et les backlights bleus, on en a des caisses depuis au moins 17 ans, contre seulement 15 ans pour un unique modèle avec une backlight orange ;)
Sinon, pour les choix des couleurs et des polices de caractères, ca sera parmi une présélection de votre choix ou vraiment totalement personnalisable ? Par exemple être que je pourrai choisir une police Comic Sans MS et mettre la tête de Steeve Jobs en visuel de fond ?
Du coup, ca sera un clavier compatible avec votre futur laptop ; est-ce qu'au moment de sa sortie il sera prévu une option pour le prendre sans clavier ? Ma collection qui prend la poussière commence à devenir assez imposante ;)
Pour utiliser activement Arch et Debian, et avoir fait un passage sur Sid pendant quelques mois, voici quelques correctifs à apporter au tableau :
Stabilité
Pour comparer la stabilité entre Sid et Manjaro, un bref test de quelques semaines ne suffit pas. De mon expérience avec Arch, la stabilité est globalement correcte mais demande ponctuellement des interventions pour corriger/réparer manuellement certaines choses. Néanmoins rien du niveau du passage à systemd depuis plusieurs années.
Sous Sid, attention à la stabilité à terme, la mienne avait implosée avec le même usage que mon Arch.
Surveillance et correctifs des failles de sécurité détectées
La comparaison entre Debian et Manjaro n'a pas de sens dans ce cas, vu que les dépôts de Manjaro reprennent le contenu des dépôts de Arch. Une comparaison plus pertinente ici, serait entre Debian et Arch.
Quelle est la disponibilité des logiciels libres à partir des dépôts officiels ?
Debian : 59 551 paquets
Sid : 62 000 paquets
Manjaro/Arch : 12 660 paquets + 78 128 paquets AUR
Je pense qu'on peut dire que Manjaro contient un peu plus de choses que les logiciels les plus courants dans ses dépôts binaires.
Globalement la plupart du temps on trouvera ce q'on cherche dans les dépôts binaires. Pour le reste, il y a AUR, qui est globalement bien intégré dans la plupart des gestionnaires de paquets de Arch/Manjaro. En entrant dans des choses moins populaires sans forcément être de niche, je n'ai pas retrouvé tout ce que j'utilisais sur Sid.
D'un autre côté, dans Sid j'ai trouvé dans les dépôts des logiciels de niches et peu maintenus qu'on ne trouve que sur AUR dans le monde Arch, avec des arbres de dépendances pour le build assez improbables.
En gros, y a à boire et à manger dans les 2, aucun n'est mieux que l'autre.
Pour les dépôts tiers sous Debian, en particulier Sid, je dirais de se méfier des bibliothèques en doublons et des versions. Ca peut être une forte source d'instabilité.
Pour les téléchargements en direct de "deb", généralement à côté un tar.gz ou un tar.xz est proposé et peut être déployé sur n'importe quelle distribution GNU/Linux. Certes il ne gère pas les dépendances, mais souvent il aura un PKGBuild dispo sur AUR pour ca.
Pour le commentaire sur AUR du tableau, honnêtement, je ne suis pas tout à fait d'accord avec celui-ci et en particulier pour la fin qui laisse supposer que c'est du petit bonheur la chance.
Déjà, d'une part, j'ai remarqué que la plupart des AUR de mon système utilisent plutôt des dépôts de codes type Git/Hub/Lab que les dépôts des autres distributions. Souvent, ca revient à de l'installation de paquets sources, les temps de compilations pouvant être parfois long.
En revanche, la stabilité de ce procédé n'est pas aussi aléatoire que le commentaire pourrait le suggérer.
De quels genres sont les logiciels de mise à jour et d’installation de logiciels ?
Archlinux utilise un format spécifique embarqué dans du tar.xz (anciennement tar.gz).
Debian utilise un format spécifique embarqué dans du tar.gz (de mémoire) renommé ".deb".
Debian a 2 principaux gestionnaires de paquets : apt et aptitude (la résolution des dépendances est différente). Il existe des wrappers graphiques.
Arch un seul gestionnaire de paquets, ayant de nombreux wrapper cli et graphiques pouvant être intégrés dans les différents environnements. Par exemple, il me semble que Discover de KDE peut être utilisé.
Possibilité de mettre à jour plusieurs mois après sans que ça casse
Debian stable : dans certains cas particuliers, peut très mal se passer, mais très généralement ca passe niquel
Debian Sid : pas vraiment testé sur du long terme, mais déjà un mois entre était de trop dans mes tests
Arch : plus de 6 mois ca passe niquel (à plusieurs reprises), sauf changement spécifiques
Utilisation en serveur possible
Manjaro : ca reste du GNU/Linux, l'interface graphique peut être enlevé par la suite. Cependant quand on sait que Manjaro est une simplification de Arch pour un usage bureautique, autant utiliser directement une Arch dans ce cas, ou alors autant comparer Manjaro à Ubuntu Desktop au lieu de Debian.
Concernant l'utilisation d'une roll-release en serveur, le choix se discute. En revanche, la raison principale de ne pas utiliser une Debian Sid en production est bien la stabilité plutôt douteuse à l'usage. Globalement, le gros point négatif de Sid est la faible qualité de certains paquets. Comme c'est le début du processus de leur intégrations dans Debian, ils n'ont pas encore été testés, des surprises inattendues peuvent arriver.
Concernant celle d'une Arch pour un usage serveur, je n'ai jamais tenté, d'autres auront de meilleurs retours. Néanmoins les paquets de Arch ont également une phase de test avant d'être intégrés dans les dépôts standards, ce qui implique une meilleure stabilité que Sid.
A vu de nez, je dirais de la même façon permettant de faire des stats de personnes vaccinées ou non, infectés par la covid et hospitalisé.
SI DEP contient toutes les données de dépistages des personnes testées. VAC SI contient les données des personnes vaccinées. En couplant les 2 bdd, il devrait y avoir tout ce qu'il faut pour le pass vaccinal.
[^] # Re: Switch @ ~
Posté par Astaoth . En réponse au journal Un switch beaucoup trop à l'écoute .... Évalué à 5.
Problème de nombre de paquets par seconde pouvant être traité sinon. Les CPU ne sont pas fait pour traiter un grand nombre de paquets d'un coup. C'est pour ca que les switchs ne font pas le routage avec du CPU, mais avec des asic, qui permettent de tenir le débit max en simultané sur tout les ports.
Emacs le fait depuis 30 ans.
[^] # Re: Réseau domestique
Posté par Astaoth . En réponse au journal Un switch beaucoup trop à l'écoute .... Évalué à 6.
Avec des jarretière faut y aller doucement quand on les tire, y a pas de kevelar (pour pouvoir tirer sur le cable sans casser la fibre) ni de vraie gaine de protection.
T'as aussi des connecteurs qui peuvent être installés au bout des fibres sans soudures, mais la qualité de ce montage peut être aléatoire.
Si une fibre casse, c'est impossible à réparer sans soudeuse, ou alors avec un fiberlock qui va mettre une énorme atténuation sur la ligne.
Puis entre des transreceivers SR et LR, les fibres monomodes et multimodes, monobrin et bibrins et les connecteurs SC, LC FC et ST, c'est un peu moins accessible qu'un bête cable ethernet Cat6.
Emacs le fait depuis 30 ans.
[^] # Re: Switch @ ~
Posté par Astaoth . En réponse au journal Un switch beaucoup trop à l'écoute .... Évalué à 4.
Plutôt un routeur maison, non ? Il manque la stack d'asic pour faire le switching à faible latence et à faible conso électrique. J'ai d'ailleurs un très gros doute que le CPU puisse tenir la charge pour router du 2.5Gbps en continue, est-ce que tu l'as testé ?
Déjà qu'un PCEngine APU2 ne tient pas la charge pour router du 1Gbps entre seulement 2 ports 2 ports avec autre chose que du Linux.
En switch low cost pour faire du 10Gbps, il y a les Force 10 S55 (L3, 48 ports 1G + possibilité d'ajouter 4 ports 10G, 2Tb de capacité de switching). J'ai pas trouvé de meilleur rapport "quantité"/prix sur ebay, mais c'est forcément un peu plus bruyant qu'un odroid et un peu différent à prendre en main qu'une webui ou qu'un linux.
Sinon il y a aussi Microtiks et Netgear qui ont des switchs manageables pas chers pour faire du 10G, mais ca vaut ce que ca vaut quoi.
Emacs le fait depuis 30 ans.
[^] # Re: Concernant la censure
Posté par Astaoth . En réponse au journal Mastodonte contre oiseau bleu : bouquet de liens. Évalué à 3.
C'est surement le genre de commentaire le moins constructif possible à faire lorsqu'on fait de la pub d'un produit ou d'une plateforme. Parce que oui, ce journal est une pub de Mastodon (aucun reproche, c'est le thème du site), et envoyer promener les gens en éludant une critique pertinente, bah c'est leur expliquer que tu viens de leur faire perdre leur temps à lire ta pub. Et c'est comme ca que 10 ans plus tard ca devient une plateforme morte, comme le souligne Zenitram.
Après, rien de nouveau, j'ai pas souvent vu de communauté du LL avoir le sens du marketing pour essayer de faire exister sa plateforme auprès du grand public.
A la place, tu aurais pu par exemple parler du problème d'origine, le partage de loli, ce qui est illégal par ici mais pas forcément partout dans le monde. Et effectivement pour ca, la blocklist partagé n'est pas le plus mauvais moyen d'en empêcher son accès via son instance perso.
Mais ca pose également le problème inverse que toute minorité ne plaisant pas à l'admin de ton instance Mastodon peut disparaitre pour toi, selon son humeur. Au final c'est ni pire ni mieux, c'est juste différent et plus complexe à comprendre pour les gens pas trop intéressés par ces sujets, qui risquent d'appliquer ton conseil à la lettre et rester sur Twitter.
Emacs le fait depuis 30 ans.
[^] # Re: Arguments en vrac
Posté par Astaoth . En réponse au journal Pourquoi cette passion française pour les ESN?. Évalué à 5.
Cette discussion comme celle de l'autre journal est assez instructive, mais je me permets un petit ajustement :
En freelance, faut un ou deux résultats annuels avant de faire un crédit immobilier (voir 3, ca dépend des banques) ; en portage 3 mois suffisent et ils font la moyenne dessus. Quand au tarif, ca dépend totalement des banques : pour la mienne, un portage est assimilé à un CDI.
Les banques sont pas connes, c'est pas parce que t'as un CDI que tu vas pas te faire virer, surtout en ce moment (boite qui coule, vague de licenciement, un RH mal luné qui fait un licenciement abusif (certaines société ont carrément des seuils de budgets ou des quotas internes de procédures aux prud-hommes), une rupture conventionnelle ou de période d'essai, etc). La différence c'est que déjà il n'y a pas de date de fin de l'activité en court (contrairement à un CDD), et qu'il y a des indémnités chomage pour continuer à payer le crédit derrière.
D'ailleurs, de ce point de vu, le statut de porté est même plus intéressant pour les banques. Le porté ne peut pas vraiment se faire virer pour faute grave et se retrouver sans chomage. Si le porté n'a pas de mission de dispo sous le coude, il peut faire une rupture conventionnelle quasi automatiquement (donc avoir le chomage derrière), et en plus il récupère sous forme de prime de départ la réserve légale correspondant à 10% de son salaire net. Pour une rupture conventionnelle en CDI, la prime associée est rarement aussi élevée.
Et concrètement, d'un point de vu risque, c'est exactement pareil. La différence c'est qu'en CDI classique tu vas aller sur les jeudis checker les offres, alors qu'en portage soit tu vas aller sur malt, soit sur les jeudis et annoncer aux RH que t'es intéressé mais en portage. Si le CV suit et le tarif est cohérent, y a de grandes chances que ca passe.
Emacs le fait depuis 30 ans.
# Sans DB
Posté par Astaoth . En réponse à la dépêche KaraDAV, un serveur WebDAV léger, compatible avec les applications ownCloud et NextCloud. Évalué à 7.
Merci pour ce service qui fonctionne sans db. Sur des petits environnements individuels ca change pas mal de chose (conso de ram de la db en moins, simplicité du backup, accès facile aux données en ligne de commande, etc).
J'aurais beaucoup aimé avoir ce service quand je découvrais l'autohébergement et que je n'avais pas beaucoup de ressources.
Emacs le fait depuis 30 ans.
[^] # Re: Combien de temps avant son abandon ?
Posté par Astaoth . En réponse au journal KataOS, un OS sécurisé basé sur SeL4 écrit en Rust ... par Google. Évalué à 4.
J'étais tombé sur un article expliquant que chez Google c'est courant de voir des projets aussitôt abandonnés une fois sorti. En gros, les équipes ont des primes pour chaque projet mis en prod. Du coup, le principe c'est de participer à un projet, et une fois sorti, de le quitter et de passer à un autre en cours de développement. Ceux qui restent ne sont du coup pas les personnes les plus compétentes du projet, qui finira très probablement abandonné.
Emacs le fait depuis 30 ans.
[^] # Re: Intéressant mais
Posté par Astaoth . En réponse à la dépêche Ecolyo pour gérer ses consommations d’eau et d’énergie. Évalué à 4.
La solution avec un rpi ne fonctionne que si tu as un USB en façade du linky ou une prise élec tout le coude.
Pour ceux qui ont aucun des deux et qui ne peuvent compter que sur la place de télémétrie, il existe des solutions en Zigbee ou alors pour récupérer les données en wifi il faudra utiliser la clef Atom de total énergie.
Le problème de base est que la prise de télémétrie ne fourni pas assez de courant pour un device qui utilise du wifi. La solution est soit de mettre un lot de condensateurs qui absorbent le pic de conso pendant l'envoie des données en wifi (mais je n'ai pas vu de montage qui permette de tenir un envoie par minute), soit d'utiliser une alim externe, soit de ne pas utiliser de wifi.
C'est un peu balot quand même.
Emacs le fait depuis 30 ans.
[^] # Re: Très cool
Posté par Astaoth . En réponse au journal La première bêta de Slidge (passerelles XMPP) est dehors !. Évalué à 8.
Le problème de Matrix c'est la partie serveur qui pèche un peu : matrix-synapse est un énorme consommateur de ressources. Il y a bien une palanquée de serveurs alternatifs, certains en Python (raté pour les perfs), d'autres en Rust, en passant par du Go, mais aucun n'est dispo dans les dépôts de Debian stable. Personnellement, par simplicité, en dehors de quelques rares webapps, je n'utilise pas de services qui ne soient pas disponibles dans les dépôts.
Du coup, finalement, un bon vieux Prosody n'est pas un si mauvais choix pour faire ses passerelles vers d'autres services.
Emacs le fait depuis 30 ans.
[^] # Re: Service de réception de SMS en ligne
Posté par Astaoth . En réponse au journal Paypal et l'authentification à deux facteurs. Évalué à 5.
Tu en connais un que tu as personnellement testé, qui fonctionne, et qui t'affiche le dit sms en moins de 5min ?
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 5.
En effet, dans l'absolue ca peut arriver sur n'importe quel système utilisant des dépôts. En pratique, ca n'est pas arrivés sur les dépôts de grosses distributions, par contre ca commence à devenir courant pour certains langages.
Emacs le fait depuis 30 ans.
[^] # Re: Sylpheed
Posté par Astaoth . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 4. Dernière modification le 26 août 2022 à 19:08.
Pour avoir utilisé Claws-mail et encore utiliser Sylpheed à côté de Thunderbird (pour des usages différents), je les trouve tout les deux particulièrement pénibles pour leur absence de multi-thread. Quand on a pas mal de boites de courriels, le temps de relève est assez long. Si c'est par hasard juste au moment où on regardait ses boîtes, on a le temps d'aller se faire un thé avant de pouvoir les consulter.
Emacs le fait depuis 30 ans.
[^] # Re: Simple comme...
Posté par Astaoth . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 2. Dernière modification le 24 août 2022 à 22:36.
Tout dépend de quoi on parle. Si tu parles du protocole, oui ca n'a aucun rapport. Mais ici, je réponds à un commentaire qui parle de son utilisation en entreprise, ce qui sous-entend qu'on parle de l'implémentation officielle (qui est systématiquement reprise lorsque wireguard est intégré dans un équipement réseau).
Bah le fait que ca ne soit pas géré dans l'implémentation en fait, soit le sujet du commentaire.
Bah du coup non, vu que de base il gère une authentification. Et les adresses IP sont bien fixées dans la configuration logicielle, il n'y a pas de possibilité de faire d'adressage dynamique. Ca a d'ailleurs été un gros sujet pour les sociétés de VPN comme Nord ou Proton, qui ont dû faire leurs propres implémentations pour compenser ca, tout en restant compatible avec l'implémentation officielle.
Encore une fois, je ne parle pas du protocole, mais de l'implémentation.
Ah, et si je ne m'abuse, une interface ethernet ou wifi ne serait pas une interface de niveau 2 ? Il ne me semble pas qu'un tun ait une adresse MAC.
Tu as manqué le point ici. Le but d'intégrer un annuaire dans un premier temps, c'est de gérer l'authentification de façon centralisée.
C'est le rôle de l'implémentation.
OpenVPN, tout comme IPSec Ikev2, intègre l'assignation d'adresses IP fixes ou dynamiques aux clients, la gestion de l'authentification des utilisateurs depuis un annuaire centrale, et supporte plutôt pas mal la traversée de NAT multiple.
Petit point qui est passé à la trappe, Wireguard supporte mal les traversées multiples de NAT. Après plusieurs tests, quand il y en a plus qu'un, ca devient délicat.
Emacs le fait depuis 30 ans.
[^] # Re: Simple comme...
Posté par Astaoth . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 3.
Marrant cette levée de boucliers. Je réponds bien à un commentaire qui parle de son utilisation en entreprise, pas au journal. Donc le propos ici est bien son utilisation en entreprise (et du coup de son implémentation en fait), pas du protocole.
J'entends bien que le but de l'implémentation n'est pas d'être un VPN d'entreprise, mais elle manque d'énormément de choses pour faire autre chose que des setup des plus basiques, d'où sa qualification de jouet, notamment par rapport à un OpenVPN ou un IPSec. En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 5.
Ce n'est pas directement dû au langage, mais à la gestion de ces dépôts de bibliothèques. Malheureusement les procédures sont beaucoup plus laxistes que pour des dépôts de distributions.
Emacs le fait depuis 30 ans.
[^] # Re: Simple comme...
Posté par Astaoth . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 6. Dernière modification le 22 août 2022 à 19:40.
En entreprise c'est mort à tout les niveaux pour l'utiliser :
- pas d'adressage IP dynamique, tout les clients doivent avoir un adressage statique
- pas d'intégrations d'annuaires
- pas de MFA
- pas de traversée de double-NAT
Wireguard, dans son état actuel est juste un jouet. C'est dommage parce qu'à côté il comble les faiblesses de ses 2 concurrents :
- OpenVPN fonctionne en user-space et est donc très consommateur de ressources
- IPSec Ikev2 ne génère pas d'interface réseau par défaut, le routage des flux se fait avec des règles XFRM.
Mais bon, pour la consommation de ressources d'OpenVPN, il "suffit" de fournir suffisement de ressources pour avoir suffisement de débit pour tout le monde. Pour Ikev2, un bon firewall fera un routage correct des flux si on a des besoin complexes, et avec StrongSwan sous Linux il est également possible de lier un tunnel à une interface réseau pour pouvoir faire du routage de flux classiques.
Du coup pour le moment, Wireguard n'a que peu d'intérêts.
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 9.
NPM pose le problème très concret de supply chain attack. Ca s'est déjà produit, et ca se reproduira.
Emacs le fait depuis 30 ans.
[^] # Re: Non
Posté par Astaoth . En réponse au journal Crontab. Évalué à 3.
Du coup, ca dépend aussi des situations. Si tu es sur un OS qui n'a pas at, ou pas de dépôts accessibles, et que tu n'as pas non plus de systemd.timer, faut bien trouver un truc quand même.
Emacs le fait depuis 30 ans.
[^] # Re: Eclairage public
Posté par Astaoth . En réponse au journal Hypocrisie d'énergie . Évalué à 7.
Et du coup quand tu entends des cris, tu vas courir dehors pour voir d'où ca vient et aider la personne ?
La sécurité publique, ce n'est pas non plus que les agressions, mais aussi voir où on met les pieds. Ca serait un peu bête de tomber et se faire une fracture crânienne à 15m de sa porte d'entrée parce qu'on a pas vu un nid de poule en marchant.
Emacs le fait depuis 30 ans.
# Eclairage public
Posté par Astaoth . En réponse au journal Hypocrisie d'énergie . Évalué à 10.
J'habite dans un quartier avec un éclairage public faible, je ne vous cache pas que s'y balader de nuit peut être assez stressant. Dans le parc juste à côté qui n'a pas d'éclairage, vaut mieux éviter de s'y balader après la tombée de la nuit pour éviter les mauvaises rencontres. Bizarrement, dans les rues bien éclairées, les mauvaises rencontres ont beaucoup moins lieu.
L'éclairage public n'est pas du tout une question de confort, mais de sécurité publique.
Emacs le fait depuis 30 ans.
[^] # Re: Gnirehtet
Posté par Astaoth . En réponse au journal BPCE et les paiements avec authentification à deux facteurs. Évalué à 2.
Ah ? Ce n'est pas Network Manager ?
Emacs le fait depuis 30 ans.
[^] # Re: Qui est wlp-acs…
Posté par Astaoth . En réponse au journal BPCE et les paiements avec authentification à deux facteurs. Évalué à 2.
Pour l'anecdote Natixis reste lié à Atos, c'est la banque qu'ils utilisent pour les épargnent salariales.
Emacs le fait depuis 30 ans.
[^] # Re: Rétroéclairage
Posté par Astaoth . En réponse à la dépêche L’ordinateur portable modulaire : La lumière au bout du tunnel. Évalué à 4.
Comme d'autres, je plussois la backlight avec une couleur chaude bien moins agressive pour les yeux.
Et les backlights bleus, on en a des caisses depuis au moins 17 ans, contre seulement 15 ans pour un unique modèle avec une backlight orange ;)
Sinon, pour les choix des couleurs et des polices de caractères, ca sera parmi une présélection de votre choix ou vraiment totalement personnalisable ? Par exemple être que je pourrai choisir une police Comic Sans MS et mettre la tête de Steeve Jobs en visuel de fond ?
Du coup, ca sera un clavier compatible avec votre futur laptop ; est-ce qu'au moment de sa sortie il sera prévu une option pour le prendre sans clavier ? Ma collection qui prend la poussière commence à devenir assez imposante ;)
Emacs le fait depuis 30 ans.
# Corrections du tableau
Posté par Astaoth . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 3.
Pour utiliser activement Arch et Debian, et avoir fait un passage sur Sid pendant quelques mois, voici quelques correctifs à apporter au tableau :
Stabilité
Pour comparer la stabilité entre Sid et Manjaro, un bref test de quelques semaines ne suffit pas. De mon expérience avec Arch, la stabilité est globalement correcte mais demande ponctuellement des interventions pour corriger/réparer manuellement certaines choses. Néanmoins rien du niveau du passage à systemd depuis plusieurs années.
Sous Sid, attention à la stabilité à terme, la mienne avait implosée avec le même usage que mon Arch.
Surveillance et correctifs des failles de sécurité détectées
La comparaison entre Debian et Manjaro n'a pas de sens dans ce cas, vu que les dépôts de Manjaro reprennent le contenu des dépôts de Arch. Une comparaison plus pertinente ici, serait entre Debian et Arch.
Quelle est la disponibilité des logiciels libres à partir des dépôts officiels ?
Debian : 59 551 paquets
Sid : 62 000 paquets
Manjaro/Arch : 12 660 paquets + 78 128 paquets AUR
Je pense qu'on peut dire que Manjaro contient un peu plus de choses que les logiciels les plus courants dans ses dépôts binaires.
Globalement la plupart du temps on trouvera ce q'on cherche dans les dépôts binaires. Pour le reste, il y a AUR, qui est globalement bien intégré dans la plupart des gestionnaires de paquets de Arch/Manjaro. En entrant dans des choses moins populaires sans forcément être de niche, je n'ai pas retrouvé tout ce que j'utilisais sur Sid.
D'un autre côté, dans Sid j'ai trouvé dans les dépôts des logiciels de niches et peu maintenus qu'on ne trouve que sur AUR dans le monde Arch, avec des arbres de dépendances pour le build assez improbables.
En gros, y a à boire et à manger dans les 2, aucun n'est mieux que l'autre.
Pour les dépôts tiers sous Debian, en particulier Sid, je dirais de se méfier des bibliothèques en doublons et des versions. Ca peut être une forte source d'instabilité.
Pour les téléchargements en direct de "deb", généralement à côté un tar.gz ou un tar.xz est proposé et peut être déployé sur n'importe quelle distribution GNU/Linux. Certes il ne gère pas les dépendances, mais souvent il aura un PKGBuild dispo sur AUR pour ca.
Pour le commentaire sur AUR du tableau, honnêtement, je ne suis pas tout à fait d'accord avec celui-ci et en particulier pour la fin qui laisse supposer que c'est du petit bonheur la chance.
Déjà, d'une part, j'ai remarqué que la plupart des AUR de mon système utilisent plutôt des dépôts de codes type Git/Hub/Lab que les dépôts des autres distributions. Souvent, ca revient à de l'installation de paquets sources, les temps de compilations pouvant être parfois long.
En revanche, la stabilité de ce procédé n'est pas aussi aléatoire que le commentaire pourrait le suggérer.
De quels genres sont les logiciels de mise à jour et d’installation de logiciels ?
Archlinux utilise un format spécifique embarqué dans du tar.xz (anciennement tar.gz).
Debian utilise un format spécifique embarqué dans du tar.gz (de mémoire) renommé ".deb".
Debian a 2 principaux gestionnaires de paquets : apt et aptitude (la résolution des dépendances est différente). Il existe des wrappers graphiques.
Arch un seul gestionnaire de paquets, ayant de nombreux wrapper cli et graphiques pouvant être intégrés dans les différents environnements. Par exemple, il me semble que Discover de KDE peut être utilisé.
Possibilité de mettre à jour plusieurs mois après sans que ça casse
Debian stable : dans certains cas particuliers, peut très mal se passer, mais très généralement ca passe niquel
Debian Sid : pas vraiment testé sur du long terme, mais déjà un mois entre était de trop dans mes tests
Arch : plus de 6 mois ca passe niquel (à plusieurs reprises), sauf changement spécifiques
Utilisation en serveur possible
Manjaro : ca reste du GNU/Linux, l'interface graphique peut être enlevé par la suite. Cependant quand on sait que Manjaro est une simplification de Arch pour un usage bureautique, autant utiliser directement une Arch dans ce cas, ou alors autant comparer Manjaro à Ubuntu Desktop au lieu de Debian.
Concernant l'utilisation d'une roll-release en serveur, le choix se discute. En revanche, la raison principale de ne pas utiliser une Debian Sid en production est bien la stabilité plutôt douteuse à l'usage. Globalement, le gros point négatif de Sid est la faible qualité de certains paquets. Comme c'est le début du processus de leur intégrations dans Debian, ils n'ont pas encore été testés, des surprises inattendues peuvent arriver.
Concernant celle d'une Arch pour un usage serveur, je n'ai jamais tenté, d'autres auront de meilleurs retours. Néanmoins les paquets de Arch ont également une phase de test avant d'être intégrés dans les dépôts standards, ce qui implique une meilleure stabilité que Sid.
Emacs le fait depuis 30 ans.
# SI-DEP + VAC SI ?
Posté par Astaoth . En réponse au journal De l'information contenue dans les passes. Évalué à 6.
A vu de nez, je dirais de la même façon permettant de faire des stats de personnes vaccinées ou non, infectés par la covid et hospitalisé.
SI DEP contient toutes les données de dépistages des personnes testées. VAC SI contient les données des personnes vaccinées. En couplant les 2 bdd, il devrait y avoir tout ce qu'il faut pour le pass vaccinal.
Emacs le fait depuis 30 ans.