Ces applis ont besoin des API de Google pour fonctionner avec LineageOS ?
Sinon, pour ce que tu as cité, il y a des applis dispo sous SailfishOS, à part pour le GPS prenant en compte le trafic routier.
En fait, ce que je veux dire par là, c'est que des fois, y a des alternatives dont on a entendu parler de nom mais qu'on connait pas, et qui peuvent convenir aux usages.
Je vais pas trop parler de LineageOS parce que finalement je le connais pas du tout. Par contre, y a une méthode de saisie de PinYin dans SailfishOS.
Un peu pareil, j'ai une voiture qui a bientôt 20 ans, et honnêtement j'en changerai que pour une autre plus ancienne. Je me passe très bien de toutes les évolutions récentes (même si je boude pas le régulateur de vitesse quand j'en ai un).
En revanche je suis beaucoup mieux installé dans les vieilles voitures que dans les récentes : sièges plus confortables, pédales plus basses, amortisseurs plus souples etc.
Entre LinegaOS et Sailfish OS, tu vois quoi comme gros sacrifices à faire pour les utiliser au quotidien ? À part Pokemon Go j'en fais pas vraiment pour ma part, mais d'un autre côté le seul Android que j'ai utilisé était le 2.2.
Ce journal me fait penser à une question d'une importance capital pour le bien de l'humanité, qui nécessite une réponse encore inconnu de tous : c'est quand les prochaines aventures de Henry ??
Rust c'est plutôt comme le Bridge, le Gin, les vacances en Bretagne ou la recherche du temps perdu, un truc pour briller en société, mais que personne n'aime vraiment.
Bah moi, j'aime bien le Gin
C'est un peu comme le whisky par rapport au cognac, le poker par rapport au tarot
Marrant, j'aime bien le tarot et le cognac, mais je déteste le whisky et le poker. J'vais ptetre me mettre au Rust finalement !
Je ne comparerais pas AUR aux PPA, c'est assez différent même.
La plupart du temps, dans AUR, les logiciels sont récupérés directement à la source (parfois faut le faire à la main). Soit c'est un logiciel proprio, donc dans ce cas c'est le logiciel pré-compilé qui est récupéré. Soit c'est un logiciel ouvert, et donc dans ce cas là c'est plutôt le code source qui est récupéré depuis la source (une version binaire pouvant être également proposé si l'éditeur en propose une).
Du coup, c'est pas vraiment un dépôts dans la même définition du PPA. Si l'éditeur d'un coup décide de rendre son logiciel inaccessible, et bien plus moyen de l'installer via AUR. La seul chose qui est présent sur le dépôt est le petit fichier de configuration expliquant comment récupérer le logiciel et comment l'installer.
Pour la partie OS j'avais bien compris l'intérêt de HaikuOS de ce point de vu là, qu'on retrouve aussi chez ReactOS. Je trouve même super de continuer à développer des OS différents, la diversité n'étant pas forcément une mauvaise chose à mon sens.
Ma question se portait vraiment sur les logiciels et l'augmentation de la base d'utilisateurs. Pour le moment, je ne pense pas que beaucoup d'utilisateurs finaux se retrouvent dans HaikuOS, même parmi les libristes (j'ai pas dit aucun non plus hein)
Par contre effectivement, je l'avais pas vu de ce point de vu là pour le développement de logiciels. C'est vrai que vu comme ça, c'est carrément intéressant et ça permet de faire finalement de petits logiciels simples, loin des gros machins qu'on trouve ailleurs. Y a même peut-être un créneau intéressant sur le segment des OS légers et efficace sur PC, avec ces superbes PC-hybrides qui galèrent avec leur petit Atome ou pour continuer à utiliser normalement un vieil ordi.
Ce n'est pas parce qu'un logiciel a commencé à être développé il y a 17 ans qu'il est obsolète. Je ne comprend pas cette manie de vouloir tout réécrire à partir de zéro tous les 5 ans.
Je n'ai pas dit qu'un logiciel commencé il y a 17 ans est obsolète, bien au contraire, le kernel Linux par exemple est même très loin d'être hors-course. Je n'ai pas parlé de jeter le vieux code et je n'ai pas non plus dit qu'un logiciel dont le dev est arrêté n'est plus capable de remplir sa tâche.
Je demandais plutôt si un logiciel dont le développement s'est terminé il y a 17 ans n'était pas quelque peu dépassé. Je pensais en terme de fonctionnalité, les besoins des utilisateurs ayant évolués, mais aussi en terme d'UI, les règles d'ergonomies ayant évoluées, en terme d'esthétique, les bibliothèques graphiques ayant également évoluées, et en terme de sécurité, les morceaux de code plus maintenus pouvant avoir d'énormes trous béants.
Comme l'a dit devnewton plus bas, en 2003 on avait plein d'environnements de bureau sympa sous Linux, mais ils ont tous décidé de tout jeter et de recommencer. C'est pas comme ça qu'on arrivera à quoi que ce soit.
Les WM managers de cette époques sont toujours là et utilisable, mon FVWM se portant très bien. Également une partie des DE a continué à évoluer au lieu de tout jeter, je pense en particulier à XFCE et E17. Mais bon, tout ceci n'a rien à voir avec ce que je disais plus haut.
Mais ça reste quand même largement moins cher de mettre à jour une application existante que de refaire tout le dev.
Je suis on ne peut plus d'accord, mais encore faut-il des gens qui le fasse, et même qui puisse le faire, ce qui n'est pas forcément le cas des anciens logiciels de BeOS, contrairement à ceux qu'on trouve dans les dépôts GNU/Linux ou *BSD par exemple.
C'est chouette d'essayer de maintenir les logiciels BeOS mais … ils ne sont pas légèrement dépassés après 17 ans ? Ca risque de ne pas trop attirer de nouveaux utilisateurs, au contraire :/
Et du coup, le but c'est d'avoir de nouveaux logiciels développés avec les API de BeOS ? Comment comptez-vous attirer de nouveaux devs sur cette plateforme ? Avec peu d'utilisateurs, ca ne pas intéresser la plupart d'entre eux.
Bonjour,
Tout d'abord, félicitation pour continuer à développer HaikuOS après tout ce temps ! Vouloir se faire une place sur le marché de l'OS de bureau est louable, cependant par le passé, on a constaté qu'une des clefs principales de la popularité d'un OS auprès des utilisateurs finaux est la quantité d'applis disponibles. Vis-à-vis de ça, comment comptez-vous obtenir une quantité respectables de logiciels modernes pour attirer les gens ? En montant une forge qui compilera les logiciels libres pour BeOS ? En faisant une couche de compatibilité avec les logiciels GNU/LInux ? Ou en espérant que des développeurs soient intéressés pour créer des logiciels pour HaikuOS ?
Ça me rappelle un projet sur lequel j'avais travaillé pour l'INRIA. Le projet portait plutôt sur le wifi, pour justement gérer de façon plus efficace les cas où on est utilisateurs par borne (typiquement dans une école, quand un prof demande d'aller chercher le pdf du tp sur son site). Le but était donc d'implémenter des solutions pour améliorer l'usage de ce wifi.
De mémoire on avait 2 algo. Un premier visait justement à privilégier les sessions transférant de petites données par rapport aux grosses. Comme ça on gagne justement un peu de latence. On a donc l'illusion d'une connexion plus rapide, même si le voisin profite du tp pour faire ses mises à jours. Et il me semble que le second algo visait à faire, en gros, une file de donnée par utilisateur pour alterner équitablement entre eux. En bref, on a travaillé sur le FQ décrit dans l'article. C'est sympa de voir qu'une solution utilisant ces algos est commercialisée, je suis curieux de savoir si ca améliore vraiment les choses !
Ce ne sont pas les seuls, j'en avais rencontrés plusieurs dans ce cas là quand je regardais les groupwares existants. Les sha sont en fait les algo que j'ai vu le plus souvent proposés par les services web à auto-héberger. Souvent il y en a d'autres de proposés, dont md5, et plus rarement d'autres choses plus sécurisé.
l'impact sur l'usage n'est pas si important puisque côté serveur tu ne le calcule pas ou une seule fois, et côté client une fois de temps en temps.
Pour le côté serveur, ca dépend du nombre de connexion à gérer en même temps. Si justement c'est un gros site avec pas mal d'auth à faire en simultané, ca doit quand même utiliser pas mal de ressources, non ?
Bah c'est sûr, si tu coupes 90% des possibilités, d'un coup le bruteforce c'est plus rapide. Dans ce cas, je peux te bruteforcer n'importe quel mdp en un temps record, à condition qu'il ne fasse qu'un seul caractère …
Et sinon, avec un mdp dont tu ne connais pas la taille, pouvant aller jusqu'à 12 (voir 36) caractères, incluant des caractères spéciaux, dont le fameux symbole '€' qui n'est quasiment jamais testé, il faut combien de temps ? Si t'as une étude dessus je suis preneur.
Et du coup, t'as des algo de hash qui sont efficaces face à un bruteforce ?
mais par contre n'a n'évite pas l'attaque brute force sur la base complète, qui à terme te permet en théorie de trouver l'intégralité des mots de passe de la base.
Est-ce que ca permet de le faire en un temps raisonnable ? Si le bruteforce trouve les mdps en 15 ans, ca me dérange pas. J'en aurai changé d'ici là.
Ah bon ? On a une attaque efficace sur tout ce qui est sha2 ? Ce n'est pas parce que sha3 est sorti qu'il existe une attaque rapide sur sha2. Même sans sel ca reste une bonne solution. Contrairement à garder des mdps en clair.
Le stockage des mdp en clair ou de façon réversible entraîne pas mal de problème parce que les gens normaux réutilisent souvent les mdps. N'importe quel argumentaire en faveur du stockage des mdps en clair ou de façon réversible n'est qu'une justification face à l'abaissement de sécurité que cela provoque et en rien une raison vis-à-vis de ce problème de sécurité.
De même, stocker en clair des mdps soit-disant parce que la sécurité de la bdd est inviolable n'est qu'un argument illusoire, valable uniquement jusqu'au jour où la bdd des mdps se fait voler.
Bref, quand on excuse "chez soit", les autres ont les mêmes type d'excuse ensuite et sont tout autant légitime.
Personnellement, sur mon serveur perso, tout mes mdps sont hashés en sha256. Et bon, se servir de la médiocrité des autres pour justifier sa propre médiocrité, c'est rentrer dans la spirale de la nullité. À un moment donné, faut bien se lancer la sécurisation de ses services sans attendre que le moindre petit site perdu du web l'ait également fait.
Franchement, les contraintes et risques liés, c'est plutôt la liberté. La liberté de configurer son installation comme on veut, de mettre les logiciels et interfaces qu'on veut etc. Faut juste avoir un second MX, au cas où on casse le premier :3
Pour la sécurité, faut bien sûr surveiller son serveur quotidiennement, mais globalement et une fois bien configuré, ça craint pas grand chose.
[^] # Re: Smartphones libres
Posté par Astaoth . En réponse au journal Vie privée et voitures connectées par Google. Évalué à 2.
Ces applis ont besoin des API de Google pour fonctionner avec LineageOS ?
Sinon, pour ce que tu as cité, il y a des applis dispo sous SailfishOS, à part pour le GPS prenant en compte le trafic routier.
Emacs le fait depuis 30 ans.
[^] # Re: Smartphones libres
Posté par Astaoth . En réponse au journal Vie privée et voitures connectées par Google. Évalué à 2. Dernière modification le 24 septembre 2018 à 18:31.
En fait, ce que je veux dire par là, c'est que des fois, y a des alternatives dont on a entendu parler de nom mais qu'on connait pas, et qui peuvent convenir aux usages.
Je vais pas trop parler de LineageOS parce que finalement je le connais pas du tout. Par contre, y a une méthode de saisie de PinYin dans SailfishOS.
Emacs le fait depuis 30 ans.
[^] # Re: Vieux con
Posté par Astaoth . En réponse au journal Vie privée et voitures connectées par Google. Évalué à 5.
Un peu pareil, j'ai une voiture qui a bientôt 20 ans, et honnêtement j'en changerai que pour une autre plus ancienne. Je me passe très bien de toutes les évolutions récentes (même si je boude pas le régulateur de vitesse quand j'en ai un).
En revanche je suis beaucoup mieux installé dans les vieilles voitures que dans les récentes : sièges plus confortables, pédales plus basses, amortisseurs plus souples etc.
Emacs le fait depuis 30 ans.
# Smartphones libres
Posté par Astaoth . En réponse au journal Vie privée et voitures connectées par Google. Évalué à 5.
Entre LinegaOS et Sailfish OS, tu vois quoi comme gros sacrifices à faire pour les utiliser au quotidien ? À part Pokemon Go j'en fais pas vraiment pour ma part, mais d'un autre côté le seul Android que j'ai utilisé était le 2.2.
Emacs le fait depuis 30 ans.
# BD-SM
Posté par Astaoth . En réponse au journal Terminologie Master/Slave . Évalué à 4.
Et dans tout ca, est-ce qu'on a toujours le droit de parler de BDSM ou c'est aussi moralement répréhensible ? :p
Emacs le fait depuis 30 ans.
# La vraie question
Posté par Astaoth . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 6.
Ce journal me fait penser à une question d'une importance capital pour le bien de l'humanité, qui nécessite une réponse encore inconnu de tous : c'est quand les prochaines aventures de Henry ??
Merci d'avance.
Emacs le fait depuis 30 ans.
[^] # Re: Il faut savoir troller bordel !
Posté par Astaoth . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 5.
Bah moi, j'aime bien le Gin
Marrant, j'aime bien le tarot et le cognac, mais je déteste le whisky et le poker. J'vais ptetre me mettre au Rust finalement !
Emacs le fait depuis 30 ans.
# AUR et PPA
Posté par Astaoth . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 5.
Je ne comparerais pas AUR aux PPA, c'est assez différent même.
La plupart du temps, dans AUR, les logiciels sont récupérés directement à la source (parfois faut le faire à la main). Soit c'est un logiciel proprio, donc dans ce cas c'est le logiciel pré-compilé qui est récupéré. Soit c'est un logiciel ouvert, et donc dans ce cas là c'est plutôt le code source qui est récupéré depuis la source (une version binaire pouvant être également proposé si l'éditeur en propose une).
Du coup, c'est pas vraiment un dépôts dans la même définition du PPA. Si l'éditeur d'un coup décide de rendre son logiciel inaccessible, et bien plus moyen de l'installer via AUR. La seul chose qui est présent sur le dépôt est le petit fichier de configuration expliquant comment récupérer le logiciel et comment l'installer.
Emacs le fait depuis 30 ans.
# Date ?
Posté par Astaoth . En réponse à la dépêche Kernel Recipes 2018 : c’est reparti pour la 7ᵉ édition !. Évalué à 2.
Quand est-ce qu'aura lieu l’événement ? Et vu que c'est Mozilla Paris qui vous accueil, j'imagine donc que ca se passe à Paris ?
Emacs le fait depuis 30 ans.
[^] # Re: Logiciels disponibles
Posté par Astaoth . En réponse à la dépêche Haiku a 17 ans. Évalué à 2.
Pour la partie OS j'avais bien compris l'intérêt de HaikuOS de ce point de vu là, qu'on retrouve aussi chez ReactOS. Je trouve même super de continuer à développer des OS différents, la diversité n'étant pas forcément une mauvaise chose à mon sens.
Ma question se portait vraiment sur les logiciels et l'augmentation de la base d'utilisateurs. Pour le moment, je ne pense pas que beaucoup d'utilisateurs finaux se retrouvent dans HaikuOS, même parmi les libristes (j'ai pas dit aucun non plus hein)
Par contre effectivement, je l'avais pas vu de ce point de vu là pour le développement de logiciels. C'est vrai que vu comme ça, c'est carrément intéressant et ça permet de faire finalement de petits logiciels simples, loin des gros machins qu'on trouve ailleurs. Y a même peut-être un créneau intéressant sur le segment des OS légers et efficace sur PC, avec ces superbes PC-hybrides qui galèrent avec leur petit Atome ou pour continuer à utiliser normalement un vieil ordi.
Emacs le fait depuis 30 ans.
[^] # Re: Retour vers le futur
Posté par Astaoth . En réponse à la dépêche Haiku a 17 ans. Évalué à -1.
J'ai du louper la fin de XFCE 4, et visiblement ma distribution aussi.
Emacs le fait depuis 30 ans.
[^] # Re: Logiciels disponibles
Posté par Astaoth . En réponse à la dépêche Haiku a 17 ans. Évalué à 4.
Je n'ai pas dit qu'un logiciel commencé il y a 17 ans est obsolète, bien au contraire, le kernel Linux par exemple est même très loin d'être hors-course. Je n'ai pas parlé de jeter le vieux code et je n'ai pas non plus dit qu'un logiciel dont le dev est arrêté n'est plus capable de remplir sa tâche.
Je demandais plutôt si un logiciel dont le développement s'est terminé il y a 17 ans n'était pas quelque peu dépassé. Je pensais en terme de fonctionnalité, les besoins des utilisateurs ayant évolués, mais aussi en terme d'UI, les règles d'ergonomies ayant évoluées, en terme d'esthétique, les bibliothèques graphiques ayant également évoluées, et en terme de sécurité, les morceaux de code plus maintenus pouvant avoir d'énormes trous béants.
Les WM managers de cette époques sont toujours là et utilisable, mon FVWM se portant très bien. Également une partie des DE a continué à évoluer au lieu de tout jeter, je pense en particulier à XFCE et E17. Mais bon, tout ceci n'a rien à voir avec ce que je disais plus haut.
Je suis on ne peut plus d'accord, mais encore faut-il des gens qui le fasse, et même qui puisse le faire, ce qui n'est pas forcément le cas des anciens logiciels de BeOS, contrairement à ceux qu'on trouve dans les dépôts GNU/Linux ou *BSD par exemple.
Emacs le fait depuis 30 ans.
[^] # Re: Logiciels disponibles
Posté par Astaoth . En réponse à la dépêche Haiku a 17 ans. Évalué à 3.
C'est chouette d'essayer de maintenir les logiciels BeOS mais … ils ne sont pas légèrement dépassés après 17 ans ? Ca risque de ne pas trop attirer de nouveaux utilisateurs, au contraire :/
Et du coup, le but c'est d'avoir de nouveaux logiciels développés avec les API de BeOS ? Comment comptez-vous attirer de nouveaux devs sur cette plateforme ? Avec peu d'utilisateurs, ca ne pas intéresser la plupart d'entre eux.
Emacs le fait depuis 30 ans.
# Logiciels disponibles
Posté par Astaoth . En réponse à la dépêche Haiku a 17 ans. Évalué à 4.
Bonjour,
Tout d'abord, félicitation pour continuer à développer HaikuOS après tout ce temps ! Vouloir se faire une place sur le marché de l'OS de bureau est louable, cependant par le passé, on a constaté qu'une des clefs principales de la popularité d'un OS auprès des utilisateurs finaux est la quantité d'applis disponibles. Vis-à-vis de ça, comment comptez-vous obtenir une quantité respectables de logiciels modernes pour attirer les gens ? En montant une forge qui compilera les logiciels libres pour BeOS ? En faisant une couche de compatibilité avec les logiciels GNU/LInux ? Ou en espérant que des développeurs soient intéressés pour créer des logiciels pour HaikuOS ?
Emacs le fait depuis 30 ans.
# Anciens algos
Posté par Astaoth . En réponse au journal Une bosse sur la ligne pour combattre le bufferbloat ?. Évalué à 1.
Ça me rappelle un projet sur lequel j'avais travaillé pour l'INRIA. Le projet portait plutôt sur le wifi, pour justement gérer de façon plus efficace les cas où on est utilisateurs par borne (typiquement dans une école, quand un prof demande d'aller chercher le pdf du tp sur son site). Le but était donc d'implémenter des solutions pour améliorer l'usage de ce wifi.
De mémoire on avait 2 algo. Un premier visait justement à privilégier les sessions transférant de petites données par rapport aux grosses. Comme ça on gagne justement un peu de latence. On a donc l'illusion d'une connexion plus rapide, même si le voisin profite du tp pour faire ses mises à jours. Et il me semble que le second algo visait à faire, en gros, une file de donnée par utilisateur pour alterner équitablement entre eux. En bref, on a travaillé sur le FQ décrit dans l'article. C'est sympa de voir qu'une solution utilisant ces algos est commercialisée, je suis curieux de savoir si ca améliore vraiment les choses !
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 3.
Ce ne sont pas les seuls, j'en avais rencontrés plusieurs dans ce cas là quand je regardais les groupwares existants. Les sha sont en fait les algo que j'ai vu le plus souvent proposés par les services web à auto-héberger. Souvent il y en a d'autres de proposés, dont md5, et plus rarement d'autres choses plus sécurisé.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 2.
Merci pour la doc.
Bah en fait, si, SOGo par exemple.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 1. Dernière modification le 07 août 2018 à 11:14.
Pour le côté serveur, ca dépend du nombre de connexion à gérer en même temps. Si justement c'est un gros site avec pas mal d'auth à faire en simultané, ca doit quand même utiliser pas mal de ressources, non ?
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à -6. Dernière modification le 07 août 2018 à 11:11.
Bah c'est sûr, si tu coupes 90% des possibilités, d'un coup le bruteforce c'est plus rapide. Dans ce cas, je peux te bruteforcer n'importe quel mdp en un temps record, à condition qu'il ne fasse qu'un seul caractère …
Et sinon, avec un mdp dont tu ne connais pas la taille, pouvant aller jusqu'à 12 (voir 36) caractères, incluant des caractères spéciaux, dont le fameux symbole '€' qui n'est quasiment jamais testé, il faut combien de temps ? Si t'as une étude dessus je suis preneur.
Et du coup, t'as des algo de hash qui sont efficaces face à un bruteforce ?
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 0. Dernière modification le 07 août 2018 à 09:24.
En quoi ? Y a une attaque viable contre sha2 ? Je t'avoue que j'attendais une réponse un peu plus élaboré qu'un simple jugement sans rien derrière.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 1.
Est-ce que ca permet de le faire en un temps raisonnable ? Si le bruteforce trouve les mdps en 15 ans, ca me dérange pas. J'en aurai changé d'ici là.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à -3.
Ah bon ? On a une attaque efficace sur tout ce qui est sha2 ? Ce n'est pas parce que sha3 est sorti qu'il existe une attaque rapide sur sha2. Même sans sel ca reste une bonne solution. Contrairement à garder des mdps en clair.
Emacs le fait depuis 30 ans.
[^] # Re: Chaussures du cordonnier
Posté par Astaoth . En réponse au journal Freenaute, ton mot de passe d'abonné est stocké en clair chez Free. Évalué à 8.
Le stockage des mdp en clair ou de façon réversible entraîne pas mal de problème parce que les gens normaux réutilisent souvent les mdps. N'importe quel argumentaire en faveur du stockage des mdps en clair ou de façon réversible n'est qu'une justification face à l'abaissement de sécurité que cela provoque et en rien une raison vis-à-vis de ce problème de sécurité.
De même, stocker en clair des mdps soit-disant parce que la sécurité de la bdd est inviolable n'est qu'un argument illusoire, valable uniquement jusqu'au jour où la bdd des mdps se fait voler.
Personnellement, sur mon serveur perso, tout mes mdps sont hashés en sha256. Et bon, se servir de la médiocrité des autres pour justifier sa propre médiocrité, c'est rentrer dans la spirale de la nullité. À un moment donné, faut bien se lancer la sécurisation de ses services sans attendre que le moindre petit site perdu du web l'ait également fait.
Emacs le fait depuis 30 ans.
[^] # Re: Il y a des gens ...
Posté par Astaoth . En réponse au journal De l'usage du courrier électronique en 2018. Évalué à 2.
Franchement, les contraintes et risques liés, c'est plutôt la liberté. La liberté de configurer son installation comme on veut, de mettre les logiciels et interfaces qu'on veut etc. Faut juste avoir un second MX, au cas où on casse le premier :3
Pour la sécurité, faut bien sûr surveiller son serveur quotidiennement, mais globalement et une fois bien configuré, ça craint pas grand chose.
Emacs le fait depuis 30 ans.
[^] # Re: Il y a des gens ...
Posté par Astaoth . En réponse au journal De l'usage du courrier électronique en 2018. Évalué à 4. Dernière modification le 05 août 2018 à 22:49.
Quand t'es auto-hébergé, pas de soucis pour en faire.
Emacs le fait depuis 30 ans.