ancarda
Joined 13 years ago
Karma
2,456
Submissions
861
Member since
Feb 10
Recent submissions
Comment · 9 months ago
Comment · 1 year ago
I really hope this is going to be entirely optional, but I know realistically it just won't be. If Rust is any example, a language that has optional async support, async will permeate into the whole ecosystem. That's to be expected with colored functions. The stdlib isn't too bad but last time I checked a lot of crates.io is filled with async functions for stuff that doesn't actually block.
Async clearly works for many people, I do fully understand people who can't get their heads around threads and prefer async. It's wonderful that there's a pattern people can use to be productive!
For whatever reason, async just doesn't work for me. I don't feel comfortable using it and at this point I've been trying on and off for probably 10+ years now. Maybe it's never going to happen. I'm much more comfortable with threads, mutex locks, channels, Erlang style concurrency, nurseries -- literally ANYTHING but async. All of those are very understandable to me and I've built production systems with all of those.
I hope when Zig reaches 1.0 I'll be able to use it. I started learning it earlier this month and it's been really enjoyable to use.
Comment · 1 year ago
It's likely because there's a citation in a paper. That's apparently the bar you need to reach to get Wikipedia to see something as significant enough. I tried to get a draft article about SourceHut ( https://sourcehut.org/ ) to be published after extensive improvements and they refused because there weren't enough third party links. This is despite the fact there's like a dozen pages in Wikipedia about software that is hosted on SourceHut, so it seems notable enough?
Comment · 1 year ago
Are you running the long-term (6.x) branch? RouterOS 7.x (stable) is much better at IPv6 as far as I know.
Comment · 1 year ago
When was the last time you tried? I used to run into issues too but for a few years now it's basically "just worked".
Comment · 1 year ago
Oh this hurts a lot. I don't know of a good alternative to this website. Other sites I've found either run fewer tests (so are less useful for debugging) or incorrectly claim I don't have IPv6 (I do?).
I don't suppose we can donate some money to keep this website up? Or perhaps some company like CloudFlare would like to host a mirror?
Comment · 1 year ago
We're slowly making progress. We're almost at 50% IPv6 worldwide traffic to Google: https://www.google.com/intl/en/ipv6/statistics.html
Depending on what country you're in and what your traffic patterns look like, it might be higher. Some countries are >70% IPv6 traffic to Google.
Do you ever check your access logs to see when you're ready to go IPv6 only?
Comment · 1 year ago
Yes and Finch wasn’t sure if what team Machine had done was a good thing, which is interesting given he’s usually so sure about resisting Samaritan
Comment · 1 year ago
I don't think it's unrelated at all. I saw the same picture and just closed the tab right away. Why should I read this article, the whole thing might be written by an LLM.
Comment · 3 years ago
Sorry, I don't have an iOS device, so I'm not sure. The only mention I could find on the website was: https://www.migadu.com/guides/gmail_android/
> While Gmail is an IMAP client app, it will not check for new mails continuously. Not only it does not support IMAP Push extensions which are standard nowadays, but the [most] frequent polling interval is 15 minutes
Which I guess implies they offer IMAP push, since they're expressing disapproval that the Gmail app doesn't support IMAP push
Comment · 3 years ago
I was a happy FastMail customer for years, but lack of IPv6+DNSSEC was also disappointing for me. I eventually heard about Migadu ( https://www.migadu.com/ ) which has all that, and AFAIK, EU servers as well.
The only downside for me is the web UI isn't nearly as polished as FastMail.
Comment · 4 years ago
I don't know a lot about C or the internals of OpenSSL, but going by the commit message, does this mean we should disable TLSv1.3 until we've had a chance to patch OpenSSL?
Edit: Actually, reading through the code a few times, maybe TLSv1.2 should be disabled?
I really wish we had some way to protect ourselves until the patch is widely available.
If you go up to https://help.kagi.com/orion/ it has this description:
> Orion is a free, lightning-fast, privacy-focused, WebKit-based browser for Mac, iOS, and soon Linux that blocks ads and trackers by default.