Vue normale

Distrochooser

13 octobre 2025 à 14:14
C'est chouette ça : répondez à un petit questionnaire, et le site vous met en avant la ou les distributions Linux qu'il considérera les mieux adaptées à votre profil. Un bon complément au sympathique [Distrosea][1], le site qui permet de tester des distributions dans une VM à travers son navigateur, dont [SebSauvage avait parlé][2].

[1]: https://distrosea.com/fr/
[2]: https://sebsauvage.net/links/?searchterm=distrosea
(Permalink)

Distrochooser

13 octobre 2025 à 14:14
C'est chouette ça : répondez à un petit questionnaire, et le site vous met en avant la ou les distributions Linux qu'il considérera les mieux adaptées à votre profil. Un bon complément au sympathique [Distrosea][1], le site qui permet de tester des distributions dans une VM à travers son navigateur, dont [SebSauvage avait parlé][2].

[1]: https://distrosea.com/fr/
[2]: https://sebsauvage.net/links/?searchterm=distrosea
(Permalink)

Advanced Tips to Improve Disk IO Performance in Linux | GoLinuxCloud

6 octobre 2025 à 09:10

Globalement très content de Linux (Mint) depuis environ 1 an.
Par contre, dès que plusieurs accès disque simultanés sont en cours (SSD local ou réseau), les perfs s'écroulent, les gestionnaires de fichiers (Nemo ou Thunar) se figent, c'est vraiment pénible.
Pas trouvé de solution pour le moment.

[edit]
A la lecture du doc, le schefuler "bfq" serait une piste.

Explore comprehensive strategies to improve disk IO performance, from optimizing kernel parameters to leveraging virtualization tools. Unlock the full potential of your system and achieve faster, more efficient disk operations.


Permalien

Gmail OAuth authentication fails [when a local webserver is running] | Thunderbird Support Forum | Mozilla Support

2 octobre 2025 à 10:02

This is silly, but Google OAuth2 fails at the last step (after clicking "Allow") if a local web server is running (on localhost I guess). Workaround is to stop the web server during the OAuth2 process -- you can then restart it just fine.

I got bitten by this with several Google calendars I use for work, for which I guess the OAuth2 token expired recently. Subsequently I got spammed with authentication requests, and my calendars stopped working properly.

The OAuth2 flow only showed the final "Allow" part, but clicking on it redirected me to my company's homepage. This added to the confusion, because the Google account I use uses my company's email, so my first guess was that the OAuth2 flow incorrectly assumed it had to finish on the email domain's website (or using some missing DNS records from it). But actually it was just my local webserver performing the redirection, but as I had set it up recently to work on my company's website, it was quite confusing -- especially as it redirected to the actuel website, for which I had a temporary local DNS entry when I worked on it last month.
I ended up messing up with TB cookies, vainly trying to finish the OAuth2 flow using cURL (I didn't document myself on the flow, and was pessimistic I could do so without a proper OAuth2 client anyway -- but I had a set of query parameters on the incorrect redirection so I guessed that just maybe if the query was made to the right place it might give me the One cookie I needed), and even trying to re-add some calendars, but nothing helped -- obviously.

Anyway, I have no clue why TB does this, but I luckily finally found this QA post when I was about to ask out of sheer despair -- not sure why I didn't find if before, maybe my queries were a bit too specific and this one didn't show up.


Permalink
❌