Can't wait for the day when people just start installing recursive resolvers on their computers -- or even better, when ISPs start doing it on their routers. Which I could totally imaging happening on a future version of the Freebox router of French ISP Free.fr.

Then Canal+ and co would have to go after the websites again, instead of going after easily identifiable public DNS servers again. That would be fun to see.

Agreed, except they might go after ISPs who can poison/drop recursive queries.

Or just force them to block IPs; they don't care about collateral damage: https://torrentfreak.com/piracy-shield-blacks-out-tech-news-...

this is why we need DoT and DoH everywhere.

If my resolver can connect using DoT or DoH all the way up to the root servers then ISP cannot intercept or poison it..

And making ISP block the IPs is the correct way to approach this problem..

Yeah, they did the same in Ingress: film a portal (pokéstop/gym) while walking around it to gain a small reward. I've always wondered what kind of dataset they were building with that -- now we know!

I've used it for years almost everywhere (terminal, IDE, my blog, even DuckDuckGo/Kagi with Iosevka Aile) and I absolutely love it. Looks great everywhere, and highly readable.

I set it up on our company thinkpad t14 gen1 and the LCD panel + iosevka gives glowing precision in text editors.. it massages my brain quite brilliantly.

Yep. But hey, blame video games instead of his policy, and maybe next time old people will vote for him instead of Le Pen!

Is this a new thing in France? People have been blaming video games and movies in the US for a really long time now

Macron can't run for president again.

Ah, that does explain why he gives exactly zero fucks about any of his work.

I use 1.5x on my Framework 13 laptop (2256x1504) and it works perfectly :) Way better than Xorg, especially when using multiple displays with different scales or fractional scales.

For the mouse cursor, I had the same issue with Xwayland windows until I explicitly setup a cursor theme. Now that works too... and I suspect it was also because of that display scale thing.

Are you using any electron based apps? I find them to be much blurrier when using fractional scaling versus Xorg so I'm running my monitors at native rather than my preferred scale of 125% (2K 16" and 4K 27" displays).

IIRC, vs code supported some extra arguments (--enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland) but this didn't work universally across electron applications and caused very noticeable input lag in others such as Discord.

Yes xwayland just renders the application in the original size and scales it leading to a very blurry experience. Using only native apps avoids it so I find it a little hard to knock wayland instead of say electron or X. This is the issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1318

Pretty common in France too: the tree is néflier, the fruit is nèfle. Disappointed too as I could find this with a simple Wikipedia search...

I've been using BazQux for years and could not be happier with it. Only time I had to get in touch for an issue with a specific feed, it was fixed in a few hours.

Unless you use git reflog.

But you can't run it on GitHub's side.

I'm just a user and I'm pretty happy with Migadu as well. I only contacted them once, and got a reply within a few hours. And a real reply, with technical details, written by someone who obviously understood the question very well.

The webmail is really basic though: it's basically Rainloop (https://www.rainloop.net/) without any plugin.

I think this is a better test:

$ openssl enc --help 2>&1 | grep gcm -aes-128-ecb -aes-128-gcm -aes-128-ofb -aes-192-ecb -aes-192-gcm -aes-192-ofb -aes-256-ecb -aes-256-gcm -aes-256-ofb

(Tested on ArchLinux with OpenSSL 1.0.1.e-5)

Thanks!

I've never understood why so many applications pipe help output to STDERR.

It's not an error... I asked for the output! shrug

Traditionally applications will print usage (which is usually the same as --help) if arguments are missing or invalid flags are given. This is clearly an error condition, and it would be very bad to print the output to stdout in that case. --help will simply call usage(), so there's no difference in behavior. I think it would be feature bloat / overkill to have programs print usage to stdout or stderr depending on how it's invoked, even if it's easy to implement.

It's not even one extra line of code. usage() should take the output stream as a parameter.

Even so, is it really advantageous to have "foo --help" send usage info to stdout, but for "foo -?" to send "Invalid switch '-?'" followed by usage info to stderr?

More importantly, usage information doesn't conform to the structure of ordinary program output, and can therefore be annoying or even dangerous if inadvertently treated as such, so it really, really does belong on stderr for any program whose stdout might reasonably be used as input to another program.

That's a weird, conceptual argument (and program output is not strongly typed). I just want "program --help | less" to work, especially when there's a lot of options.

I appreciate your point, but I still disagree.

> usage information doesn't conform to the structure of ordinary program output

This is weak. Pretty much every command line program will have multiple flags that change the output in some profound way. Why should --help get special treatment?

Mark Jason Dominus did a quick-and-dirty survey on where usage messages should go: http://blog.plover.com/Unix/usage.html

Most people think stderr (so as not to muck up pipelines when you get the invocation syntax wrong). But then there is also the cleverer option of using stdout if and only if the help is explicitly requested, which seems to be justifiable, popular in the survey, but (I think) not much implemented.