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, et sans pubs ni télémétrie.
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.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
Ç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, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
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 ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
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à.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
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.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
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, et sans pubs ni télémétrie.
J'ai eu un peu le même genre de réflexions lorsque je suis passé en auto-hébergé. Concrètement, je me suis dit que ca serait pas mal de compartimenter un peu la gestion de mes courriels en faisant des boîtes séparées. Voilà ce que j'ai à présent :
- une adresse général, pour parler avec le monde connu
- une adresse pro, pour communiquer uniquement sur le boulot
- une adresse pour tout ce qui est service relié à mon identité réelle et qui recoit beaucoup de spam, du style SNCF, Air France, commerce en ligne, et certaines mailing list
- une adresse pour tout ce qui est inscription en ligne qui n'est pas directement relié à mon identité réelle
- et enfin une dernière adresse traitée automatiquement pour tout ce qui est relié à des services envoyant des factures récurrentes
Ça fait beaucoup, mais au moins les services qui envoient beaucoup de courriels ne masquent pas ceux qui sont importants et ceux des amis.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Oh, sérieux ! J'avais jamais vu qu'on pouvait faire ca, à chaque fois j'ajustais l'image en faisant un clique droit sur le curseur de rotation. C'est apparu avec quelle version ??
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Super sympa la ligne d'horizon pour le traitement des photos ! Un de mes rêves serait que ce soit justement intégré à DarkTable pour enfin avoir des photos à peu près droite !
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Honnêtement, j'ai pas lu l'article, seulement la conclusion de l'auteur. Si une journée de boulot en informatique n'est équivalente à que 9km en voiture, c'est du coup un bon argument pour le développement du télé-travail ! Faudra que j'en parle à mon manageur à notre prochaine réunion !
Bon par contre, va sérieusement falloir lancer une campagne pour expliquer que non, en français, digital n'est pas un synonyme de numérique. C'est aussi fatigant de lire des articles qui font ce mélange tout au long de leur contenu que entre un programmeur et un programmateur par exemple.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Ravi de voir que mon troll sur Python a bien pris !
C'est l'exception qui rend tout ce concept caduque,
Personnellement, je n'aime pas python parce que sa grammaire se base justement sur les marques de formatage du code. J'ai pas besoin d'un langage de ce genre pour avoir du code bien indenté, et j'aime bien justement pouvoir choisir la façon dont j'indente mes blocs. Questions de goûts et de couleurs quoi.
Maintenant, je doute qu'il existe un IDE adapté pour coder avec tout les langages du monde. Au contraire, le choix de l'IDE et des éventuels plugins installés se font plutôt en fonction du langage et de ses préférences personnelles. Donc pour les pythonneurs, rien n'impose l'utilisation de ces tabulations elastiques si c'est inutilisable avec ce langage ou que ca ne convient pas aux développeurs. C'est donc très loin de rendre ce concept caduque.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
# 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, et sans pubs ni télémétrie.
# 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
[^] # 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, et sans pubs ni télémétrie.
# Mêmes réflexions
Posté par Astaoth . En réponse au journal De l'usage du courrier électronique en 2018. Évalué à 2.
J'ai eu un peu le même genre de réflexions lorsque je suis passé en auto-hébergé. Concrètement, je me suis dit que ca serait pas mal de compartimenter un peu la gestion de mes courriels en faisant des boîtes séparées. Voilà ce que j'ai à présent :
- une adresse général, pour parler avec le monde connu
- une adresse pro, pour communiquer uniquement sur le boulot
- une adresse pour tout ce qui est service relié à mon identité réelle et qui recoit beaucoup de spam, du style SNCF, Air France, commerce en ligne, et certaines mailing list
- une adresse pour tout ce qui est inscription en ligne qui n'est pas directement relié à mon identité réelle
- et enfin une dernière adresse traitée automatiquement pour tout ce qui est relié à des services envoyant des factures récurrentes
Ça fait beaucoup, mais au moins les services qui envoient beaucoup de courriels ne masquent pas ceux qui sont importants et ceux des amis.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Télétravail
Posté par Astaoth . En réponse au journal Pollution numérique. Évalué à 1.
Y a pas à dire, j'aime LinuxFR <3
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Ligne d'horizon
Posté par Astaoth . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 1.
Oh, sérieux ! J'avais jamais vu qu'on pouvait faire ca, à chaque fois j'ajustais l'image en faisant un clique droit sur le curseur de rotation. C'est apparu avec quelle version ??
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# Ligne d'horizon
Posté par Astaoth . En réponse à la dépêche GIMP 2.10.4 : on garde le rythme !. Évalué à 4.
Super sympa la ligne d'horizon pour le traitement des photos ! Un de mes rêves serait que ce soit justement intégré à DarkTable pour enfin avoir des photos à peu près droite !
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Larousse
Posté par Astaoth . En réponse au journal Pollution numérique. Évalué à 6.
Faut leur renvoyer http://www.larousse.fr/dictionnaires/francais/digital_digitale_digitaux/25502/difficulte en échange.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# Télétravail
Posté par Astaoth . En réponse au journal Pollution numérique. Évalué à 8.
Honnêtement, j'ai pas lu l'article, seulement la conclusion de l'auteur. Si une journée de boulot en informatique n'est équivalente à que 9km en voiture, c'est du coup un bon argument pour le développement du télé-travail ! Faudra que j'en parle à mon manageur à notre prochaine réunion !
Bon par contre, va sérieusement falloir lancer une campagne pour expliquer que non, en français, digital n'est pas un synonyme de numérique. C'est aussi fatigant de lire des articles qui font ce mélange tout au long de leur contenu que entre un programmeur et un programmateur par exemple.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Anglicisme
Posté par Astaoth . En réponse au journal Pollution numérique. Évalué à 1.
Maudit Pythagore !
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Et Python ? Et Emacs ?
Posté par Astaoth . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. Évalué à 3.
Ravi de voir que mon troll sur Python a bien pris !
Personnellement, je n'aime pas python parce que sa grammaire se base justement sur les marques de formatage du code. J'ai pas besoin d'un langage de ce genre pour avoir du code bien indenté, et j'aime bien justement pouvoir choisir la façon dont j'indente mes blocs. Questions de goûts et de couleurs quoi.
Maintenant, je doute qu'il existe un IDE adapté pour coder avec tout les langages du monde. Au contraire, le choix de l'IDE et des éventuels plugins installés se font plutôt en fonction du langage et de ses préférences personnelles. Donc pour les pythonneurs, rien n'impose l'utilisation de ces tabulations elastiques si c'est inutilisable avec ce langage ou que ca ne convient pas aux développeurs. C'est donc très loin de rendre ce concept caduque.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.