Pourtant le contrat avec l’OpenSource® était assez clair ; siphonner le logiciel libre pour gagner de l’argent. Maintenant que c’est le cas les libristes semblent tomber de leur chaise.

Bonjour :)

Merci de ta lecture. <3

Oui, j’ai un peu tordu la vérité pour expliquer la recopie du state 0, quitte à un peu travestire le comportement réel.

Mais tu as raison l’utilisation du terme “desugar” est un abus de langage de ma part ^^’

Chouette article didactique qui prend l’approche d’expliquer tout ce sur quoi repose les Stream pour en expliquer le fonctionnement. Top :)

Un petit détail sur la partie où X implémente Copy pour permettre de le réutiliser et éviter le move. En fait, ce n’est pas le compilateur qui décide de faire une copie avant d’effectuer la boucle for, c’est bien la signature de into_iter qui force ce comportement:

fn into_iter(self) -> Self::IntoIter

La fonction prend self par valeur. Pour une structure implémentant Copy, une copie sera faite, sinon ce sera un move.

Du coup, l’exemple ne se “désugarise” pas en:

let x = X { state: 0 };

let x_copy1 = x; // x_copy1 = X { state: 0 } -- copie de x en x_copy1
let iterator1 = x_copy1.into_iter(); // x_copy1 est consommé par into_iter mais pas x
for i in iterator1 {
    println!("{i}")
}

let x_copy2 = x; // x_copy2 = X { state: 0 } -- copie de x en x_copy2
let iterator2 = x_copy2.into_iter(); // x_copy2 est consommé par into_iter mais pas x
for i in iterator2 {
    println!("{i}")
}

Mais plutôt en:

let x = X { state: 0 };

let iterator1 = x.into_iter(); // x est copié pour l'envoyer à into_iter qui veut consommer self
for i in iterator1 {
    println!("{i}")
}

let iterator2 = x.into_iter(); // idem
for i in iterator2 {
    println!("{i}")
}

Sinon, bon article. Merci :)

Content que ça t’ait plu :)

Merci pour l’article, j’ai trouvé ça super.

Abonnez-vous pour soutenir le travail

Je n’ai jamais essayé mais il y a PantherX. Ils ont construits un système d’exploitation basé sur Guix, dans le but de le commercialiser, pour le rendre accessible.

Pour compléter, voici une conf de woodpecker pour builder un site avec hugo et pousser le code générée sur une branche spécifique (contexte : https://www.deblan.io/post/624/gitnet-heberge-vos-pages-statiques) : https://gitnet.fr/deblan/pages-ci/src/branch/master/.woodpecker.yml

Je n’aime (vraiment) pas Github Actions donc je comprend l’envie de s’en éloigner. Par contre, une CI comme Woodpecker est simple et je pense adaptée pour faire ça. Dans ce concept de déploiement, je trouve qu’il y a plusieurs problèmes. Le premier est d’avoir des outils de build sur ton serveur. Le second est que tu ne tests pas si ton build se passe bien.

Pas de nginx dans Redhat ? Mais oui bien sûr…

Perso, dans le repo git de mon site hugo, j’ai ajouté un simple script shell dans .git/hooks/pre-push . À chaque fois que je git push, il est automatiquement executé, ça génère le site et tout le bordel et pousse les fichiers vers le serveur qui héberge.

Oui, j’aurais pu aussi faire ça. Ca m’obligerait à avoir un accès SSH à ma machine, ce qui n’est pas le cas aujourd’hui (elle est pas directement exposée sur Internet, uniquement trafic HTTP et encore, elle est derrière un reverse proxy)

Et les webhooks c’est pas une spécificité de Github donc c’est pas vraiment une dépendance

Oh, mais que l’idée est bonne !!! Tu veux bien me fournir ton script pre-push… après faut que je voye/trouve avec Gitea comment faire, mais étant donné que mon service Gitea est sur la même machine que mon service web… :p

J’ai quand même l’impression que ça aurait pu simplement se faire en utilisant un script lancé par git.

Perso, dans le repo git de mon site hugo, j’ai ajouté un simple script shell dans .git/hooks/pre-push . À chaque fois que je git push, il est automatiquement executé, ça génère le site et tout le bordel et pousse les fichiers vers le serveur qui héberge.

Du coup pas de webhook, pas de dépendance à github.

Si vous ne connaissez pas, je vous conseille de jeter un oeil à MailU. C’est une solution mail complète en docker basée sur les outils courants (dovecot, postfix, rspamd, snappymail) avec une interface web de management. un fichier environnement à compléter, et un coup de docker compose : tout est configuré. il reste juste à faire la conf “réseau”, à savoir le DKIM/SPF sur votre domaine (mailu vous dit quoi déclarer) et le tour est joué.

Je n’utilise pas cette solution personnellement, mais je la vois tourner ailleurs et c’est simple (en tout cas ça se teste dans l’heure)

Avoir un serveur de messagerie à domicile semble un challenge à relever. Est-ce qu’on peut réussir à surmonter les cas communs ? C’est surprenant. Je dispose actuellement d’une connexion fibre Orange. Sur des sites Web évoquant l’auto-hébergement, on peut lire que le port 25 de la « box » est bloqué, ce qui empêche l’échange de courriels entre serveurs. On peut aussi lire que les routeurs domestiques sont généralement limités en terme de fonctionnalités. Je pense que cela est vrai dans une certaine mesure. Orange ne supporte pas officiellement les solutions alternatives. Il est par exemple formellement interdit de modifier le micrologiciel de leur « box » ou de réaliser une quelconque manipulation parce que l’opérateur est tenu responsable de la sécurité de son réseau. Il paraît que le blocage du port 25, sur le « réseau » Orange, puisse se désactiver en IPv6 ou en ayant son propre routeur. On peut trouver des informations sur le Web, pour les téméraires, afin de remplacer la « box » de son opérateur. Cela introduit des limitations (voir la téléphonie ou la télévision) et permet éventuellement d’en surmonter certaines. Donc, en étant un fou furieux de la technique, est-ce qu’on se retrouve dans la situation dépeinte par l’auteur de l’article, à savoir, « ne pas faire parce que c’est trop difficile » ?

Mon précédent message n’est pas aussi clair que je l’aurais souhaité. Ce que je trouve regrettable ce n’est pas l’article en soi. C’est le fait que l’auto-hébergement a une dimension globale qui s’adresse en fait, principalement aux personnes ayant un certain niveau de connaissance en réseautique, comme l’a averti explicitement l’auteur.

Tant que ce n’est pas hasardeux cela peut en valoir la peine. Or, il faut tout prendre en compte si possible. Le niveau des gens augmentent avec le temps et les interconnexions. Les choses peuvent dérailler. À l’origine, il paraît que le premier virus informatique était une sorte de jeu. Clairement, l’équilibre initial peut être rompu à cause de la malveillance. Je me demande comment un particulier peut faire face aux scénarios catastrophes lorsqu’on a pas suffisamment de recul sur ce qu’il faut faire. C’est alarmiste mais néanmoins possible, en considérant que certains sont dénués d’états d’âme. Je m’interroge sur les dégâts que cela peut causer. En pensant au malheur et à la violence qui en découle, et à notre époque contemporaine, où un certain nombre de choses se transposent désormais sous forme automatique (avec désincarnation ou pas).

A-t-on besoin de garantie pour absolument tout ? Franchement non.

Faut arrêter de tout le temps vouloir des trucs infaillibles à 100%. Ça a un coût humain et environnemental vraiment mauvais. Il faut apprendre à accepter que parfois des choses ne marchent pas (tant que la sécurité des gens n’en est pas menaçée).

J’auto-héberge mes mails depuis quinze ans, j’ai dû avoir un mois de coupure en tout et pour tout, ça ne m’a pas spécialement impacté. Vouloir tout redonder dans tous les sens nécessiterait beaucoup de matos pour une plus-value vraiment négligeable.

Tout ceci est gênant, surtout en axant pas son propos. Les prérequis en réseautique sont essentiels pour réaliser la mise en œuvre de services réseaux. Pour avoir des garanties que cela fonctionne convenablement malgré ce qui pourrait survenir. L’auto-hébergement, il n’y a pas de garantie générale.

Félicitations à tous ceux qui y arrivent, parce que cela peut être problématique.

C’est vrai qu’il est de 2019. Un autre site c’est mail-tester.com, ça donne 3 tentatives pour faire un test d’envoi de mail, ça donne une note pour voir si on est bien configuré sur l’envoi