PreInternet01

OK, shameful confession time here: I just cannot grasp flame charts, no matter how hard I try. And yes: that's just me, I'm dumb, etc. etc. (and I freely admit all of that, including the et-ceteras!)

I tried to follow along with things that are relevant to my job, like https://randomascii.wordpress.com/2016/09/05/etw-flame-graph... ...And totally failed? I look at the reddest part of the chart, I look at the peaks, and none of that matches the conclusion reached in the blog post?

And then I tried to grok all the knowledge conveyed in https://www.brendangregg.com/flamegraphs.html and... came away similarly confused? Sure, I see patterns, but when asked to identify which of those patterns indicate problems, I would still score <50%?

And, I mean, I do memory/CPU traces like all day every day, and I fix code all the time based on that, but that's all just based on hierarchical bar charts, which are NOT the same as inverted flame graphs, as far as I can tell?

Anyway, thanks for coming to my therapy session, and feel free to leave your helpful-comment-that-will-finally-enlighten-me and/or downvote at the door.

Sure, if you find smoking doesn't reduce your lifespan enough already, subjecting yourself to the additional indignity of flying Ryanair (proud Boeing 737 MAX customer!) should definitely do the trick.

Snort. Yeah, so, back in the late 90s, I met the CTO for ICL (later acquired by Fujitsu, but it was basically what was then left of the 'British IBM'), after evaluating their Visual Basic 5-based front-end software for a day or two, at the instigation of Microsoft UK.

VB5 was not an entirely horrific choice for an UI running on Windows touchscreen hardware at the time, but the project was riddled with basic mistakes, like blocking foreground threads with long-running background operations, and, mostly, threading model mismatches between UI and back-end code (which was all C++, but not the good kind -- and oh, it implemented some weird distributed messaging bus, where you could do just about anything, but nothing really worked, especially not if the ISDN-based network was acting up...).

My recommendation was to upgrade to VB6, which made multi-threaded foreign function calls at least reliable-ish, to re-do the entire calling surface of the C++ libraries accordingly, plus to significantly improve documentation, since literally nobody seemed to know which calls did exactly what (as in: which parameters they required and what they returned) and how to handle retries.

The guy literally listened to me for 30 seconds (possibly less!), then turned around, and told his minions to escort me out and "get someone who understands what we're doing here". Well...

Yeah, not available yet or anytime soon, and if it's anything like the JH7110 eval board I tried last year, it's slower than a RPi4 and has some weird PCIe issues that make M2 SSDs behave badly as well. Plus, mainline Linux support was, and from what I can tell is, nowhere to be found.

This headline makes as much sense as "the Kia Niro is no match for the Volvo FH" -- it really all depends on what you want to do with it?

RPi5 is a great platform for prototyping, and many hobbyist applications, even if you move to ESP32 or similar afterwards, or if you decide that PC-ish platforms work better for you after all.

"One size fits all" has never worked in computing history and most likely never will...

Potato, potato...

> expands lobbying team to influence regulation

Just out of curiosity, is WSJ just editorializing here by re-stating the obvious, or are there actually any other reasons to "expand (your) lobbying team" than to "influence regulation(s)"?

Oh, sure. But for me, the lack of self-awareness in "my command line inputs include extremely sensitive identifiers all the time, and this is fine, if it weren't for your optional AI plugins" is especially grating.

So, like, if I ever happen to execute 'history' in any session of yours that I manage to get access to, I hit the jackpot?

> While an API key and explicit user action were always needed to use AI features, some users asked for an impenetrable firewall for safety and regulatory purposes

Yes, some users are truly experts at driving Open Source developers to the point of burnout.

I use iTerm2, in pretty sensitive environments, where 'OK, you didn't enable this feature', closely followed by 'not that we had Internet access here anyway, LOL' were (though-experimentally, as are all the 'concerns' of 'some users') eclipsed by 'hey, why is it a thing to enter sensitive data on command lines anyway -- should we not have ways to avoid that?'

Counterexample, and the reason why there is so much emphasis on 'software bills of materials' and similar stuff recently: Log4j.

Fully open-source, packaged by many, many open-source (and closed-source) vendors. Had a widely-publicized series of terrible bugs which caused billions of actual losses, as in: "we had to pay to get this remediated and/or had to shut stuff down for a while, and that made us look bad, without anyone to sue."

Reducing that to "let's get rid of insecure, proprietary software" is a take, but not necessarily an accurate or helpful one...

Well, reading https://academia.stackexchange.com/ every now and then makes me pretty convinced this kind of behavior is not confined to China.

The "publish or perish" mindset does not seem to produce particularly healthy results.

So, what I see here, is yet another Open Source creator/maintainer being crowd-bullied into compliance with the (possibly correct, but never-mind) consensus on new features.

It's my personal opinion, not backed by any scientific studies or whatever, that this kind of behavior directly leads to developer burnout, and is, put plainly, toxic and counterproductive.

Note that that particular tool doesn't work very well for modern Windows versions anymore.

Use https://github.com/lucasg/Dependencies instead (even though that isn't exactly up-to-date either...)

If you have Visual Studio installed (and have selected the 'x64/x86 build tools (latest)' in the installer), `dumpbin /dependents` from a VS Developer Command Prompt remains the most reliable option.

Yeah, no, I'm good -- having seen what happened to the ones that came before me, I'm quite happy to limit myself to policing (nah, gardening) my own little corner of the Internet...

> Send an auto-reply telling them they can get their mail through if they copy a code in the reply

Never auto-reply to any email ever. You're only making the spam problem worse.

(Plus, if you think there are not actual persons behind most Outlook/Gmail spam, I've got news for you. They will reply, and beg you for another chance, sometimes in highly emotional terms).

"550 5.7.1 The recipient has set a policy that prohibits email from this sender" at the SMTP level is the only way forward here.

Strict SPF enforcement will get rid of most of the random-IP spam. Then, you'll identify a few hosting providers that actually get SPF right, but are very easy to block based on rDNS or name servers. And then it's really mostly Amazon/Google/Microsoft and assorted transactional/list SaaSes...

The 'digital marketing' and 'mobile app' spam is, in my experience, mostly sent via 'retail' outlook/gmail/aol/yahoo/hotmail.com accounts, and mostly by actual people pasting the address list into the BCC field.

These are not that easy to filter due to the risk of false positives, but in general, a sender with a From: header matching '.*\d{1,}@(outlook|gmail|aol|yahoo|hotmail)\.com`, no To: header matching the actual recipient, and a number of keywords in the message text can be safely rejected as bizdev/SEO spam.

The big-brand spam is actually pretty easy to filter, as there are always 'tells' in the message structure. Even just requiring a match between From: display names and domains yields pretty good results, especially if you normalize the display name to eliminate homoglyphs and nearly-similar spellings.

Sorry, "turning your mailer off" seems outbound-related to me, whereas DNSBLs are typically used for inbound filtering?

And in 2009, filtering inbound SMTP traffic using a popular DNSBL or two was definitely effective (as was greylisting). Alas, no more.

But I probably misunderstand what you're saying?

Interesting, thanks! For what it's worth: my multiple-thousands-of-users mail server hasn't seen any of these Azure tenants in the past 14 days.

You... seem to get a lot of spam! Just out of interest, across how many unique local recipient addresses is this, and how did you determine these messages were illegitimate?

SPF definitely stops most 'stupid' spam (with the second-most valuable metric being EHLO-to-rDNS correspondence). Now, Salesforce and most other non-malicious transactional/list-based SaaSes present other challenges, mostly solved by applying SPF to their content From: header in addition to the SMTP 'mail from' address.

This also involves promoting sender domains from 'DATA reject' to 'MAIL FROM reject' based on behavior, since most spammers see 'MAIL FROM accept' as a win, and won't check any further results.

Yes, Microsoft is very slow in blocking their customers from sending spam, yet very quick in blocking external senders for that reason (same for Google, Salesforce, Amazon, etc. BTW). Funny how that works...

But, if you can, record the `X-MS-Exchange-CrossTenant-Id` header value for the spam you receive. If it ends in 'aaaa', that means it comes from the public outlook.com/hotmail.com service, and you'll need to do text content/from-address filtering to get rid of spam.

But otherwise, deny-listing the GUID you get, will do wonders to eliminate future spam from that source...

Well, mostly from your incoming spam. The header you're looking for is `X-MS-Exchange-CrossTenant-Id`. If it ends in `aaaa`, don't touch it, as that's the freemail-outlook.com, but otherwise, feel free to (test-)reject it.

To get started: 41a71966-4fa6-4839-a87d-034d66bdda33 d931cb4a-3984-4328-9fb6-96d7d7fd51b0 e85f2c00-2730-4ca5-b8d8-609b15bd4746

(all seen-in-the-wild compromised instances in the past 14 days)

If your mail server or appliance still relies on DNSBLs, it's high time to upgrade to a solution that doesn't.

These days, a list of 'compromised Azure tenant IDs' (or domains abusing the Gmail API, or dodgy Salesforce senders: Microsoft is by no means the only issue here) is way more useful than anything source-IP-related...

So, while the loss of SORBS is troubling (I mean: yet another initially-volunteer-driven and widely-used project burning out...), it, like other DNSBLs, is not very relevant to modern spam filtering anymore.

With, like, 80+% of inbound SMTP traffic coming from Google, Microsoft, Amazon and assorted non-malicious transactional/list-based SaaSes, a simple 'I either like or dislike the sending IP' approach has been infeasible for many years.

> you'd only get back your own deleted data

That depends: if the operation was on a floppy you got from someone else, that data might very well be theirs.

> NTFS has a "zero fill" flag

True, but irrelevant: the Windows API guarantees the "seeking to an offset greater than the file length and then writing anything, including nothing, will fill the intervening bytes with zeroes" behavior. How this translates to the underlying file system (which may very well not be NTFS) is an implementation detail.

"If this does not solve all of our problems, it solves none of them" is also a widely known anti-pattern. But, hey, why worry about anything!

Not sure why this is titled "C" at the time I write this: the title of the linked blog post is "New Consent and Bot Management features for Cloudflare Zaraz"

Nor am I sure why it's upvoted 3 times already: posts about Cloudflare abuse management tend not to lead to very useful discussion here...

Yeah, "in order to create a file of N MB, just seek to the offset you need and write 0 bytes" has been one of my favorite pieces of trivia for a long while -- this pattern even survives in Win32's SetFilePointer.

On Windows, the resulting file is guaranteed to have any intervening bytes zero-initialized, but for DOS, that wasn't always the case, and any thus-created file could recycle previously deleted data, especially on redirected filesystems (e.g. LAN Manager or Novell NetWare volumes).

Also cheap: bike insurance, with "we'll drop your new bike within 1hr of you reporting the theft" SLAs. At least, where I live... (and where my last bike was stolen, like, over a decade ago).