|
|
查看内核版本： uname -a
more /etc/*release
more /etc/redhat-release
more /proc/version
查看CPU信息：grep "model name" /proc/cpuinfo
more /proc/cpuinfo
查看CPU位数：getconf LONG_BIT
ls 如果在root下ls有lib64 文件夹说明系统64
查看libc、gcc版本：ldd /sbin/mii-tool
rpm -qa | grep glibc
gcc –v
查看内存信息：more /proc/meminfo
grep MemTotal /proc/meminfo
linux是指GNU/Linux内核和GNU/Linux工具集组合而成的一套操作系统, 一个最基本的linux 由
内核 kernel,二进制工具包 binutils, GNU C library glibc和shell 组成
Linux下gcc编译介绍
Linux系统下的Gcc（GNU C Compiler）是GNU推出的功能强大、性能优越的多平台编译器，是GNU的代表作品之一。gcc是可以在多种硬体平台上编译出可执行程序的超级编译器，其执行效率与一般的编译器相比平均效率要高20%~30%。
Gcc编译器能将C、C++语言源程序、汇程式化序和目标程序编译、连接成可执行文件，如果没有给出可执行文件的名字，gcc将生成一个名为 a.out的文件。在Linux系统中，可执行文件没有统一的后缀，系统从文件的属性来区分可执行文件和不可执行文件。而gcc则通过后缀来区别输入文件的类别，下面我们来介绍gcc所遵循的部分约定规则。
.c为后缀的文件，C语言源代码文件；
.a为后缀的文件，是由目标文件构成的档案库文件；
.C，.cc或.cxx 为后缀的文件，是C++源代码文件；
.h为后缀的文件，是程序所包含的头文件；
.i 为后缀的文件，是已经预处理过的C源代码文件；
.ii为后缀的文件，是已经预处理过的C++源代码文件；
.m为后缀的文件，是Objective-C源代码文件；
.o为后缀的文件，是编译后的目标文件；
.s为后缀的文件，是汇编语言源代码文件；
.S为后缀的文件，是经过预编译的汇编语言源代码文件。
Gcc的执行过程
虽然我们称Gcc是C语言的编译器，但使用gcc由C语言源代码文件生成可执行文件的过程不仅仅是编译的过程，而是要经历四个相互关联的步骤∶预处理(也称预编译，Preprocessing)、编译(Compilation)、汇编(Assembly)和连接(Linking)。
命令gcc首先调用cpp进行预处理，在预处理过程中，对源代码文件中的文件包含(include)、预编译语句(如宏定义define等) 进行分析。接着调用cc1进行编译，这个阶段根据输入文件生成以.o为后缀的目标文件。汇编过程是针对汇编语言的步骤，调用as进行工作，一般来讲，.S 为后缀的汇编语言源代码文件和汇编、.s为后缀的汇编语言文件经过预编译和汇编之后都生成以.o为后缀的目标文件。当所有的目标文件都生成之后，gcc就调用ld来完成最后的关键性工作，这个阶段就是连接。在连接阶段，所有的目标文件被安排在可执行程序中的恰当的位置，同时，该程序所调用到的库函数也从各自所在的档案库中连到合适的地方。
Gcc的基本用法和选项
在使用Gcc编译器的时候，我们必须给出一系列必要的调用参数和文件名称。Gcc编译器的调用参数大约有100多个，其中多数参数我们可能根本就用不到，这里只介绍其中最基本、最常用的参数。
Gcc最基本的用法是∶gcc [options] [filenames]
其中options就是编译器所需要的参数，filenames给出相关的文件名称。
-c，只编译，不连接成为可执行文件，编译器只是由输入的.c等源代码文件生成.o为后缀的目标文件，通常用于编译不包含主程序的子程序文件。
-o output_filename，确定输出文件的名称为output_filename，同时这个名称不能和源文件同名。如果不给出这个选项，gcc就给出预设的可执行文件a.out。
-g，产生符号调试工具(GNU的gdb)所必要的符号资讯，要想对源代码进行调试，我们就必须加入这个选项。
-O，对程序进行优化编译、连接，采用这个选项，整个源代码会在编译、连接过程中进行优化处理，这样产生的可执行文件的执行效率可以提高，但是，编译、连接的速度就相应地要慢一些。
-O2，比-O更好的优化编译、连接，当然整个编译、连接过程会更慢。
-Idirname，将dirname所指出的目录加入到程序头文件目录列表中，是在预编译过程中使用的参数。C程序中的头文件包含两种情况∶
A)#include
B)#include “myinc.h”
其中，A类使用尖括号(< >)，B类使用双引号(“ ”)。对于A类，预处理程序cpp在系统预设包含文件目录(如/usr/include)中搜寻相应的文件，而对于B类，cpp在当前目录中搜寻头文件，这个选项的作用是告诉cpp，如果在当前目录中没有找到需要的文件，就到指定的dirname目录中去寻找。在程序设计中，如果我们需要的这种包含文件分别分布在不同的目录中，就需要逐个使用-I选项给出搜索路径。
-Ldirname，将dirname所指出的目录加入到程序函数档案库文件的目录列表中，是在连接过程中使用的参数。在预设状态下，连接程序ld在系统的预设路径中(如/usr/lib)寻找所需要的档案库文件，这个选项告诉连接程序，首先到-L指定的目录中去寻找，然后到系统预设路径中寻找，如果函数库存放在多个目录下，就需要依次使用这个选项，给出相应的存放目录。
-lname，在连接时，装载名字为“libname.a”的函数库，该函数库位于系统预设的目录或者由-L选项确定的目录下。例如，-lm表示连接名为“libm.a”的数学函数库。
上面我们简要介绍了gcc编译器最常用的功能和主要参数选项，更为详尽的资料可以参看Linux系统的联机帮助。
假定我们有一个程序名为test.c的C语言源代码文件，要生成一个可执行文件，最简单的办法就是∶
gcc test.c
这时，预编译、编译连接一次完成，生成一个系统预设的名为a.out的可执行文件，对于稍为复杂的情况，比如有多个源代码文件、需要连接档案库或者有其他比较特别的要求，就要给定适当的调用选项参数。再看一个简单的例子。
整个源代码程序由两个文件testmain.c 和testsub.c组成，程序中使用了系统提供的数学库，同时希望给出的可执行文件为test，这时的编译命令可以是∶
gcc testmain.c testsub.c □lm □o test
其中，-lm表示连接系统的数学库libm.a。
Gcc的错误类型及对策
Gcc编译器如果发现源程序中有错误，就无法继续进行，也无法生成最终的可执行文件。为了便于修改，gcc给出错误资讯，我们必须对这些错误资讯逐个进行分析、处理，并修改相应的语言，才能保证源代码的正确编译连接。gcc给出的错误资讯一般可以分为四大类，下面我们分别讨论其产生的原因和对策。
第一类∶C语法错误
错误资讯∶文件source.c中第n行有语法错误(syntex errror)。这种类型的错误，一般都是C语言的语法错误，应该仔细检查源代码文件中第n行及该行之前的程序，有时也需要对该文件所包含的头文件进行检查。有些情况下，一个很简单的语法错误，gcc会给出一大堆错误，我们最主要的是要保持清醒的头脑，不要被其吓倒，必要的时候再参考一下C语言的基本教材。
第二类∶头文件错误
错误资讯∶找不到头文件head.h(Can not find include file head.h)。这类错误是源代码文件中的包含头文件有问题，可能的原因有头文件名错误、指定的头文件所在目录名错误等，也可能是错误地使用了双引号和尖括号。
第三类∶档案库错误
错误资讯∶连接程序找不到所需的函数库，例如∶
ld: -lm: No such file or directory
这类错误是与目标文件相连接的函数库有错误，可能的原因是函数库名错误、指定的函数库所在目录名称错误等，检查的方法是使用find命令在可能的目录中寻找相应的函数库名，确定档案库及目录的名称并修改程序中及编译选项中的名称。
第四类∶未定义符号
错误资讯∶有未定义的符号(Undefined symbol)。这类错误是在连接过程中出现的，可能有两种原因∶一是使用者自己定义的函数或者全局变量所在源代码文件，没有被编译、连接，或者干脆还没有定义，这需要使用者根据实际情况修改源程序，给出全局变量或者函数的定义体；二是未定义的符号是一个标准的库函数，在源程序中使用了该库函数，而连接过程中还没有给定相应的函数库的名称，或者是该档案库的目录名称有问题，这时需要使用档案库维护命令ar检查我们需要的库函数到底位于哪一个函数库中，确定之后，修改gcc连接选项中的-l和-L项。
排除编译、连接过程中的错误，应该说这只是程序设计中最简单、最基本的一个步骤，可以说只是开了个头。这个过程中的错误，只是我们在使用C语言描述一个算法中所产生的错误，是比较容易排除的。我们写一个程序，到编译、连接通过为止，应该说刚刚开始，程序在运行过程中所出现的问题，是算法设计有问题，说得更玄点是对问题的认识和理解不够，还需要更加深入地测试、调试和修改。一个程序，稍为复杂的程序，往往要经过多次的编译、连接和测试、修改。下面我们学习的程序维护、调试工具和版本维护就是在程序调试、测试过程中使用的，用来解决调测阶段所出现的问题。窗体顶端
窗体底端
什么是gtk
GTK+的原始的作者是
Peter Mattis
Spencer Kimball
Josh MacDonald
GTK+是一个小型而高效的控件库,具有Motif的外观和风格.实际上,它比Motif看起来好多了,它包含有基本的控件和一些很复杂的的控件:例如文件选择控件和颜色选择控件.
GTK+提供了一些独特的特性,(至少,我知道其他的控件库不提供他们),例如,按钮不提供标签,它包含了一个子控件,在很多的时候是一个标签,但是,这个子控件也可以是一个映射,图像或者任何其他的程序员想要的集合.在整个的库中,你随处可见这种伸缩性
gtk整体说来还是不错的不太难，另外vc 2003中也是可以编译的，要设置库，适合初学者，另外生成的.exe文件只能在装有GTK的机器中运行，有点不方便。
楼主可以试试用PEG+ 类似GTK但更简单，生成的exe文件可以在任何os运行。可以去他的官网下载免费版本。
glibc glibc 是gnu发布的libc库，也即c运行库。
glibc是linux系统中最底层的api（应用程序开发接口），
几乎其它任何的运行库都会依赖于glibc。
glibc除了封装linux操作系统所提供的系统服务外，
它本身也提供了许多其它一些必要功能服务的实现，主要的如下：
（1）string，字符串处理
（2）signal，信号处理
（3）dlfcn，管理共享库的动态加载
（4）direct，文件目录操作
（5）elf，共享库的动态加载器，也即interpreter
（6）iconv，不同字符集的编码转换
（7）inet，socket接口的实现
（8）intl，国际化，也即gettext的实现
（9）io
（10）linuxthreads
（11）locale，本地化
（12）login，虚拟终端设备的管理，及系统的安全访问
（13）malloc，动态内存的分配与管理
（14）nis
（15）stdlib，其它基本功能
GLIBC 的内容
由於 glibc 囊括了几乎所有的 UNIX 通行的标准，可以想见其内容包罗万有。而就像其他的 UNIX 系统一样，其内含的档案群分散于系统的树状目录结构中，像一个支架一般撑起整个作业系统。以 glibc-2.2 为例，这些档案群主要包括:
1.分享函式库群:
这是 glibc 的主体，分?鸯 /lib 与 /usr/lib 中，包括 libc 标准 C 函式库、libm 数学函式库、libcrypt 加密与编码函式库、libdb 资料库函式库、libpthread 行程多执行绪函式库、libnss 网路服务函式库 .... 等等。这些都是可分享函式库，档名都以 .so 做结尾。其中，/lib/ld*.so 是程式与函式库连结的工具。有的用于程式编译时将程式与函式库内的函式物件连结，在只支援静态连结的系统中，此连结方式就是直接将所需的物件自函式库中抽出?砼c程式的可执行档相连，而在支援可分享函式库的系统中，在程式编译时期的连结只是在执行档中纪录了那些函式物件是存在那个函式库档案中，等该程式开始执行时，则由另一个负责动态连结的 ld*.so 将所需的函式库连结好?K执行。
一般而言，负责程式编译时期的连结器档名为 ld.so，而负责程式执行时的动态连结器档名为 ld- .so 或 ld-linux.so (在 GNU/Linux 系统中)。
函式库标头档与程式开发元件:
这些标头档档名都以 .h 为结尾，全部在 /usr/include/ 底下，其内容为函式库中各函式的宣告、巨集定义、资料物件的型别 .... 等等，这些都是程式开发者不可或缺的部分。
除此之外，在 /usr/lib/ 中还有若干 .o 与 .a 的档案，这些是程式编译过程中要连结为可执行档时所需的元件，有些则为上述可分享函式库的静态连接版本，而後者可以在某些特殊场合下需要静态连结程式时使用。
函式库说明文件:
在一般的 UNIX 系统下，这些说明文件是放在 /usr/man 或 /usr/share/man 底下，统称为 man pages，其底下还分若干章?，其中第二章 (man2) 讲的是系统呼叫，而第三章 (man3) 讲的就是 libc 标准函式库，这些都是系统开发者重要的参考资料。
而在 GNU 的系统中，除了 man pages 之外，还有一套称为 info 的文件资料系统，而且里头的说明往往比 man pages 还要详尽，这在 glibc 中也不例外。glibc 的 info 文件位於 /usr/share/info/libc.info* ，本文中有许多素材就是取自这些文件的内容。
字集转换模组与区域化资料库:
这些是与程式国际化与本土化相关的部分，主要可分成四大块: /usr/lib/gconv/ 内含大量的字集转换模组，大部分是各种字集及编码方式与系统的基底字集之间的 转换。第二块是 /usr/lib/locale，内含以系统基底字集写成的区域化资料库 (locale)，像是 LC_CTYPE、LC_TIME .... 等等。第三块是
/usr/share/locale/，内含可跨平台使用的区域化资料，主要是各应用程式的?息翻译部分。而最後一块是 /usr/share/i18n/，其内容是各区域化资料库的原始码，以及系统支援的内码对应表 .... 等等。
时区资料库:
主要分?鸯 /usr/share/zoneinfo 底下，内含世界各地时区与格林威治时间的转换资料。
其他工具程式与设定档:
工具程式分?言 /usr/bin 与 /sbin 底下，包括一些转码与区域化资料库相关的程式如 iconv, locale, localedef 等，以及用?盹@示应用程式与可分享函式库相依关系的 ldd, 还有可分享函式库搜寻路?焦芾沓淌 ldconfig .... 等。而其相关的设定档则位于 /etc 底下。
disaos
03-11-03, 10:42
GLIBC 的规格
在 GNU/Linux 系统中，其 C 函式库的发展史点出了 GNU/Linux 演进的几个重要里程碑，由此可以突显出 C 函式库在系统中的地位与重要性。早期的 GNU/Linux 系统?K不支援可分享函式库，因此所有的应用程式都是以静态连结的方式存於系统中。直到 1995-1996 年 libc5 问世以後，系统才开始支援 ELF 可分享函式库，同时该版的 C 函式库也?作了其他 UNIX 上大部分的功能与函式群，可谓 GNU/Linux 发展上的一大进步。
然而 libc5 在程式国际化 (I18N) 与本土化 (L10N) 方面的支援很差，故那个时候若要开发所谓中文化的程式，就非得自行?作一套标准不可。直到一两年後， GNU/Linux 换用了 GNU 所开发的 glibc-2.0 做为其 C 函式库後，其国际化与本土化的支援才开始起步，後?须v经 glibc-2.1，到了现在的 2.2 版，整个多国语文的开发环境才大至成熟。
用 glibc 做为系统的 C 函式库，是 GNU/Linux 演进的一个重要里程碑。在 GNU 的计画中，开发 glibc 原本是要给他们尚未问世的核心 GNU/Hurd 用的，由于当时几乎 99% 的 GNU 系统工具已开发完成，就独缺核心 Hurd，而恰巧 Linux 核心在 Torvalds 的带领下已逐?u成熟稳定，而且可以顺利执行所有的 GNU 系统工具。故 GNU 团队便顺应 Linux 核心的特性，改写了他们的 glibc，使其可以适用于 Hurd 核心与 Linux 核心。如此，在这两个平台上就有了一致的程式开发环境，使得所有的 GNU 程式可以在这两个平台之间顺利移植。
比起过去的 libc5，glibc 系列 (一般又称之为 libc6) 除了有完整的国际化与本土化支援外，同时还符合许多标准与规格，使得在 glibc 下开发的程式可以很容易移植到其他 UNIX 平台去。这些标准包括:
ISO C:
ISO C 是 International Standard for the C programming language 的缩写，此标准明定了 C 语言的语法，标准 C 函式库应具备那些标头档、巨集定义、函式与物件 .... 等等，几乎在任何平台上的 C 语言 (包括非 UNIX 平台) 都支援此标准。
POSIX:
POSIX 是 Portable Operating System Interface for Computer Environments 的缩写，它是 ISO C 的延伸，明定了一个可移植的作业系统所应具备种种条件，其范围不只有系统函式库而已，还同时包括一些标准的工具程式、系统核心应有的特色与?作、以及在 C 函式库中某些与作业系统相关的低阶控制支援 (如系统呼叫窗口) 等等。由于 glibc 是完全按照 POSIX 的标准制作的，同时搭配了符合 POSIX 标准的 Linux 核心，故在此环境下开发的程式可以做到完全符合 POSIX 的规格。
Berkeley Unix:
Berkeley Unix 泛称柏克莱大学所开发的 UNIX 系列作业系统，包括 4.2 BSD、4.3 BSD、4.4 BSD 以及早期的 SunOS。这些系统的 C 函式库中有许多杰出的设计，但却没有在上述两个标准中，包括 select() 函式、sockets .... 等等，这些在 glibc 中都有支援。
SVID:
SVID 是 System V Interface Description 的缩写，它是一份描述 AT&T UNIX System V 系统规格的文件，它是 POSIX 标准的延伸。Glibc ?作了大部分的 SVID 规格要求，其中较重要的包括了行程之间的通?标准以及分享式记忆体 (shared memory)，至于其他的部分则较不常使用。?作 SVID 主要的目的是希望可以做到与 UNIX System V 的相容与程式的可移植性。
XPG:
XPG 是 X/Open Portability Guide 的缩写，是由 X/Open Company, Ltd. 所发表，同时 X/Open 还拥有 UNIX 商标的版权。而这份规格不但是 POSIX 标准的扩充，同时也明定了一个 UNIX 作业系统所应符合的要求。其中包括了 iconv() 字集转换介面，以及部分 BSD 与 SVID 的特色。
除了上述的规格外，glibc 还内含了 GNU 特有的特色，称之为 GNU Extension。这些特色在某些情况下可以方便程式的撰写与维护，但就不见得可以移植到其他 UNIX 平台上，故在可移植性的考量下使用时必须留意。
安装下列程序: catchsegv, gencat, getconf, getent, glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale, localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown, rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump 和 zic
安装下列库文件: ld.so, libBrokenLocale.[a,so], libSegFault.so, libanl.[a,so], libbsd-compat.a, libc.[a,so], libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a, libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a, libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so, libpcprofile.so, libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so], libthread_db.so 和 libutil.[a,so]
简短说明
catchsegv 当程序发生segmentation fault的时候, 用来建立一个堆栈跟踪。
gencat 建立消息列表。
getconf 针对文件系统的指定变量显示其系统设置值。
getent 从系统管理数据库获取一个条目。
glibcbug 建立glibc的bug报告并且email到bug报告的邮件地址。
iconv 转化字符集。
iconvconfig 建立快速读取的iconv模块所使用的设置文件。
ldconfig 设置动态链接库的实时绑定。
ldd 列出每个程序或者命令需要的共享库。
lddlibc4 辅助 ldd 操作目标文件。
locale 是一个 Perl 程序，可以告诉编译器打开或关闭内建的locale支持。
localedef 编译locale标准。
mtrace...
nscd 提供对常用名称设备调用的缓存的守护进程。
nscd_nischeck 检查在进行NIS+侦查时是否需要安全模式。
pcprofiledump 打印PC profiling产生的信息。
pt_chown 是一个辅助程序，帮助grantpt设置子虚拟终端的属主，用户组和读写权限。
rpcgen 产生实现RPC协议的C代码。
rpcinfo 对RPC服务器产生一个RPC呼叫。
sln 用来创建符号链接，由于它本身是静态连接的，在动态连接不起作用的时候，sln仍然可以建立符号链接。
sprof 读取并显示共享目标的特征描述数据。
tzselect 对用户提出关于当前位置的问题,并输出时区信息到标准输出。
xtrace 通过打印当前执行的函数跟踪程序执行情况。
zdump 显示时区。
zic 时区编译器。
ld.so 帮助动态链接库的执行。
libBrokenLocale 帮助程序处理破损locale，如Mozilla。
libSegFault 处理 segmentation fault 信号，试图捕捉segfaults。
libanl 异步名称查询库。
libbsd-compat 为了在linux下执行一些BSD程序,libbsd-compat提供了必要的可移植性。
libc 是主要的C库--常用函数的集成。
libcrypt 加密编码库。
libdl 动态连接接口。
libg g++的运行时。
libieee IEEE浮点运算库。
libm 数学函数库。
libmcheck 包括了启动时需要的代码。
libmemusage 帮助 memusage 搜集程序运行时内存占用的信息。
libnsl 网络服务库。
libnss* 是名称服务切换库，包含了解释主机名，用户名，组名，别名，服务，协议等等的函数。
libpcprofile 帮助内核跟踪在函数, 源码行和命令中CPU使用时间。
libpthread POSIX 线程库。
libresolv 创建,发送及解释到互联网域名服务器的数据包。
librpcsvc提供RPC的其他服务。
librt 提供了大部分的POSIX.1b实时扩展的接口。
libthread_db 对建立多线程程序的调试很有用。
libutil 包含了在很多不同的 Unix程序中使用的“标准”函数。
Glibc 安装依赖关系
Glibc 依赖于: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.
linux 下的X Window KDE GNOME
X Window是linux下的图形终端，以客户端、服务器的形式运行，客户端和服务器可以处于一台机子，也可以在网络上访问。客户端和服务器之间用协议沟通。当用户处于客户端上要显示什么东西时，客户端把这个请求发送到服务器由服务器完成。
可见X Window并不是我们常见的图形界面，他只是一套协议和接口，程序通过这套接口来显示图形，比如Xterm就是利用这些接口来显示一个命令窗口，实际上X Window在后台运行，我们是看不见的。
所以光一个X Window是没有像Windows下这样的任务栏等功能的，只是一系列接口，使用起来当然不方便，不是人人都愿意打命令。所以人们就利用X Window的接口做出了窗口最小化、切换等功能，叫窗口管理器，你说的KDE、Gnome等就是窗口管理器。
早期的窗口管理器只有简单的窗口管理功能，只有一个桌面，上面一些窗口排列，最小化的窗口被放在某个地方，非常简陋。现在的窗口管理器则功能强大，提供了大量的附加功能，已经不局限于管理窗口了。
综上所述，你不装KDE或Gnome，也是可以运行一些图形界面的程序的，但如果你要像在windows下一样的方便，窗口管理器必不可少。
什么是KDE？
KDE，K桌面环境(K Desktop Environment)的缩写。一种著名的运行于Linux、Unix以及FreeBSD等操作系统上面自由图形工作环境，整个系统采用的都是 TrollTech公司所开发的Qt程序库。KDE和Gnome都是Linux操作系统上最流行的桌面环境系统。
概览
KDE是一个用于UNIX工作站的网络透明的现代化桌面环境。KDE会为满足在Unix工作站上对于易用桌面的需求而不断探索，例如在Mac OS和微软的Windows那样的桌面环境。我们相信 UNIX操作系统是当今可用的最好的操作系统。实际上在这些年来UNIX已经成为信息技术专业人员无可争议的选择，当提到稳定性、可扩展性和开放性，没有什么可以和UNIX 竞争。但无论如何，在UNIX上缺乏易于使用的现代化桌面环境已成为了让UNIX成为办公和家庭场合中普通计算机用户的桌面系统的重大阻碍。UNIX在服务器市场占有优势，并且是计算机专业人士和科学领域中的首选计算平台，没有UNIX，就没有互联网。但是UNIX也从事于满足普通计算机用户的需求。自从大量的类UNIX（Debian GNU/Linux、 FreeBSD和NetBSD等等）在互联网上自由可用的时候，这种情况更加使人遗憾。上述的几个平台都具有非凡的品质和稳定性。
KDE的一点历史
* KDE项目始建于1996年10月，确切的公布日期是1996年10月14日。
* 1997年8月15日：KDE第一次代表会议于德国阿恩斯伯格市召开，共15人参加。
* 1997年12月：KDE协会创建，这是一个为在法律和财政上保护核心成员避免相关纠纷而设立的组织。
* 1998年4月8日：KDE Free Qt基金会成立。
* 1999年10月20日，KDE Beta 1发布；1997年11月23日，KDE Beta 2发布；1998年2月1日，KDE Beta 3发布；1998年4月19日，KDE Beta 4发布。
* 1998年4月19日，KDE 1.0发布。
* 1999年2月2日，KDE 1.1发布。
* 1999年5月5日，KDE 1.1.1发布。
* 1999年9月13日，KDE 1.1.2发布。
* 1999年10月7日至10日，KDE第二次代表会议在德国爱尔兰根市召开。
* 1999年12月15日，KDE 1.89发布。
* 2000年5月12日，KDE 1.90 (KDE2 beta1)发布；2000年6月14日，KDE 1.91 (KDE2 beta2)发布。2000年7月31日，KDE 1.92 (KDE2 beta3)发布。
* 2000年7月9日至19日，KDE第三次代表会议于在挪威特吕西尔市召开。
* 2000年8月23日，KDE 1.93 (KDE2 beta4)发布。
* 2000年9月4日，Qt开始使用GPL授权。
* 2000年9月15日，KDE 1.94 (KDE2 beta5)发布。
* 2000年10月10日，KDE 2.0 RC（发布候选版）发布。
* 2000年10月23日，KDE 2.0发布。
* 2000年12月5日，KDE 2.0.1发布。
* 2000年12月16日，KDE 2.1 Beta 1发布。
* 2001年1月31日，KDE 2.1 Beta 2发布。
* 2001年2月26日，KDE 2.1 发布。
* 2001年3月27日，KDE 2.1.1发布。
* 2001年4月30日，KDE 2.1.2发布。
* 2001年7月4日，KDE 2.2 Beta1发布。
* 2001年8月15日，KDE 2.2 发布。
* 2001年9月19日，KDE 2.2.1发布。
* 2001年11月21日，KDE 2.2.2发布。
* 2002年4月3日，KDE 3.0发布。
* 2002年5月22日，KDE 3.0.1发布。
* 2002年7月2日，KDE 3.0.2发布。
* 2002年7月11日，KDE 3.1 Alpha1发布。
* 2002年8月19日，KDE 3.0.3发布。
* 2002年8月21日，KDE 3.1 Beta1发布。
* 2002年10月2日，KDE 3.1 Beta2发布。
* 2002年10月9日，KDE 3.0.4发布。
* 2002年11月18日，KDE 3.0.5发布。
* 2002年12月21日，KDE 3.0.5a发布。
* 2003年1月28日，KDE 3.1发布。
* 2003年3月20日，KDE 3.1.1发布。
* 2003年5月19日，KDE 3.1.2发布。
* 2003年7月29日，KDE 3.1.3发布。
* 2003年9月10日，KDE 3.2 Alpha 1发布。
* 2003年9月16日，KDE 3.1.4发布。
* 2004年1月14日，KDE 3.1.5发布。
* 2004年2月3日，KDE 3.2发布。
* 2004年3月9日，KDE 3.2.1发布。
* 2004年4月19日，KDE 3.2.2发布。
* 2004年6月9日，KDE 3.2.3发布。
* 2004年8月19日，KDE 3.3发布。
* 2004年10月12日，KDE 3.3.1发布。
* 2004年12月8日，KDE 3.3.2发布。
* 2005年3月16日，KDE 3.4发布。
* 2005年5月31日，KDE 3.4.1发布。
* 2005年7月28日，KDE 3.4.2发布。
* 2005年10月13日，KDE 3.4.3发布。
* 2005年11月29日，KDE 3.5发布。
* 2006年1月31日，KDE 3.5.1发布。
* 2006年3月28日，KDE 3.5.2发布。
* 2006年5月31日，KDE 3.5.3发布。
* 2006年8月2日，KDE 3.5.4发布。
* 2006年10月11日，KDE 3.5.5发布。
* 2007年1月25日，KDE 3.5.6发布。
* 2008年1月11日，革命版本——KDE 4.0发布
* 2008年7月29日，更加完美更加成熟的4系列版本4.1发布，在不久的将来大部分kde发行版使用kde4作为缺省桌面环境。
GNOMEGNOME 即GNU网络对象模型环境 (The GNU Network Object Model Environment)，GNU计划的一部分，开放源码运动的一个重要组成部分。 是一种让使用者容易操作和设定环境的工具。
目标是基于自由软件，为Unix或者类Unix操作系统构造一个功能完善、操作简单以及界面友好的桌面环境，他是GNU计划的正式桌面。
GNOME计划是1997年8月由Miguel de Icaza和Federico Mena发起，作为KDE的替代品。
使用孟加拉国语的GNOMEKDE是一个基于Qt部件工具箱自由的桌面环境，而QT是由 Trolltech开发，当时并未使用自由软件许可。GNU项目的成员关注于使用象这样的一种工具箱构造自由的软件桌面和应用软件，从而发起两个项目：一个是作为纯粹Qt库替代品的“Harmony”；还有就是目的在于使用完全与Qt无关的自由软件构造桌面系统的GNOME项目。
在GNOME变得实用和普及之后，2000年9月Trolltech在GNU GPL和QPL（去掉了大多数争论多年的内容）双重许可证下发布了GNU/Linux版的QT库。但是Qt的许可证还是在许多人中间有争议，因为GPL用于库时对与之链接的代码－例如的KDE框架和任何为其编写的程序－都施加了许可证限制。
GIMP Toolkit(GTK+)被选中做为Qt toolkit的替代，担当GNOME桌面的基础。GTK+使用GNU宽通用公共许可证（LGPL，一个自由软件许可证），允许链接到它的软件——例如 GNOME的应用程序——使用任意的许可证。GNOME桌面的库使用LGPL，而GNOME计划内的应用程序使用GPL许可证。
GNOME桌面系统使用C语言编程，但也存在一些其它语言的绑定使得能够使用其它语言编写GNOME应用程序，例如C++, Java, Ruby, C#, Python, Perl 等等。
| |
