查看Linux内核、CPU、内存及各组件版本的命令和方法 

本文出自 “黄宝的博客” 博客,请务必保留此出处http://huangbao.blog.51cto.com/725279/152679

查看内核版本: uname -a

more/etc/*release

more/etc/redhat-release

more/proc/version

查看CPU信息:grep"modelname"/proc/cpuinfo

more/proc/cpuinfo

查看CPU位数:getconfLONG_BIT

ls如果在root下ls有lib64文件夹说明系统64

查看libc、gcc版本:ldd/sbin/mii-tool

rpm-qa|grepglibc

gcc–v

查看内存信息:more /proc/meminfo
    grep MemTotal /proc/meminfo

linux是指GNU/Linux内核和GNU/Linux工具集组合而成的一套操作系统,一个最基本的linux由

内核kernel,二进制工具包binutils,GNUClibraryglibc和shell组成

Linux下gcc编译介绍

Linux系统下的Gcc(GNUCCompiler)是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为后缀的目标文件,通常用于编译不包含主程序的子程序文件。

-ooutput_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语言源代码文件,要生成一个可执行文件,最简单的办法就是∶

gcctest.c

这时,预编译、编译连接一次完成,生成一个系统预设的名为a.out的可执行文件,对于稍为复杂的情况,比如有多个源代码文件、需要连接档案库或者有其他比较特别的要求,就要给定适当的调用选项参数。再看一个简单的例子。

整个源代码程序由两个文件testmain.c和testsub.c组成,程序中使用了系统提供的数学库,同时希望给出的可执行文件为test,这时的编译命令可以是∶

gcctestmain.ctestsub.c□lm□otest

其中,-lm表示连接系统的数学库libm.a。

Gcc的错误类型及对策

Gcc编译器如果发现源程序中有错误,就无法继续进行,也无法生成最终的可执行文件。为了便于修改,gcc给出错误资讯,我们必须对这些错误资讯逐个进行分析、处理,并修改相应的语言,才能保证源代码的正确编译连接。gcc给出的错误资讯一般可以分为四大类,下面我们分别讨论其产生的原因和对策。

第一类∶C语法错误

错误资讯∶文件source.c中第n行有语法错误(syntexerrror)。这种类型的错误,一般都是C语言的语法错误,应该仔细检查源代码文件中第n行及该行之前的程序,有时也需要对该文件所包含的头文件进行检查。有些情况下,一个很简单的语法错误,gcc会给出一大堆错误,我们最主要的是要保持清醒的头脑,不要被其吓倒,必要的时候再参考一下C语言的基本教材。

第二类∶头文件错误

错误资讯∶找不到头文件head.h(Cannotfindincludefilehead.h)。这类错误是源代码文件中的包含头文件有问题,可能的原因有头文件名错误、指定的头文件所在目录名错误等,也可能是错误地使用了双引号和尖括号。

第三类∶档案库错误

错误资讯∶连接程序找不到所需的函数库,例如∶

ld:-lm:Nosuchfileordirectory

这类错误是与目标文件相连接的函数库有错误,可能的原因是函数库名错误、指定的函数库所在目录名称错误等,检查的方法是使用find命令在可能的目录中寻找相应的函数库名,确定档案库及目录的名称并修改程序中及编译选项中的名称。

第四类∶未定义符号

错误资讯∶有未定义的符号(Undefinedsymbol)。这类错误是在连接过程中出现的,可能有两种原因∶一是使用者自己定义的函数或者全局变量所在源代码文件,没有被编译、连接,或者干脆还没有定义,这需要使用者根据实际情况修改源程序,给出全局变量或者函数的定义体;二是未定义的符号是一个标准的库函数,在源程序中使用了该库函数,而连接过程中还没有给定相应的函数库的名称,或者是该档案库的目录名称有问题,这时需要使用档案库维护命令ar检查我们需要的库函数到底位于哪一个函数库中,确定之后,修改gcc连接选项中的-l和-L项。

排除编译、连接过程中的错误,应该说这只是程序设计中最简单、最基本的一个步骤,可以说只是开了个头。这个过程中的错误,只是我们在使用C语言描述一个算法中所产生的错误,是比较容易排除的。我们写一个程序,到编译、连接通过为止,应该说刚刚开始,程序在运行过程中所出现的问题,是算法设计有问题,说得更玄点是对问题的认识和理解不够,还需要更加深入地测试、调试和修改。一个程序,稍为复杂的程序,往往要经过多次的编译、连接和测试、修改。下面我们学习的程序维护、调试工具和版本维护就是在程序调试、测试过程中使用的,用来解决调测阶段所出现的问题。窗体顶端

窗体底端什么是gtk
GTK+的原始的作者是

PeterMattis

SpencerKimball

JoshMacDonald

GTK+是一个小型而高效的控件库,具有Motif的外观和风格.实际上,它比Motif看起来好多了,它包含有基本的控件和一些很复杂的的控件:例如文件选择控件和颜色选择控件.

GTK+提供了一些独特的特性,(至少,我知道其他的控件库不提供他们),例如,按钮不提供标签,它包含了一个子控件,在很多的时候是一个标签,但是,这个子控件也可以是一个映射,图像或者任何其他的程序员想要的集合.在整个的库中,你随处可见这种伸缩性

gtk整体说来还是不错的不太难,另外vc2003中也是可以编译的,要设置库,适合初学者,另外生成的.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底下,统称为manpages,其底下还分若干章?,其中第二章(man2)讲的是系统呼叫,而第三章(man3)讲的就是libc标准函式库,这些都是系统开发者重要的参考资料。

而在GNU的系统中,除了manpages之外,还有一套称为info的文件资料系统,而且里头的说明往往比manpages还要详尽,这在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平台去。这些标准包括:

ISOC:

  ISOC是InternationalStandardfortheCprogramminglanguage的缩写,此标准明定了C语言的语法,标准C函式库应具备那些标头档、巨集定义、函式与物件....等等,几乎在任何平台上的C语言(包括非UNIX平台)都支援此标准。

POSIX:

POSIX是PortableOperatingSystemInterfaceforComputerEnvironments的缩写,它是ISOC的延伸,明定了一个可移植的作业系统所应具备种种条件,其范围不只有系统函式库而已,还同时包括一些标准的工具程式、系统核心应有的特色与?作、以及在C函式库中某些与作业系统相关的低阶控制支援(如系统呼叫窗口)等等。由于glibc是完全按照POSIX的标准制作的,同时搭配了符合POSIX标准的Linux核心,故在此环境下开发的程式可以做到完全符合POSIX的规格。

BerkeleyUnix:

  BerkeleyUnix泛称柏克莱大学所开发的UNIX系列作业系统,包括4.2BSD、4.3BSD、4.4BSD以及早期的SunOS。这些系统的C函式库中有许多杰出的设计,但却没有在上述两个标准中,包括select()函式、sockets....等等,这些在glibc中都有支援。

SVID:

SVID是SystemVInterfaceDescription的缩写,它是一份描述AT&TUNIXSystemV系统规格的文件,它是POSIX标准的延伸。Glibc?作了大部分的SVID规格要求,其中较重要的包括了行程之间的通?标准以及分享式记忆体(sharedmemory),至于其他的部分则较不常使用。?作SVID主要的目的是希望可以做到与UNIXSystemV的相容与程式的可移植性。

XPG:

  XPG是X/OpenPortabilityGuide的缩写,是由X/OpenCompany,Ltd.所发表,同时X/Open还拥有UNIX商标的版权。而这份规格不但是POSIX标准的扩充,同时也明定了一个UNIX作业系统所应符合的要求。其中包括了iconv()字集转换介面,以及部分BSD与SVID的特色。

除了上述的规格外,glibc还内含了GNU特有的特色,称之为GNUExtension。这些特色在某些情况下可以方便程式的撰写与维护,但就不见得可以移植到其他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当程序发生segmentationfault的时候,用来建立一个堆栈跟踪。

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打印PCprofiling产生的信息。

pt_chown是一个辅助程序,帮助grantpt设置子虚拟终端的属主,用户组和读写权限。

rpcgen产生实现RPC协议的C代码。

rpcinfo对RPC服务器产生一个RPC呼叫。

sln用来创建符号链接,由于它本身是静态连接的,在动态连接不起作用的时候,sln仍然可以建立符号链接。

sprof读取并显示共享目标的特征描述数据。

tzselect对用户提出关于当前位置的问题,并输出时区信息到标准输出。

xtrace通过打印当前执行的函数跟踪程序执行情况。

zdump显示时区。

zic时区编译器。

ld.so帮助动态链接库的执行。

libBrokenLocale帮助程序处理破损locale,如Mozilla。

libSegFault处理segmentationfault信号,试图捕捉segfaults。

libanl异步名称查询库。

libbsd-compat为了在linux下执行一些BSD程序,libbsd-compat提供了必要的可移植性。

libc是主要的C库--常用函数的集成。

libcrypt加密编码库。

libdl动态连接接口。

libgg++的运行时。

libieeeIEEE浮点运算库。

libm数学函数库。

libmcheck包括了启动时需要的代码。

libmemusage帮助memusage搜集程序运行时内存占用的信息。

libnsl网络服务库。

libnss*是名称服务切换库,包含了解释主机名,用户名,组名,别名,服务,协议等等的函数。

libpcprofile帮助内核跟踪在函数,源码行和命令中CPU使用时间。

libpthreadPOSIX线程库。

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下的XWindowKDEGNOME

X Window是linux下的图形终端,以客户端、服务器的形式运行,客户端和服务器可以处于一台机子,也可以在网络上访问。客户端和服务器之间用协议沟通。当用户处于客户端上要显示什么东西时,客户端把这个请求发送到服务器由服务器完成。

可见XWindow并不是我们常见的图形界面,他只是一套协议和接口,程序通过这套接口来显示图形,比如Xterm就是利用这些接口来显示一个命令窗口,实际上XWindow在后台运行,我们是看不见的。

所以光一个XWindow是没有像Windows下这样的任务栏等功能的,只是一系列接口,使用起来当然不方便,不是人人都愿意打命令。所以人们就利用XWindow的接口做出了窗口最小化、切换等功能,叫窗口管理器,你说的KDE、Gnome等就是窗口管理器。

早期的窗口管理器只有简单的窗口管理功能,只有一个桌面,上面一些窗口排列,最小化的窗口被放在某个地方,非常简陋。现在的窗口管理器则功能强大,提供了大量的附加功能,已经不局限于管理窗口了。

综上所述,你不装KDE或Gnome,也是可以运行一些图形界面的程序的,但如果你要像在windows下一样的方便,窗口管理器必不可少。

什么是KDE?

  KDE,K桌面环境(KDesktopEnvironment)的缩写。一种著名的运行于Linux、Unix以及FreeBSD等操作系统上面自由图形工作环境,整个系统采用的都是TrollTech公司所开发的Qt程序库。KDE和Gnome都是Linux操作系统上最流行的桌面环境系统。

概览

KDE是一个用于UNIX工作站的网络透明的现代化桌面环境。KDE会为满足在Unix工作站上对于易用桌面的需求而不断探索,例如在MacOS和微软的Windows那样的桌面环境。我们相信UNIX操作系统是当今可用的最好的操作系统。实际上在这些年来UNIX已经成为信息技术专业人员无可争议的选择,当提到稳定性、可扩展性和开放性,没有什么可以和UNIX竞争。但无论如何,在UNIX上缺乏易于使用的现代化桌面环境已成为了让UNIX成为办公和家庭场合中普通计算机用户的桌面系统的重大阻碍。UNIX在服务器市场占有优势,并且是计算机专业人士和科学领域中的首选计算平台,没有UNIX,就没有互联网。但是UNIX也从事于满足普通计算机用户的需求。自从大量的类UNIX(DebianGNU/Linux、FreeBSD和NetBSD等等)在互联网上自由可用的时候,这种情况更加使人遗憾。上述的几个平台都具有非凡的品质和稳定性。

KDE的一点历史

*KDE项目始建于1996年10月,确切的公布日期是1996年10月14日。

*1997年8月15日:KDE第一次代表会议于德国阿恩斯伯格市召开,共15人参加。

*1997年12月:KDE协会创建,这是一个为在法律和财政上保护核心成员避免相关纠纷而设立的组织。

*1998年4月8日:KDEFreeQt基金会成立。

*1999年10月20日,KDEBeta1发布;1997年11月23日,KDEBeta2发布;1998年2月1日,KDEBeta3发布;1998年4月19日,KDEBeta4发布。

*1998年4月19日,KDE1.0发布。

*1999年2月2日,KDE1.1发布。

*1999年5月5日,KDE1.1.1发布。

*1999年9月13日,KDE1.1.2发布。

*1999年10月7日至10日,KDE第二次代表会议在德国爱尔兰根市召开。

*1999年12月15日,KDE1.89发布。

*2000年5月12日,KDE1.90(KDE2beta1)发布;2000年6月14日,KDE1.91(KDE2beta2)发布。2000年7月31日,KDE1.92(KDE2beta3)发布。

*2000年7月9日至19日,KDE第三次代表会议于在挪威特吕西尔市召开。

*2000年8月23日,KDE1.93(KDE2beta4)发布。

*2000年9月4日,Qt开始使用GPL授权。

*2000年9月15日,KDE1.94(KDE2beta5)发布。

*2000年10月10日,KDE2.0RC(发布候选版)发布。

*2000年10月23日,KDE2.0发布。

*2000年12月5日,KDE2.0.1发布。

*2000年12月16日,KDE2.1Beta1发布。

*2001年1月31日,KDE2.1Beta2发布。

*2001年2月26日,KDE2.1发布。

*2001年3月27日,KDE2.1.1发布。

*2001年4月30日,KDE2.1.2发布。

*2001年7月4日,KDE2.2Beta1发布。

*2001年8月15日,KDE2.2发布。

*2001年9月19日,KDE2.2.1发布。

*2001年11月21日,KDE2.2.2发布。

*2002年4月3日,KDE3.0发布。

*2002年5月22日,KDE3.0.1发布。

*2002年7月2日,KDE3.0.2发布。

*2002年7月11日,KDE3.1Alpha1发布。

*2002年8月19日,KDE3.0.3发布。

*2002年8月21日,KDE3.1Beta1发布。

*2002年10月2日,KDE3.1Beta2发布。

*2002年10月9日,KDE3.0.4发布。

*2002年11月18日,KDE3.0.5发布。

*2002年12月21日,KDE3.0.5a发布。

*2003年1月28日,KDE3.1发布。

*2003年3月20日,KDE3.1.1发布。

*2003年5月19日,KDE3.1.2发布。

*2003年7月29日,KDE3.1.3发布。

*2003年9月10日,KDE3.2Alpha1发布。

*2003年9月16日,KDE3.1.4发布。

*2004年1月14日,KDE3.1.5发布。

*2004年2月3日,KDE3.2发布。

*2004年3月9日,KDE3.2.1发布。

*2004年4月19日,KDE3.2.2发布。

*2004年6月9日,KDE3.2.3发布。

*2004年8月19日,KDE3.3发布。

*2004年10月12日,KDE3.3.1发布。

*2004年12月8日,KDE3.3.2发布。

*2005年3月16日,KDE3.4发布。

*2005年5月31日,KDE3.4.1发布。

*2005年7月28日,KDE3.4.2发布。

*2005年10月13日,KDE3.4.3发布。

*2005年11月29日,KDE3.5发布。

*2006年1月31日,KDE3.5.1发布。

*2006年3月28日,KDE3.5.2发布。

*2006年5月31日,KDE3.5.3发布。

*2006年8月2日,KDE3.5.4发布。

*2006年10月11日,KDE3.5.5发布。

*2007年1月25日,KDE3.5.6发布。

*2008年1月11日,革命版本——KDE4.0发布

*2008年7月29日,更加完美更加成熟的4系列版本4.1发布,在不久的将来大部分kde发行版使用kde4作为缺省桌面环境。

GNOME

GNOME即GNU网络对象模型环境(TheGNUNetworkObjectModelEnvironment),GNU计划的一部分,开放源码运动的一个重要组成部分。是一种让使用者容易操作和设定电脑环境的工具。

目标是基于自由软件,为Unix或者类Unix操作系统构造一个功能完善、操作简单以及界面友好的桌面环境,他是GNU计划的正式桌面。

GNOME计划是1997年8月由MigueldeIcaza和FedericoMena发起,作为KDE的替代品。

  使用孟加拉国语的GNOMEKDE是一个基于Qt部件工具箱自由的桌面环境,而QT是由Trolltech开发,当时并未使用自由软件许可。GNU项目的成员关注于使用象这样的一种工具箱构造自由的软件桌面和应用软件,从而发起两个项目:一个是作为纯粹Qt库替代品的“Harmony”;还有就是目的在于使用完全与Qt无关的自由软件构造桌面系统的GNOME项目。

在GNOME变得实用和普及之后,2000年9月Trolltech在GNUGPL和QPL(去掉了大多数争论多年的内容)双重许可证下发布了GNU/Linux版的QT库。但是Qt的许可证还是在许多人中间有争议,因为GPL用于库时对与之链接的代码-例如的KDE框架和任何为其编写的程序-都施加了许可证限制。

GIMPToolkit(GTK+)被选中做为Qttoolkit的替代,担当GNOME桌面的基础。GTK+使用GNU宽通用公共许可证(LGPL,一个自由软件许可证),允许链接到它的软件——例如GNOME的应用程序——使用任意的许可证。GNOME桌面的库使用LGPL,而GNOME计划内的应用程序使用GPL许可证。

GNOME桌面系统使用C语言编程,但也存在一些其它语言的绑定使得能够使用其它语言编写GNOME应用程序,例如C++,Java,Ruby,C#,Python,Perl等等。

相关推荐