massaman_yams

Yeah, with a CV strip the Mean Wells with CC dimming have an abrupt shutoff at low brightness - maybe 5% (I haven't measured it), and a brief flash upon increasing brightness just above that threshold. Otherwise they work reasonably well for my use case.

Thanks for the additional recommendations.

Mean Well has some constant current dimmable 24v power supplies with zero flicker. You'd need 2 if you want each strip to be independently controllable. They also can take a PWM signal if you're so inclined, but I bought them because I prefer flicker-free dimming. e.g. https://www.mouser.com/ProductDetail/709-HLG40H-24B

Can you think of a scenario where a well-intentioned organization doesn't realize they're sending some unwanted mail, and by looking at the right metrics they realize they have a problem and take steps to fix it?

Speaking from quite a bit of experience, content can matter at Gmail if it's very obviously malicious/spammy, but not usually otherwise. Metrics matter more than content at gmail.

For other filters/ISPs, content can matter a bit more, but as a general rule for consumer mailbox providers, metrics are the primary thing that affects filter outcomes.

I deal with email at global scale, and yes, you're a fringe case. There are many billions of messages sent every day which have lots of links, and which recipients in general are interested in, and want delivered to the inbox (or promotions), rather than spam.

You're correct that a lot of senders have no idea when they're sending unwanted email, and that unwanted email is well within the realm of possibility here. But don't assume DOI is a panacea; you can use DOI and still send unwanted email. It can improve quality metrics (fewer bounces), but engagement metrics are a much stronger signal, especially for gmail.

Gmail is subject to specific targeting by spammers in a way that fastmail is not. The returns for spending weeks or months finding a niche way through Gmail's filters are justified by the number of gmail addresses that can be targeted, which is probably 3 orders of magnitude larger than the total number of fastmail subscribers.

Prefect, dagster, or maybe one could argue google cloud composer is different enough from vanilla airflow that it earns a spot on this list?

But you're right, Airflow is still the de facto standard, there's just increasing awareness of pain points with it.

Another comment suggested an extra rinse cycle.

It's not the only ambiguous wording in the post; the math doesn't add up here. It's probably a peak of 254 million/hr.

"during Black Friday processed a whopping 254 million emails every hour and 3.3 billion during the day"

Table S3 here[1] starting on page 9 appears to show nearly 80 different genuses within stool samples after filtering out "vegetative (non–spore form) bacteria, fungi, parasites, and viruses" [2]. No word on how many strains per genus, but reasonable to assume multiple, if not hundreds in some cases.

[1] https://www.nejm.org/doi/suppl/10.1056/NEJMoa2106516/suppl_f... [2] https://www.nejm.org/doi/full/10.1056/NEJMoa2106516

It's not quite clear if this is cultivated or not but I know this MD was working on cultivation at one point. "SER-109 is composed of approximately 50 species of Firmicutes spores derived from stool specimens from healthy donors."

https://academic.oup.com/jid/article/214/2/173/2572105

Diet alone can't restore strains that don't exist in a patient's microbiome.

Yes, it's clear Gordon has applied a mastering limiter to the tracks he delivered to Bethesda, and given that the style of the music involves heavy processing/effects and multiple levels of compression, a somewhat aggressive mastering limiter seems appropriate here.

But your point about "increased dynamic range" due to the editing errors is a distraction from your claim that Gordon applied a mastering limiter (which he clearly did). It creates ambiguity, because you're using it in a way that's not aligned with common usage in this context. That's part of why you're getting pushback.

In any case, if we want to try to answer the question of why the OST has low dynamic range (in the mastering limiter sense), I am somewhat receptive to ndepoel's argument - it seems reasonable that in-game tracks could be mastered more aggressively, and with lower dynamic range, than what would be appropriate for a proper OST release. Caveat: I haven't done mastering work in the context of game audio so I can't say if that's common practice, but it seems a little more likely than not.

Now, applying a mastering limiter to sub-tracks? Extremely novice mistake, and could be described as brickwalling. Certainly within the realm of possibility given the novice quality of the editing here.

"Brickwall" limiting is about very short-term transient compression; to oversimplify things, those limiters are operating at the timespan of 1-30 milliseconds, more or less.

These edits are a few hundred ms to a few seconds at a time, so it doesn't make sense that Gordon would refer to them as "brickwall".

(Another problem here is that evaluating a mastered waveform's dynamic range by eye is extremely subjective, and I would argue next to useless most of the time. The way these waveforms are shown in the post, we'd be hard-pressed to tell 9db (hyper-compressed) from 14db (pretty good) by eye. Professionals have software and metering to measure this; that's a much better approach.)

Bottom line: do these clumsy edits contribute to brickwalling? Really doesn't look like it, but I don't have the raw files to measure to know for sure. Are the edits good? Not in a million years.

You're making an extremely pedantic distinction, which is only correct in a purely technical sense. Which is the worst kind of correct.

Yes, mastering engineers work from track-level dynamic range (usually achieved with slow-response compression) to transient-level dynamic range (fast compression/limiting), and the range in between. When the context for this discussion is about "brickwall limiting", we're talking about very fast, transient-level compression, and your comment mistakes slower dynamic range for the transient-level dynamic range everyone else is discussing.

So, no. In this context, what you're talking about isn't increased dynamic range.

Delivering to gmail is unpredictable when you try to send from IP space with unmanaged or poorly-managed IP range reputation, like most low-cost VPSes or residential ISP IP space.

Incidentally, I'm pretty confident the same filtering engine runs both gmail and google workspaces spam filters. Perhaps with some minor differences.

If you're paying for an email service from a respected provider like Fastmail, they almost always have professionals managing IP range reputation, so gmail delivery ends up being significantly more predictable. Make sure you set up DKIM/SPF if you're sending from your own domain.

The reasons Gmail's filters tend to generate complaints that surface on HN is:

  1) IP range reputation can frequently be a stronger spam signal than individual IP reputation  
  2) Most people aren't aware how much of an impact IP range reputation can have on delivery  
  3) There's no way to publicly check IP range reputation with gmail

Some commenters here also significantly underestimate the challenges and complexity of running spam filters at scale.

Disclaimer: I don't work for google or fastmail.

Is it getting harder to self-host? Yes. Impossible? No. Most senders just find it easier to pay for it.

Exceptions to the rule do happen; I'm sorry your experience was the exception. Dealing with that kind of thing can be quite a pain if you're not experienced with it.

But again: "If you find yourself in an IP range involved in a severe, ongoing, high-volume spam scenario that's affecting your delivery, then it means your provider is not managing IP range reputation, or not doing it very well, and you should vote with your dollars and move somewhere else."

This is not my system, to be clear, but you might be surprised how little 20 years of data matters to filter accuracy, empirically speaking; recent sending behavior carries orders of magnitude more weight.

The overwhelming majority of legitimate mail will never see anything remotely near a 14-day block. Again, it's reserved for severe, ongoing, high-volume spam scenarios; ISPs use other methods like short-term deferrals for more common/less severe problems.

If you find yourself in an IP range involved in a severe, ongoing, high-volume spam scenario that's affecting your delivery, then it means your provider is not managing IP range reputation, or not doing it very well, and you should vote with your dollars and move somewhere else.

As a rule of thumb, email-specific service providers tend to do a better job of managing IP range reputation than more general purpose providers like VPSes.

> "... small non-spam senders would congregate" Congratulations, you've invented the email service provider. Most small non-spam senders don't want to spend the time figuring out IP reputation, DKIM, or SPF already, so they pay someone to do it for them. What makes netblock reputation different?

Reputation isn't public because then spammers game it and you get worse filtering outcomes. ISPs learned this the hard way.

As a practitioner, I can tell you that this proposal would be quite a bit behind state of the art for email spam filter accuracy. For example, there's a surprising amount of legitimate mail that gets sent without authentication, and which you don't want to block because your end users will get mad if it goes missing.

I may also point out that "reputation scoring for netblocks" is the exact problem the original blog post was complaining about. He was trying to send from residential ISP and VPS netblocks that had poor reputation, and saw delivery problems as a result.

I am not a Google employee, but I do work with email anti-spam at scale. There's a lot to critique here but it boils down to three points:

1. Spam filter behavior has changed because spam has increased in volume and sophistication, not because ISPs want to save money, or to eliminate competition. Some techniques that worked well 5 years ago aren't as effective anymore. One of the consequences of this has been a reduction in the value of IP reputation, from a spam signal perspective, particularly for low-volume IPs.

2. IP range reputation does matter. The increase in the value of IP range reputation, as a spam signal, has paralleled the decline in value of low-volume IP reputation. In practice, this means you need to either send enough volume to outweigh the reputation of your IP range (exact quantity varies based on a lot of variables, but as a very rough approximation, 1000 messages a day), or find an IP range with good reputation.

IP range reputation is not easy to assess, sometimes even for email professionals. So you can either gamble with a residential ISP IP, or a VPS IP, or you can find a provider that spends time, effort, and expertise on managing IP range reputation. The practical solution for most senders is the latter. Many of these offer a free tier, and many options are available among providers of all sizes.

3. The filtering behavior reported here is either misunderstood or misrepresented. First, no, no major ISP (Gmail, Yahoo, Microsoft/Outlook, icloud) is going to permanently block an IP range; filters are designed to be dynamic. In severe, ongoing, high-volume spam scenarios, you could see a 2-week block, maybe occasionally 30 days. But never "one strike".

Mail deletion without a bounce also cam happen, particularly at Microsoft, but again it's almost never seen for legitimate mail - that response is reserved for long-term, severe spam scenarios, where anyone reasonable would agree that a block is warranted. And, again, this is dynamic.

So it looks like OP is either exaggerating, or has been trying to send from IP ranges with unusually bad spam problems.

I might be reading into this a little, but you seem to be arguing that "Spam is a reasonably solved problem at my scale, therefore spam is a reasonably solved problem at global scale", and those are very different things. One of the key differences is: a small domain like yours is multiple orders of magnitude less attractive of a target, vs. Gmail, and as a result Gmail's filters are subject to constant, high-volume adversarial attacks, and you are not.

SPF and DKIM are pretty explicit in their RFCs that passing authentication isn't a sign the mail is legitimate. The presence of passing auth in a message does change how filters should handle it, but for most larger-scale production filtering systems (not spamassassin) that mostly ends up as "change the weight of certain reputation identifiers in the spam filtering inputs", more or less.

This happens at stunning scale; there are probably several billion messages a month sent via malicious form submissions globally, by my rough semi-informed estimate. (That includes other types of abuse than the one you mentioned.)

Perhaps this is bias from dealing with that kind of spam on a regular basis, but my current position is that a captcha needs to be present any web form which can even indirectly or occasionally result in an email being sent.

Can confirm. Async bounces make up somewhere around a few percent of overall bounces for most senders.

They're not actually providing it themselves - Aiven actually runs the backend. Seems like that points to it having some longevity.

https://kb.timescale.cloud/en/articles/2752585-timescale-clo...

cuDF has supported Dask for distributed processing for a while now, maybe a year or two?