What a strange hill to die on. Just don't buy the boards?
426 karma · joined April 6, 2012
It must be an interesting culture over there to allow these sorts of designs to get to the retail market outside of their chassis, in comparison to, e.g., SuperMicro WIO designs that don't really fit anything but SM chassis.
As to the latter question, until/unless AMD updates TR Pro, this is the only HEDT option in the DDR5/PCI-e 5.0 era. Whether that matters to you and your needs is another question entirely.
Nobody wants the LA smog of the 1970s back, but controlled burns are largely impossible much of the year due to their effects on air quality.
Wildland firefighters - of whom I count several among my cousins - are between a rock and a hard place on this issue. They spend more of each year in “fire season” in part because they cannot pollute the air during “not fire season” with controlled burns.
Before I moved on to working on our Ruby VM, I was doing the work on our Redis fork for Haplo. Robey was working on the routing middleware in Scala.
Yao would have taken over from me when the cache team sprang into existence around that same time, with the emergence of twemproxy and twemcache. Most anything written in C would eventually land on her team.
There’s more to say of course, but we appreciated having these sorts of conversations with upstream authors of software we adopted at Twitter whenever possible.
Feel free to continue using that (historically-correct) answer in interviews. :P
Buffer counts and buffer sizing is also a notoriously cut-throat game in vendor marketing, almost on par with (mis-)use of the term "wire speed".
This is not an easy/cheap problem to solve, and I fully agree with the conclusion: Mikrotik hardware is good up to the point where the price/performance curve falls the wrong way in a particular situation.
I also get a lot of use from Mikrotik hardware, particularly the passively-cooled models where performance isn't as important as price + silence.
I've gone to Mikrotik for routing 10Gb in the home now. Excuse the horrible part number: the CCR2004-16G-2S+PC has worked out great for me. They're a bit hard to find right now, but I wouldn't hesitate to recommend them over whatever Ubiquiti is trying to sell in the space. For multi-gig routing, the Mikrotik RB5009 has also been a great piece of hardware.
25Gb is really getting into a different class of hardware entirely. If I needed to route at that speed, I'd seriously consider a Supermicro + Opnsense build.
25/50 and 100/400 have supplanted 10/40 in the data center, and 800Gb is here now.
The salient aspect of the paper is how it derives the log logically, not how that is mechanically implemented in a real system outside of academia.
> However, none of the prior issues you responded to were problems with the original Calvin paper either, at least by my reading.
I wasn't clear what exactly you do (or don't) know of the architecture which would lead you to believe this NxN messaging story, as that relates directly to your contention regarding the scalability (or not) of the architecture. That much is clear to me now.
You're under the mistaken impression that we have the same data/log architecture as described in the Calvin paper, which requires that every host talk with every other host. That is not true of FaunaDB.
A transaction is committed to the log with sufficient information necessary for the log (and each storage host) to know whether any particular host is involved in that transaction. There's no need for a message to prove a host's absence from that transaction - it has all it needs in the log to determine that it isn't involved. There is some complexity around how that information maps to the cluster's physical topology, but hosts which aren't involved in a transaction don't process that transaction and need not check with any other host to know that fact.
[ETA] That information is derived from the read set when constructing the transaction to propose to the log. Logical partitions that weren't a part of that read set don't need to know that they weren't involved - that fact is obvious from their absence.
> I think scalability is something that is a function of both theoretical expectations and practical demonstration.
I agree with you, though as a commercial product operated as a service, that practical demonstration is naturally limited in this forum.
No, that's not correct. FaunaDB is inspired by Calvin, but is not a direct implementation of Calvin. Transactions are applied independently on each storage host, though checking OCC locks may involve peers within a single replica.
> assuming it is
We used to offer on-premises delivery, but we are strictly a managed service now.
> I'm also not aware how large any real world clusters have gotten with FaunaDB in practice as yet. Do you have any data on that?
I'm not at liberty to say.
Disclosure: I work on FaunaDB.
Have a little self-awareness.
I will definitely be using this regardless!
Dub would feel slightly (slightly!) more polished if it used a more common package format. TOML would be a good choice.
Disclosure: I work on FaunaDB.