thequux

So, ICANN. That's what they do; for-profit registrars are only a small part of it.

In my experience, it depends. 99% of the time, malloc/free is your best bet: fast enough, battle-tested, everything already uses it, etc.

In the 1%, though, you'll have needs that malloc/free don't fit. Complex object graphs don't really have a single point of ownership or requiring that you free something in all the places that it might be released is too much to handle. In this case you can reach for a garbage collector (including, for example, implementing reference counting). Other times, you may need to make a lot of allocations in a short time where they can all be freed at once. Request processing in a network server is a common example of this: once the request is complete, everything allocated can be dropped, and you generally want minimal latency.

All of this comes with tradeoffs, though. With a GC, you lose predictability and performance changes; sometimes for the better and sometimes for the worse. Depending on the GC, you may not be able to have stable pointers, and you may lose the ability to finalize objects. With an arena, you can't free or reallocate, so you need to scope the arena to a small region of execution (this is where the author went wrong, for example).

Finally, regardless of which approach you use, you're going to need to thread the allocator through the application; probably implement your own datastructures, etc. Depending on how complex your memory management model is, you may need more than one allocator at any given point (e.g., a GC for the persistent data and an arena per connection and per request). If you're implementing your own allocator, you'll also likely have bugs, and allocator bugs tend to be insidious and obnoxious to debug.

If you can avoid going down that route, I recommend it. Sometimes, though, you have enough constraints that you need to brave the jungle.

Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much microarchitecture to userspace: it would forever be pinned to having three execution ports with very specific capabilities, and any changes to the µarch would have resulted in all of the complicated register rename and instruction scheduling hardware that VLIW was supposed to avoid.

I'll grant that it seemed like a decent idea at the time, but there was enough risk there that I can only describe Intel's all-in stance on Itanium to have been a blunder.

(There's a worthwhile distinction to be made between a blunder and a mistake. Mistakes are calculated risks that don't pan out, whereas a blunders is something that should have been obvious that it would go poorly when the decision was made. Losing your savings in the stock market from a surprise dip is a mistake. Losing your savings by betting it all on 14 in Vegas is a blunder. Similarly, the design of Itanium was a mistake. Betting the company on it was a blunder.)

Don't underestimate the importance of a pen, ink, and paper you like. I found my pen a decade ago: Lamy Studio, in British Racing Green, with a medium nib. I found my ink not long after, from J Herbin's collection.

It wasn't until I got a nice notebook from Leuchtturm 1917, though, that the ensemble came together and I started looking for excuses to get my kit out and write things down. Since then, I've moved onto notebooks from de Kempen, but the point stands

I can't judge the veracity of the history of hash functions, but the moment it starts talking about cryptography it goes completely off the rails: it seems to indicate that finite field exponentiation o'r high degree polynomials are used in cryptographic hash functions; they are emphatically not. It presents password hashing as just applying a suggest function to the password; in practice a KDF is used, which is a completely different design space (for a start, KDFs have a tweak parameter, usually called a salt in this context). Finally, there's a haven't reference to quantum computers breaking hash functions and needing post-quantum algorithms as a result. This does brush with reality in that Grover's algorithm does theoretically eat half the first preimage resistance security level of your hash function, but even SHA256 will require 2^128 iterations on a quantum computer, which will likely never be feasible. Worse, it doesn't help at all in attacks against second perimeter resistance or collision resistance.

Considering that everything I have personal knowledge of here is obviously bunk, best ignore the rest of it too

It's been a long time since I've touched any of this, so the details have slipped my mind. However, the general idea was that there were two different exit calls in DOS: terminate and terminate and stay resident. The difference between the two is that the stay resident option wouldn't release the memory used by your application. Further, the interrupt table, which told the processor how to handle each interrupt, was in RAM and therefore writable.

So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place

How do you feel about ADD 5 TO X GIVING X?

I kid, of course, but "X is x + 5" brings Prolog to mind with all the unification and bidirectionality that implies.

> So I think the following is IMO by far the biggest problem, no matter one's personal opinion: > > "Rakoff entered a permanent worldwide injunction covering ten Anna’s Archive domains: annas-archive.org, .li, .se, .in, .pm, .gl, .ch, .pk, .gd, and .vg."

Legally speaking, the Southern District of New York can say whatever it likes, and Libera, Sweden, India, St-Pierre-et-Miquelon, Greenland, Switzerland, Pakistan, Grenada, and the British Virgin Islands are free to ignore what the US says. They all have national sovereignty over their respective ccTLDs, and of them, most are not going to simply accept the US telling them what to do considering recent geopolitical missteps.

$227k just to apply, and another few hundred thousand in legal, compliance, and contracting to reach delegation.

Source: I'm on the board of dotMeow and wrote the financial plan

Hi! I'm one of the founders of dotMeow, and it's been a long road to get to the point that we're willing to stake our reputations on a crowdfunding campaign. From applying to the applicant support program (we believe we were one of the first, if not the first organization accepted) to working out financial plans and overall strategy to achieve NIS2 compliance on a shoestring budget, it's been a year and a half of effort to reach where we are now.

It's quite late here in Belgium, so I'm about to go to sleep, but in the morning, I'll happily answer any questions people have about the project.

Do catgirls count? We've got one or two on staff. We'd have a cat, too, if it weren't for the fact that I'm allergic.

The sad thing is, this is one of the rhetorical flourishes that gets drilled into you in debate and comms education. ChatGPT picked it up because it's extremely common.