PreInternet01

It's not a SwitchOS (which can and should be ignored) versus RouterOS issue, more that Mikrotik is limited by the capabilities of the off-the-shelf switching SoCs they have to use due to their size.

Once you run into limitations there (which can already be due to something like "needing to use VLANs"), it's all CPU-based, which isn't necessarily a problem (the amount of switching performance you get out of a Tile-based 'router' is pretty amazing).

The most interesting piece of documentation about any piece of Mikrotik kit is the block diagram, followed by close reading of the L2/L3 offload docs...

Yes, it does have hardware offload, but that works better in theory than it does in practice. (For doing line-rate NAT with more than a handful of clients, it's not an option, mostly because of the state table limits already mentioned in a sibling comment).

"Will the hardware offload actually do anything useful?" is a time-honored Mikrotik game: see the sometimes surprising limits at https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offlo...

Quick note on the CRS312: while absolutely lovely as a switch, you have to be careful about what exactly you want to do with it, as, as with the entire Mikrotik range, it can do absolutely everything (provided you can wrap your head around the configuration), but isn't necessarily good at it.

In the case of the CRS312, its potato-class CPU means that even NAT at 10Gb/s can be challenging. However, if you pair it with something like a CCR1036 (discontinued, but still available and sporting a 36-core CPU) or its successor, the CCR2004 (or even something like the RB5009UPr, which adds PoE, but is limited to 2.5Gb/s) you'll be all set.

Full disclosure: after a week of various things happening to me, the CrowdStrike thing was not a thing that affected me.

I don't feel better, worse, or, basically anything because of that fact.

And no, none of the options switch to Linux, evict all security vendors and/or go and live on an island (tempting though the latter is) would have made anything any better, thank you for (not) asking...

The "cyber sector" is... awful? Nah... irresponsible? Nah... immature? Yeah, probably!

Right now, pretty much everyone is looking to outsource their "security" to a single vendor, disregarding the fact that security is not a product, but a process.

That... won't change! And incumbents will get less-awful about their impact on "protected" systems.

And yet, there's an opportunity here! Do you truly understand Windows? And whatever happens on that platform? And how to monitor that activity for adverse actions? Without taking down your customers on a regular/observable basis?

Step right up! There are a lot of incumbents facing imminent replacement...

Yeah, you're right, and I totally missed that on my first scan, probably due to being blinded by the huge hex conversion chart...

Oh, well, having DTAG removed from the Firefox and Chrome/Windows root stores would be... oddly satisfying?

I know that in the US, ISP-wise, mostly Comcast has a bad reputation, but in the EU and from a business perspective, Deutsche Telekom is also not, eh, universally liked...

Yeah, or, see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4927102/ ("Is Butter Back? A Systematic Review and Meta-Analysis of Butter Consumption and Risk of Cardiovascular Disease, Diabetes, and Total Mortality")

TL;DR as well as hot-ish take: whether your diet is healthy or not doesn't actually depend that much on the quality of your baking fats. Oil, butter, margarine, whatever: it's more about quantity than quality.

And of course, truly bad products will damage your health (so, yeah, glycol-infused oil is way worse than any butter, and vice versa), but otherwise: just use what the recipe says, and enjoy in moderation...

On the one hand, the Z80 was indeed a CPU you could easily wrap your mind around, on the other hand, similar sheets exist for Intel chips (from the same author: https://vtda.org/docs/computing/MicroLogic/MicroLogic8086&80...), so maybe the differences between architectures aren't as stark as we like to think?

Having said that, I'm not sure how actually-useful this particular reference card is: huge hex conversion table, but no instruction timing chart?

Anyway... pure nostalgia caused me to go through an old Z80 assembly book just now ("Advanced Spectrum Machine Language"), and I found some code I wrote a good 35 years or so ago: https://ibb.co/fvqtwkQ

This was printed on thermal paper (not sure about the printer model: I don't think it was the original ZX Printer, as that used differently-sized paper), so sort-of impressed it survived that long (most printouts I had from that time long faded). As to why I wrote the code or what it does: I think it was to create an animated tape loading screen, but...

Alternatively, do use Excel for data analysis, but instead of opening CSV files directly in Excel, create a new blank workbook, then go to the Data tab, select From Text/CSV, and follow the prompts, which will allow you to preview your data and select proper data types for each column.

This will avoid all the issues alluded to here. And yes, I know that it's stupidly simple to go the wrong route, but I also think by now people would be wise to all of this, since the proper functionality has only been there for a decade or so. But, hey, apparently total helplessness keeps getting clicks.

Well, CA wines are, on the whole, ridiculously overpriced.

A lot of people moved in on that, making it not entirely unlikely that supply now outstrips demand?

Same thing happened in various regions in France at various points in time. The viable plots will be reclaimed at some point, and make some fine wines in the future, except possibly not at the price point the original owners had in mind...

Well, SO is now (possibly was?) owned[1] by the same group of companies[2] that failed to secure their own TLDs[3] for purely technical reasons, so, before nefarious intent, please also consider plain incompetence....

[1] https://techcrunch.com/2021/06/02/stack-overflow-acquired-by... [2] https://www.google.com/search?q=prosus+multichoice [3] e.g. https://www.icann.org/en/registry-agreements/terminated/mult...

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

Powershell, Get-AppxPackage *Microsoft.WindowsNotepad* | Remove-AppxPackage and get on with your life. It will restore the legacy notepad.exe (as will, like, right-clicking the new Notepad in the start menu and selecting Uninstall) -- but yeah, I know, you didn't opt in to this, <insert rest of generic Microsoft-related HN complaints here>

Well, then maybe write a blog post explaining exactly what happened here and submit that?

Because, even having re-read the article you linked, it does not support the conclusion that "[an] exchange[...] was totally ruined because of [weak isolation]" at all?

The submitted title deviates from that of the linked post ("Do we fear the serializable isolation level more than we fear subtle bugs?") and, having read the source, I'm not even sure if it's even close to accurate...

Well, the C-130 has been pretty much everywhere pretty much forever -- not sure if anyone in the military in the last 5 decades or so has not been in and/or near them at some point?

My Mi-26 experience was as a staff tech (military, but as part of a humanitarian effort) airlifting medical trucks into a flood-struck area in India, like, 30 years ago or so, but as I understand it, they're still used pretty widely outside NATO, even today.

I can't say anything about the Mi-6, but its successor, the Mi-26, definitely isn't that loud. Definitely "huge transport aircraft" loud, but not "C-130 loud" (where, if you sit just behind the forward bulk head, kidney stone removal is an automatic benefit included with take-off)

Au contraire, plain text is just about the only format for logs that works. Having to use some obscure tool to query logs just isn't worth it, especially not in 20 years time, when you still need to analyze said logs but the tool doesn't even run on any contemporary systems anymore and the documentation about the binary format has been irretrievably lost.

And yeah, sure, you want to use structured logging. So, in addition to the greppable log message, include a Magic Separator Character (say, \t) that you treat as 'end-of-line' in human-oriented processing, and have your key-value-pair structured data following that for automated tooling to have its way with. Or, be really creative with [key=value] blocks that are both human- and machine-readable.

Some of my most painful logging experiences were having to extract application logs from binary blobs created by a proprietary Windows tool (no, not the main Windows event log: that's bad, but at least documented). Even the most recent versions of the official viewer just crashed, the vendor was not interested in fixing that (since we were not a customer, just a third party in need of log data, but even an offer of a modest payment was met with indifference...), and the actual format turned out to be byzantine beyond words.

So, yeah, give me plain text all day, every day...

I think people should take a step back here, and meditate a bit on what "disclaimer of warranty" means.

All of the popular open source licenses, GPL, MIT and BSD, quite plainly state that, to the extent permissible by law, there is no warranty about anything, whatsoever.

There was a time when Linux users (in general) understood this. You want free? You pick any distribution you like. You want a warranty? You pick RedHat.

But over time, it seems we've gotten to a point where "I imported your package, so that means you're obliged not to break my precious CI" has somehow become the norm.

This is bad for open source, and, frankly, bad for everyone, and I think it's high time that people start taking responsibility for their dependencies, either by paying for support, or by maintaining their own bugfix branches...

As the article correctly states, writing a book is a good idea for many reasons, but generating income isn't among those.

My personal experience: during the golden days of the technical book market, a good 15-20 years ago, writing a chapter would net you $1500 (for, like, 2-3 weeks of work, better pay than a magazine article that would take approximately the same time but pay a bit less) an entire book maybe $25K, but that would take you at least 6 months to complete.

Of course, that was just the upon-completion payment, with the promise of later royalties if the book did well, but, unless you were very lucky, that pretty much never happened.

Still, a payment of $2500-in-todays-dollars for less than a month of work isn't entirely bad, and being a published author did have its perks for getting consulting gigs.

But these days, "a magazine or book deal that pays actual money" just isn't a thing anymore, so, yeah...

Intel T14 Gen5 works fine: with Windows 11 and the 'Best power efficiency' preset, you'll pretty much forget the thing even has a fan.

Ah, OK, so there is a graph, where magnitude is meaningless, colors are meaningless, runtime is relative, yet, with "enough domain knowledge" you can "see where the problem is right away"...

I'm pretty sure we're done here.

> Record::hasVariable takes a long time

As does Memdata::Cache::getVarsByName[blah] right above it, and many functions below (unsurprisingly, but still...), and they all have pretty much the same width and color.

The point of flame graph proponents is that "you see where the problem is right away."

My question is: "how, exactly?" And the answers so far seems to be mostly... lacking, to the point that I now officially declare flame graphs a cargo cult that is in no way superior to my "hierarchical bar charts" religion...

> Probably the simplest way to use the flame graph is work from the bottom of the flamegraph and walk upwards until you find something interesting you optimize

OK, so going by what is apparently the 'simple example' in the linked article: https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc...

I work my way up. First thing that is really red is Conversion::Process::Run, but that probably wraps a lot of things, so I keep going up.

Next is Cps::Editor::relate_edits, or possibly EditingAPI::Rules::countPeopleMatching, because it's a darker red?

And then there is another red-ish function, followed(?) by some yellow-colored (and thus unimportant?) stack entries, and then the apparent culprit: Record::hasVariable.

So, and I'm truly not trying to be difficult or argumentative here: how was I supposed to pick out 'Record::hasVariable' right away from 'https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc...'?

The first function that is red being called from yellow-colored functions with about the same duration (width)? And if so, why is Metadata::Cache::getVarsByName not a more likely optimization target?

By the 'simple example', I assume you mean https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc...?

If so, the widest, reddest, and highest-magnitude function I see there is __int__malloc. Right?

Yet, reading on, it seems that has nothing to do with anything, and the actual culprit is Record::hasVariable, which is somewhere in the middle of the graph, and not any redder or less red, or wider or less wide, than many other functions.

So, looking at just the first graph, how am I supposed to immediately spot the culprit?

Yeah, I imagine it, and still don't see how the flame graph would help?

Shown as a hierarchical bar chart, this would suggest 'b' is problematic.

Where, color-wise (because peak-wise, 'c' would be the culprit here) do I see this issue in a flame graph? Because I fear that either 'main' or 'a' would have the most dominant shade of red here?

> Did you read the linked article?

From https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article"

And yes, I did, and I truly don't grasp even the 'simple' explanation. I already admitted I'm dumb.

Do you have anything to add to the discussion?

> I think flame graphs, like all graphs, are more helpful when the reader has a lot of context about what's supposed to happen, or some intuition about how the chart is supposed to look.

Yeah, and then your comment... just ends? So, what I get here is that, in a flame graph, the reddest part isn't the most interesting, and neither is the widest part, nor the part with the most peaks.

So, what, exactly, am I looking for? "You know what this graph should look like in case all was OK" is not exactly helpful, right, because I might just lack that baseline?

Well, thank you for pointing out that hierarchical bar charts do a pretty good job at showing the hot path.

So my (and I guess your) workflow is then to fix the top-X hot paths, and then re-profile, etc.

The attraction of flame graphs, as I understand it, is that you can get the same information without the need to iterate. Which is obviously very valuable if you're operating on single-shot bug reports, but... how exactly? (Not a question directed at you, obviously, but more towards the general discussion)