En php, la position du $ n’est pas du tout optimale (en haut à gauche). Donc c’est un peu pénible car c’est utilisé à chaque manipulation de variable.
Donc encore pire pour le shell (tiens, un délire pour le jour ou je m'ennuie: compter le nombre d'instance de chaque caractère dans mes codes, et classer par langage…)
Quelques fois il m’arrive de taper des espaces insécables (maj + espace)
Ça, ça m'arrive aussi avec azerty… et libinput aime pas. Enfin, quand je suis sous zsh, j'ai pas le problème, il doit comprendre qu'une espace, c'est une espace putain… mais avec bash, bien souvent, "command not found", virer une espace et hop, ça marche. Évidemment, moi de pester avec le shell à la con ensuite (même si le vrai problème, c'est moi, mais quand même!)
Ça semble logique, mais bon, d'un autre côté ça permets d'apprendre, au moins visuellement, la disposition (parce que du coup, le smartphone, faut lire les touches, elles sont sous tes yeux…), ce qui doit rendre la transition moins raide ensuite sur un vrai outil de travail (on pardonne plus facilement une lenteur d'écriture sur tél que sur clavier je pense).
Je pourrais piper ton texte dans sed -e 's/ddg/google/' -e 's/google/ddg' que mon commentaire aurait autant d'intérêt que le tiens: une assertion péremptoire sans preuve.
Pourrais-tu nous indiquer quels termes, je cite, font que l'on "ne trouve rien"? Ainsi nous pourrions juger…
Pour moi, ne rien trouver, c'est arriver sur une page blanche, pour info. Trouver des résultats non pertinents, c'est autre chose, et plus compliqué à définir. D'où ma question plus haut, en fait.
Désolé de te détromper. Quand j'ai lu le roman, à l'époque, je n'ai pas vraiment fait le lien avec Staline. Ce n'étais pour moi «qu'une uchronie de plus» dans les oeuvres lues (une excellente, certes).
Le roman que j'ai lu étais un traduction française, j'avais 16 ans, et, oui, je connaissais l'histoire de la guerre froide.
Il n'empêche que dans mes souvenirs, l'auteur décrit très clairement 3 blocs, tous les mêmes, et jamais on ne sait dans lequel on se situe d'ailleurs, c'est loin de «la nuit des temps» de Barjavel sur ce point, très, très loin. Devant.
Bref, que j'aie tort ou raison de ne pas avoir fait le mélange avec Staline, ça n'empêche pas que cette affirmation "tout le monde pense à Staline en lisant le roman." est fausse, moi n'ayant pas eu de telle pensée.
Non, mais j'ajoute ça à ma TODO-list, effectivement des Z e des 7 barrés, et ce genre de choses ne seraient pas un luxe pour coder, si ça peut ma permettre d'avoir des fontes plus petites tout aussi lisibles, moi, je prend! (parce que plus je vois de contexte de mon code, plus je suis heureux)
Tiens, j'avais complètement oublié, à force de lire du texte écrit à la machine, que le 7 et le Z avaient des barres! Merci, du coup!
Sinon, je lis cela : Des versions spécifiques pour les webdesigners (webfonts) sont disponibles sur demande. Je ne vois pas bien pourquoi ne pas mettre en libre téléchargement si le projet est libre…
Certains projets libres font payer les binaires windows (hexchat par exemple fait payer le truc intégré au "store" MS de W10, mais pas l'installateur pour W7 et plus récent), par exemple. Je ne vois pas d'inconvénient à ça, perso, libre ne devrais pas vouloir dire "on fait tout le boulot pour vous, à l'oeil".
… ça ne passe pas "le test du O0" pour moi. C'est dommage, parce que même sans être malvoyant, j'aime avoir des fontes pour lesquelles je ne peux pas confondre deux caractères usuels. Par contre ça passe celui du 1Il, toutes les fontes ne peuvent pas en dire autant.
Parce que perso, je trouve les résultats de ddg largement satisfaisants. Quand je ne trouve pas sur ddg et que je cherche sur google, je ne trouve pas plus, en fait. Mais c'est peut-être le fait que, n'ayant pas assez d'infos sur moi, google ne peux pas facilement me mettre dans "la bonne bulle"?
Déjà que depuis peu (quelques mois) ddg me mets dans la bulle "france" et ça me fait chier, je n'ose imaginer ou je finirai avec google.
Outre ce critère, il y a aussi la syntaxe bang! que j'utilisais beaucoup, avant de prendre l'habitude d'enregistrer moi-même mes moteurs de recherche spécialisés, dont j'ai pas souvenir que google ait un équivalent?
Je peux aussi citer la structure d'affichage des recherches, mais ça je crois que google a rattrapé son retard dessus, au moins en partie… après vérification, non, en fait, l'UI est toujours aussi foireuse (question de goûts, sûrement).
Du coup, comment tu évalues "le meilleur"? Je n'ai ici abordé, tu l'auras remarqué, que des questions terre-à-terre, si on commence a aborder le problème de l'éthique (supposée) de ddg vs celle de google, bon… voila quoi. Mais il est probable qu'il y ait mieux.
En fait, "le meilleur", ça dépend de chacun, et des priorités de la personne qui le proclame. Pour moi, le moteur de recherche de google est loin d'être le meilleur.
Même si les terminaux et la fabrication du serveurs coûtent, ce dont je ne doute pas, les optimisations (parce qu'au final, pour réduire la facture, faut optimiser ou virer des fonctionnalités lourdes, j'imagine) qui permettent de consommer moins (de RAM, de CPU, d'espace disque) ne peuvent-elles pas du même coup rendre le soft utilisable, justement, sur du plus vieux matériel?
Quand je vois que par exemple sur mes systèmes (Debian 10, fonctionnant sur runit) les processus qui gèrent les daemons (runsv pour la gestion d'un daemon, svlogd pour gérer ses logs) ont un coût de RSS (mémoire résidente) de 740Kio en moyenne, pour un coût total de ~1.5Mio par daemon, je me pose des questions. Ces outils ne faisant quasi rien…
Une rapide comparaison très biaisée indique, pour int main() { for( ;; ); }:
Le VSZ, on s'en fout un peu (c'est la mémoire utilisée, mais pas réservée. Si je dis pas de conneries, lancer 2 processus images du même programme auront notamment les sections .text communes, les lib partagées également, etc, sans compter la mémoire réservée mais pas utilisée (overcommit) et ce genre de joyeusetés).
La taille de binaire est surtout pertinente du fait que, ben, ça prend de la bande passante quand il faut installer, l'espace disque est aussi un argument, mais il me semble moins pertinent. N'empêche que ça reste un argument (la bande passante, ça fait chauffer pleins de machines).
Par contre, le RSS, ça me semble pertinent: c'est une pas si mauvaise approximation de l'impact sur la RAM (pas exacte, cependant, par exemple GNU free -h ou busybox free -m ne me donnent pas du tout les mêmes valeurs, GNU free étant inférieur à la somme des RSS de tous les processus, la ou busybox trouve justement cette valeur).
Bon, évidemment, le programme ici ne fait tellement rien (d'autre que monter un coeur à 100%) que ces résultats ne peuvent pas servir de manière brute.
Sur de gros programmes, le coût est probablement négligeable: par exemple, sur ma machine, free rapporte 3.5Gio utilisés pour 183 lignes dans ps -A.
Un calcul rapide (et surtout bien pourri) permettrait de dire "(744 - 4 )*183 => ~132Mio soit ~3.7% économisés".
C'est évidemment faux, ne serait-ce que parce que ps -A montre aussi des éléments du noyau je crois (rcu_sched, migration/3, etc) ce qui implique que le résultat est trop élevé par rapport à la réalité.
N'empêche que si on prend un système moins puissant que mon PC de bureau, et plus vieux, par exemple une beaglebone black (512Mio de RAM).
Le surcoût de pas loin de 1.5Mio gâchés par daemon (on pourrait même dire de 2.1Mio pour la plupart des daemon, puisqu'eux aussi souffrent de ce problème), multiplié par le nombre de daemons d'un système (cron, getty, client dhcpd, cups, mpd, caches dns parfois, proxy ldap (nslcd), etc) peut vite représenter une valeur non négligeable.
Disons 10 daemons. 15Mio. 512Mio de RAM dispo. Presque 3%. Si on compte le daemon lui même, on monte donc à 21Mio, soit plus de 4%.
Bref.
En réduisant ces coûts, je pense qu'il est probable que l'on puisse aussi utiliser plus longtemps les vieux systèmes, et donc baisser l'impact énergétique de l'informatique puisque l'on diminuerais le nombre de machines jetées à la benne en plus de diminuer légèrement la consommation fonctionnelle.
Peut-être que certains (meta-)moteurs de la concurrence te permettraient d'éviter le problème, sans prise de tête et sans bidouille?
Pour ma part, j'utilise ddg, qui utilise aussi du JS et de la redirection dans ses liens, il me semble. En théorie pour nous protéger, de mémoire, mais je t'avoue ne pas avoir creusé (j'en doute, hein, mais bon, sait-on jamais).
Je ne doute pas qu'il en existe d'autres, d'ailleurs.
Ne marche pas avec mawk pour le coup. Je pense que c'est lié à l'utilisation de comparaison pour les patterns, alors que ça devrais puisque le standard (POSIX-10031-2017) dit:
An awk program is composed of pairs of the form:
pattern { action }
plus loin:
Patterns
A pattern is any valid expression, a range specified by two expressions separated by a comma, or one of the two special patterns BEGIN or END.
Du coup, je me demande si ça ne serait pas un bug de mawk? Ça y ressemble en tout cas beaucoup?
Peut-être spécifique à debian?
Pour info:
```sh
% mawk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
compiled limits:
max NF 32767
sprintf buffer 2040
```
Non parce que hein, les divers outils vus dans cette dépêche sont tous basés sur une techno hyper lourde: le HTML5.
On peut éventuellement améliorer la situation du point de vue du respect de la vie privée en patchant des logiciels fondés sur cette techno, certes, et c'est mieux que rien, mais sauver la planète?
J'en doute. Fort. Très fort. À mes yeux, le web est le principal moteur qui implique de devoir balancer du matos encore fonctionnel mais "trop vieux".
Parce qu'en terme de distros magiques, j'en connais une autre qui s'en revendique: sourcemage (bon, c'est surtout pour la blague, hein, j'ai jamais utilisé après tout).
À suivre les liens, on trouve des sources, tu pourras juger et chercher ce qui te plaît, ce à quoi que tu veux faire jouer a ces enfants. Pourquoi pas, jouer avec eux?
Tu peux aussi éventuellement chercher dans ton navigateur de paquet préféré, aptitude via les catégories ou, soyons fous, les debtags (si tu trouves un soft qui tiens la route je suis preneur).
D'autres on peut-être d'autres outils.
Je réagis seulement à la remarque sur Hugo : certes c'est un logiciel complexe (comme beaucoup de générateurs de site statique, il réimplémente pas mal de fonctionnalités de make), mais il sert seulement à générer du contenu statique, contenu qui peut être aussi simple que l'on veut.
Et si le contenu est simple, pourquoi utiliser hugo? S'il est possible de faire des sites simples facilement, de compiler aisément un layout et une liste, par exemple, de documents markdown en un site simple et propre, pourquoi un truc aussi complexe que hugo?
Notes bien, je ne tape pas en soit sur hugo, c'est juste probablement le générateur statique le plus utilisé en ce moment… il ne sert que d'exemple pour illustrer ce que, oui, je qualifie de complexité.
Bon, sur le layout, il semble qu'il va me falloir revoir mon jugement, cela dis.
[^] # Re: Programmation
Posté par freem . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 3.
Donc encore pire pour le shell (tiens, un délire pour le jour ou je m'ennuie: compter le nombre d'instance de chaque caractère dans mes codes, et classer par langage…)
Ça, ça m'arrive aussi avec azerty… et libinput aime pas. Enfin, quand je suis sous zsh, j'ai pas le problème, il doit comprendre qu'une espace, c'est une espace putain… mais avec bash, bien souvent, "command not found", virer une espace et hop, ça marche. Évidemment, moi de pester avec le shell à la con ensuite (même si le vrai problème, c'est moi, mais quand même!)
[^] # Re: Super retour !
Posté par freem . En réponse au journal Ça y est!! Je suis passé au bépo…. Évalué à 2.
Ça semble logique, mais bon, d'un autre côté ça permets d'apprendre, au moins visuellement, la disposition (parce que du coup, le smartphone, faut lire les touches, elles sont sous tes yeux…), ce qui doit rendre la transition moins raide ensuite sur un vrai outil de travail (on pardonne plus facilement une lenteur d'écriture sur tél que sur clavier je pense).
[^] # Re: pourquoi s'acharner...
Posté par freem . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 0.
Je pourrais piper ton texte dans
sed -e 's/ddg/google/' -e 's/google/ddg'que mon commentaire aurait autant d'intérêt que le tiens: une assertion péremptoire sans preuve.Pourrais-tu nous indiquer quels termes, je cite, font que l'on "ne trouve rien"? Ainsi nous pourrions juger…
Pour moi, ne rien trouver, c'est arriver sur une page blanche, pour info. Trouver des résultats non pertinents, c'est autre chose, et plus compliqué à définir. D'où ma question plus haut, en fait.
[^] # Re: À votre service
Posté par freem . En réponse au journal Orwell dans le domaine public: nouvelle traduction chez Agone (et deux autres chez Gallimard). Évalué à 0.
J'aurai utilisé «pensée parallèle» moi.
[^] # Re: Wesh gros frère
Posté par freem . En réponse au journal Orwell dans le domaine public: nouvelle traduction chez Agone (et deux autres chez Gallimard). Évalué à 7.
Désolé de te détromper. Quand j'ai lu le roman, à l'époque, je n'ai pas vraiment fait le lien avec Staline. Ce n'étais pour moi «qu'une uchronie de plus» dans les oeuvres lues (une excellente, certes).
Le roman que j'ai lu étais un traduction française, j'avais 16 ans, et, oui, je connaissais l'histoire de la guerre froide.
Il n'empêche que dans mes souvenirs, l'auteur décrit très clairement 3 blocs, tous les mêmes, et jamais on ne sait dans lequel on se situe d'ailleurs, c'est loin de «la nuit des temps» de Barjavel sur ce point, très, très loin. Devant.
Bref, que j'aie tort ou raison de ne pas avoir fait le mélange avec Staline, ça n'empêche pas que cette affirmation "tout le monde pense à Staline en lisant le roman." est fausse, moi n'ayant pas eu de telle pensée.
[^] # Re: dommage...
Posté par freem . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 3.
Pas faux.
[^] # Re: dommage...
Posté par freem . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 2. Dernière modification le 18 janvier 2021 à 13:29.
Non, mais j'ajoute ça à ma TODO-list, effectivement des Z e des 7 barrés, et ce genre de choses ne seraient pas un luxe pour coder, si ça peut ma permettre d'avoir des fontes plus petites tout aussi lisibles, moi, je prend! (parce que plus je vois de contexte de mon code, plus je suis heureux)
[^] # Re: dommage...
Posté par freem . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 3.
Tiens, j'avais complètement oublié, à force de lire du texte écrit à la machine, que le 7 et le Z avaient des barres! Merci, du coup!
Certains projets libres font payer les binaires windows (hexchat par exemple fait payer le truc intégré au "store" MS de W10, mais pas l'installateur pour W7 et plus récent), par exemple. Je ne vois pas d'inconvénient à ça, perso, libre ne devrais pas vouloir dire "on fait tout le boulot pour vous, à l'oeil".
[^] # Re: pourquoi s'acharner...
Posté par freem . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 3.
Oui mais non. Même sur "toutes les régions", le contenu qui apparaît est, par exemple, majoritairement français, sur une recherche telle que "test".
# dommage...
Posté par freem . En réponse au lien Luciole : une police de caractère conçue spécifiquement pour les personnes malvoyantes. Évalué à 7.
… ça ne passe pas "le test du O0" pour moi. C'est dommage, parce que même sans être malvoyant, j'aime avoir des fontes pour lesquelles je ne peux pas confondre deux caractères usuels. Par contre ça passe celui du 1Il, toutes les fontes ne peuvent pas en dire autant.
[^] # Re: pourquoi s'acharner...
Posté par freem . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 4.
Intéressant. Le meilleur selon quels critères?
Parce que perso, je trouve les résultats de ddg largement satisfaisants. Quand je ne trouve pas sur ddg et que je cherche sur google, je ne trouve pas plus, en fait. Mais c'est peut-être le fait que, n'ayant pas assez d'infos sur moi, google ne peux pas facilement me mettre dans "la bonne bulle"?
Déjà que depuis peu (quelques mois) ddg me mets dans la bulle "france" et ça me fait chier, je n'ose imaginer ou je finirai avec google.
Outre ce critère, il y a aussi la syntaxe bang! que j'utilisais beaucoup, avant de prendre l'habitude d'enregistrer moi-même mes moteurs de recherche spécialisés, dont j'ai pas souvenir que google ait un équivalent?
Je peux aussi citer la structure d'affichage des recherches, mais ça je crois que google a rattrapé son retard dessus, au moins en partie… après vérification, non, en fait, l'UI est toujours aussi foireuse (question de goûts, sûrement).
Du coup, comment tu évalues "le meilleur"? Je n'ai ici abordé, tu l'auras remarqué, que des questions terre-à-terre, si on commence a aborder le problème de l'éthique (supposée) de ddg vs celle de google, bon… voila quoi. Mais il est probable qu'il y ait mieux.
En fait, "le meilleur", ça dépend de chacun, et des priorités de la personne qui le proclame. Pour moi, le moteur de recherche de google est loin d'être le meilleur.
[^] # Re: Energie grise
Posté par freem . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. Évalué à 5. Dernière modification le 17 janvier 2021 à 20:06.
Même si les terminaux et la fabrication du serveurs coûtent, ce dont je ne doute pas, les optimisations (parce qu'au final, pour réduire la facture, faut optimiser ou virer des fonctionnalités lourdes, j'imagine) qui permettent de consommer moins (de RAM, de CPU, d'espace disque) ne peuvent-elles pas du même coup rendre le soft utilisable, justement, sur du plus vieux matériel?
Quand je vois que par exemple sur mes systèmes (Debian 10, fonctionnant sur runit) les processus qui gèrent les daemons (runsv pour la gestion d'un daemon, svlogd pour gérer ses logs) ont un coût de RSS (mémoire résidente) de 740Kio en moyenne, pour un coût total de ~1.5Mio par daemon, je me pose des questions. Ces outils ne faisant quasi rien…
Une rapide comparaison très biaisée indique, pour
int main() { for( ;; ); }:Le VSZ, on s'en fout un peu (c'est la mémoire utilisée, mais pas réservée. Si je dis pas de conneries, lancer 2 processus images du même programme auront notamment les sections .text communes, les lib partagées également, etc, sans compter la mémoire réservée mais pas utilisée (overcommit) et ce genre de joyeusetés).
La taille de binaire est surtout pertinente du fait que, ben, ça prend de la bande passante quand il faut installer, l'espace disque est aussi un argument, mais il me semble moins pertinent. N'empêche que ça reste un argument (la bande passante, ça fait chauffer pleins de machines).
Par contre, le RSS, ça me semble pertinent: c'est une pas si mauvaise approximation de l'impact sur la RAM (pas exacte, cependant, par exemple GNU
free -houbusybox free -mne me donnent pas du tout les mêmes valeurs, GNU free étant inférieur à la somme des RSS de tous les processus, la ou busybox trouve justement cette valeur).Bon, évidemment, le programme ici ne fait tellement rien (d'autre que monter un coeur à 100%) que ces résultats ne peuvent pas servir de manière brute.
Sur de gros programmes, le coût est probablement négligeable: par exemple, sur ma machine,
freerapporte 3.5Gio utilisés pour 183 lignes dansps -A.Un calcul rapide (et surtout bien pourri) permettrait de dire "(744 - 4 )*183 => ~132Mio soit ~3.7% économisés".
C'est évidemment faux, ne serait-ce que parce que
ps -Amontre aussi des éléments du noyau je crois (rcu_sched, migration/3, etc) ce qui implique que le résultat est trop élevé par rapport à la réalité.N'empêche que si on prend un système moins puissant que mon PC de bureau, et plus vieux, par exemple une beaglebone black (512Mio de RAM).
Le surcoût de pas loin de 1.5Mio gâchés par daemon (on pourrait même dire de 2.1Mio pour la plupart des daemon, puisqu'eux aussi souffrent de ce problème), multiplié par le nombre de daemons d'un système (cron, getty, client dhcpd, cups, mpd, caches dns parfois, proxy ldap (nslcd), etc) peut vite représenter une valeur non négligeable.
Disons 10 daemons. 15Mio. 512Mio de RAM dispo. Presque 3%. Si on compte le daemon lui même, on monte donc à 21Mio, soit plus de 4%.
Bref.
En réduisant ces coûts, je pense qu'il est probable que l'on puisse aussi utiliser plus longtemps les vieux systèmes, et donc baisser l'impact énergétique de l'informatique puisque l'on diminuerais le nombre de machines jetées à la benne en plus de diminuer légèrement la consommation fonctionnelle.
[^] # Re: Flutter et le libre...
Posté par freem . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à -1. Dernière modification le 17 janvier 2021 à 18:30.
Ben, le truc en fait, c'est que le web, il est toujours en alpha, donc bon, déjà atteindre le stade beta c'est un exploit pour moi…
Parce que beta ça veut dire:
Hors, si je ne m'abuse, le web semble ne toujours pas être assez complet. On est donc bien dans de l'alpha perpétuelle.
# pourquoi s'acharner...
Posté par freem . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 10.
… à utiliser google?
Peut-être que certains (meta-)moteurs de la concurrence te permettraient d'éviter le problème, sans prise de tête et sans bidouille?
Pour ma part, j'utilise ddg, qui utilise aussi du JS et de la redirection dans ses liens, il me semble. En théorie pour nous protéger, de mémoire, mais je t'avoue ne pas avoir creusé (j'en doute, hein, mais bon, sait-on jamais).
Je ne doute pas qu'il en existe d'autres, d'ailleurs.
# ne marche pas avec mawk
Posté par freem . En réponse au journal TapTempo contest : un peu moins d'octets en Awk. Évalué à 2.
Ne marche pas avec
mawkpour le coup. Je pense que c'est lié à l'utilisation de comparaison pour les patterns, alors que ça devrais puisque le standard (POSIX-10031-2017) dit:plus loin:
Du coup, je me demande si ça ne serait pas un bug de mawk? Ça y ressemble en tout cas beaucoup?
Peut-être spécifique à debian?
Pour info:
```sh
% mawk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
compiled limits:
max NF 32767
sprintf buffer 2040
```
[^] # Re: ...
Posté par freem . En réponse au journal Un hacker français finance l'alt right US avec Bitcoin. Évalué à 10.
Tant qu'ils brisent pas la cruche à force de trop mettre le récipient à l'eau, moi je dis, tout va bien.
[^] # Sauver la planète n'impliquerait-il pas de changer de techno également?
Posté par freem . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 8.
Non parce que hein, les divers outils vus dans cette dépêche sont tous basés sur une techno hyper lourde: le HTML5.
On peut éventuellement améliorer la situation du point de vue du respect de la vie privée en patchant des logiciels fondés sur cette techno, certes, et c'est mieux que rien, mais sauver la planète?
J'en doute. Fort. Très fort. À mes yeux, le web est le principal moteur qui implique de devoir balancer du matos encore fonctionnel mais "trop vieux".
[^] # Re: Nope.
Posté par freem . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 2.
J'aimerai en être si sûr :]
# La plus magique?
Posté par freem . En réponse au journal Vous prendrez bien un peu de Mageia pour bien commencer l'année. Évalué à 4.
Parce qu'en terme de distros magiques, j'en connais une autre qui s'en revendique: sourcemage (bon, c'est surtout pour la blague, hein, j'ai jamais utilisé après tout).
# diverses sources:
Posté par freem . En réponse au message Recherche de jeux à jouer en LAN. Évalué à 2.
À suivre les liens, on trouve des sources, tu pourras juger et chercher ce qui te plaît, ce à quoi que tu veux faire jouer a ces enfants. Pourquoi pas, jouer avec eux?
Tu peux aussi éventuellement chercher dans ton navigateur de paquet préféré,
aptitudevia les catégories ou, soyons fous, les debtags (si tu trouves un soft qui tiens la route je suis preneur).D'autres on peut-être d'autres outils.
[^] # Re: port 625 ouvert sur box free
Posté par freem . En réponse au message Port 625 ouvert sur box free. Évalué à 1.
yw. Désolé, pas pu m'empêcher.
[^] # Re: Pas de sex toy dans les "super creepy"?
Posté par freem . En réponse au lien Objets connectés : vie privée non comprise. Évalué à 4.
Ben oui, justement, une ceinture de chasteté quoi :)
[^] # Re: Oui, mais ce n'est pas une raison pour modifier la réalité...
Posté par freem . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 3.
Pas faux. J'avais mal interprété tes propos, désolé.
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par freem . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 2. Dernière modification le 31 décembre 2020 à 02:24.
Tout à fait, ma réponse était d'ailleurs garantie 100% sans ironie :)
En vrai, ma réponse marche. Dans certains contextes. Pas dans les bons. De la même manière que la réponse à laquelle je répondais…
[^] # Re: Oui, mais ce n'est pas une raison pour modifier la réalité...
Posté par freem . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 3.
Et si le contenu est simple, pourquoi utiliser hugo? S'il est possible de faire des sites simples facilement, de compiler aisément un layout et une liste, par exemple, de documents markdown en un site simple et propre, pourquoi un truc aussi complexe que hugo?
Notes bien, je ne tape pas en soit sur hugo, c'est juste probablement le générateur statique le plus utilisé en ce moment… il ne sert que d'exemple pour illustrer ce que, oui, je qualifie de complexité.
Bon, sur le layout, il semble qu'il va me falloir revoir mon jugement, cela dis.