Il faudrait que je m’y penche plus attentivement. Ce que j’aime avec Gitlab et qui me manquait avec Gogs, c’est la partie CI/CD. Peut être que Gitea a ajouté des fonctionnalités sur ce point…
J’entends tout à fait ton point de vue et je le partage. C’est à mon avis le modèle qui permet à tout le monde d’être gagnant (Red Hat en est le meilleur exemple).
Je me dis simplement que pour certains softs ça n’est peut être pas possible et c’est mieux que rien. GitLab fera peut être à l’avenir des conneries, mais pour le moment c’est une très bonne alternative à GitHub, ça permet d’avoir de la concurrence et si tu veux installer la version CE sur ton serveur, tu peux.
Il faut aussi savoir où placer le curseur de l’open core. Sur certains projet, c’est à la limite de l’utilisable et tu ne peux presque rien faire sans passer à la caisse, pour d’autres les parties payantes s’adressent vraiment aux utilisateurs entreprises.
Rien à voir, qu’est-ce qui t’as fait switcher de Gitea à SourceHut ?
Je ne sais pas si c’est moi (probablement quand même) mais je trouve cette conversation SMS très orientée en faveur de l’application. Je m’attendais à quelque chose de plus équilibré mais non en fait et je trouve que certains arguments proposés en faveur de l’application sont un peu faibles :
Risque de sécurité ? pas de soucis, il y a un bug bounty.
Le Bluetooth peut ne pas fonctionner comme il faut ? “T’es une experte en Bluetooth toi maintenant ?”
Ça ne marche pas encore très bien ? Mais il y a plein de scientifique qui travaillent dessus.
Détournement d’usages de l’application ? non, c’est tiré par les cheveux (et puis c’est illégal, si je résume)…
Je suis d’accord aussi sur le fait qu’une fois sur la table, ce type d’outil sera forcement réutilisé pour tout et n’importe quoi, il suffit d’attendre…
Oui ça se discute, chacun tente de trouver un business model. C’est également le BM de Gitlab ainsi que de beaucoup d’autres projets il me semble. Il faut que chacun y trouve son compte.
Intéressant ! Je vois que Seafile propose aussi un wiki et supporte le Md, ça ne convenait pas ?
Et il existe aussi Pydio comme alternative intéressante. L’avais tu considéré ?
Et ça va encore finir en norme a la con qui seront plus un frein a la sécurité, et la pour verrouiller le marché. Un exemple ? Le medical, Tellement compliqué pour mettre a jour un produit, que finalement ils restent aux normes dans l’etat avec toutes ces failles de secu.
j’ai toujours un léger doute sur ces recettes toute faites, donc certaines semblent bien vieilles (je pense aux préconisations anssi pour le durcissement des distributions gnu/linux par exemple). Un dev C sécu pour nous dire ce que ça vaut réellement s’il a déjà pratiqué ?
Salut !
Je n’y vois pas d’intérêt sur serveur.
Cependant pour un poste de travail, qui n’a pas beaucoup de RAM, c’est quand même plus réactif que le SWAP sur fichier.
Autant sur un vieux PC, on a un vieux CPU MAIS c’est plus réactif que de swapper pour le coup.
Cas typique, une bécane avec 4Go de RAM d’il y a 5 ans, tu évites de swapper, le système continue de marcher presque normalement, là où en swappant, les perfs sont nulles :D
Avec 8Go + SSD, si tu swappes un peu, tu n’uses pas ton SSD.
Avec 16Go c’est discutable en effet.
Les utilisateurs de RAMFS/TMPFS chargés en RAM peuvent disposer d’un peu plus de “place”
Article sympa pour vulgariser le chiffrement. Seul petit point négatif AMHA : insister autant sur MD5.
Je me doute que c’est pour simplifier la rédaction, et c’est expliqué que c’est dépassé, mais quand on voit qu’il y a encore des sites qui s’en servent pour chiffrer les mots de passe, je trouve dommage de ne pas avoir au moins cité dans le paragraphe qui parle de MD5 les algorithmes qu’il faut utiliser de nos jours.
Il faudrait que je m’y penche plus attentivement. Ce que j’aime avec Gitlab et qui me manquait avec Gogs, c’est la partie CI/CD. Peut être que Gitea a ajouté des fonctionnalités sur ce point…
J’entends tout à fait ton point de vue et je le partage. C’est à mon avis le modèle qui permet à tout le monde d’être gagnant (Red Hat en est le meilleur exemple).
Je me dis simplement que pour certains softs ça n’est peut être pas possible et c’est mieux que rien. GitLab fera peut être à l’avenir des conneries, mais pour le moment c’est une très bonne alternative à GitHub, ça permet d’avoir de la concurrence et si tu veux installer la version CE sur ton serveur, tu peux.
Il faut aussi savoir où placer le curseur de l’open core. Sur certains projet, c’est à la limite de l’utilisable et tu ne peux presque rien faire sans passer à la caisse, pour d’autres les parties payantes s’adressent vraiment aux utilisateurs entreprises.
Rien à voir, qu’est-ce qui t’as fait switcher de Gitea à SourceHut ?
Je ne sais pas si c’est moi (probablement quand même) mais je trouve cette conversation SMS très orientée en faveur de l’application. Je m’attendais à quelque chose de plus équilibré mais non en fait et je trouve que certains arguments proposés en faveur de l’application sont un peu faibles :
Je suis d’accord aussi sur le fait qu’une fois sur la table, ce type d’outil sera forcement réutilisé pour tout et n’importe quoi, il suffit d’attendre…
Oui ça se discute, chacun tente de trouver un business model. C’est également le BM de Gitlab ainsi que de beaucoup d’autres projets il me semble. Il faut que chacun y trouve son compte.
Intéressant ! Je vois que Seafile propose aussi un wiki et supporte le Md, ça ne convenait pas ? Et il existe aussi Pydio comme alternative intéressante. L’avais tu considéré ?
Et ça va encore finir en norme a la con qui seront plus un frein a la sécurité, et la pour verrouiller le marché. Un exemple ? Le medical, Tellement compliqué pour mettre a jour un produit, que finalement ils restent aux normes dans l’etat avec toutes ces failles de secu.
j’ai toujours un léger doute sur ces recettes toute faites, donc certaines semblent bien vieilles (je pense aux préconisations anssi pour le durcissement des distributions gnu/linux par exemple). Un dev C sécu pour nous dire ce que ça vaut réellement s’il a déjà pratiqué ?
J’en parle dans l’article ;)
Second life ?
Ouais je pense que c’est davantage pour des vieux pc limités en RAM.
Merci, Tcho !
Salut ! Je n’y vois pas d’intérêt sur serveur. Cependant pour un poste de travail, qui n’a pas beaucoup de RAM, c’est quand même plus réactif que le SWAP sur fichier. Autant sur un vieux PC, on a un vieux CPU MAIS c’est plus réactif que de swapper pour le coup. Cas typique, une bécane avec 4Go de RAM d’il y a 5 ans, tu évites de swapper, le système continue de marcher presque normalement, là où en swappant, les perfs sont nulles :D Avec 8Go + SSD, si tu swappes un peu, tu n’uses pas ton SSD. Avec 16Go c’est discutable en effet. Les utilisateurs de RAMFS/TMPFS chargés en RAM peuvent disposer d’un peu plus de “place”
Salute,
Quels sont les cas d’utilisation ? Je veux dire quelqu’un l’utilise et dans quel cas ?
Tcho !
Tout est juste dans l’article, sauf la dernière phrase.
Dommage, encore une fois, le grand absent - ou petit, c’est selon - est bien OpenBSD, voire les deux autres que sont NetBSD et Dragonfly BSD.
Hey JeanMarcS, Merci de ce retour, je m’en vais de ce pas rajouter quelques précisions.
Heuuu c’est quasiment du 2K… à pas grand chose près.
Article sympa pour vulgariser le chiffrement. Seul petit point négatif AMHA : insister autant sur MD5.
Je me doute que c’est pour simplifier la rédaction, et c’est expliqué que c’est dépassé, mais quand on voit qu’il y a encore des sites qui s’en servent pour chiffrer les mots de passe, je trouve dommage de ne pas avoir au moins cité dans le paragraphe qui parle de MD5 les algorithmes qu’il faut utiliser de nos jours.
Article intéressant à lire ; je dirais même mieux plaisant à lire. Une petite revue…
Quelques typos à corriger :
Ah les rpm de Rémi, que de souvenir :)
Désolé, mais je n’ai pas pu m’en empêcher: https://michael.parienti.net/posts/2020/05/22/monitorer-des-certificats-avec-bash/