⑴ android驅動開發好了，怎麼調試
本文用《Android深度探索（卷1）：HAL與驅動開發》的隨書源代碼為例詳細說明如何配置Android驅動開發和測試環境，並且如何使用源代碼中的build.sh腳本文件在各種平台（Ubuntu linux、Android模擬器和S3C6410開發板）上編譯、安裝和測試Linux驅動。建議讀者使用Ubuntu Linux12.04或更高版本實驗本文的方法。最好用root賬號登錄Linux。
一、安裝交叉編譯器
如果只是在Ubuntu Linux上測試Linux驅動就不需要安裝交叉編譯器了，但要在Android模擬器或S3C6410開發板上進行測試，就必須安裝交叉編譯器。
首先下載交叉編譯器（分卷壓縮）
下載後解壓，會發現有兩個tgz文件，可以將這兩個文件放到/root/compilers目錄中，在Linux終端進入該目錄，執行如下命令安裝交叉編譯器。
[plain] view plain
# tar zxvf arm-linux-gcc-4.3.2.tgz -C /
# tar jxvf arm-none-linux-gnueabi-arm-2008q3-72-for-linux.tar.bz2 -C /
二、編譯和測試Linux內核
這里的Linux內核有兩個，一個是goldfish，也就是Android模擬器使用的Linux內核、另外一個是S3C6410開發板使用的Linux內核（Linux2.6.36）。讀者首先要下載這兩個Linux內核。
Android模擬器用的Linux內核源代碼（分卷壓縮）
用於S3C6410開發板的Linux內核源代碼（分卷壓縮）
分卷1
分卷2
由於隨書代碼中的word_count驅動已經在goldfish和linux2.6.36中分別建立了符號鏈接，以便在編譯linux內核時同時也會編譯word_count驅動，所以linux內核與源代碼目錄應與作者機器上的目錄相同。也就是兩個linux內核目錄與源代碼目錄如下：
linux內核目錄
/root/kernel/goldfish
/root/kernel/linux_kernel_2.6.36
源代碼目錄
/root/drivers
注意/root/drivers目錄下就直接是每一章的源代碼了，例如/root/drivers/ch06、/root/drivers/ch07
現在需要將/usr/local/arm/arm-none-linux-gnueabi/bin路徑加到Linux的PATH環境變數中（不會加的上網查，這是Linux的基本功）
最後進入/root/compilers/goldfish目錄，執行make命令編譯linux內核，如果完全編譯，大概20分鍾左右。編譯完成後，會在/root/kernel/goldfish/arch/arm/boot目錄中生成一個zImage文件，代碼1.7MB，這就是用於Android模擬器的Linux內核文件。
三、編譯Linux驅動
現在來編譯隨書光碟的驅動程序，這里以word_count驅動為例。在Linux終端進入/root/drivers/ch06/word_count目錄。先別忙著編譯。首先要設置打開/root/drivers/common.sh文件，修改第一行UBUNTU_KERNEL_PATH變數值為自己機器上安裝的Ubuntu Linux內核路徑，只要執行「ls /usr/src」命令即可查看當前機器可用的linux內核。如可以設置下面的路徑。
UBUNTU_KERNEL_PATH=/usr/src/linux-headers-3.2.0-23-generic
剩下的兩個（S3C6410_KERNEL_PATH和/root/kernel/goldfish）只要按著前面的路徑解壓Linux內核源代碼，就不用設置了。
在word_count目錄中執行「source build.sh」命令，會允許選擇在哪個平台上編譯驅動，直接按回車會在Ubuntu Linux上編譯。如果編譯成功，會發現當前目錄多一個word_count.ko文件（驅動文件）。
現在來編譯S3C6410上運行的word_count驅動。先別忙，在編譯之前，需要Android中的adb命令。因為build.sh足夠只能，在編譯完後，如果有多個Android設備連接到PC，會允許用戶選擇上傳到哪個設備裝載，這里需要選擇S3C6410開發板，然後會直接上傳到開發板上，如圖1所示。
可以直接使用adb shell命令進入開發板，也可以使用/root/drivers/shell.sh腳本完成同樣的工作，只是後者如果有多個android設備，會允許用選擇，而不是輸入相應的設備ID。使操作更方便。在/root/drivers目錄中提供了很多這樣的腳本（shell.sh、push.sh、pull.sh等），這些腳本都會允許用戶選擇操作的Android設備。
我們通常使用Android SDK中的adb命令，到官方網站下載裝載linux版本的Android SDK，然後將<AndroidSDK根目錄> /platform-tools加到PATH環境變數中。
現在再次執行「source build.sh」命令，選擇第2項（S3C6410開發板），如果系統沒找到開發板，需要將USB線拔下重插一下。然後就可以進入開發板的終端，輸入lsmod命令查看驅動的安裝情況了。
如果在模擬器上測試，選第3項。具體測試的方法請參見書中相應的章節。
四、測試Linux驅動
測試word_count驅動的方法很多，通過命令行測試的方法請參見書中相應的章節，在word_count目錄中有一個test_word_count程序，通過執行如下的命令可以測試word_count驅動，編譯test_word_count.c程序的方法書中已詳細描述。
test_word_count 「abc bb cc」
上面的命令會輸出單詞數為3。
如果要編譯Android HAL，需要Android源代碼。購買S3C6410開發板時商家通常會帶一些光碟，裡面有用於開發板的Android源代碼，如果商家沒給光碟，別忘了要哦！
⑵ 《自然》評選改變科學的10個計算機代碼項目
從Fortran到arXiv.org，這些計算機編碼和平台讓生物學、氣候科學和物理學等學科的發展達到了真正「日新月異」的速度。
2019年，事件視界望遠鏡團隊讓世界首次看到了黑洞的樣子。不過，研究人員公布的這張發光環形物體的圖像並不是傳統的圖片，而是經過計算獲得的。利用位於美國、墨西哥、智利、西班牙和南極地區的射電望遠鏡所得到的數據，研究人員進行了數學轉換，最終合成了這張標志性的圖片。研究團隊還發布了實現這一壯舉所用的編程代碼，並撰文記錄這一發現，其他研究者也可以在此基礎上進一步加以分析。
這種模式正變得越來越普遍。從天文學到動物學，在現代每一項重大科學發現的背後，都有計算機的參與。美國斯坦福大學的計算生物學家邁克爾·萊維特因「為復雜化學系統創造了多尺度模型」與另兩位研究者分享了2013年諾貝爾化學獎，他指出，今天的筆記本電腦內存和時鍾速度是他在1967年開始獲獎工作時實驗室製造的計算機的1萬倍。「我們今天確實擁有相當可觀的計算能力，」他說，「問題在於，我們仍然需要思考。」
如果沒有能夠解決研究問題的軟體，以及知道如何編寫並使用軟體的研究人員，一台計算機無論再強大，也是毫無用處的。如今的科學研究從根本上已經與計算機軟體聯系在一起，後者已經滲透到研究工作的各個方面。近日，《自然》（Nature）雜志將目光投向了幕後，著眼於過去幾十年來改變科學研究的關鍵計算機代碼，並列出了其中10個關鍵的計算機項目。
這台CDC 3600型計算機於1963年交付給位於科羅拉多州博爾德的國家大氣研究中心，研究者在Fortran編譯器的幫助對其進行了編程
語言先驅：Fortran編譯器（1957年）
最初的現代計算機並不容易操作。當時的編程實際上是手工將電線連接成一排排電路來實現的。後來出現了機器語言和匯編語言，允許用戶用代碼為計算機編程，但這兩種語言都需要對計算機的架構有深入的了解，使得許多科學家難以掌握。
20世紀50年代，隨著符號語言的發展，特別是由約翰·巴克斯及其團隊在加州聖何塞的IBM開發的「公式翻譯」語言Fortran，這種情況發生了變化。利用Fortran，用戶可以用人類可讀的指令來編程，例如x = 3 + 5。然後由編譯器將這些指令轉換成快速、高效的機器代碼。
不過，這一過程仍然很不容易。早期的程序員使用打孔卡來輸入代碼，而復雜的模擬可能需要數萬張打孔卡。盡管如此，新澤西州普林斯頓大學的氣候學家真鍋淑郎（Syukuro Manabe）還是指出，Fortran讓非計算機科學家也能編程，「這是我們第一次能夠自己給計算機編程」。他和同事們利用這種語言開發的氣候模型是最早取得成功的模型之一。
Fortran發展至今已經到了第八個十年，它仍然廣泛應用於氣候建模、流體動力學、計算化學等學科，這些學科都涉及到復雜線性代數並需要強大的計算機來快速處理數字。Fortran生成的代碼速度很快，而且仍然有很多程序員知道如何編寫。古早的Fortran代碼庫仍然活躍在世界各地的實驗室和超級計算機上。「以前的程序員知道他們在做什麼，」美國海軍研究院的應用數學家和氣候模型師弗蘭克·吉拉爾多說，「他們非常注重內存，因為他們擁有的內存非常少。」
信號處理器：快速傅立葉變換（1965）
當射電天文學家掃描天空時，他們捕捉到的是隨時間變化的復雜信號雜音。為了理解這些無線電波的本質，他們需要看到這些信號作為頻率的函數時是什麼樣的。一種名為「傅里葉變換」的數學過程可以幫到研究人員，但它的效率很低，對於一個大小為N的數據集需要N^2次計算。
1965年，美國數學家詹姆斯·庫利和約翰·杜基想出了一種加速該過程的方法。快速傅里葉變換（FFT）通過遞歸（一種通過重復將問題分解為同類的子問題而解決問題的編程方法）將計算傅里葉變換的問題簡化為N log2（N）步。隨著N的增加，速度也會提高。對於1000個點，速度提升大約是100倍；100萬個點則是5萬倍。
這個「發現」實際上是一個再發現，因為德國數學家高斯在1805年就對此進行了研究，但他從未發表過。而詹姆斯·庫利和約翰·杜基做到了，他們開啟了傅里葉變換在數字信號處理、圖像分析、結構生物學等領域的應用，成為應用數學和工程領域的重大事件之一。FFT在代碼中的應用已有很多次，近年一個流行的方案是FFTW，被認為是世界上最快的FFT。
保羅·亞當斯是加州勞倫斯伯克利國家實驗室分子生物物理學和綜合生物成像部門的主任，他回憶稱，當他在1995年改進細菌蛋白質凝膠的結構時，即使使用FFT和超級計算機，也需要「很多個小時，甚至數天」的計算。「如果在沒有FFT的情況下嘗試做這些，我不知道在現實中應該如何做到，」他說，「那可能要花很長時間。」
分子編目：生物資料庫（1965年）
資料庫是當今科學研究中不可或缺的組成部分，以至於人們很容易忘記它們也是由軟體驅動的。過去的幾十年中，資料庫資源的規模急劇膨脹，影響了許多領域，但或許沒有哪個領域的變化會比生物學領域更引人注目。
蛋白質資料庫Protein Data Bank擁有超過17萬個分子結構的檔案，包括這種細菌的「表達子」（expressome），其功能是結合RNA和蛋白質合成的過程。
今天，科學家所用的龐大基因組和蛋白質資料庫源於美國物理化學家瑪格麗特·戴霍夫的工作，她也是生物信息學領域的先驅。20世紀60年代初，當生物學家們致力於梳理蛋白質的氨基酸序列時，戴霍夫開始整理這些信息，以尋找不同物種之間進化關系的線索。她與三位合著者於1965年發表了《蛋白質序列和結構圖譜》，描述了當時已知的65種蛋白質的序列、結構和相似性。 歷史 學家布魯諾·斯特拉瑟在2010年寫道，這是第一個「與特定研究問題無關」的數據集，它將數據編碼在打孔卡中，這使得擴展資料庫和搜索成為可能。
其他「計算機化」的生物資料庫緊隨其後。蛋白質資料庫Protein Data Bank於1971年投入使用，如今詳細記錄了超過17萬個大分子結構。加州大學聖地亞哥分校的進化生物學家拉塞爾·杜利特爾在1981年創建了另一個名為Newat的蛋白質資料庫。1982年，美國國立衛生研究院（NIH）與多個機構合作，成立了GenBank資料庫，這是一個開放獲取的DNA序列資料庫。
這些資料庫資源在1983年7月證明了其存在價值。當時，由倫敦帝國癌症研究基金會蛋白質生物化學家邁克爾·沃特菲爾德領導的團隊，與杜利特爾的團隊各自獨立報道了一個特殊的人類生長因子序列與一種導致猴子出現癌症的病毒蛋白質之間的相似性。觀察結果顯示了一種病毒誘發腫瘤機制——通過模仿一種生長因子，病毒會誘導細胞不受控制地生長。美國國家生物技術信息中心（NCBI）前主任詹姆斯·奧斯特爾說：「這一結果讓一些對計算機和統計學不感興趣的生物學家頭腦里靈光一閃：我們可以通過比較序列來了解有關癌症的一些情況。」
奧斯特爾還表示，這一發現標志著「客觀生物學的到來」。除了設計實驗來驗證特定的假設，研究人員還可以挖掘公共數據集，尋找那些實際收集數據的人可能從未想到的聯系。當不同的數據集連接在一起時，這種力量就會急劇增長。例如，NCBI的程序員在1991年通過Entrez實現了這一點；Entrez是一個可以讓研究人員在DNA、蛋白質和文獻之間自由檢索和比對的工具。
預測領先者：大氣環流模式（1969年）
在第二次世界大戰結束時，計算機先驅約翰·馮·諾伊曼開始將幾年前用於計算彈道軌跡和武器設計的計算機轉向天氣預測問題。真鍋淑郎解釋道，在那之前，「天氣預報只是經驗性的」，即利用經驗和直覺來預測接下來會發生什麼。相比之下，馮·諾伊曼的團隊「試圖基於物理定律進行數值天氣預測」。
新澤西州普林斯頓的美國國家海洋和大氣管理局（NOAA）地球物理流體動力學實驗室的建模系統部門負責人Venkatramani Balaji表示，幾十年來，人們已經熟知這些方程式。但早期的氣象學家無法實際解決這些問題。要做到這一點，需要輸入當前的條件，計算它們在短時間內會如何變化，並不斷重復。這個過程非常耗時，以至於在天氣狀況實際出現之前還無法完成數學運算。1922年，數學家劉易斯·弗萊·理查森花了幾個月時間計算德國慕尼黑的6小時預報。根據一段 歷史 記載，他的結果是「極不準確的」，包括「在任何已知的陸地條件下都不可能發生的」預測。計算機使這個問題變得很容易解決。
20世紀40年代末，馮·諾伊曼在普林斯頓高等研究院建立了天氣預報團隊。1955年，第二個團隊——地球物理流體動力學實驗室——開始進行他所謂的「無限預測」，也就是氣候建模。
真鍋淑郎於1958年加入氣候建模團隊，開始研究大氣模型；他的同事柯克·布萊恩將這一模型應用在海洋研究中。1969年，他們成功將二者結合起來，創造了《自然》雜志在2006年所說的科學計算「里程碑」。
今天的模型可以將地球表面劃分為一個個25公里 25公里的正方形，並將大氣層劃分為數十層。相比之下，真鍋淑郎和布萊恩的海洋-大氣聯合模型劃分的面積為500平方公里，將大氣分為9個層次，只覆蓋了地球的六分之一。盡管如此，Venkatramani Balaji表示，「這個模型做得很好」，使研究團隊第一次能夠通過計算機預測二氧化碳含量上升的影響。
數字運算機：BLAS（1979年）
科學計算通常涉及到使用向量和矩陣進行相對簡單的數學運算，但這樣的向量和矩陣實在太多了。但在20世紀70年代，還沒有一套普遍認可的計算工具來執行這些運算。因此，從事科學工作的程序員會將時間花在設計高效的代碼來進行基本的數學運算，而不是專注於科學問題。
加州勞倫斯利弗莫爾國家實驗室的Cray-1超級計算機。在BLAS編程工具於1979年問世之前，並沒有線性代數標准可供研究人員在Cray-1超級計算機等機器上工作
編程世界需要一個標准。1979年，這樣的標准出現了：基本線性代數程序集（Basic Linear Algebra Subprograms，簡稱BLAS）。這是一個應用程序介面（API）標准，用以規范發布基礎線性代數操作的數值庫，如矢量或矩陣乘法。該標准一直發展到1990年，為向量數學和後來矩陣數學定義了數十個基本常式。
美國田納西大學計算機科學家、BLAS開發團隊成員傑克·唐加拉表示，事實上，BLAS把矩陣和向量數學簡化成了和加法和減法一樣基本的計算單元。
美國德克薩斯大學奧斯汀分校的計算機科學家Robert van de Geijn指出，BLAS「可能是為科學計算定義的最重要的介面」。除了為常用函數提供標准化的名稱之外，研究人員還可以確保基於BLAS的代碼在任何計算機上以相同方式工作。該標准還使計算機製造商能夠優化BLAS的安裝啟用，以實現在其硬體上的快速操作。
40多年來，BLAS代表了科學計算堆棧的核心，也就是使科學軟體運轉的代碼。美國喬治·華盛頓大學的機械和航空航天工程師洛雷娜·巴爾巴稱其為「五層代碼中的機械」。而傑克·唐加拉說：「它為我們的計算提供了基礎結構。」
顯微鏡必備：NIH Image（1987年）
20世紀80年代初，程序員韋恩·拉斯班德在馬里蘭州貝塞斯達的美國國立衛生研究院的腦成像實驗室工作。該實驗室擁有一台掃描儀，可以對X光片進行數字化處理，但無法在電腦上顯示或分析。為此，拉斯班德寫了一個程序。
這個程序是專門為一台價值15萬美元的PDP-11小型計算機設計的，這是一台安裝在架子上的計算機，顯然不適合個人使用。然後，在1987年，蘋果公司發布了Macintosh II，這是一個更友好、更實惠的選擇。拉斯班德說：「在我看來，這顯然是一種更好的實驗室圖像分析系統。」他將軟體轉移到新的平台上，並重新命名，建立了一個圖像分析生態系統。
NIH Image及其後續版本使研究人員能在任何計算機上查看和量化幾乎任何圖像。該軟體系列包括ImageJ，一個拉斯班德為Windows和Linux用戶編寫的基於Java的版本；以及Fiji，這是ImageJ的分發版，由德國德累斯頓的馬克斯普朗克分子細胞生物學和遺傳學研究所的Pavel Tomancak團隊開發，其中包括關鍵的插件。「ImageJ無疑是我們所擁有的最基礎的工具，」布洛德研究所（由麻省理工學院和哈佛大學聯合創立）成像平台的計算生物學家貝絲·契米妮說，「我從來沒有和一個使用過顯微鏡，但沒有使用過ImageJ或Fiji的生物學家說過話。」
拉斯班德表示，部分原因可能是這些工具是免費的。但威斯康星大學麥迪遜分校的生物醫學工程師Kevin Eliceiri指出，另一個原因是用戶可以很容易地根據自己的需求定製工具。自拉斯班德退休後，Kevin Eliceiri的團隊一直領導著ImageJ的開發。ImageJ提供了一個看似簡單、極簡主義的用戶界面，自20世紀90年代以來基本上沒有改變。然而，由於其內置的宏記錄器（允許用戶通過記錄滑鼠點擊和菜單選擇的序列來保存工作流）、廣泛的文件格式兼容性和靈活的插件架構，該工具具有無限的可擴展性。該團隊的編程主管柯蒂斯·魯登表示，有「數以百計的人」為ImageJ貢獻了插件。這些新添加的功能極大擴展了研究人員的工具集，例如在視頻中跟蹤對象或自動識別細胞的功能。
Kevin Eliceiri說：「這個程序的目的不是做到一切或終結一切，而是服務於用戶的目標。不像Photoshop和其他程序，ImageJ可以成為你想要的任何東西。」
序列搜索器：BLAST （1990年）
可能沒有什麼能比把軟體名稱變成動詞更能說明文化的相關性了。提到搜索，你會想到谷歌；而提到遺傳學，研究者會立刻想到BLAST。
通過諸如替代、刪除、缺失和重排等方式，生物將進化中的改變蝕刻在分子序列中。尋找序列之間的相似性——特別是蛋白質之間的相似性——可以讓研究人員發現進化關系，並深入了解基因功能。在迅速膨脹的分子信息資料庫中，想要快速而准確地做到這一點並不容易。
瑪格麗特·戴霍夫在1978年提供了關鍵的進展。她設計了一種「點接受突變」矩陣，使研究人員不僅可以根據兩種蛋白質序列的相似程度，還可以根據進化距離來為評估它們的親緣關系。
1985年，弗吉尼亞大學的威廉·皮爾森和NCBI的大衛·利普曼引入了FASTP，這是一種結合了戴霍夫矩陣和快速搜索能力的演算法。
數年後，利普曼與NCBI的沃倫·吉什和斯蒂芬·阿特舒爾，賓夕法尼亞州立大學的韋伯·米勒，以及亞利桑那大學的吉恩·邁爾斯一起開發了一種更強大的改進技術：BLAST（Basic Local Alignment Search Tool）。BLAST發布於1990年，將處理快速增長的資料庫所需的搜索速度，與提取進化上更為遙遠的匹配結果的能力結合起來。與此同時，該工具還可以計算出這些匹配發生的概率。
阿特舒爾表示，計算結果出來得非常快，「你可以輸入搜索內容，喝一口咖啡，搜索就完成了。」但更重要的是，BLAST很容易使用。在一個通過郵寄更新資料庫的時代，沃倫·吉什建立了一個電子郵件系統，後來又建立了一個基於網路的架構，允許用戶在NCBI計算機上遠程運行搜索，從而確保搜索結果始終是最新的。
哈佛大學的計算生物學家肖恩·艾迪表示，BLAST系統為當時處於萌芽階段的基因組生物學領域提供了一個變革性的工具，即一種根據相關基因找出未知基因可能功能的方法。對於各地的測序實驗室，它還提供了一個新穎的動詞。「它是眾多由名詞變成動詞的例子之一，」艾迪說，「你會說，你正准備BLAST一下你的序列。」
預印本平台：arXiv.org （1991年）
20世紀80年代末，高能物理學家經常將他們已投稿的論文手稿副本郵寄給同行，徵求他們的意見——但只發給少數人。物理學家保羅·金斯帕格在2017年寫道：「處於食物鏈較低位置的人依賴於一線研究者的成果，而非精英機構中有抱負的研究人員則往往身處特權圈以外。」
1991年，當時在新墨西哥州洛斯阿拉莫斯國家實驗室工作的金斯帕格編寫了一個電子郵件自動應答程序，希望建立一個公平的競爭環境。訂閱者每天都會收到預印本列表，每一篇都與文章標識符相關聯。只需通過一封電子郵件，世界各地的用戶就可以從實驗室的計算機系統中提交或檢索論文，並獲得新論文的列表，或按作者或標題進行搜索。
金斯帕格的計劃是將論文保留三個月，並將內容限制在高能物理學界。但一位同事說服他無限期地保留這些文章。他說：「就在那一刻，它從布告欄變成了檔案館。」於是，論文開始從比各個領域如潮水般涌來。1993年，金斯伯格將這個系統遷移到互聯網上，並在1998年將其命名為arXiv.org，沿用至今。
arXiv成立已近30年，擁有約180萬份預印本，全部免費提供，而且每月有超過1.5萬份論文提交，下載量達3000萬次。十年前，《自然-光子學》（Nature Photonics）的編輯在評論arXiv創立20周年時寫道：「不難看出為什麼arXiv的服務會如此受歡迎，這個系統讓研究人員能快速而方便地插上旗幟，顯示他們所做的工作，同時避免投稿傳統同行評議期刊時的麻煩和時間成本。」
arXiv網站的成功也促進了生物學、醫學、 社會 學和其他學科同類預印本網站的繁榮。在如今已出版的數萬份關於新冠病毒的預印本中就可以看到這種影響。「很高興看到30年前在粒子物理學界之外被認為是異端的方法，現在被普遍認為是平淡無奇和自然而然的，」金斯伯格說，「從這個意義上說，它就像一個成功的研究項目。」
數據瀏覽器：IPython Notebook （2011年）
2001年，費爾南多·佩雷斯還是一位希望「尋找拖延症」的研究生，當時他決定採用Python的一個核心組件。
Python是一種解釋型語言，這意味著程序是逐行執行的。程序員可以使用一種稱為「讀取-評估-列印循環」（read–evaluate–print loop，簡稱REPL）的計算調用和響應工具，在其中輸入代碼，然後由解釋器執行代碼。REPL允許快速 探索 和迭代，但佩雷斯指出，Python的REPL並不是為科學目的而構建的。例如，它不允許用戶方便地預載入代碼模塊，也不允許打開數據可視化。因此，佩雷斯自己編寫了另一個版本。
結果就是IPython的誕生，這是一個「互動式」Python解釋器，由佩雷斯在2001年12月推出，共有259行代碼。十年後，佩雷斯與物理學家布萊恩·格蘭傑和數學家埃文·帕特森合作，將該工具遷移到web瀏覽器上，推出了IPython Notebook，開啟了一場數據科學革命。
與其他計算型Notebook一樣，IPython Notebook將代碼、結果、圖形和文本合並在一個文檔中。但與其他類似項目不同的是，IPython Notebook是開源的，邀請了大量開發者社區的參與其中。而且它支持Python，一種很受科學家歡迎的語言。2014年，IPython演變為Jupyter，支持大約100種語言，允許用戶在遠程超級計算機上 探索 數據，就像在自己的筆記本電腦上一樣輕松。
《自然》雜志在2018年寫道：「對於數據科學家，Jupyter實際上已經成為一個標准。」當時，在GitHub代碼共享平台上有250萬個Jupyter Notebook；如今，這一數字已經發展到1000萬個，在2016年引力波的發現，以及2019年的黑洞成像工作中，它們都發揮了重要的作用。佩雷斯說：「我們對這些項目做出了很小的貢獻，這是非常值得的。」
快速學習器：AlexNet（2012年）
人工智慧有兩種類型。一種是使用編碼規則，另一種則通過模擬大腦的神經結構來讓計算機「學習」。加拿大多倫多大學的計算機科學家傑弗里•辛頓表示，幾十年來，人工智慧研究人員一直認為後者是「一派胡言」。但在2012年，他的研究生亞力克斯·克里澤夫斯基和伊爾亞·蘇茨克維證明了事實並非如此。
在一年一度的ImageNet比賽中，研究人員被要求在一個包含100萬張日常物體圖像的資料庫中訓練人工智慧，然後在一個單獨圖像集上測試生成的演算法。辛頓表示，當時最好的演算法錯誤分類了大約四分之一的圖像。克里澤夫斯基和蘇茨克維的AlexNet是一種基於神經網路的「深度學習」演算法，它將錯誤率降低到了16%。辛頓說：「我們基本上把錯誤率減半了，或者說幾乎減半了。」
辛頓還指出，該團隊在2012年的成功反映了足夠大的訓練數據集與出色的編程，以及新出現的圖形處理單元的強大能力的結合。圖形處理單元是最初設計用來加速計算機視頻性能的處理器。「突然之間，我們可以將（演算法）運行速度提高30倍，」他說，「或者說，學習多達30倍的數據。」
真正的演算法突破實際上發生在三年前，當時辛頓的實驗室創建了一個神經網路，可以比經過幾十年改進的傳統人工智慧更准確地識別語音。「只是稍微好一點，」辛頓說，「但這已經預示了某些東西。」
這些成功預示著深度學習在實驗室研究、臨床醫學和其他領域的崛起。通過人工智慧的深度學習，手機能夠理解語音查詢，圖像分析工具能夠很容易地在顯微照片中識別出細胞；這就是為什麼AlexNet會成為眾多從根本上改變科學，也改變世界的工具之一。（任天）
⑶ ai晶元編譯器開發師前景
1.
如果要進入編譯器這個領域,AI晶元編譯器無疑是個好的選擇。不管AI晶元在國內能火多久,AI本身是一個趨勢已經沒有疑問。做AI晶元編譯器能加深對AI的理解,因為AI晶元編譯器不光涉及編譯器知識,還涉及AI晶元架構和並行計算如OpenCL/Cuda等。如果從深度學習平台獲得IR輸入,還需要了解深度學習平台如Tensorflow、TVM等。所以通過AI晶元編譯器開發,能對AI開發有更多了解。
2.
如果要進入AI領域,AI晶元編譯器不是個好選擇。因為編譯器領域的知識本身就非常艱深,和AI模型本身的關系也不是特別緊密,很難將AI建模作為發展方向,可以多關注GPGPU Architecture。即使AI晶元過氣了,GPGPU還是會長盛不衰。
⑷ vs編譯cv4.5必須要cuda環境嘛
先說一下我的需求：在win10中，顯卡是3070的機器上，使用的IDE是Qt，實現基於open pose的旗語的檢測。說白了就是自己編譯一個能使用cuda加速的一個opencv，利用opencv的dnn模塊的介面實現對深度學習模型的調用。在這里只記錄一個環境配置的過程。
本機環境：win10 RTX3070 Qt 5.9.2 msvc編譯器
下面只記錄比較重要的一些過程，給大家一些參考。
1、第一步，先安裝QT。大部分安裝Qt，就自帶了裡面的mingw編譯器，但是想要編譯能用cuda加速的opencv，我使用mingw編譯器，沒有把opencv編譯成功。我猜大概是mingw搞定不了opencv +cuda的編譯（不確定，猜想）。所以就安裝vs了。肯定需要安裝vs2015及其以上的版本，15，17，19三個版本中，查看了很多資料，了解到應該是2017在編譯opencv中最不容易出現問題。最好是用vs2017。
如果你在安裝QT過程中沒有選擇msvc2017的話，就應該得重新安裝一下了。Qt配置msvc編譯器的教程網路一下就可以。安裝完記得配置一下QT 的環境變數。記住根據自己的Qt安裝位置來配置。然後運行一下Qt能用說明第一步就完成了。
⑸ 「Keil C51」下如何讓編譯器優先使用片內「RAM」
C51內存結構深度剖析x0dx0a在編寫應用程序時，定義一個變數，一個數組，或是說一個固定表格，到底存儲在什麼地方；當定義變數大小超過MCU的內存范圍時怎麼辦；如何控制變數定義不超過存儲范圍；以及如何定義變數才能使得變數訪問速度最快，寫出的程序運行效率最高。以下將一一解答。x0dx0ax0dx0a1 六類關鍵字（六類存儲類型）x0dx0adata idata xdata pdata code bdatax0dx0ax0dx0a code： code memory （程序存儲器也即只讀存儲器）用來保存常量或是程序。code memory 採用16位地址線編碼，可以是在片內，或是片外，大小被限制在64KBx0dx0a 作用：定義常量，如八段數碼表或是編程使用的常，在定義時加上code 或明確指明定義的常量保存到code memory（只讀）x0dx0a 使用方法：x0dx0a char code table[]={0xc0,0xf9,0xa4,0xb0,0x99,0x92,0x82,0xf8,0x80,0x90};x0dx0a 此關鍵字的使用方法等同於constx0dx0ax0dx0adata data memory （數據存儲區）只能用於聲明變數，不能用來聲明函數，該區域位於片內，採用8位地址線編碼，具有最快的存儲速度，但是數量被限制在128byte或更少。x0dx0a 使用方法：x0dx0a unsigned char data fast_variable=0;x0dx0ax0dx0a idata idata memory（數據存儲區）只能用於聲明變數，不能用來聲明函數. 該區域位於片內，採用8位地址線編碼,內存大小被限制在256byte或更少。該區域的低地址區與data memory地址一致；高地址區域是52系列在51系列基礎上擴展的並與特殊功能寄存器具有相同地址編碼的區域。即：data memory是idata memory的一個子集。x0dx0a x0dx0a xdata xdata memory 只能用於聲明變數，不能用來聲明函數，該區域位於MCUx0dx0a 外部，採用16位地址線進行編碼，存儲大小被限制在64KB以內。x0dx0a 使用方法：x0dx0a unsigned char xdata count=0;x0dx0ax0dx0apdata pdata memory 只能用於聲明變數，不能用來聲明函數，該區域位於MCU外部，採用8位地址線進行編碼。存儲大小限制在256byte. 是xdata memory的低256byte。為其子集。x0dx0a 使用方法x0dx0a unsigned char pdata count=0;x0dx0ax0dx0a bdata bdata memory 只能用於聲明變數，不能用來聲明函數。該區域位於8051內部位數據地址。定義的量保存在內部位地址空間，可用位指令直接讀寫。x0dx0a 使用方法：x0dx0a unsigned char bdata varab=0x0dx0ax0dx0a 註：有些資料講，定義字元型變數時，在預設unsigned 時，字元型變數，默認為無符號，與標准C不同，但我在Keil uVision3中測試的時候發現並非如此。在預設的情況下默認為有符號。或許在以前的編譯器是默認為無符號。所以看到有的資料上面這樣講的時候，要注意一下，不同的編譯器或許不同。所以我們在寫程序的時候，還是乖乖的把unsigned signed 加上，咱也別偷這個懶。x0dx0a 2函數的參數和局部變數的存儲模式x0dx0a C51 編譯器允許採用三種存儲器模式：SMALL，COMPACT 和LARGE。一個函數的存儲器模式確定了函數的參數的局部變數在內存中的地址空間。處於SMALL模式下的函數參數和局部變數位於8051單片機內部RAM中，處於COMPACT和LARGE模式下的函數參數和局部變數則使用單片機外部RAM。在定義一個函數時可以明確指定該函數的存儲器模式。方法是在形參表列的後面加上一存儲模式。x0dx0a x0dx0a 示例如下：x0dx0a #pragma large //此預編譯必須放在所有頭文前面x0dx0a int func0(char x,y) small;x0dx0a char func1(int x) large;x0dx0a int func2(char x);x0dx0a 註：x0dx0a 上面例子在第一行用了一個預編譯命令#pragma 它的意思是告訴c51編譯器在對程序進行編譯時，按該預編譯命令後面給出的編譯控制指令LARGE進行編譯，即本常式序編譯時的默認存儲模式為LARGE.隨後定義了三個函數，第一個定義為SMALL存儲模式，第二個函數定義為LARGE第三個函數未指定，在用C51進行編譯時，只有最後一個函數按LARGE存儲器模式處理，其它則分別按它們各自指定的存儲器模式處理。x0dx0a 本例說明，C51編譯器允許採用所謂的存儲器混合模式，即允許在一個程序中將一些函數使用一種存儲模式，而其它一些則按另一種存儲器模式，採用存儲器混合模式編程，可以充分利用8051系列單片機中有限的存儲器空間，同時還可以加快程序的執行速度。x0dx0ax0dx0a3絕對地址訪問 absacc.h（相當重要）x0dx0ax0dx0a#define CBYTE ((unsigned char volatile code *) 0)x0dx0a#define DBYTE ((unsigned char volatile data *) 0)x0dx0a#define PBYTE ((unsigned char volatile pdata *) 0)x0dx0a#define XBYTE ((unsigned char volatile xdata *) 0)x0dx0a 功能：CBYTE 定址 CODE區x0dx0a DBYTE 定址 DATA區x0dx0a PBYTE 定址 XDATA（低256）區x0dx0a XBYTE 定址 XDATA區x0dx0a 例： 如下指令在對外部存儲器區域訪問地址0x1000x0dx0a xvar=XBYTE[0x1000];x0dx0a XBYTE[0x1000]=20;x0dx0ax0dx0a#define CWORD ((unsigned int volatile code *) 0)x0dx0a#define DWORD ((unsigned int volatile data *) 0)x0dx0a#define PWORD ((unsigned int volatile pdata *) 0)x0dx0a#define XWORD ((unsigned int volatile xdata *) 0)x0dx0ax0dx0a 功能：與前面的一個宏相似，只是它們指定的數據類型為unsigned int .。x0dx0a 通過靈活運用不同的數據類型，所有的8051地址空間都是可以進行訪問。x0dx0a 如x0dx0aDWORD[0x0004]=0x12F8;x0dx0a即內部數據存儲器中(0x08)=0x12; (0x09)=0xF8x0dx0ax0dx0a註：用以上八個函數，可以完成對單片機內部任意ROM和RAM進行訪問，非常方便。還有一種方法，那就是用指鍾，後面會對C51的指針有詳細的介紹。x0dx0ax0dx0a4寄存器變數（register）x0dx0a 為了提高程序的執行效率，C語言允許將一些頻率最高的那些變數，定義為能夠直接使用硬體寄存器的所謂的寄存器變數。定義一個變數時，在變數類型名前冠以「register」 即將該變數定義成為了寄存器變數。寄存器變數可以認為是一自動變數的一種。有效作用范圍也自動變數相同。由於計算機寄存器中寄存器是有限的。不能將所有變數都定義成為寄存器變數，通常在程序中定義寄存器變數時，只是給編譯器一個建議，該變數是否真正成為寄存器變數，要由編譯器根據實際情況來確定。另一方面，C51編譯器能夠識別程序中使用頻率最高的變數，在可能的情況下，即使程序中並未將該變數定義為寄存器變數，編譯器也會自動將其作為寄存器變數處理。被定義的變數是否真正能成為寄存器變數，最終是由編譯器決定的。x0dx0ax0dx0a5內存訪問雜談x0dx0a 1指鍾x0dx0a指鍾本身是一個變數，其中存放的內容是變數的地址，也即特定的數據。8051的地址是16位的，所以指針變數本身佔用兩個存儲單元。指針的說明與變數的說明類似，僅在指針名前加上「*」即可。x0dx0a 如 int *int_point; 聲明一個整型指針x0dx0a char *char_point; 聲明一個字元型指針x0dx0a 利用指針可以間接存取變數。實現這一點要用到兩個特殊運算符x0dx0a & 取變數地址x0dx0a * 取指針指向單元的數據x0dx0ax0dx0a示例一:x0dx0aint a,b;x0dx0a int *int_point; //定義一個指向整型變數的指針x0dx0a a=15;x0dx0a int_point=&a; //int_point指向 ax0dx0a *int_point=5; //給int_point指向的變數a 賦值5 等同於a=5; x0dx0a示例二:x0dx0a char i,table[6],*char_point;x0dx0a char_point=table;x0dx0a for(i=0;i<6;i++)x0dx0a {x0dx0a char_point=i;x0dx0a char_point++;x0dx0a}x0dx0a註：x0dx0a 指針可以進行運算，它可以與整數進行加減運算（移動指針）。但要注意，移動指針後，其地址的增減量是隨指針類型而異的，如，浮點指針進行自增後，其內部將在原有的基礎上加4，而字元指針當進生自增的時候，其內容將加1。原因是浮點數，佔4個內存單元，而字元佔一個位元組。x0dx0ax0dx0a宏晶科技最新一代STC12C5A360S2系列，每一個單片機出廠時都有全球唯一身份證號碼（ID號），用戶可以在單片機上電後讀取內部RAM單元F1H~F7H的數值，來獲取此單片機的唯一身份證號碼。使用MOV @Ri 指令來讀取。下面介紹C51 獲取方法：x0dx0a char id[7]={0};x0dx0a char i;x0dx0a char idata *point;x0dx0a for(i=0;i<7;i++)x0dx0a {x0dx0a id[i]=*point;x0dx0a point++;x0dx0a}x0dx0a x0dx0a（此處只是對指針做一個小的介紹，達到訪問內部任何空間的方式，後述有對指針使用的詳細介紹）x0dx0a2對SFR，RAM ，ROM的直接存取x0dx0aC51提供了一組可以直接對其操作的擴展函數x0dx0a若源程序中，用#include包含頭文件，io51.h 後，就可以在擴展函數中使用特殊功能寄存器的地址名，以增強程序的可讀性：x0dx0ax0dx0a 注 此方法對SFR,RAM,ROM的直接存取不建議使用.因為,淡io51.h這個頭文件在KEIL中無法打開，可用指針，或是採用absacc.h頭文件，
⑹ 華為解決了手機端操作系統，PC端操作系統如何解決，會不會收編深度
美國針對華為的「禁售令」，我們都為華為捏了一把汗，一個全球最強的國家，傾全國之力封鎖一家中國的公司。
晶元斷供，華為海思「備胎」晶元補上；手機操作系統斷供，華為「鴻蒙」操作系統補上；那麼，微軟斷供windows系統，有備胎計劃嗎？下文具體說一說。
余承東透漏，在今年秋天或者明年春天，華為將發布自研的操作系統，「 打通了手機、電腦、平板、智能穿戴，統一成一個操作系統 」。華為的操作系統基於Linux核心進行了優化，因此可以兼容手機的ARM架構和PC端的x86架構。
手機、電腦、智能穿戴設備採用統一的操作系統是否有可能？答案是可以的，比如蘋果的iphone、Mac電腦、apple watch均採用了蘋果的系統，IOS、MAC OS等均是基於UNIX系統的BSD分支。那麼華為的自研操作系統基於Linux，同樣可以做的兼容x86架構和arm架構的處理器。
眾所周知， 操作系統是否能夠成功，關鍵是其「生態鏈」 ，即圍繞操作系統的相關應用。比如手機操作系統的微信、QQ、淘寶、支付寶；電腦操作系統的office、作圖、辦公軟體等。
手機操作系統「生態鏈」
根據余承東的說法， 華為的手機操作系統兼容所有的安卓應用 ，並且對安卓應用通過「方舟編譯器」編譯之後，運行性能提升超過60%，可以媲美蘋果的IOS系統。既然常用的應用軟體可以使用，手機流暢度比安卓更好，我個人是非常期待華為手機操作系統的。
電腦操作系統「生態鏈」
為了能夠統一安裝到手機、電腦、智能穿戴設備，那麼華為操作系統必然選擇了linux核心。根據我使用ubuntu的經歷， linux電腦桌面發展已經很成熟，常用的辦公軟體、影音播放軟體、作圖軟體、編程軟體可以完美支持 。伺服器端更是不用愁，伺服器端可以說是linux一統天下了，windows server占的份額比較少。
總之，我對華為的操作系統比較有信心，華為的操作系統可能不會基於開源的android系統二次開發，而是在linux核心的基礎上替換掉android的相關東西，打通了手機、電腦、智能穿戴設備，形成統一的操作系統，兼容arm架構和x86架構的處理器。
華為可以解決宇宙間的一切問題！宇宙沒有華為地球不會自轉，宇宙沒有華為太陽不會發光，宇宙沒有華為行星就會隕落，宇宙沒有華為天空一片漆黑…………
只可惜華為從內到外就只是一個三流品質一流價格的水軍產品！！！
華為解決了手機端操作系統，PC端操作系統如何解決，會不會收編深度？從目前透露的鴻蒙系統信息來看，鴻蒙系統是可以在電腦端運行的，收編深度對其沒有太多意義，像現在一樣作為合作夥伴也是不錯的。
Deepin目前是國產Linux定製化做得不錯的PC端系統，圖形界面漂亮簡潔、對新手友好、最大程度符合了國人操作習慣，已經有一大批軟體可以在系統中使用。可以滿足個人或辦公通常的應用，比如系統中帶有微信、QQ、WPS、搜狗輸入法、網易雲音樂、網路雲等等，當然還有可以再深度商店中下載各種應用。當同樣也有硬體效能不足、CPU管控及顯示驅動支持不完善、很多驅動也沒有等等問題。
而作為華為花費了7年時間打造的被迫轉正的鴻蒙系統，是打通手機、電腦、平板、電視、 汽車 、智能穿戴的統一操作系統，均可以在這些設備上運行。並且兼容所有安卓應用和WEB應用，目前正在進行百萬台手機端的測試，並據測試數據表明比目前安卓要快體驗要好，而在PC端並沒有更多的消息。所以鴻蒙系統在電腦上也是可以使用的，如果Windows系統不被使用，那麼華為也可以使用自家鴻蒙系統。
PC端鴻蒙系統與深度系統應該是有所區別，對於華為來說兩個PC系統也沒有太多意義。專一打造好鴻蒙系統，在中國市場獲得桌面操作系統的部分份額。而在伺服器操作系統方面，華為已經與深度建立了合作關系，專門針對華為的TaiShan系列企業級伺服器定製打造操作系統產品。這種合作關系對於深度系統的發展會有更多促進。
華為本身也有系統研發體系，對Linux應該不陌生，至於收編深度，可能並沒有多大意義。而且深度公司也可能有自己的想法，未必就一定會賣掉自己。雖然目前的盈利點也並不多，產品及技術難度也並不會給華為帶來多少助益，反而保持這樣的合作雙方都可以收益，卻也並不會限制深度的發展。
我為什麼覺得華為系統和深度肯定有關系呢？
一方面，因為華為鴻蒙系統是基於Linux內核；而且余承東明確說了，將打通PC、手機、智能設備等等，形成一體化；而深度操作系統也是基於Linux內核，桌面應用為主的開源GNU/Linux操作系統。似乎有很多共同的地方，所以，我們似乎覺得華為和深度有關聯的可能性很大。
去年的時候，就有消息傳出，華為與深度達成合作，打造國產應用新平台。關鍵大家找到的點是：合作的taishan2280伺服器入選中央政府采購網信息類產品名錄。
其實，深度系統作為我國自己的操作系統，雖然沒有Windows強大，可是使用深度操作系統，你能感覺到桌面是非常「干凈」，能夠滿足日常辦公、家用需求。
而華為和深度的合作雖然是在伺服器上的合作，可是我們不能忽略華為和深度會在其他方面的合作，可能有的人說，華為的PC系統是華為雲方向，我並不認同。
其實，從華為目前的被美國制約來看，如果華為和深度合作，可以為它打通PC一體化很有幫助，畢竟深度的 歷史 也不短，技術也不俗。
當然，我們現在只是猜測，華為系統都沒有出現，我們也不能有太大的奢望，希望華為的系統可以有不一樣的發展，這才是我們期待看到的！
其實華為目前還有解決手機端的操作系統。
雖然華為發布了一款基於微內核的操作系統——鴻蒙OS，但是這款操作系統更多的是應用在物聯網之上而非用於手機端的操作系統，華為手機仍然是使用的Android操作系統，但是由於谷歌不再授權華為GMS服務，因此在海外市場多少會受到一些沖擊，國內由於谷歌退出了大陸市場，因此影響不大。
從長遠來看，鴻蒙系統或許未來會成為一個可以替代目前Android系統的新移動系統，但是這個系統的發展過程是非常深遠的。它必須要能超越目前的Android，帶來前所未有的新交互體驗，同時還要具備良好的生態環境。生態環境是支持一個系統持續發展下去的根本，不過好在華為的鴻蒙OS現在已經在面向開發者推出了軟體開發獎勵了。
至於PC端的系統，目前Mac OS僅支持蘋果適用於自家的Macbook，Windows仍然是全球覆蓋面最廣的PC操作系統，Linux是伺服器領域和Android軟體開發有著非常不錯的發揮，市場上基本都已經形成了穩定的局面，華為如果想推出自家的操作系統，讓然需要走非常長遠的路。
華為目前還沒有解決手機端操作系統！
美國商務部將華為列為實體名單，也就是說美國商務部正式開始封禁華為。盡管經過協調美國給出了90天的延期，很明顯這只是美國給出的一個「緩刑期」，這也是我們在沒有掌握絕對核心技術必須面對的挑戰。
在華為被禁之後，海思總裁何庭波給海思員工發出了一封公開郵件，何庭波在郵件中講述了海思成立的原因。
海思成立是當時的華為高層做了一個大家以為永遠不會發生的假設，現在回頭看看你可以說是高瞻遠矚，更多是深處在這樣的行業領域，隨時都存在的危機感讓華為被迫從最壞的假設出發，做出了一個很多人覺得匪夷所思的假設「假設某一天美國的晶元和先進技術不可得」。
因為這個看似不可能發生的假設，讓華為走上了自主創新的道路，華為開始自己研發晶元，包括通信晶元、手機處理器晶元。華為的處理器晶元已經被應用到了手機上，可是通信晶元一直是華為的備胎，只不過現在美國商務部真正應驗了，當然幸運的是華為的備胎足以成為應對方案。
美國商務部禁令出了以後，谷歌公司、微軟公司先後終止了與華為的部分合作，華為又只好被迫提前讓自研的鴻蒙操作系統提前曝光，並且最早在今年秋就會亮相。華為本來沒准備這么早亮劍，只不過沒想到華為不得不提前被迫出鞘亮劍。
中興被美國封禁以後，最終在我商務部的斡旋下，最終完成和解，過程是艱難的，最重要的是和解的代價是慘痛的、甚至可以說是極為慘重的。
作為和解的條件，中興必須向美方支付10億美金，並且額外拿出4億美元在第三方託管。而在此之前的2017年，中興已經向美國方面支付了超過8.92億美元的和解費，中興前後總共給美國支付了22.92億美元，這也是中國企業海外所支出的最大的罰款。
更大的代價是，中興兩家公司的董事會和管理層全部撤換，美國商務部哈講選派合規的協調員入住中興，工資還由中興支付，這些人直接向美國商務部和中興新董事會主席匯報工作，如果發現中興後期經營活動違反了協議，那麼美國方面有權隨時再次制裁中興。
總之，目前華為面臨的挑戰還很大，更大的挑戰還是中國整個技術行業面臨的挑戰，我們不知道在哪些領域我們還會受到一些技術上的限制，不過可以肯定的是咱也不是好欺負的，咱現在腰桿兒也開始硬了。
華為解決了手機端操作系統， PC 端操作系統如何解決，會不會收編深度？
你好樓主！我看了一下贊數和評論比較高的回答，發現他們由於回答時間較早，獲得的信息有限，現在我來補充一下答案。
在2019年8月舉行的華為開發者大會上，華為消費者總裁余承東正式提出了鴻蒙系統，並且大篇幅詳細地介紹了鴻蒙系統的全場景分布式特性以及未來的應用場景。
根據這張圖看來，在2020年時，搭載鴻蒙OS2.0的創新國產PC會正式落地，可見華為可能會使用鴻蒙系統代windows操作
系統。
而根據早前網傳的余承東言論
，鴻蒙OS打通了手機，電腦，平板，電視， 汽車 ，智能穿戴，統一成一個操作系統。如果消息屬實，那麼我們就可以確定華為電腦會使用鴻蒙系統，而非深度。
而且微博上有博主稱華為電腦會在明年初
發布。
不管怎麼樣，我們對華為鴻蒙系統不要抱有很快就能完善的想法，鴻蒙系統很可能在初期非常不完善，就如同當初的K2V3，在體驗上無法做到差強人意，畢竟華為當初沒有預料到美國竟然會制裁一家民營企業。
吾個人對華為操作系統相對悲觀，甚至絕望的給其判了死刑！ 如果迫於強勢壓力，吾等非得自研操作系統，那麼操作系統出於阿里、騰訊和網路的可能性最大，因為互聯網是開源、共享的代名詞，這也是開源操作系統賴以布局開花的前提條件！！！如若華為出此系統，小米OV等自避而遠之，開源之說則無從談起！然若華為東施效顰，欲學蘋果軟硬兼施、閉合生態，多半也只黃粱一夢；只因喬布斯腦門爆裂，前無古人、後無來著，開創iPhone時代，智能手機風潮雲涌之前，iOS早已泰山永固，而成世界獨一無二之閉合生態，再無他者插足之地！！！故此華為系統欲成其事，唯有擊破時代！撥弄起下一巨浪滔天，開創時代新品，賦能以系統生態，如此方能於江濤狂涌之前，完其大業！
華為對於操作系統其實早已經有了自有方案，余大嘴最早在今年年初的時候就提出過已經有B計劃，准備好了手機系統和電腦系統。而在美國封殺令後，余大嘴則持續爆料稱自研操作系統最快今秋面世，最晚明年春天，並且新系統是跨平台的系統！
由於是跨平台的系統， 也就等於華為自研的系統已經全面解決了手機和電腦這兩大終端，並且向外延伸至了平板、電視、智能穿戴以及 汽車 等設備，新系統採用了微內核結構。如果真是如此的話，華為的新系統絕對是下一代的操作系統，已經並非是我們當前理解上的操作系統了。
系統現狀： 現有的系統格局其實移動端和PC端是完全分開，Windows霸佔桌面領域，安卓和iOS占據手機系統，當然iOS其實也算是一個跨平台的系統，不僅被用於手機，也被用於平板、MAC電腦，以及智能穿戴設備上。
對於這種現狀，谷歌是不滿意的（包括對安卓系統的問題），因此其已經在打造下一代的新系統Fuchsia，也是跨平台的系統，基於微內核架構。去年外媒曾報道華為在榮耀 Play上測試該新系統。
華為系統： 如果將這些消息合並起來看，那華為顯然已經針對系統這塊做足的功夫，布好了局。此外，還需要注意一點事，華為在5G領域上的領先優勢，任正非在近期的采訪時已經說了，5G上至少領先2-3年。在面對5G這種能給整個信息產業帶來大變化的時刻，絕對是一個彎道超車的絕佳機會。所以華為的新系統一定是搭配著5G的技術和設備一起來打造的。也只有這樣，華為才可能繞過現有系統打造起來的壁壘，實現真正的超越，或者是使自己的成功更加事半功倍。
現在美國又封殺了華為，在我看來算是人為的創造出了一個較好的切換系統的時機，如果沒有封殺，華為單獨上線這個系統推廣時受到的阻力可能更大，不光是國內用戶，也包括谷歌這些巨頭，畢竟人家也是在搞類似的東西。現在被封堵後就可以正大光明的推系統，國內用戶的支持力度也會更好，即便在國際上也能多少獲得部分用戶的同情和認可。
所以，綜合現有信息來說，華為已經解決了手機和PC端的系統，也不會簡單的收購深度這類linux桌面系統。
首先華為是否真正解決了手機端操作系統，這還是個問號。需要等時間來驗證。因為建立在手機系統上的app生態鏈是最主要的。
對於電腦系統，首先假設微軟不給用windows了，這個只能是假設。早期電腦出廠多數都不預裝windows的，DOS，Linux這些免費都先裝上，你買回家自己裝就是了。
深度是基於linux的。很多應用軟體都是不支持的，只能應付下日常基本使用。對於很多專業領域的工作，其相應工程軟體僅支持windows，連蘋果的MAC OS都不支持。
所以對於電腦端操作系統來說，生態也是一道要命題。在這個別人已經深耕占據統治地位的地盤里，要插入一腳其艱難可以預見。
⑺ 為什麼需要改變編譯器
答案如下：
1.編譯器是把源程序的每一條語句都編譯成機器語言,並保存成二進制文件,這樣運行時計算機可以直接以機器語言來運行此程序,速度很快;
2.解釋器則是只在執行程序時,才一條一條的解釋成機器語言給計算機來執行,所以運行速度是不如編譯後的程序運行的快的.
3.因為計算機不能直接認識並執行我們寫的語句,它只能認識機器語言(是二進制的形式).
4.編譯是將源程序翻譯成可執行的目標代碼，翻譯與執行是分開的；而解釋是對源程序的翻譯與執行一次性完成，不生成可存儲的目標代碼。這只是表象，二者背後的最大區別是：對解釋執行而言，程序運行時的控制權在解釋器而不在用戶程序；對編譯執行而言，運行時的控制權在用戶程序。
4.編譯器在優化過程中採用了自動或半自動的代碼生成用以替代人工優化。人的精力是有限的，通過（接近無限）的算力去適配每一個應用場景看到的網路，改變編譯器，這是編譯技術比人工路線強的所在。