This is why I never use these IANA-reserved domains like .test, .example, .invalid, .localhost.
I always make up some impossible domains like domain.tmptest
Otherwise you're one DNS "misconfiguration" away from sending dev logs and auth tokens to some random server.
> Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' mail servers at sei.co.jp, potentially sending test credentials there.
It so happens that in this very specific case your obviously bad choice didn't make anything worse, that doesn't make it a good choice.
"Aha, the defective trucks only cause injuries to people who have their hands on the wheel at highway speeds, but I've never bothered holding the wheel at high speed, I just YOLO so I wouldn't be affected"
If people had used IANA's reserved TLDs they too would be unaffected because although Windows will stupidly try to talk to for example autodiscover.example that can't exist by policy and so the attempt will always fail.
As others have pointed out, using 'tmptest' works until someone buys tmptest -- unlikely, but people will buy anything these days.
I always use the ISO-3166 "user-assigned" 2-letter codes (AA, QM-QZ, XA-XZ, ZZ), with the theory being that ISO-3166 Maintenance Agency getting international consensus to move those codes back to regular country codes will take longer than the heat death of the universe, so using them for internal domains is probably safe.
You can also safely use .home .corp and .mail as those have been explicitly rejected by ICANN on the basis that they would cause widespread naming conflicts. I have my devices configured to redirect queries against .home to a local nameserver, leaving .local open for avahi.
According to it, it seems that if someone registers autodiscover.com then example.com lacking autodiscover.example.com will make Outlook try checking if autodiscover.com has an entry.
Would that really make a difference in this case? It's a configuration error / bug in Microsoft's discovery server, they could have a fallback that goes "any unknown address, return this .jp address".
From what I understand they basically couldn't scale writes in PostgreSQL to their needs and had to offload what they could to Azure's NoSQL database.
I wonder, is there another popular OLTP database solution that does this better?
> For write traffic, we’ve migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB.
> Although PostgreSQL scales well for our read-heavy workloads, we still encounter challenges during periods of high write traffic. This is largely due to PostgreSQL’s multiversion concurrency control (MVCC) implementation, which makes it less efficient for write-heavy workloads. For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version. Under heavy write loads, this results in significant write amplification. It also increases read amplification, since queries must scan through multiple tuple versions (dead tuples) to retrieve the latest one. MVCC introduces additional challenges such as table and index bloat, increased index maintenance overhead, and complex autovacuum tuning.
That would mean it improved somewhat. We always got better write performance from mysql vs postgres, however that is a while ago; we then tried tidb to go further but it was basically rather slow. Again, a while ago.
When did you get your results, might be time to re-evaluate.
It was 1 year ago. Around 15 tikv serves, 32 cpu, 128 ram each, 4 tb nvme. In this case latency matters a lot. When i had load server in different region with ping of 3ms I got 70k inserts, when moved to the same region with sub ms ping it went to thousands
I was thinking about the same paragraph because write-amplification is exactly the problem solved by LSM trees _and_ they already have a solution for that in-house - one of the first acquisitions that OpenAI made is Rockset - a company that actually built the RocksDb at scale.
So, this is the part that actually made me left wondering why.
> This is not an improvement on existing methods... a case of it being all they have to work with.
But the article says Tilapia skin is better in multiple aspects:
> "We got a great surprise when we saw that the amount of collagen proteins, types 1 and 3, which are very important for scarring, exist in large quantities in tilapia skin, even more than in human skin and other skins," Maciel said. "Another factor we discovered is that the amount of tension, of resistance in tilapia skin is much greater than in human skin. Also the amount of moisture."
It says it's different to human skin in multiple aspects.
Do I need more collagen or more moisture in my skin? I would expect evolution made some pretty good choices around default human skin for typical human activities, and if more moisture was obviously good, I would already have it.
Maybe tilapia skin is better for people who spend 24 hours a day swimming in lakes.
> It says it's different to human skin in multiple aspects.
No it says "even more than in human skin and other skins". Not different.
> Do I need more collagen or more moisture in my skin?
For this context? Yes? Clearly the article answers that already. I even included in my first reply but you'll have a third chance to read it:
> ...which are very important for scarring...
And your attempt to move the goal post fails miserably as well. Or do you think humans evolved to perfection by thinking this:
> I would expect evolution made some pretty good choices around default human skin for typical human activities, and if more moisture was obviously good, I would already have it.
I don't think you are debating in good faith. Good luck.
Funny, but I wrote some environment initialization and setup scripts that you just unzip to a new dev desktop, and run the first powershell script, and it will work through (have to reboot after a couple installs), but it goes through, then once WSL is up, it'll rely on the /mnt/c/ paths to run bash scripts to initialize the wsl environment too... was pretty handy.
You can turn all the interop and mounting of the windows FS with ease. I run claude in yolo mode using this exact setup. Just role out a new WSL env for each claude I want yoloing and away it goes. I suppose we could try to theorize how this is still dangerous buts its getting into extremely silly territory.
reply