Ⅰ 腳本和機器人問題。
第一個問題,腳本是不帶POD的,你的CS是帶POD插件的么?不帶的話,就去下載一個!帶的話,加不上人的原因就是你的腳本與CS里的POD插件沖突了!
第二個問題,你進的F有可能是安裝的檢測,你的腳本與伺服器OP相沖突,換個腳本試試!實在不行,就完全卸載,重新安裝一次!就不要安那種腳本了!
有什麼不明白的繼續追問!
Ⅱ 什麼是pod類型
Clifton F. Vaughn 答案: 確實如此，在這個方面 C# 與 C++ 是有差別的。在 C++ 中，如果你從構造函數或者析構函數中調用虛擬函數，編譯器調用的虛擬函數是定義在這個正在被構造的類實例中的（例如，如果從 Base::Base 中調用 Base::SomeVirtFn ），不是最底層派生的實例（the most derived instance），正像你說的那樣，因為在最底層派生的構造函數執行之前，虛表還沒有完全被初始化。另一種說法是派生類還沒有被創建。
Figure 2 虛擬函數 TestSimilarly
正如你所指出的那樣，在 C# 有所不同。託管對象——無論是在 C#，託管 C++ 中，還是任何其它的 .NET 兼容語言中——是作為其最終類型被創建的，也就是說，如果你從構造函數或析構函數中調用虛函數，系統調用的是最末層派生的函數。Figure 1 所示程序舉例說明了這一點。如果你編譯並運行這個程序，你會看到 Figure 2 所示輸出。
這種行為對於 C++ 程序員來說似乎有些奇特。它意味著在派生類被初始化之前，你可以調用某個派生類型的虛擬函數——也就是說在其構造函數運行之前。同樣，如果你從基類析構函數中調用虛函數，該函數是在派生類被銷毀之後運行的——也就是說在析構函數被調用之後。那麼先不說這種差別存在的原因，剛才不是還說從構造函數/析構函數中調用虛函數被認為是糟糕的實踐。
為什麼微軟的傢伙們要像這樣來設計 C# 呢？因為它簡化了內存管理。垃圾收集器為了釋放內存，它需要知道對象有多大。如果 C# 像 C++ 那樣構造對象，那麼你可能會碰到這樣一種情況：有兩個對象，Obj1 和 Obj2，下面這兩條語句都為真：typeof(Obj1)==typeof(Obj2) sizeof(Obj1)!= sizeof(Obj2) 因為對象之一是被部分構造。（不要忘了垃圾收集器是非同步運行的。）通過將對象構造成最終類型，垃圾收集器能從其類型決定對象的大小。如果 C# 像 C++ 那樣進行部分構造，則垃圾收集器將需要更多的代碼來決定部分構造對象的真實大小。這樣將帶來復雜性和性能下降，首先要解決這個問題很讓人氣餒，所以為了較快的垃圾收集利益，微軟的傢伙們決定像上面那樣來實現 C#。有關這方面的討論參見 Raymond Chen 的 blog：「The Old New Thing」。
問題: 在2004 三月的專欄中，你展示了如何改變文件打開對話框的最新視圖狀態設置，但沒有涉及到保存這個用戶使用的最新視圖設置。我遇到的問題是讀取用戶已有的打開文件對話框設置。我只找到直接讀取列表框信息的方法，但當用戶選擇縮略圖模式時，那樣做不能得到正確的信息。對此你有沒有解決辦法？ Maarten van Dillen 問題: 我正在用公共的 CFileDialog 類做開發，應該不是很難，但事情似乎並不是那樣。我想強制文件打開對話框的視圖模式為縮略圖。我要用 Visual C++ 來做，你能否提供一些建議？ Elliot Leonard
答案: 有幾個讀者都在問文件打開對話框中的縮略圖問題。在我三月份的專欄中，我示範了如果向文件打開對話框中的 SHELLDLL_DefView 專用窗口發送 WM_COMMAND 消息以設置不同的視圖模式——但你如何知道當前所處的模式是哪一個呢？你必須獲取列表控制項並調用 CListCtrl::GetView：// in dialog class HWND hlc = ::FindWindowEx(m_hWnd, NULL, _T("SysListView32"), NULL); CListCtrl* plc = (CListCtrl*)CWnd::FromHandle(hlc); DWORD dwView = plc->GetView(); CListCtrl::GetView 返回 LV_XXX 代碼之一，但正像 Maarten 發現的那樣，Windows 對圖標模式和縮略圖模式都返回 LV_VIEW_ICON。
那麼如何區分到底是哪種視圖模式呢？我絞盡腦汁並鑽進頭文件查找，最後發現一個叫 LVM_GETITEMSPACING 的消息，該消息是作什麼用的呢——用來獲取圖標間隔。顧名思義，圖標間隔是圖標視圖模式中圖標之間的像素間隔。LVM_GETITEMSPACING 不是很好使用，以至於 MFC 都沒有對之進行包裝（比如說 MFC 中並沒有 CListCtrl::GetIconSpacing 這樣的函數）。所以在 MFC 中你得自己發送消息：CSize sz = CSize(plc->SendMessage(LVM_GETITEMSPACING)); Windows 按照通常方式返回尺寸，在高位和低位字中編碼的 cx/cy，然後CSize很禮貌地為你進行解碼。一旦有了圖標間隔，你便可以將它與 GetSystemMetrics(SM_CXICONSPACING) 返回的系統間隔值進行比較。如果列表視圖的圖標間隔與系統的一樣，則視圖是圖標模式。如果大於系統間隔，則視圖為縮略圖模式：if (sz.cx > GetSystemMetrics(SM_CXICONSPACING)) { // thumbnail view } else { // icon view } 講了那麼多縮略圖，接下來的問題是如何持續化不同用戶會話的視圖狀態？對此，當程序終止時，你需要用 Profile 函數在用戶配置文件中保存最後使用的模式，並在下一次啟動程序時再次恢復它。我寫了一個小示範程序，DlgTest。程序使用了一個實現持續化程序行為的類 CPersistOpenDlg。這個類又藉助另外一個類 CListViewShellWnd，用它來封裝 SHELLDLL_DefView 窗口（參見三月份專欄）。CListViewShellWnd 包含獲取和設置視圖模式的函數，由這些函數來區分圖標和縮略圖模式：CListViewShellWnd m_wndLVSW; ... m_wndLVSW.SetViewMode(ODM_VIEW_THUMBS); CListViewShellWnd 的 OnDestroy 處理器在某個數據成員 m_lastViewMode 中保存視圖模式。當對話框被銷毀時，CPersistOpenDlg 的析構函數調用 WriteProfileInt 將這個值寫入用戶配置文件。對話框啟動時，CPersistOpenDlg 給自己送一個初始化消息；該消息處理常式調用 GetProfileInt 從磁碟讀取存儲在配置文件中的值並設置視圖模式。PostMessage 是必須調用的，因為常規初始化消息 WM_INITDIALOG 和 CDN_INITDONE 在文件對話框被完全初始化之前就會到來——有關這一點的解釋參見三月份專欄。
順便說一下，任何時候你都應該使用 GetProfileXxx 和 WriteProfileXxx 來持續化應用程序的設置。MFC 用 CWinApp 包裝了這些函數。如果你在應用程序啟動時調用（一般都是在 InitInstance 函數中） CMyApp::SetRegistryKey("KeyName")，MFC 使用注冊表來存儲用戶配置信息，而不是 INI 文件。下面是 DlgTest 用的 INI 文件： [settings] ViewMode=28717問題: 偶爾在一些文字資料和 C++ 文檔以及 Microsoft .NET 框架中看到術語「POD 類型」。這個術語是什麼意思？
Shelby Nagwitz 答案: 你可以將 POD 類型看作是一種來自外太空的用綠色保護層包裝的數據類型，POD 意為「Plain Old Data」（譯者：如果一定要譯成中文，那就叫「徹頭徹尾的老數據」怎麼樣！）這就是 POD 類型的含義。其確切定義相當粗糙（參見 C++ ISO 標准），其基本意思是 POD 類型包含與 C 兼容的原始數據。例如，結構和整型是 POD 類型，但帶有構造函數或虛擬函數的類則不是。 POD 類型沒有虛擬函數，基類，用戶定義的構造函數，拷貝構造，賦值操作符或析構函數。
為了將 POD 類型概念化，你可以通過拷貝其比特來拷貝它們。此外， POD 類型可以是非初始化的。例如：struct RECT r; // value undefined POINT *ppoints = new POINT[100]; // ditto CString s; // calls ctor ==> not POD 非POD 類型通常需要初始化，不論是調用預設的構造函數（編譯器提供的）還是自己寫的構造函數。
過去， POD 對於編寫編譯器或與C 兼容的 C++ 程序的人來說很重要。現在，POD 來到 .NET 的環境中。在託管 C++ 中，託管類型（包括 __value 和 __gc 兩者）能包含嵌入的原生 POD 類型。 Figure 3 展示了例舉說明代碼。託管的 Circle 類能包含 POINT，但無法包含 CPoint 類。如果你嘗試編譯 pod.cpp 會報一個 C3633 錯誤：「Cannot define ''m_center'' as a member of managed ''Circle'' because of the presence of default constructor ''CPoint::CPoint'' on class ''CPoint''.」（譯者：意思是由於類 CPoint 有預設的構造函數『CPoint::CPoint』，所以不能將『m_center』定義為託管類『Circle』的一個成員）
.NET 限定嵌入的本地對象只能為 POD 類型的理由是這樣做能安全地拷貝它們，不用擔心調用構造函數，初始化虛表，或任何非 POD 類型需要的其它機制。
向Paul 提問和評論請發到 [email protected].
作者簡介 Paul DiLascia 是一名自由作家，顧問和 Web/UI 設計者。他是《Writing Reusable Windows Code in C++》書（Addison-Wesley, 1992）的作者。
Ⅲ cs中如何調PODBOT智商是修改腳本的
在進行游戲時，按H鍵，在彈出的BOT設置菜單里就可以改了
Ⅳ 什麼是「腳本文件」
一、啥叫腳本呢？
其實就是一段代碼，作用就是：這些代碼通過你的瀏覽器來鼓搗一下你的機器。這樣，你就能通過點一下滑鼠就可以發點歡迎詞、發點情話啥地了。
腳本script是使用一種特定的描述性語言，依據一定的格式編寫的可執行文件，又稱作宏或批處理文件。腳本通常可以由應用程序臨時調用並執行。各類腳本目前被廣泛地應用於網頁設計中，因為腳本不僅可以減小網頁的規模和提高網頁瀏覽速度，而且可以豐富網頁的表現，如動畫、聲音等。舉個最常見的例子，當我們點擊網頁上的E－mail地址時能自動調用Outlook Express或Foxmail這類郵件軟體，就是通過腳本功能來實現的。又如洪恩網站�http�／／www．hongen．com一些網頁的英文新聞內容旁會有一個三角符號，點擊它就可以聽到英文誦讀，這也是腳本在起作用。 也正因為腳本的這些特點，往往被一些別有用心的人所利用。例如在腳本中加入一些破壞計算機系統的命令，這樣當用戶瀏覽網頁時，一旦調用這類腳本，便會使用戶的系統受到攻擊。所以用戶應根據對所訪問網頁的信任程度選擇安全等級，特別是對於那些本身內容就非法的網頁，更不要輕易允許使用腳本。通過「安全設置」對話框，選擇「腳本」選項下的各種設置就可以輕松實現對腳本的禁用和啟用。
解釋二
動態程序一般有兩種實現方式，一是二進制方式，一是腳本方式。
二進制方式是先將我們編寫的程序進行編譯，變成機器可識別的指令代碼（如.exe文件），然後再執行。這種編譯好的程序我們只能執行、使用，卻看不到他的程序內容。
腳本簡單地說就是一條條的文字命令，這些文字命令是我們可以看到的（如可以用記事本打開查看、編輯），腳本程序在執行時，是由系統的一個解釋器，將其一條條的翻譯成機器可識別的指令，並按程序順序執行。因為腳本在執行時多了一道翻譯的過程，所以它比二進製程序執行效率要稍低一些。
我們上面提到的各種動態語言，如ASP、PHP、CGI、JSP等，都是腳本語言。
按目前的服務規則，虛擬主機網站只能採用腳本語言來實現
Ⅳ cocoapods執行pod install , pod update都出現下面的錯誤
http://blog.csdn.net/zhangao0086/article/details/39703083
Ⅵ 請教kubernetes部署問題，pod一直處於pending狀態
我們先從整體上看一下Kubernetes的一些理念和基本架構，然後從網路、資源管理、存儲、服務發現、負載均衡、高可用、rollingupgrade、安全、監控等方面向大家簡單介紹Kubernetes的這些主要特性。當然也會包括一些需要注意的問題。主要目的是幫助大家快速理解Kubernetes的主要功能，今後在研究和使用這個具的時候有所參考和幫助。1.Kubernetes的一些理念：用戶不需要關心需要多少台機器，只需要關心軟體（服務）運行所需的環境。以服務為中心，你需要關心的是api，如何把大服務拆分成小服務，如何使用api去整合它們。保證系統總是按照用戶指定的狀態去運行。不僅僅提給你供容器服務，同樣提供一種軟體系統升級的方式；在保持HA的前提下去升級系統是很多用戶最想要的功能，也是最難實現的。那些需要擔心和不需要擔心的事情。更好的支持微服務理念，劃分、細分服務之間的邊界，比如lablel、pod等概念的引入。對於Kubernetes的架構，可以參考官方文檔。大致由一些主要組件構成，包括Master節點上的kube-apiserver、kube-scheler、kube-controller-manager、控制組件kubectl、狀態存儲etcd、Slave節點上的kubelet、kube-proxy，以及底層的網路支持（可以用Flannel、OpenVSwitch、Weave等）。看上去也是微服務的架構設計，不過目前還不能很好支持單個服務的橫向伸縮，但這個會在Kubernetes的未來版本中解決。2.Kubernetes的主要特性會從網路、服務發現、負載均衡、資源管理、高可用、存儲、安全、監控等方面向大家簡單介紹Kubernetes的這些主要特性->由於時間有限，只能簡單一些了。另外，對於服務發現、高可用和監控的一些更詳細的介紹，感興趣的朋友可以通過這篇文章了解。1）網路Kubernetes的網路方式主要解決以下幾個問題：a.緊耦合的容器之間通信，通過Pod和localhost訪問解決。b.Pod之間通信，建立通信子網，比如隧道、路由，Flannel、OpenvSwitch、Weave。c.Pod和Service，以及外部系統和Service的通信，引入Service解決。Kubernetes的網路會給每個Pod分配一個IP地址，不需要在Pod之間建立鏈接，也基本不需要去處理容器和主機之間的埠映射。注意：Pod重建後，IP會被重新分配，所以內網通信不要依賴PodIP；通過Service環境變數或者DNS解決。2）服務發現及負載均衡kube-proxy和DNS，在v1之前，Service含有欄位portalip和publicIPs，分別指定了服務的虛擬ip和服務的出口機ip，publicIPs可任意指定成集群中任意包含kube-proxy的節點，可多個。portalIp通過NAT的方式跳轉到container的內網地址。在v1版本中，publicIPS被約定廢除，標記為deprecatedPublicIPs，僅用作向後兼容，portalIp也改為ClusterIp,而在serviceport定義列表裡，增加了nodePort項，即對應node上映射的服務埠。DNS服務以addon的方式，需要安裝skydns和kube2dns。kube2dns會通過讀取KubernetesAPI獲取服務的clusterIP和port信息，同時以watch的方式檢查service的變動，及時收集變動信息，並將對於的ip信息提交給etcd存檔，而skydns通過etcd內的DNS記錄信息，開啟53埠對外提供服務。大概的DNS的域名記錄是servicename.namespace.tenx.domain,"tenx.domain"是提前設置的主域名。注意：kube-proxy在集群規模較大以後，可能會有訪問的性能問題，可以考慮用其他方式替換，比如HAProxy，直接導流到Service的endpints或者Pods上。Kubernetes官方也在修復這個問題。3）資源管理有3個層次的資源限制方式，分別在Container、Pod、Namespace層次。Container層次主要利用容器本身的支持，比如Docker對CPU、內存、磁碟、網路等的支持；Pod方面可以限制系統內創建Pod的資源范圍，比如最大或者最小的CPU、memory需求；Namespace層次就是對用戶級別的資源限額了，包括CPU、內存，還可以限定Pod、rc、service的數量。資源管理模型－》簡單、通用、准確，並可擴展目前的資源分配計算也相對簡單，沒有什麼資源搶占之類的強大功能，通過每個節點上的資源總量、以及已經使用的各種資源加權和，來計算某個Pod優先非配到哪些節點，還沒有加入對節點實際可用資源的評估，需要自己的schelerplugin來支持。其實kubelet已經可以拿到節點的資源，只要進行收集計算即可，相信Kubernetes的後續版本會有支持。4）高可用主要是指Master節點的HA方式官方推薦利用etcd實現master選舉，從多個Master中得到一個kube-apiserver保證至少有一個master可用，實現highavailability。對外以loadbalancer的方式提供入口。這種方式可以用作ha，但仍未成熟，據了解，未來會更新升級ha的功能。一張圖幫助大家理解：也就是在etcd集群背景下，存在多個kube-apiserver，並用pod-master保證僅是主master可用。同時kube-sheller和kube-controller-manager也存在多個，而且伴隨著kube-apiserver同一時間只能有一套運行。5）rollingupgradeRC在開始的設計就是讓rollingupgrade變的更容易，通過一個一個替換Pod來更新service，實現服務中斷時間的最小化。基本思路是創建一個復本為1的新的rc，並逐步減少老的rc的復本、增加新的rc的復本，在老的rc數量為0時將其刪除。通過kubectl提供，可以指定更新的鏡像、替換pod的時間間隔，也可以rollback當前正在執行的upgrade操作。同樣，Kuberntes也支持多版本同時部署，並通過lable來進行區分，在service不變的情況下，調整支撐服務的Pod，測試、監控新Pod的工作情況。6）存儲大家都知道容器本身一般不會對數據進行持久化處理，在Kubernetes中，容器異常退出，kubelet也只是簡單的基於原有鏡像重啟一個新的容器。另外，如果我們在同一個Pod中運行多個容器，經常會需要在這些容器之間進行共享一些數據。Kuberenetes的Volume就是主要來解決上面兩個基礎問題的。Docker也有Volume的概念，但是相對簡單，而且目前的支持很有限，Kubernetes對Volume則有著清晰定義和廣泛的支持。其中最核心的理念：Volume只是一個目錄，並可以被在同一個Pod中的所有容器訪問。而這個目錄會是什麼樣，後端用什麼介質和裡面的內容則由使用的特定Volume類型決定。創建一個帶Volume的Pod：spec.volumes指定這個Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到這個VolumeKubernetes對Volume的支持非常廣泛，有很多貢獻者為其添加不同的存儲支持，也反映出Kubernetes社區的活躍程度。emptyDir隨Pod刪除，適用於臨時存儲、災難恢復、共享運行時數據，支持RAM-backedfilesystemhostPath類似於Docker的本地Volume用於訪問一些本地資源（比如本地Docker）。gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。awsElasticBlockStore類似於GCEdisk節點必須是AWSEC2的實例nfs-支持網路文件系統。rbd-RadosBlockDevice-Cephsecret用來通過KubernetesAPI向Pod傳遞敏感信息，使用tmpfs（aRAM-backedfilesystem）persistentVolumeClaim-從抽象的PV中申請資源，而無需關心存儲的提供方glusterfsiscsigitRepo根據自己的需求選擇合適的存儲類型，反正支持的夠多，總用一款適合的:)7）安全一些主要原則：基礎設施模塊應該通過APIserver交換數據、修改系統狀態，而且只有APIserver可以訪問後端存儲（etcd）。把用戶分為不同的角色：Developers/ProjectAdmins/Administrators。允許Developers定義secrets對象，並在pod啟動時關聯到相關容器。以secret為例，如果kubelet要去pull私有鏡像，那麼Kubernetes支持以下方式：通過dockerlogin生成.dockercfg文件，進行全局授權。通過在每個namespace上創建用戶的secret對象，在創建Pod時指定imagePullSecrets屬性（也可以統一設置在serviceAcouunt上），進行授權。認證（Authentication）APIserver支持證書、token、和基本信息三種認證方式。授權（Authorization）通過apiserver的安全埠，authorization會應用到所有http的請求上AlwaysDeny、AlwaysAllow、ABAC三種模式，其他需求可以自己實現Authorizer介面。8）監控比較老的版本Kubernetes需要外接cadvisor主要功能是將node主機的containermetrics抓取出來。在較新的版本里，cadvior功能被集成到了kubelet組件中，kubelet在與docker交互的同時，對外提供監控服務。Kubernetes集群范圍內的監控主要由kubelet、heapster和storagebackend（如influxdb）構建。Heapster可以在集群范圍獲取metrics和事件數據。它可以以pod的方式運行在k8s平台里，也可以單獨運行以standalone的方式。注意：heapster目前未到1.0版本，對於小規模的集群監控比較方便。但對於較大規模的集群，heapster目前的cache方式會吃掉大量內存。因為要定時獲取整個集群的容器信息，信息在內存的臨時存儲成為問題，再加上heaspter要支持api獲取臨時metrics，如果將heapster以pod方式運行，很容易出現OOM。所以目前建議關掉cache並以standalone的方式獨立出k8s平台。
Ⅶ exec...的docker中的EXEC
我們在應用容器的過程中，無論是在通過Dockerfile在調試構建鏡像的過程，還是容器運行一段時間想查看內部結構，我們還是希望能像操作本地機器一樣，實時的查看容器內部文件，代碼或者日誌。或是修改文件，拷貝文件目錄等等。
- 訪問容器內部，目前有兩種方法
1. Docker自帶的exec命令2. Nsenter工具- 來說說Docker exec 命令方式訪問
- 如圖所示，簡單的ls命令。Linux系統自帶的命令都可以通過這種方式運行。文件放錯位置了，mv一下，查看log，就cat log.log一下，等等。
Exec加點料
- 簡單的操作不能滿足我們對他的好奇...- 我們運行一下 docker exec -ti 61f ps -ef
- 發現只有3個進程，進程1是CMD命令啟動的腳本;進程2是腳本啟動的程序;進程3是我們運行ps -ef的進程。- 出於好奇，我又docker exec 9fe0 kill 15
- 容器從此就停止了...- 原因是殺掉進程後，Dockerfile指定的CMD[/run.sh]腳本運行結束，CMD入口已經退出，導致容器退出。
問題還沒結束
- Kubernetes是一個基於docker的容器集群管理系統，它的一大特點是擁有Replication Controllers，他的作用主要是保持所起動的Pod數量不變（pod裡面裝的是container）。我猜想如果類似的kill掉容器內部的進程，那麼kubernetes應該會讓這個container重新啟動。於是就來動手試試。- 時速雲他們應用了kubernetes，並且提供了客戶端tce可以使用exec功能。運行 tce exec bbb-145fv-zkdqz ps -ef
- tce exec bbb-145fv-zkdqz kill 15
沒有重啟？？
- 再次運行 tce exec bbb-145fv-zkdqz ps -ef
- 又出現了。- 由此可見Kubernentes的Replication Controllers還是很強大的。保證了集群中有指定數量的pod副本在運行。
Ⅷ 怎麼hack kubernetes的pod的啟動停止
從 Docker 層面有一個可能的思路是在 Dockerfile 指定 ENTRYPOINT 為一個腳本文件，然後在腳本文件里加上特定信號的捕捉器，在捕捉器裡面處理 Pod 退出時的邏輯。 例如這個入口腳本就用了類似的功能。 function shutdown { -> 退出時的清理工作... } trap shutdown SIGTERM SIGINT #注冊信號捕捉器 不確定 Kubernetes 關閉 Pod 時候，容器的入口程序會不會收到特定的信號。 只是想到這么個點子，提供一個思路，沒有實際測試過，不一定可行。