Jump to content

Wikipedia:Articles for deletion/Virtual synchrony (2nd nomination)

From Wikipedia, the free encyclopedia
The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was merge to Reliable multicast. Sandstein 09:10, 16 January 2019 (UTC)[reply]

Virtual synchrony (edit | talk | history | protect | delete | links | watch | logs | views) – (View log · Stats)
(Find sources: Google (books · news · scholar · free images · WP refs· FENS · JSTOR · TWL)

Article is mostly original research. The problems raised eleven years ago at the last AFD persist: the term is largely confined to Birman's work and doesn't seem to have entered into the academic mainstream. This page is Birman's personal essay, and it appears that that is all it will ever amount to, and unfortunately, Wikipedia isn't a collection of essays. SITH (talk) 22:29, 26 December 2018 (UTC)[reply]

Note: This discussion has been included in the list of Computing-related deletion discussions. Coolabahapple (talk) 08:12, 27 December 2018 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America1000 03:41, 2 January 2019 (UTC)[reply]

I’m not sure what the basic issue is here. Your proposal is dominated by personal-attack language, which somewhat obscures the real question. Are you simply saying “Wikipedia shouldn’t have a separate article on this topic”, or that “this content should be merged into some other primary article with broader coverage”?

As to the facts, Google scholar lists 2,740 articles with some mention of the two-word phrase “virtual synchrony” (a few dozen of which are by me or my students). The great majority were written by authors unrelated to me or my research group, and some use the term in their title or abstract.

The model played (and still plays) a legitimate role, yielded a CORBA standard. It was the first (and is still the primary) self-management model for fault tolerance services that employ a dynamically adaptive group structure, where processes join and leave while updates are underway. Recent textbooks continue to discuss it.

Among contemporary, widely used systems, ZooKeeper employs a form of virtual synchrony. That tool is the majority solution for cloud management and it plays a key role in Apache HDFS, Hadoop, Kafka, and other major components of the Apache cloud infrastructure. The French air traffic control system bases its correctness proof on virtual synchrony, and has been in continuous use since 1995. It is “why you are safe” when you use a self-driving car that depends on ZooKeeper, or fly into French-managed airspace. The NYSE depended upon virtual synchrony for a ten year period from 1995 to 2005, enabling it to self heal when disrupted by network component failures.

What I think could be discussed would be a merge of this material into the article on reliable multicast. It would make sense to explore such a merge, and doing so wouldn’t leave a hole in the Wikipedia “knowledge base”, whereas simply deleting the page would create a gap. The question is: who would carry this task out? Clearly, not me.

I would easily be able to suggest domain experts, but I don’t know if any are Wikipedia editors.

Ken Birman (talk) 19:39, 5 January 2019 (UTC)[reply]

Hi Ken Birman, sorry it's taken me so long to respond, I've had a lot on my plate. While I agree that my nomination may have been worded somewhat tersely (for which I apologise, I tend to truncate what I say to save time), I adamantly disagree that I violated the policy to which you refer (no personal attacks). If I'd have said "your research is all lies" or "you're a liar", that would be a personal attack. My nomination is in no way intended to cast a shadow on your academic record (I'm some random pleb on the Internet and you're a Professor at Cornell, I don't think anyone's disputing that you know more about the topic you're writing about than I do), I am merely pointing out that the vast majority of the sources cited are written by you. One of the five pillars of Wikipedia is that we don't publish original research. The article was created by a user whose username is also the attribution given to the sources which cover the term the most. That is the policy upon which I was basing my argument. Many thanks, SITH (talk) 20:13, 8 January 2019 (UTC)[reply]
Edit: and I would be more than happy to help facilitate a merge to the article you've highlighted. SITH (talk) 20:15, 8 January 2019 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: I might as well ping @Ken Birman: to keep the discussion rolling.
Please add new comments below this notice. Thanks, J947(c), at 01:47, 9 January 2019 (UTC)[reply]
SITH apology accepted. I’m fine with you deleting the page and tackling this merge. Let me know when you’ve made your edit and I’ll take a look. I don’t get notifications instantly on Wikipedia... email me ([email protected]) if a question arises.


You should probably cite the Derecho paper (accepted by ACM Transactions on Computing Systems, should appear soon) at the same time. Idit Keidar has a theoretical analysis of solutions to the reliable multicast problem (aka State machine replication, Paxos) and gives theoretical lower bounds (a way to identify the best possible protocols is to characterize the minimum amount of information or messages tha must be exchanged).
Derecho, which uses virtual synchrony and runs on RDMA (when the hardware isn’t available it just switches to TCP), is the first solution to achieve this lower bound and in that sense, is the ultimate protocol in this space. No future protocol could outperform it other than through clever use of the hardware or some other engineering innovation: it simply isn’t possible to reduce the message costs. As such there are several pages that probably should cite this paper. I was planning to just add it to the long lists of cited works on those once the TOCS citation is in a final state (lacks page numbers and an exact date right this second). Ken Birman (talk) 09:06, 10 January 2019 (UTC)[reply]
Note to closer: I'm fine with implementing the merge and redirect per Ken Birman's directions above (although I can't promise I'll do it immediately), so I move to close as merge. SITH (talk) 17:01, 14 January 2019 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.