你是否經常會聽到人們把 Linux 及 BSD 系統混為一談?是的,我有時會經常聽到一些新手,甚至于媒體都這么說。當然,事實上這兩者確實有很多相似之處,比如它們都是基于 Unix 演變而來,而且基本上這兩類系統都是由非盈利組織及團隊開發,另外我更想說的是,這兩個系統都有一個共同的目標–那就是創建最有用、最可靠的操作系統。
不過話說回來,這兩個系統確實存在著明顯的差異,當人們忽略這點的時候,整個 BSD 社區都會感到異常的憤怒,因此我們也可以經??吹?BSD
社區人員或 BSD 用戶會對 Linux 不屑一顧。因此,我會盡我所能來幫助我的 BSD 的弟兄們,讓更多的人了解到 Linux 與 BSD
的不同之處在哪里。
1、許可證
正如我們所知道的,Linux 操作系統是基于 GPL 許可證授權下的。該許可證可防止開源軟件被轉換為封閉源代碼軟件及確保源代碼的可用性。 GPL 許可證的目的就是防止二進制包成為唯一的軟件發行源。
而 BSD 許可證的限制則要少得多,它甚至允許二進制包成為唯一的發行源。這就是核心差異,可以這樣理解:GPL 許可證讓您有權擁有任何你想要使用該軟件的方法,但你必須確保提供源代碼給下一個使用它的人(包括你對它的改變部分)。而 BSD 許可證并不是要求你必須那么做。( 譯者注:這里分別維基百科上對 BSD 及 GPL 許可證的解釋)
2、代碼控制
BSD 的代碼不是被控制在任何一個人手里,而 Linux 的內核基本上被 Linus Torvalds ( Linux 創始人 ) 所控制,BSD 并沒有單一的人來說什么可以或什么不可以進入代碼。 <script src="/javascripts/tinymce/themes/advanced/langs/zh.js" type="text/javascript"></script><script src="/javascripts/tinymce/plugins/javaeye/langs/zh.js" type="text/javascript"></script> 相反,BSD 通過一個核心小組 ” Core Team” 來管理該項目,這個核心小組比非核心小組有更多的發言權來指導 BSD 社區的發展方向,(譯者注:而據我所知,FreeBSDD 核心小組的成員會每兩年選舉一次。)
3、內核 vs 操作系統
BSD 項目維護的是整個操作系統,而 Linux 則只是主要集中在單一的內核上面。這點確實是需要注意的,雖然這兩個系統上都運行著許多相同的軟件。
4、UNIX-Like
這里有一個關于 BSD vs Linux 的古老說法:” BSD is what you get when a bunch of UNIX hackers sit down to try to port a UNIX system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a UNIX system for the PC “,這里表達了很多。你會發現 BSD 系統更為類似于 UNIX ,而事實上它就是傳統 UNIX 的直接衍生品。而 Linux ,則是一個松散的基于 UNIX 衍生品 ( Minix ) 而新創建的一個 OS 。
5、基本系統
這是一個關于 BSD 與 Linux 之間差異的至關重要的理念。 Linux 的”基本系統” 是并不真正存在的,許多人會說,Linux 的基本系統就是內核,但問題是如果沒有任何可用的應用程序的話,那么這個內核是完全沒有價值的。而另一方面,BSD 則有一個包括眾多工具的基本系統, 甚至 libc 也是基本系統的一部分。因為這些組件都被作為一個基本系統,所以它們都是被一起開發和打包的,許多事實表明這樣更能創建出一個更具凝聚力的整體。
6、更多來自于源代碼
由于 BSD 的開發方式(使用 Ports 系統 ) 的關系,所以用戶們更多的是從源代碼來安裝程序,而不是預先編譯好的二進制包。這是一個優勢還是劣勢?這取決于不同的用戶。如果你更多的想從友好或易用性 方面考慮的話,看到這一點后你也許會有放棄的念頭,對于新用戶更是如此。但一些新的用戶也有想要從源代碼編譯安裝,這可能比較累人。但是,從源碼安裝也有 一定的優勢,比如(庫版本控制,通過特殊的包來構建系統等等)。
7、升級
由于 BSD 的開發方式的原因(見第5項),你可以利用一條指令就可以升級你的基本系統到最新版本 ( Freebsd 下是用 freebsd-update fetch update 命令)。或者你也可以下載整個源代碼樹,然后通過編譯來升級。而在 Linux 中,你也可以通過內置的包管理系統來升級系統。前者 (BSD) 僅更新基本系統,而后者 ( Linux ) 則會升級整個系統。不過請記住,BSD 中升級到最新的基本系統并不意味著所有的附加軟件包也將會被更新,而 Linux 升級的時候,所有的軟件包都會被升級。這是否意味著 Linux 處理得更好嗎?在我看未必。我經常會看到 Linux 在升級時出現嚴重錯誤,從而需要重新安裝整個系統,但這個現象基本不太可能發生在 BSD 的升級過程中。
8、前沿技術
基本上你不太可能會看到 BSD 系統運行著任何非常前沿版本的軟件。而在 Linux 這一方面,大量的發行版會分發前沿版本的軟件包。如果你是一個 ” If it isn’t broken, don’t fix it” 這樣觀點的持有者的話,你將會是 BSD 的超級粉絲。但是,如果你很新潮,想要體驗一切最新的東西,那么你最好盡快遷移到 Linux 。
9、硬件支持
你會發現,通常情況下 Linux 的硬件支持要比 BSD 更早一些。但這并不是說 BSD 沒有像 Linux 那樣支持足夠多的硬件,它只是意味著在某些情況下 Linux 會在 BSD 之前先支持某些硬件。因此,如果你想要最新的、最好的顯卡的話,基本上不用考慮 BSD 了。如果你有一個包含了最新無線芯片的新型筆記本的話,建議你選擇 Linux,運氣好的話也許它會支持。
10、用戶群
在這里我冒險概括一下計算機用戶們,但我想先聲明一下每一個事物都有例外。下面我要向你展示我對用戶分布方面的概括。
Mac –> Windows –> Linux –> BSD –> UNIX
從左邊到右邊,分別是”使用該 OS 的人里精通電腦的用戶群最少”到”使用該 OS 的人里精通電腦的用戶群最多”的過渡。我們可以看到,Linux的被放置在了中間,而 BSD 則更接近于右邊。許多人會對此有爭論,也有些人可能會感覺被冒犯了。但是,個人認為這是一個對”哪些用戶使用哪些系統”相當準確的概括。
其他的不同點?
這個列表并不想表明哪個系統比哪個更好。事實上,BSD 和 Linux 各有著自己的亮點。你認為怎么樣?有興趣的話也請表達出你的觀點。
RabbitVCS是Linux下替代TortoiseSVN的一個可視化工具,非常不錯!
1. Go to http://wiki.rabbitvcs.org/wiki/download and click on the PPA link
2. Add "deb http://ppa.launchpad.net/rabbitvcs/ppa/ubuntu lucid main" to
/etc/apt/sources.list as requested
3. sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 34EF4A35
4. sudo apt-get update
5. sudo apt-get install rabbitvcs-cli rabbitvcs-core rabbitvcs-gedit rabbitvcs-nautilus rabbitvcs-thunar thunarx-python
6. reboot
SRT Sources
網易(速度很快)
ubuntu官方上海源,提供 Kernel,Hiweed,ubuntu
搜狐
骨頭源,骨頭源是bones7456架設的一個Ubuntu源 ,提供ubuntu,deepin
en_GB.UTF-8
locale
/var/lib/locales/supported.d/local
and add the following line:en_GB ISO-8859-1
sudo dpkg-reconfigure locales
/etc/environment
and ensure
the LANG
and LANGUAGE
lines read as follows:LANG="en_GB"
LANGUAGE="en_GB:en"
/etc/default/locale
rather than /etc/environment
- Thanks Guy!locale
to check that your default locale is now en_GB
LANG="en_US.UTF-8"
LANGUAGE="en_US:en"
2、sudo reboot
3、locale
顯示環境變量已經全部是英文1、輸入用戶管理的命令,新建用戶(以test為例):
useradd test
修改 test 用戶的密碼:
passwd test
2、將新用戶添加到管理組:
gpasswd -a test admin
3、給 test 用戶創建自己的目錄:
cd /home
mkdir test
chown test /home/test
4、重新啟動,
reboot
然后用 test 登錄,
登錄以后,點菜單“系統-系統管理-用戶和組”,進去選中你的用戶,點右邊的“屬性”按鈕,到用戶權限里打勾需要的;
sudo apt-get install mplayer mozilla-mplayer
安裝mplayer的插件。
同時在about:config里增加了兩個配置項:
Network.protocol-handler.app.mms string /usr/bin/mplayer
Network.protocal-handler.external.mms boolean True
restart it ,就OK了。
同時可以參考:
1、安裝軟件和相應解碼器
sudo apt-get install mplayer mozilla-mplayer totem-xine libxine-extracodecs w32codecs audacious
sudo gedit /etc/network/interface
將其內容刪除
加上一下內容
auto lo
iface lo inet loopback
auto etho
iface etho inet static
address 192.168.0.168
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
保存
然后修改DNS
sudo gedit /etc/resolv.conf
將內容修改為
nameserver 202.103.24.68
保存
重啟網絡連接
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
打開終端,執行以下命令,或使用Adept/新立得軟件管理器,在其中分別搜索"sun-java6-jre"和"sun-java6-jdk"并標記安裝。
sudo apt-get install sun-java6-jre
如果空間富裕,建議安裝一個JDK。
sudo apt-get install sun-java6-jdk
提示:安裝過程中需要你回答是否同意使用協議(終端中紅藍色的提示界面),此時按tab鍵至OK,再按回車即可正常安裝。
設置當前默認的java解釋器:
sudo update-alternatives --config java
執行后會出現類似如下的畫面:
There are 2 alternatives which provide `java'.
Selection Alternative
-----------------------------------------------
1 /usr/bin/gij-wrapper-4.1
*+ 2 /usr/lib/jvm/java-6-sun/jre/bin/java
Press enter to keep the default[*], or type selection number:
輸入 有包含 "sun" 的行的前面的數字。如上面顯示,則輸入2,然后回車確定。
配置JAVA環境變量:
sudo gedit /etc/environment
在其中添加如下兩行:
CLASSPATH=.:/usr/lib/jvm/java-6-sun/libv
JAVA_HOME=/usr/lib/jvm/java-6-sun
sudo gedit /etc/jvm
將文件中的
/usr/lib/jvm/java-6-sun
這一行填入到配置塊的頂部
安裝瀏覽器的JAVA Plugin(可選):
sudo apt-get install sun-java6-plugin
mod_python is similar to (and inspired by) mod_perl : It embeds Python within Apache and loads Python code into memory when the server starts. Code stays in memory throughout the life of an Apache process, which leads to significant performance gains over other server arrangements.
Django requires Apache 2.x and mod_python 3.x, and you should use Apache’s prefork MPM, as opposed to the worker MPM.
You may also be interested in How to use Django with FastCGI, SCGI or AJP (which also covers SCGI and AJP).
To configure Django with mod_python, first make sure you have Apache installed, with the mod_python module activated.
Then edit your httpd.conf file and add the following:
<Location "/mysite/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite
PythonDebug On
</Location>
...and replace mysite.settings with the Python import path to your Django project's settings file.
This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the Django mod_python handler." It passes the value of DJANGO_SETTINGS_MODULE so mod_python knows which settings to use.
Because mod_python does not know we are serving this site from underneath the /mysite/ prefix, this value needs to be passed through to the mod_python handler in Django, via the PythonOption django.root ... line. The value set on that line (the last item) should match the string given in the <Location ...> directive. The effect of this is that Django will automatically strip the /mysite string from the front of any URLs before matching them against your URLConf patterns. If you later move your site to live under /mysite2, you will not have to change anything except the django.root option in the config file.
When using django.root you should make sure that what's left, after the prefix has been removed, begins with a slash. Your URLConf patterns that are expecting an initial slash will then work correctly. In the above example, since we want to send things like /mysite/admin/ to /admin/, we need to remove the string /mysite from the beginning, so that is the django.root value. It would be an error to use /mysite/ (with a trailing slash) in this case.
Note that we're using the <Location> directive, not the <Directory> directive. The latter is used for pointing at places on your filesystem, whereas <Location> points at places in the URL structure of a Web site. <Directory> would be meaningless here.
Also, if your Django project is not on the default PYTHONPATH for your computer, you'll have to tell mod_python where your project can be found:
<Location "/mysite/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite
PythonDebug On
PythonPath "['/path/to/project'] + sys.path"
</Location>
The value you use for PythonPath should include the parent directories of all the modules you are going to import in your application. It should also include the parent directory of the DJANGO_SETTINGS_MODULE location. This is exactly the same situation as setting the Python path for interactive usage. Whenever you try to import something, Python will run through all the directories in sys.path in turn, from first to last, and try to import from each directory until one succeeds.
An example might make this clearer. Suppose you have some applications under /usr/local/django-apps/ (for example, /usr/local/django-apps/weblog/ and so forth), your settings file is at /var/www/mysite/settings.py and you have specified DJANGO_SETTINGS_MODULE as in the above example. In this case, you would need to write your PythonPath directive as:
PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path"
With this path, import weblog and import mysite.settings will both work. If you had import blogroll in your code somewhere and blogroll lived under the weblog/ directory, you would also need to add /usr/local/django-apps/weblog/ to your PythonPath. Remember: the parent directories of anything you import directly must be on the Python path.
Note
If you're using Windows, we still recommended that you use forward slashes in the pathnames, even though Windows normally uses the backslash character as its native separator. Apache knows how to convert from the forward slash format to the native format, so this approach is portable and easier to read. (It avoids tricky problems with having to double-escape backslashes.)
This is valid even on a Windows system:
PythonPath "['c:/path/to/project'] + sys.path"
You can also add directives such as PythonAutoReload Off for performance. See the mod_python documentation for a full list of options.
Note that you should set PythonDebug Off on a production server. If you leave PythonDebug On, your users would see ugly (and revealing) Python tracebacks if something goes wrong within mod_python.
Restart Apache, and any request to /mysite/ or below will be served by Django. Note that Django's URLconfs won't trim the "/mysite/" -- they get passed the full URL.
When deploying Django sites on mod_python, you'll need to restart Apache each time you make changes to your Python code.
It's entirely possible to run multiple Django installations on the same Apache instance. Just use VirtualHost for that, like so:
NameVirtualHost *
<VirtualHost *>
ServerName www.example.com
# ...
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</VirtualHost>
<VirtualHost *>
ServerName www2.example.com
# ...
SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
</VirtualHost>
If you need to put two Django installations within the same VirtualHost (or in different VirtualHost blocks that share the same server name), you'll need to take a special precaution to ensure mod_python's cache doesn't mess things up. Use the PythonInterpreter directive to give different <Location> directives separate interpreters:
<VirtualHost *>
ServerName www.example.com
# ...
<Location "/something">
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonInterpreter mysite
</Location>
<Location "/otherthing">
SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
PythonInterpreter othersite
</Location>
</VirtualHost>
The values of PythonInterpreter don't really matter, as long as they're different between the two Location blocks.
If you use mod_python for your development server, you can avoid the hassle of having to restart the server each time you make code changes. Just set MaxRequestsPerChild 1 in your httpd.conf file to force Apache to reload everything for each request. But don't do that on a production server, or we'll revoke your Django privileges.
If you're the type of programmer who debugs using scattered print statements, note that print statements have no effect in mod_python; they don't appear in the Apache log, as one might expect. If you have the need to print debugging information in a mod_python setup, either do this:
assert False, the_value_i_want_to_see
Or add the debugging information to the template of your page.
Django doesn't serve media files itself; it leaves that job to whichever Web server you choose.
We recommend using a separate Web server -- i.e., one that's not also running Django -- for serving media. Here are some good choices:
If, however, you have no option but to serve media files on the same Apache VirtualHost as Django, here's how you can turn off mod_python for a particular part of the site:
<Location "/media">
SetHandler None
</Location>
Just change Location to the root URL of your media files. You can also use <LocationMatch> to match a regular expression.
This example sets up Django at the site root but explicitly disables Django for the media subdirectory and any URL that ends with .jpg, .gif or .png:
<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>
<Location "/media">
SetHandler None
</Location>
<LocationMatch "".(jpg|gif|png)$">
SetHandler None
</LocationMatch>
Note that the Django development server automagically serves admin media files, but this is not the case when you use any other server arrangement. You're responsible for setting up Apache, or whichever media server you're using, to serve the admin files.
The admin files live in (django/contrib/admin/media) of the Django distribution.
Here are two recommended approaches:
If you installed Django from a Python egg or are using eggs in your Django project, some extra configuration is required. Create an extra file in your project (or somewhere else) that contains something like the following:
import os
os.environ['PYTHON_EGG_CACHE'] = '/some/directory'
Here, /some/directory is a directory that the Apache webserver process can write to. It will be used as the location for any unpacking of code the eggs need to do.
Then you have to tell mod_python to import this file before doing anything else. This is done using the PythonImport directive to mod_python. You need to ensure that you have specified the PythonInterpreter directive to mod_python as described above (you need to do this even if you aren't serving multiple installations in this case). Then add the PythonImport line in the main server configuration (i.e., outside the Location or VirtualHost sections). For example:
PythonInterpreter my_django
PythonImport /path/to/my/project/file.py my_django
Note that you can use an absolute path here (or a normal dotted import path), as described in the mod_python manual. We use an absolute path in the above example because if any Python path modifications are required to access your project, they will not have been done at the time the PythonImport line is processed.
When you use Apache/mod_python, errors will be caught by Django -- in other words, they won't propagate to the Apache level and won't appear in the Apache error_log.
The exception for this is if something is really wonky in your Django setup. In that case, you'll see an "Internal Server Error" page in your browser and the full Python traceback in your Apache error_log file. The error_log traceback is spread over multiple lines. (Yes, this is ugly and rather hard to read, but it's how mod_python does things.)
If Apache causes a segmentation fault, there are two probable causes, neither of which has to do with Django itself.
If you continue to have problems setting up mod_python, a good thing to do is get a barebones mod_python site working, without the Django framework. This is an easy way to isolate mod_python-specific problems. Getting mod_python Working details this procedure.
The next step should be to edit your test code and add an import of any Django-specific code you're using -- your views, your models, your URLconf, your RSS configuration, etc. Put these imports in your test handler function and access your test URL in a browser. If this causes a crash, you've confirmed it's the importing of Django code that causes the problem. Gradually reduce the set of imports until it stops crashing, so as to find the specific module that causes the problem. Drop down further into modules and look into their imports, as necessary.
File "/tmp/easy_install-nHSsgl/MySQL-python-1.2.2/setup_posix.py", line 26, in mysql_config
EnvironmentError: mysql_config not found
后來發現是由于Mysql編譯安裝后沒有 mysql_config這個值,解決方法:
打開 setup_posix.py, 將其中line:26手動改成系統中對應的Mysql選項(這里我的是/usr/local/mysql):
mysql_config = /usr/local/mysql/bin/mysql_config
重新執行 :python setup.py build,沒有了剛才的錯誤,但是出現了另外一個錯誤:
error: /usr/bin/ld: cannot find -lmysqlclient
網上搜索了一下這個錯誤,發現有幾種不同的情況,主要有以下幾個原因:
1.沒有安裝mysqlclient。解決方法:找到對應的版本進行安裝。
2.安裝的mysqlclient的版本不匹配。對應鏈接: http://www.hao32.com/webserver/258.html
3.已經安裝了對應的mysqlclient但是找不到對應的鏈接。這是在一個國外的網站上看到的,具體網址已經找不到了,后來那位仁兄將對應的
mysql_home/lib/mysql文件夾下面libmysqlclient對應的文件全部拷貝到/usr/local/lib下面才解決了問題。
按照對應方案,問題解決。
重新執行:
python setup.py build
python setup.py install
安裝完成。
### CentOS-4 APT repository
rpm http://mirror.be10.com centos/4/apt/i386 os addons updates extras
rpm http://mirror.be10.com centos/4/apt/i386 contrib centosplus
[base]
name=CentOS-4 - Base
baseurl=http://mirror.be10.com/centos/4/os/i386/
gpgcheck=1
#released updates
[update]
name=CentOS-4 - Updates
baseurl=http://mirror.be10.com/centos/4/updates/i386/
gpgcheck=1
#packages used/produced in the build but not released
[addons]
name=CentOS-4 - Addons
baseurl=http://mirror.be10.com/centos/4/addons/i386/
gpgcheck=1
#additional packages that may be useful
[extras]
name=CentOS-4 - Extras
baseurl=http://mirror.be10.com/centos/4/extras/i386/
gpgcheck=1
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-4 - Plus
baseurl=http://mirror.be10.com/centos/4/centosplus/i386/
gpgcheck=1
enabled=0
#contrib - packages by Centos Users
[contrib]
name=CentOS-4 - Contrib
baseurl=http://mirror.be10.com/centos/4/contrib/i386/
gpgcheck=1
enabled=0
#packages in testing
[testing]
name=CentOS-4 - Testing
baseurl=http://mirror.be10.com/centos/4/testing/i386/
gpgcheck=1
enabled=0
一、查看所有環境變量的名稱和值:
Linux下:export
Windows下:set
二、根據名稱查該環境變量的值:
Linux下:echo $環境變量名
比如:echo $ORACLE_HOME
Windows下:set 環境變量名
Wicd的功能:
無需依賴Gnome運行環境 (盡管它確實需要GTK),就是說可以在XFCE、Fluxbox, Openbox、Enlightenment 等X下使用
可以管理有線和無線網絡連接
每個無線和有線網絡連接都有獨立的配置文件
支持多種加密方式,包括 WEP、WPA、WPA2 等
保持了對 wireless-tools 的兼容性
在系統托盤顯示網絡狀況和信號強度
在Ubuntu中安裝 Wicd:
首先編輯 /etc/apt/sources.list 文件
sudo gedit /etc/apt/sources.list
7.10 (gutsy) 在里面添加如下一行:
deb http://apt.wicd.net gutsy extras
8.04 (hardy) 用戶在里面添加這行:
deb http://apt.wicd.net hardy extras
保存退出
現在用下面的命令更新源列表
sudo aptitude update
通過下面這行命令安裝 wicd
sudo aptitude install wicd
請注意,此操作將刪除GNOME的默認網絡管理器 network-manager,可能導致暫時失去網絡連接。
在GNOME中,如果您想讓它自動啟動并顯示系統托盤圖標。那么請在 系統→首選項→會話 的 啟動程序 標簽中點擊 添加。設定個名字(比如”Wicd”)并在命令一欄中輸入 “/opt/wicd/tray.py”。
啟動后效果如下:
使用 Wicd
在GNOME中通過應用程序菜單啟動 wicd 的方法是點擊 應用程序→互聯網→Wicd。
在wicd的窗口中您將看見一個系統檢測到的無線網絡列表。有時 Wicd 在剛啟動的時候不能搜索到所有范圍內的無線網絡。請點擊工具條上的刷新按鈕來重新搜索。
點擊網絡名稱下面的那個 連接 后稍候幾秒就應該連上您選擇的網絡了。
如果網絡是加密的,您需要再干點兒活兒。Wicd支持的加密方式包括:WPA、WEP、LEAP、TTLS、EAP 和 PEAP。
點擊您要連接的那個網絡名稱邊上的箭頭,然后點擊高級設置。在這里選中 Use Encryption 框,并在下拉菜單里選擇對應的加密方式,最后在密鑰欄填上您的密碼。
卻提示 sendmail.mc:10: m4: Cannot open /usr/share/sendmail-cf/m4/cf.m4: No such file or directory
這是因為沒有安裝sendmai-cf這個包
安裝完成后問題解決