本文章僅以cnvd、cnnvd、cve三個大型公益平台為例，關於src另外再說，主要圍繞著漏洞挖掘、如何提交、如何拿到證書以及編號等，問題進行闡述.
關於cve的闡述：
首先說下國際性質的cve，個人認為cve最簡單也是最好拿到cve編號的漏洞大多數是cms，當然我這裡指的是小眾化的，一般大型cms例如wordpass、oracle、等基本上不是太好挖掘造成的不是很好提交，另外就是主機層的漏洞更不好挖掘以及提交，另外cve是只收通用型別的為主，似乎事件型的不收（個人認為），然後cve是不需要截圖的你只需要把存在漏洞的**提交上去即可，然後不管你是機翻，還是手工翻，寫乙份英文報告發布在github上即可，並且把該鏈結貼上至漏洞提交處。
關於cnnvd的闡述：
其次說說國內的cnnvd，個人認為是最難提交的，從web層到主機層的，都很難提交，看過我文章的人都知道我曾經發過一篇閉源通用的文章，該文章就是當時由於挖掘出來，提交至cnnvd最終認定為閉源通用被沒收了，從而失敗了，由此可見cnnvd是更難提交的，cms要麼是大型的，小眾化的cms基本上是不收錄的，主機層漏洞就更不用說了，然後cnnvd事件型的主要看是否為閉源和開源，通用型的看波及面是否廣泛。
關於cnvd的闡述：
最後在說說cnvd，cnvd個人認為還是比較好點的（曾經更好提交）小眾化cms，或者大型cms，不管是什麼語言基本上都沒問題，只要是能夠證明的危害基本上都收錄的，主機層漏洞也是收錄的，不管是通用型還是事件型都是可以的。
個人認為：
但由於近幾年來，各種明文條款規則（法律）什麼的都在不斷的完善當中，所以越來越嚴格，然後就是規則的變動，個人認為cnvd目前小眾化的cms基本上接近乙個飽和的狀態所以，估計以後很難再提交了，當然不排除有特殊性質的，另外條令條例（法律）中基本上也會限制了針對於事件型的漏洞挖掘，所以這裡我不是很建議大家挖掘事件型的，不過可以去選擇挖掘一些通用型的，不管是黑盒測試還是白盒測試或者灰盒測試，都是可以只要能夠證明就行，有的時候不必要去挖掘事件型的，這個看自己怎麼去提交並且通過了，如果我提交的話都會直接跟漏洞審核人員進行協商。
由此以上表達能夠看出來乙個趨勢，以及乙個個人認為的排行。
個人建議：
不挖掘或者少挖掘沒有授權或者授權不是很大的事件型漏洞，挖掘通用漏洞能不去復現事件型的就不要去復現了吧，畢竟太危險這個誰也保不准，另外提兩個真實案例，其實都知道的案例，乙個是近期的銀川事件，另外乙個是幾年前的世紀佳緣事件，兩個事件均作為乙個典型的「農夫與蛇」的故事代表，所以謹慎謹慎再謹慎吧。
首先針對於乙個趨勢的個人認定：
從大多數漏洞到少數漏洞的乙個發展，也就是說一些小眾化的不好被收錄了，但是大型的還是可以被收錄。
其次是針對於乙個排行的個人認定（從難道易）：
主機型別的漏洞：
1.cve
2.cnnvd
3.cnvd
web型別的漏洞：
1.cnnvd
2.cnvd
3.cve
註明：以上所說的均為個人觀點，如有不同觀點可以找我**下互相交流學習
關於ROS的個人見解
ros只是乙個程式開發框架而已，它主要有以下東西組成 1 ros執行環境,主要負責全域性資訊 訊息傳遞 名稱管理。2 ros專用函式庫，主要是規定ros各種規則 通訊 管理全域性資訊。3 各種能重複利用的package 4 一些方便開發的工具 ros本身執行在linux中 用ros開發框架，開發出來...
關於CAP的個人見解
在集群環境下，保證各個節點的資料在任一時刻訪問都是一致的 在集群環境下，保證任一時刻都能保證服務可用 在集群環境下，當部分服務不可用時，整體服務對外依舊可用，但分割槽容錯性理論來講不能達到100 的可能，因為既然是分布式，就會存在諸如網線之類的各種通訊故障問題，嚴格來講，只能說達到99.9999 網...
博弈 個人 見解
由於周測 做了好久的博弈題，找了好多關於博弈的相關資料，感覺自己，似乎還是動了那麼一點點。臨睡前，就小小的總結一下，希望以後看到的時候，可以有所感悟吧！接下來是正題。講到博弈，事實上也就是找規律，可是知道一般的博弈型別能夠高速便捷的解決這個問題。博弈的型別大致有下面幾種 巴什博弈，威佐夫博奕，尼姆博...