See my comment in the main thread for an example. In a worst case scenario, some data is simply too "frizzy" to index/search efficiently and with good performance in a B-tree.
"The deeper the tree, the slower it is to look up elements. Thus, we want shallow trees for our databases!"
With composite indices in InnoDB it's even more important to keep the tree streamlined and let it fan out according to data cardinality: https://news.ycombinator.com/item?id=34404641
I believe OP is asking for a before/after of Apple Maps, because just seeing the map now isn't telling us whether Apple previously disclosed the villages and towns. I'm sure OP isn't thinking that the region is full of random roads out in the wilderness leading to nothing, which is the wrong conclusion the downvoters are probably leaping at.
In my experience they will mark your e-mails as spam for no sound reason at all. I run my own MX, for myself personally, and my e-mails to friends using Gmail regularly gets classed as spam as soon as it's been "long enough" since my last mail. My MX does everything by the books, ticks all the boxes, never ended up on any DNSBL etc. Their behavior is effectively a form of systemic sabotage.
Yes absolutely this. I've put so much effort into making sure I tick all the boxes and yet I constantly wonder if my email is getting delivered. This feels anti competitive to me. It's Google constantly telling me, give up, you know deep down you should just use Gmail.
we switched email providers from our all-EU stack to gmail... just as a last desperate attempt at not being marked as spam for actually sending low volume (crazy, right).
well, now we're stuck with gmail for a year, and no, it haven't improved anything!
I've been running my own MX for my business for a couple decades. I've never had trouble with Google. Apple on the other hand...as expected are not accommodating to anyone operating outside of the Apple garden. They don't even do DMARC reports, and just point you at their policy page with no indication of why they reject some mail to icloud addresses but not others. I will say I have received specific feedback from a human at Apple after submitting an email and waiting about a month for a response. But it was shocking in how braindead and years-out-of-date their reason was for blocking some (not all!) emails from our domain.
Actually the absolute worst are the rinky dink "free email" hosting that is bundled with some cheap web hosting services, where they use the UCEPROTECT block lists. UCEPROTECT is basically a protection racket where they expect you to pay to be removed from their blocklists, and they are often the one and only blocklist a domain or IP will appear on (which indicates it is likely a false positive money grab)
Agreed. I spent a lot of time programming the GBA in the early 2000s (back when the state of the art devkit was a flash cartridge writer with parallel cable...) and I consider it the last "grounded" console that Nintendo made, where you immediately and directly get to touch hardware right off the bat, without any gyrations. After having worked with the SNES in the 90s the GBA was a very familiar and pleasant platform to experience, in many ways similar to and built upon the SNES' foundation.
I've never coded for SNES, but the GBA having access to a mainline, modern C compiler is a massive buff. Also, emulators for it have always been available on practically any computer, console and mobile phone, and there's many so-called "emulation handhelds" that bring its (and similar) form-factor handheld devices to the market. If you really need an upgraded OG experience, many upgrade kits for the handheld exist as well.
None of this fixes the audio, but it sure gets damn close.
Just curious what you mean by "fixing the audio"? In GBA emulation or on the hardware?
I'm aware that if you need/want PCM audio, there's going to be mixing, probably with a software library, and significant CPU use for it. Is emulated GBA audio buggy?
One of my first gigs was Game Boy and Game Gear programming. I know the GBA allows DMG audio compatibility and, with all its constraints, well it sure does keep things simple. And emulation is reliable AFAIK.
I see what happened, I was replying to a different comment, that did mention the GBA audio, when I wrote that, but somehow ended up replying to this one.
I sadly have to agree. The damned thing struggles with a handful of basic stuff, it still has a config UI of which you can't tell head from tail, complete with teeth and whiskers and even a full "about:config" panel à la Firefox hidden underneath. Spell checker. Calendar. Chat client. Complete web-browser internals, with grindy disk-caching. To add insult to injury, the macOS bundle is half a fxxxing GiB in size (universal flavor, but still).
In my experience running my own MX, greytrapping hasn't been an efficient countermeasure for well over 15 years at this point. Spammers have endless constitutional resources. The botnets they wield, too, are endless resources. It costs them not a dime to do everything by the book and keep retrying - and surely everyone (besides the author) must have noticed by now that they keep sending more and more spam instead of giving up for good. This reality itself is at odds with the ridiculous idea that delaying a malicious MX would somehow cause the operator to take a new career path.
But it costs us a lot to keep waiting forever for important and legitimate e-mail. Arguments like "twenty-four hours is short enough to not cause serious disruption of legitimate traffic" and "we already know that spam senders rarely use a fully compliant SMTP implementation to send their messages" are 20 years out of touch and completely void of connection with reality. They use OpenSMTPd, Dovecot and EXIM like everyone else. They have FCrDNS, SPF/DMARC records and a valid DKIM setup like everyone else. "I'll send you this important e-mail and hopefully it finds its way to you by tomorrow." ...Seriously? How many millions of repeated e-mails would such a baseline incur globally every month? "You didn't get it? But I mailed it already an hour ago. I'll try sending it again." Everything about the author's reasoning around greytrapping is long past expiry.
> Arguments like "twenty-four hours is short enough to not cause serious disruption of legitimate traffic" and "we already know that spam senders rarely use a fully compliant SMTP implementation to send their messages" are 20 years out of touch and completely void of connection with reality.
Just recently I found out a very prominent local service recovery emails are not delivered to the end-user mailbox.
Reason? The email doesn't have Message-ID. Like it get's generated, sent out, "my" PMG box receives it... and throws it out because no Message-ID. Insult to an injury? It was password recovery emails. Regular marketing ones are going through.
Doesn't that depend on when they acquired the gold and at what price? It has roughly tripled in just 10 years, and increased tenfold since the early 2000s.
reply