你是否經(jīng)常會(huì)聽(tīng)到人們把 Linux 及 BSD 系統(tǒng)混為一談?是的,我有時(shí)會(huì)經(jīng)常聽(tīng)到一些新手,甚至于媒體都這么說(shuō)。當(dāng)然,事實(shí)上這兩者確實(shí)有很多相似之處,比如它們都是基于 Unix 演變而來(lái),而且基本上這兩類系統(tǒng)都是由非盈利組織及團(tuán)隊(duì)開(kāi)發(fā),另外我更想說(shuō)的是,這兩個(gè)系統(tǒng)都有一個(gè)共同的目標(biāo)–那就是創(chuàng)建最有用、最可靠的操作系統(tǒng)。
不過(guò)話說(shuō)回來(lái),這兩個(gè)系統(tǒng)確實(shí)存在著明顯的差異,當(dāng)人們忽略這點(diǎn)的時(shí)候,整個(gè) BSD 社區(qū)都會(huì)感到異常的憤怒,因此我們也可以經(jīng)常看到 BSD
社區(qū)人員或 BSD 用戶會(huì)對(duì) Linux 不屑一顧。因此,我會(huì)盡我所能來(lái)幫助我的 BSD 的弟兄們,讓更多的人了解到 Linux 與 BSD
的不同之處在哪里。
1、許可證
正如我們所知道的,Linux 操作系統(tǒng)是基于 GPL 許可證授權(quán)下的。該許可證可防止開(kāi)源軟件被轉(zhuǎn)換為封閉源代碼軟件及確保源代碼的可用性。 GPL 許可證的目的就是防止二進(jìn)制包成為唯一的軟件發(fā)行源。
而 BSD 許可證的限制則要少得多,它甚至允許二進(jìn)制包成為唯一的發(fā)行源。這就是核心差異,可以這樣理解:GPL 許可證讓您有權(quán)擁有任何你想要使用該軟件的方法,但你必須確保提供源代碼給下一個(gè)使用它的人(包括你對(duì)它的改變部分)。而 BSD 許可證并不是要求你必須那么做。( 譯者注:這里分別維基百科上對(duì) BSD 及 GPL 許可證的解釋)
2、代碼控制
BSD 的代碼不是被控制在任何一個(gè)人手里,而 Linux 的內(nèi)核基本上被 Linus Torvalds ( Linux 創(chuàng)始人 ) 所控制,BSD 并沒(méi)有單一的人來(lái)說(shuō)什么可以或什么不可以進(jìn)入代碼。 <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 通過(guò)一個(gè)核心小組 ” Core Team” 來(lái)管理該項(xiàng)目,這個(gè)核心小組比非核心小組有更多的發(fā)言權(quán)來(lái)指導(dǎo) BSD 社區(qū)的發(fā)展方向,(譯者注:而據(jù)我所知,F(xiàn)reeBSDD 核心小組的成員會(huì)每?jī)赡赀x舉一次。)
3、內(nèi)核 vs 操作系統(tǒng)
BSD 項(xiàng)目維護(hù)的是整個(gè)操作系統(tǒng),而 Linux 則只是主要集中在單一的內(nèi)核上面。這點(diǎn)確實(shí)是需要注意的,雖然這兩個(gè)系統(tǒng)上都運(yùn)行著許多相同的軟件。
4、UNIX-Like
這里有一個(gè)關(guān)于 BSD vs Linux 的古老說(shuō)法:” 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 “,這里表達(dá)了很多。你會(huì)發(fā)現(xiàn) BSD 系統(tǒng)更為類似于 UNIX ,而事實(shí)上它就是傳統(tǒng) UNIX 的直接衍生品。而 Linux ,則是一個(gè)松散的基于 UNIX 衍生品 ( Minix ) 而新創(chuàng)建的一個(gè) OS 。
5、基本系統(tǒng)
這是一個(gè)關(guān)于 BSD 與 Linux 之間差異的至關(guān)重要的理念。 Linux 的”基本系統(tǒng)” 是并不真正存在的,許多人會(huì)說(shuō),Linux 的基本系統(tǒng)就是內(nèi)核,但問(wèn)題是如果沒(méi)有任何可用的應(yīng)用程序的話,那么這個(gè)內(nèi)核是完全沒(méi)有價(jià)值的。而另一方面,BSD 則有一個(gè)包括眾多工具的基本系統(tǒng), 甚至 libc 也是基本系統(tǒng)的一部分。因?yàn)檫@些組件都被作為一個(gè)基本系統(tǒng),所以它們都是被一起開(kāi)發(fā)和打包的,許多事實(shí)表明這樣更能創(chuàng)建出一個(gè)更具凝聚力的整體。
6、更多來(lái)自于源代碼
由于 BSD 的開(kāi)發(fā)方式(使用 Ports 系統(tǒng) ) 的關(guān)系,所以用戶們更多的是從源代碼來(lái)安裝程序,而不是預(yù)先編譯好的二進(jìn)制包。這是一個(gè)優(yōu)勢(shì)還是劣勢(shì)?這取決于不同的用戶。如果你更多的想從友好或易用性 方面考慮的話,看到這一點(diǎn)后你也許會(huì)有放棄的念頭,對(duì)于新用戶更是如此。但一些新的用戶也有想要從源代碼編譯安裝,這可能比較累人。但是,從源碼安裝也有 一定的優(yōu)勢(shì),比如(庫(kù)版本控制,通過(guò)特殊的包來(lái)構(gòu)建系統(tǒng)等等)。
7、升級(jí)
由于 BSD 的開(kāi)發(fā)方式的原因(見(jiàn)第5項(xiàng)),你可以利用一條指令就可以升級(jí)你的基本系統(tǒng)到最新版本 ( Freebsd 下是用 freebsd-update fetch update 命令)。或者你也可以下載整個(gè)源代碼樹(shù),然后通過(guò)編譯來(lái)升級(jí)。而在 Linux 中,你也可以通過(guò)內(nèi)置的包管理系統(tǒng)來(lái)升級(jí)系統(tǒng)。前者 (BSD) 僅更新基本系統(tǒng),而后者 ( Linux ) 則會(huì)升級(jí)整個(gè)系統(tǒng)。不過(guò)請(qǐng)記住,BSD 中升級(jí)到最新的基本系統(tǒng)并不意味著所有的附加軟件包也將會(huì)被更新,而 Linux 升級(jí)的時(shí)候,所有的軟件包都會(huì)被升級(jí)。這是否意味著 Linux 處理得更好嗎?在我看未必。我經(jīng)常會(huì)看到 Linux 在升級(jí)時(shí)出現(xiàn)嚴(yán)重錯(cuò)誤,從而需要重新安裝整個(gè)系統(tǒng),但這個(gè)現(xiàn)象基本不太可能發(fā)生在 BSD 的升級(jí)過(guò)程中。
8、前沿技術(shù)
基本上你不太可能會(huì)看到 BSD 系統(tǒng)運(yùn)行著任何非常前沿版本的軟件。而在 Linux 這一方面,大量的發(fā)行版會(huì)分發(fā)前沿版本的軟件包。如果你是一個(gè) ” If it isn’t broken, don’t fix it” 這樣觀點(diǎn)的持有者的話,你將會(huì)是 BSD 的超級(jí)粉絲。但是,如果你很新潮,想要體驗(yàn)一切最新的東西,那么你最好盡快遷移到 Linux 。
9、硬件支持
你會(huì)發(fā)現(xiàn),通常情況下 Linux 的硬件支持要比 BSD 更早一些。但這并不是說(shuō) BSD 沒(méi)有像 Linux 那樣支持足夠多的硬件,它只是意味著在某些情況下 Linux 會(huì)在 BSD 之前先支持某些硬件。因此,如果你想要最新的、最好的顯卡的話,基本上不用考慮 BSD 了。如果你有一個(gè)包含了最新無(wú)線芯片的新型筆記本的話,建議你選擇 Linux,運(yùn)氣好的話也許它會(huì)支持。
10、用戶群
在這里我冒險(xiǎn)概括一下計(jì)算機(jī)用戶們,但我想先聲明一下每一個(gè)事物都有例外。下面我要向你展示我對(duì)用戶分布方面的概括。
Mac –> Windows –> Linux –> BSD –> UNIX
從左邊到右邊,分別是”使用該 OS 的人里精通電腦的用戶群最少”到”使用該 OS 的人里精通電腦的用戶群最多”的過(guò)渡。我們可以看到,Linux的被放置在了中間,而 BSD 則更接近于右邊。許多人會(huì)對(duì)此有爭(zhēng)論,也有些人可能會(huì)感覺(jué)被冒犯了。但是,個(gè)人認(rèn)為這是一個(gè)對(duì)”哪些用戶使用哪些系統(tǒng)”相當(dāng)準(zhǔn)確的概括。
其他的不同點(diǎn)?
這個(gè)列表并不想表明哪個(gè)系統(tǒng)比哪個(gè)更好。事實(shí)上,BSD 和 Linux 各有著自己的亮點(diǎn)。你認(rèn)為怎么樣?有興趣的話也請(qǐng)表達(dá)出你的觀點(diǎn)。
RabbitVCS是Linux下替代TortoiseSVN的一個(gè)可視化工具,非常不錯(cuò)!
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
網(wǎng)易(速度很快)
ubuntu官方上海源,提供 Kernel,Hiweed,ubuntu
搜狐
骨頭源,骨頭源是bones7456架設(shè)的一個(gè)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
顯示環(huán)境變量已經(jīng)全部是英文1、輸入用戶管理的命令,新建用戶(以test為例):
useradd test
修改 test 用戶的密碼:
passwd test
2、將新用戶添加到管理組:
gpasswd -a test admin
3、給 test 用戶創(chuàng)建自己的目錄:
cd /home
mkdir test
chown test /home/test
4、重新啟動(dòng),
reboot
然后用 test 登錄,
登錄以后,點(diǎn)菜單“系統(tǒng)-系統(tǒng)管理-用戶和組”,進(jìn)去選中你的用戶,點(diǎn)右邊的“屬性”按鈕,到用戶權(quán)限里打勾需要的;
sudo apt-get install mplayer mozilla-mplayer
安裝mplayer的插件。
同時(shí)在about:config里增加了兩個(gè)配置項(xiàng):
Network.protocol-handler.app.mms string /usr/bin/mplayer
Network.protocal-handler.external.mms boolean True
restart it ,就OK了。
同時(shí)可以參考:
1、安裝軟件和相應(yīng)解碼器
sudo apt-get install mplayer mozilla-mplayer totem-xine libxine-extracodecs w32codecs audacious
sudo gedit /etc/network/interface
將其內(nèi)容刪除
加上一下內(nèi)容
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
將內(nèi)容修改為
nameserver 202.103.24.68
保存
重啟網(wǎng)絡(luò)連接
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
打開(kāi)終端,執(zhí)行以下命令,或使用Adept/新立得軟件管理器,在其中分別搜索"sun-java6-jre"和"sun-java6-jdk"并標(biāo)記安裝。
sudo apt-get install sun-java6-jre
如果空間富裕,建議安裝一個(gè)JDK。
sudo apt-get install sun-java6-jdk
提示:安裝過(guò)程中需要你回答是否同意使用協(xié)議(終端中紅藍(lán)色的提示界面),此時(shí)按tab鍵至OK,再按回車即可正常安裝。
設(shè)置當(dāng)前默認(rèn)的java解釋器:
sudo update-alternatives --config java
執(zhí)行后會(huì)出現(xiàn)類似如下的畫面:
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" 的行的前面的數(shù)字。如上面顯示,則輸入2,然后回車確定。
配置JAVA環(huán)境變量:
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
后來(lái)發(fā)現(xiàn)是由于Mysql編譯安裝后沒(méi)有 mysql_config這個(gè)值,解決方法:
打開(kāi) setup_posix.py, 將其中l(wèi)ine:26手動(dòng)改成系統(tǒng)中對(duì)應(yīng)的Mysql選項(xiàng)(這里我的是/usr/local/mysql):
mysql_config = /usr/local/mysql/bin/mysql_config
重新執(zhí)行 :python setup.py build,沒(méi)有了剛才的錯(cuò)誤,但是出現(xiàn)了另外一個(gè)錯(cuò)誤:
error: /usr/bin/ld: cannot find -lmysqlclient
網(wǎng)上搜索了一下這個(gè)錯(cuò)誤,發(fā)現(xiàn)有幾種不同的情況,主要有以下幾個(gè)原因:
1.沒(méi)有安裝mysqlclient。解決方法:找到對(duì)應(yīng)的版本進(jìn)行安裝。
2.安裝的mysqlclient的版本不匹配。對(duì)應(yīng)鏈接: http://www.hao32.com/webserver/258.html
3.已經(jīng)安裝了對(duì)應(yīng)的mysqlclient但是找不到對(duì)應(yīng)的鏈接。這是在一個(gè)國(guó)外的網(wǎng)站上看到的,具體網(wǎng)址已經(jīng)找不到了,后來(lái)那位仁兄將對(duì)應(yīng)的
mysql_home/lib/mysql文件夾下面libmysqlclient對(duì)應(yīng)的文件全部拷貝到/usr/local/lib下面才解決了問(wèn)題。
按照對(duì)應(yīng)方案,問(wèn)題解決。
重新執(zhí)行:
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
一、查看所有環(huán)境變量的名稱和值:
Linux下:export
Windows下:set
二、根據(jù)名稱查該環(huán)境變量的值:
Linux下:echo $環(huán)境變量名
比如:echo $ORACLE_HOME
Windows下:set 環(huán)境變量名
Wicd的功能:
無(wú)需依賴Gnome運(yùn)行環(huán)境 (盡管它確實(shí)需要GTK),就是說(shuō)可以在XFCE、Fluxbox, Openbox、Enlightenment 等X下使用
可以管理有線和無(wú)線網(wǎng)絡(luò)連接
每個(gè)無(wú)線和有線網(wǎng)絡(luò)連接都有獨(dú)立的配置文件
支持多種加密方式,包括 WEP、WPA、WPA2 等
保持了對(duì) wireless-tools 的兼容性
在系統(tǒng)托盤顯示網(wǎng)絡(luò)狀況和信號(hào)強(qiáng)度
在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
保存退出
現(xiàn)在用下面的命令更新源列表
sudo aptitude update
通過(guò)下面這行命令安裝 wicd
sudo aptitude install wicd
請(qǐng)注意,此操作將刪除GNOME的默認(rèn)網(wǎng)絡(luò)管理器 network-manager,可能導(dǎo)致暫時(shí)失去網(wǎng)絡(luò)連接。
在GNOME中,如果您想讓它自動(dòng)啟動(dòng)并顯示系統(tǒng)托盤圖標(biāo)。那么請(qǐng)?jiān)?系統(tǒng)→首選項(xiàng)→會(huì)話 的 啟動(dòng)程序 標(biāo)簽中點(diǎn)擊 添加。設(shè)定個(gè)名字(比如”Wicd”)并在命令一欄中輸入 “/opt/wicd/tray.py”。
啟動(dòng)后效果如下:
使用 Wicd
在GNOME中通過(guò)應(yīng)用程序菜單啟動(dòng) wicd 的方法是點(diǎn)擊 應(yīng)用程序→互聯(lián)網(wǎng)→Wicd。
在wicd的窗口中您將看見(jiàn)一個(gè)系統(tǒng)檢測(cè)到的無(wú)線網(wǎng)絡(luò)列表。有時(shí) Wicd 在剛啟動(dòng)的時(shí)候不能搜索到所有范圍內(nèi)的無(wú)線網(wǎng)絡(luò)。請(qǐng)點(diǎn)擊工具條上的刷新按鈕來(lái)重新搜索。
點(diǎn)擊網(wǎng)絡(luò)名稱下面的那個(gè) 連接 后稍候幾秒就應(yīng)該連上您選擇的網(wǎng)絡(luò)了。
如果網(wǎng)絡(luò)是加密的,您需要再干點(diǎn)兒活兒。Wicd支持的加密方式包括:WPA、WEP、LEAP、TTLS、EAP 和 PEAP。
點(diǎn)擊您要連接的那個(gè)網(wǎng)絡(luò)名稱邊上的箭頭,然后點(diǎn)擊高級(jí)設(shè)置。在這里選中 Use Encryption 框,并在下拉菜單里選擇對(duì)應(yīng)的加密方式,最后在密鑰欄填上您的密碼。
卻提示 sendmail.mc:10: m4: Cannot open /usr/share/sendmail-cf/m4/cf.m4: No such file or directory
這是因?yàn)闆](méi)有安裝sendmai-cf這個(gè)包
安裝完成后問(wèn)題解決