mrngm

Probably trace_log (we had a similar experience), but you'll only notice with limited storage space, and a regular keen eye on how your database fills up.

Unfortunately, even domains that did not have DNSSEC enabled earlier today are affected.

We observed issues on a non-DNSSEC .de domain at 19:45Z and confirmed around 20:12Z it wasn't just us, but also more high profile domain names.

If you have individual request logs with timing infomation, you could construct that afterwards. It does take some effort to have an effective way of displaying these metrics. Where would you put an individual request that took 532ms and started at t=34.682s? Would you align all requests that started in the 34th second at t=34s, or look at completion time (ie within t=35s)?

Would you rather see "number of requests started at this ms" (you seem to suggest this), or is something else more interesting?

I think a sort of Gantt chart that plots duration of requests as well as starting time within the time span (e.g. a second or more) might be very informative. Each individual request on a different position on the Y axis, time on the X axis. Perhaps you have some bound on requests in flight, that could be the height of the Y axis, so you can easily see calm or busy periods.

At least our observability stack doesn't show this level of detail, but it would be very interesting to have it. (We do have calculated heatmaps based on maximum request time in Grafana, which is at least better than plots of average request times)

That reminds me of this talk[0] by Gil Tene called "How NOT to Measure Latency" at the Strangeloop conference in 2015 (or read this blog post[1] that contains the most important points).

[0] https://www.youtube.com/watch?v=lJ8ydIuPFeU

[1] https://bravenewgeek.com/everything-you-know-about-latency-i...

[2020], and written for IOCCC: The International Obfuscated C Code Contest.

This was awarded "Best of Show - abuse of libc" at the time[0]. See also the judges' remarks[1]:

This program consists of a single printf(3) statement wrapped in a while loop. You would not think that this would amount to much, but you would be very, very wrong. A clue to what is happening and how this works is encoded in the ASCII art of the program source.

[0] https://www.ioccc.org/2020/index.html

[1] https://www.ioccc.org/2020/carlini/index.html

Related thread from 11 days ago: https://news.ycombinator.com/item?id=47067395 "What years of production-grade concurrency teaches us about building AI agents", 144 points, 51 comments.

Interesting problem, perhaps you could replicate results using RIPE Atlas to see geographical impact as well?

Agree. I'll catch up on group chats that do not require immediate attention when it suits me, not when the stream of messages happens to arrive.

As for OP: read up on alert fatigue; if a notification isn't directly actionable, you shouldn't even see it!

The pull model for information is more durable for humans than the push model. Try RSS for news/blogs, take some time (preferably offline) each week to prepare for the important events in the upcoming week(s), write them down on something you pass by every day (such as a whiteboard near your front door).

This.

It seems your project is at a really early stage. Almost none of the links on the page work, which is too bad, because it could have provided more background information on your goals and wishes. The only thing that seems to work is login through Google, which is a bit much for a demo site.

What's going to be the edge above the already excellent https://bgp.tools ?

You could have a _somewhat_ static blog and incorporate something like Webmentions[0] for comments or replies. For example, Molly White's microblog[1] shows the following text below the post:

  Have you responded to this post on your own site? Send a webmention[0]! Note: Webmentions are moderated for anti-spam purposes, so they will not appear immediately.

[0] https://indieweb.org/Webmention

[1] https://www.mollywhite.net/micro/entry/202511101848

I found this document[0] very insightful. It's quite a long read, but gradually introduces the concepts needed for double-entry bookkeeping.

I think the main advantage is that you can granularly keep track of the movement of money, stocks, commodities, etc., and their conversions. As a day-to-day example, it gives you the ability to follow, for example, invoices received (Liabilities or Accounts Payable), transactions on a bank account (Assets), and what you are going to spend (or at some point, have spent) (Expenses).

This separation allows you to, for example, enter an invoice you've received on January 1 in Accounts Payable, with a corresponding value in Expenses. At this moment, nothing happened yet, it's simply an administrative transfer of some amount from an asset account to an expenses account (the sum of these transfers must be zero, so one amount is negative whereas the other amount is positive. See [0] for more details).

As a result, this gives you insight in what still needs to be paid. Once a transaction for that invoice enters your bank account on, for example, January 10, it gets "paid" to Accounts Payable, thus giving you a link between an invoice, its payment, and finally the amount spent. (This concept also works the other way around, see this sibling comment[1], where it's also extended into working with multiple accounts.)

[0] https://beancount.github.io/docs/the_double_entry_counting_m...

[1] https://news.ycombinator.com/item?id=46464893

paperless-ngx and their built-in OCR might help here for the data transformation.

I do like how it has some brutalist web design elements. With regards to drop-shadow colours on the /symbols page, it doesn't provide additional structure, so I would choose either none or a grayscale tint. Or, if you prefer colours, choose as many distinct colours as there are categories, such that they provide that additional structure.

The symbols on that page could be a bit bigger, though, as they are the main subject. (I changed 1.125rem to something like 1.6rem for text-lg; that works, but it could get a bit crowded with the clickable arrow on lower resolution screens).

I'm not a huge fan of things that move; the offset of a block of symbols, as well as scaling of an individual symbol block when hovering seems a bit too much. I would do either, but not both.

The timeline mentioned:

  Disclosure Timeline:
  - 21.10.2025: Submission of initial version of this report.

  Upcoming Timeline:
  - 24.10.2025: Submission of a talk for 39th Chaos Communication Congress (39C3). No technical details shared.
  - 21.12.2025: Disclosure of this report on https://seclists.org/fulldisclosure/
  - 26-31.12.2025: If accepted by content team, 39C3 Congress talk regarding this report

https://github.com/farrokhi/dnsdiag is another great toolbox for looking into DNS problems.

Same with What's New modals, some people will benefit from learning these things (notably power users?), but they'll annoy others.

I think power users are most annoyed by those modals. It prevents them from doing the exact thing they were planning to do. Instead, they'll have to reinterpret what the application is telling them, consider it to be irrelevant (most of the times), and then pick up whatever they were planning to do. This creates friction.

I don't need the application to tell me a sidebar was introduced. I see that immediately because it differs from the layout I'm already used to. And then I'm annoyed they added the sidebar, because it takes up space without offering relevant new functionality.

Earlier submission of the Internet Resiliency Club linked in the article: https://news.ycombinator.com/item?id=44287395 (579 points, 340 comments)

Most, if not all, Asian take-out / restaurants in NL still use a TUI for registering your order. Several motorcyle retailers in NL use a TUI for parts management, invoicing, repair tracking. In both cases, people operating these systems develop muscle memory for their everyday usage. I'm not sure if it's still in use, but for at least a decade since 2005 or so, the local university's student canteen used an in-house developed TUI for selling snacks and drinks.

And if you stretch the definition of TUI a bit, the Bloomberg terminal is a fascinating example.

I suppose that's a flexible way of looking at orders, but it sounds more like a shopping basket. What if the customer ordered three items, you started shipping those, then the customer cancels one item. That sounds like the wrong order (hah) of things.

I'm not sure why orders/purchases/subscriptions would be seen as mutable. At some point in time, customer X decided to exchange money amount M for a subscription Y. This means the company is obliged to deliver subscription Y, because the customer engaged in a contract with the company, moved amount M to the company, and expecting to (regularly) receive Y. At renewal, the customer, again, needs to pay amount M in order to continue receiving Y.

The only mutable thing here would be the end date of said subscription, at which point the company no longer requires amount M from the customer, and the customer no longer receives Y.

Then on the accounting side, every time subscription Y renews, said customer in account 750xx needs to have its balance lowered by amount M, only to get increased again when they pay.

The only way to bridge this gap is to have the engineers know what accounting needs, and let them build the right infrastructure. In this [2018] [video] https://www.youtube.com/watch?v=KH0l8QqhzYk I recently watched, the speaker Rahul Pilani explains how Netflix organised their billing systems, and how all parts fit together. I'm not saying you should copy their infrastructure, but it doesn't hurt to look at a higher level how the business operates and what their accounting requirements are.

It would be useful to have some examples on the web page, as I'm not inclined to immediately download an app.

Have a look at Info-Beamer as well: https://github.com/info-beamer

That really depends on local policy. It could be that an AS x present on multiple IXes (assuming another peer AS y is present on the same IXes) prefers sending traffic for AS y on IX t, while AS y prefers sending traffic for AS x on IX v.

Of course, the goal is to transport traffic in many directions, but in essence only routing information is explicitly exchanged.

Ideally, participants in an internet exchange purely exchange routing information, usually using the Border Gateway Protocol (BGP). This implies that devices connected to an internet exchange are routers. These devices receive routes for other autonomous systems (AS), and (selectively) publish their routes to other parties on the internet exchange.

(Internet exchanges typically offer a route server, such that every participant of the IX can easily publish routes for other participants, and simultaneously receive published routes of all other participants.)

The _effect_ of exchanging routing information is that IX-local participants know where to send traffic destined for certain IP ranges from other participants.

An autonomous system internally "knows" where each of their routers are located, and all these routers are typically connected with each other. When several routers of an AS are connected on different IXes, this means they can take informed decisions on where to send traffic destined for other ASes. It could be that AS 64496 is only present in IX-A, while AS 64510 is only present at IX-B. Suppose AS 64499 is connected to both IX-A and IX-B, traffic sourced from AS 64499 (e.g. endusers or "eyeballs") and destined for either 64496 or 64510 knows, through internally exchanged routes, where to send that traffic.

Scale this to even more autonomous systems and IXes in different geographic reasons, and you'll find it becomes a network of networks, or: the internet.

https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments).

First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.

Ceph has opt-in telemetry since a couple of years. This dashboard[0] panel suggests there are about 4-5 clusters (that send telemetry) within the 32-64 PiB range.

It would be really interesting to see larger clusters join in on their telemetry as well.

[0] https://telemetry-public.ceph.com/d/ZFYuv1qWz/telemetry?orgI...

"If you're remote, ramble" https://news.ycombinator.com/item?id=44775563 (976 points, 464 comments)

Perhaps get in touch with the people behind SwiNOG? https://www.swinog.ch/ (Swiss Network Operators Group)

If anything, it allows hiding long URIs... especially those with tracking elements that visitors here may want to exclude when clicking on it.

One of my pet peeves is single line paragraphs.

It's like you have to take a breath after reading one paragraph.

But the paragraph was just one sentence.

---

"Justified", I suppose, just looks nicer in smaller width columns, like in a newspaper where there might be four columns on one page. "Ragged right" prevents a 'natural' line on the right side of the column, somewhat diffusing the bounding box of the column. Nonetheless, it's interesting to see another view on reading, where the parent commenter prefers wider rather than more narrow columns. I usually lose track on a line level, rather than paragraph level, when the column is too wide.

This also reminds me of an internal diff tool that showed changes with a red (removed) and green (added) coloured backgrond. At some point a colleague pointed out that they could not see the difference between those backgrounds! An eye-opener, if you will, in terms of accessibility that requires adding other, non-coloured, elements indicating the semantic meaning of those background colours.

Relatable recent thread https://news.ycombinator.com/item?id=44602532 "When root meets immutable: OpenBSD chflags vs. log tampering" (153 points, 45 comments).

Not to necessarily focus on the operating system used, but think of the attacker model and risk appetite of the organisation. What are the required integrity goals? What retention do you (legally) require? Who should be able to access those logs; on their own, or n-eye principle? Do such accesses need to be logged as well? What are the requirements from the users of the audit log?

The things you'll need to log will become clear after answering such questions. How you structure them depends on the required access patterns. Tamper evidence can be achieved in many ways, but that depends on the integrity requirements; is an empty log line where one should have been enough "tamper evident"? Do you need some sort of verification mechanism that confirms the log lines you see were stored in that order?

If your log only persists on the machine where it originated, does that satisfy integrity requirements?