UbuCon Summit 2016峰会已经落下帷幕,众多Ubuntu开发者已经重回工作岗位继续他们伟大的开发征程。援引外媒SoftPedia报道,开发者Didier Roche于今天发布了新版的Ubuntu Make工具,在最新的16.01.2版本中添加了很多新功能,例如支持苹果的开源Swift编程语言,使用“umake swift”命令能够轻松安装至Ubuntu Linux操作系统上。

Roche表示:“上周在阳光明媚的帕萨迪纳Pasadena,我非常荣幸的能够在UbuCon峰会上宣布新版Ubuntu Make版本。该工具达到了16.01.2里程碑版本,这个版本能够成功发布还要感谢社区提供了三个全新的支持框架。”

Ubuntu Make工具是命令行应用,你可以在Ubuntu 15.10 (Wily Werewolf), Ubuntu 15.04 (Vivid Vervet)和Ubuntu 14.04 LTS (Trusty Tahr) 的终端应用中运行如下命令来安装。此外,Ubuntu 16.04 LTS (Xenial Xerus)中可以从默认软件存储库中安装。

sudo apt-add-repository ppa:ubuntu-desktop/ubuntu-make
sudo apt-get update && sudo apt-get install -y ubuntu-make

臃肿、bug多、错误不断的Java Web浏览器插件,终于被甲骨文Oracle判了死刑。就在上个月,Adobe实际上已经开始了让Flash从web上退休的节奏,转而推动标准更友好的HTML5。而现在,Oracle也做出了同样的决定。当然,该公司不是立即完全甩掉这个包袱,但表示Java Web浏览器插件的灭亡或许是不可避免的。

不过,该公司用来替代它的,还是一项基于Java的技术(通过一个浏览器链接来运行完整的应用程序)。

Flash和Java是摆脱网页插件的两个最大的阻碍,毕竟它们的技术“曾经年轻过”、催生了无数的交互式站点、强大的web应用程序、甚至推动了Web本身的边界。

时间快进到今天,这类插件却遗憾地成为了互联网的一大安全风险。尽管Flash或多或少地可以用HTML5来替代,许多用于内联网或企业设定下的站点,却仍在使用基于插件的Java应用。

在某种程度上,甲骨文在强行让插件退休之外,确实没有了其它的选择。现代浏览器已经砍去了对NPAPI的支持,而几乎同样年迈的Flash和Java也注定迎来同样的命运。

没有了插件,依赖它们的应用就无法在运行。当然,甲骨文并不希望用户一道在Web上放弃Java,因此提供了Java Web Start(或曰JavaWS)作为替代。

与旧式的Java Applet一样,JavaWS应用仍然采用了Java,并且可以通过点击网页链接的方式启动。但不同的是,JavaWS是作为独立的应用程序而运行于浏览器之外的(尽管还是在Java虚拟沙箱里跳舞)。

如果JavaWS应用没有在你的机器上安装,点击相关链接就会先行下载应用并自动运行。JavaWS被夸赞为更加健壮,且应用比Java Web Applets更易升级和维护。

总而言之,对于那些仍在使用老式applet的企业,还是能够在不升级Java(以及web浏览器)版本的情况下一直使用下去的。当然,别指望有其它人继续帮你提供安全修复和更新了。

Java Web插件将从计划于九月发布的JDK 9开始被弃用,然后在未来版本的JDK和JRE中被彻底移除(具体时间仍不确定)。

观点

笔者对《龙芯之痛:国产芯片陷烧钱怪圈》一文中部分叙述表示认同,比如龙芯最大的差距不在于技术指标,而是未能与产业链对接、建立与之相匹配的生态系统。

但文中部分观点和结论笔者不敢苟同。一些论述中,例子也无法和原作者的观点相契合,比如认为“长电科技并购星科金朋、通富微电收购AMD封测厂、中芯国际增资扩股等10多个项目”是“欲速而不达”,是“烧钱”,并含沙射影的表示对这些项目的否定。特别是《龙芯之痛:国产芯片陷烧钱怪圈》这个标题,很容易造成读者龙芯“烧钱”错误印象。 

龙芯“烧”了多少钱?

作者以《龙芯之痛:国产芯片陷烧钱怪圈》为题,特别是文末先说一些企业烧钱,后用“龙芯用了14年时间,付出了巨大代价,才明白这个道理”——字里行间仿佛在表达龙芯在14年里烧了大量的钱,才明白“这个道理”。这种行文方式很容易对读者造成误导,以为龙芯是个烧钱货。

龙芯自2001年成立以来,从国家863计划、核高基专项中累计获得项目经费5亿人民币。龙芯中科公司成立后,获得北京市政府2亿人民币的股权投资。也就是说龙芯成立至今共从国家获得资金7亿元。

7亿元咋一看很多,但是芯片研发对资金需求极大,国家对龙芯的补助无异于杯水车薪。

举个列子,俄罗斯贝尔加电子的Baikal-T1处理器研发成本折算为人民币是1.85亿元,该芯片是购买MIPS Warrior P5600微结构集成双核CPU,主频1.2G,用于路由器、打印机、复印机等产品。如果贝尔加电子自主研发微结构的话,成本会更高。换言之,贝尔加电子研发一枚路由器芯片的研发成本(而且还不是自己研发微结构)相当于国家对龙芯的总投入的四分之一。华为海思麒麟920的研发成本据小道消息称是2亿美元,是国家在总计15年时间里对龙芯投入的1.7倍……

即便和其他几家有国资背景的合资公司相比,国家对龙芯的扶持可以说是少的可怜。最近高通和贵州省政府成立合资公司,光注册资本18.5亿元,其中国资占55%。若以国外巨头作参照,则差距更大,2014年Intel研发经费超过100亿美元,员工达10万余人。

正是鉴于国家对龙芯扶持非常有限,在“2015中国计算机大会”笔者采访胡伟武老师时,他表示,“其实这也不是坏事,逼着龙芯只能在市场中谋生存、谋发展,逼着龙芯去服务客户,走市场化道路,而不是去服务领导、伺候领导,这其实也是件好事。就像60年代苏联撤走专家,逼着中国人凭借自己的力量就把两弹一星搞出来了。”

2015年,龙芯营收突破1亿,已基本摆脱政府输血,实现自收自支,自负盈亏。

因此,所谓“烧钱”,骗经费之类的标签,和龙芯八竿子搭不上关系。

关于龙芯又在要政策

虽然原文章中对此做了说明,但力度轻描淡写,而且对来龙去脉也没有做说明。在互联网时代,人们碎片化获取信息时很容易被忽略。

其实,该事件和笔者还有一定的联系,因此,笔者在此对该事件做说明。

在“2015中国计算机大会”时,笔者采访了胡伟武老师,胡老师的原话是“政府应该干啥,应该在黑暗森林里围个篱笆墙,构建一个小森林,把国外芯片挡一挡。进入小森林的CPU公司必须严格界定,什么是自主的,什么是可控的,必须有统一的标准,把真正自主可控的放进小森林,小森林里玩的是市场竞争的丛林法则。让国内各家CPU公司在小森林里适者生存的竞争——谁的产品好,谁的服务好,就选谁的产品,政府不要去干涉。在市场竞争中练出自己的体格,最后的胜出者踏着失败者的尸体成长壮大后,再打破藩篱,和黑暗森林里的国外产品竞争。”

一言蔽之,就是幼稚工业保护论,通过对真正自主可控的芯片间的市场竞争,使中国芯磨砺成长。

而目前政府的种种干涉其实并不利于通过市场竞争优胜劣汰——胡老师曾表示,“我希望政府不要过多的干涉,政府很喜欢干啥,看谁弱一点,或者不行了,就去扶他一把,看他能自主发展了,就去帮弱的,而且帮助力度还非常大,发展的好的CPU公司靠自己努力取得的优势一下子就被行政力量抹平了,这对能摆脱政府扶持,自主发展的CPU公司非常不公平,搞的竞争法则不起作用了。”

但国内一些媒体非常喜欢断章取义,不仅修改了笔者的标题,还对文章内容进行删节,甚至篡改,以至于越传越邪乎,最后变成了龙芯又在要政策。

但客观事实正完全相反,相对于那些基本依赖政府输血的IC设计公司,龙芯反倒是能够摆脱政府输血生存——主要是依靠从市场和股东资本金来养队伍和研发新产品,从国家获得的资金不仅总量非常少,而且占龙芯资金来源的比例也很低,龙芯从国家获得的资金远远低于国内其他几家CPU公司。

所谓“国产芯片陷烧钱怪圈”

读完全文一直没看明白所谓的“烧钱怪圈”是什么?

集成电路产业的发展离不开资金、技术、人才、政策的全方位支持,耗费大量资金是必然的!

可能是作者是财经记者,分不清自己所引用的企业和龙芯之间有什么区别,将IC设计、代工、封测,甚至和硬盘、NAND Flash厂商起了个共同的名字,也是比较“神奇”的名字——“中国芯企业”。

比如原文中“随着国家集成电路产业投资基金(下称“大基金”)的成立,中国芯片产业掀起了一场资本介入潮。大基金募集资金超过1380亿元,在其带动下,多个地方政府也设立了地方版的集成电路产业投资基金,长电科技并购星科金朋、通富微电收购AMD封测厂、中芯国际增资扩股等10多个项目陆续尘埃落定。以紫光集团为代表,中国芯片和中国资本更是拉开了海外并购的大幕,引发了全球芯片行业的关注和大讨论……龙芯用了14年时间,付出了巨大代价,才明白这个道理。现在,欲速则不达的道理与中国速度的诱惑如何取舍,摆在了更多中国芯企业的面前。”

笔者对原作者所谓的“中国芯企业”做个盘点

长电科技、星科金朋、通富微电等是封测公司,中芯国际是芯片代工企业;

紫光收购的企业中,西部数据主营业务是硬盘,而西数出面收购的闪迪业务为NAND Flash,力成和南茂、矽品是封测企业,华三是主营业务是网络设备、服务器等。

紫光收购展讯和锐迪科是2013年底,而且也并非文章中的“海外并购”,更非文章中“随着国家集成电路产业投资基金(下称“大基金”)的成立”后的并购。

因此,原作者所谓的“国产芯片陷烧钱怪圈”中指出的公司中,没有一家和龙芯一样属于国产芯片设计公司。

在摆出大部分不属于IC设计公司“烧钱”的论据后,原作者话风一转,说“龙芯付出了巨大的代价,才明白这个道理”,不知原作者的潜台词是否龙芯在烧钱后明白了烧钱无用“这个道理”?也就是原作者所谓的“国产芯片陷烧钱怪圈”?

先不提龙芯15年来从来就没烧过钱——龙芯过去曾经犯过很多错误,但唯独没有“烧钱”。

从全世界的芯片代工、封测,以及存储芯片企业发展的过程来看,其实都是用钱砸出来的,都离不开海量资本的注入。中芯国际、长电科技等芯片代工、封测公司在海量资本的辅助下发展壮大。笔者可以断言,虽然紫光的一些收购缺乏性价比,但中芯国际、长电科技的“烧钱”能壮大中国芯片代工和封测产业,是具有积极意义的,反而有利于龙芯的成长,可以给龙芯提供强有力的产业支持。

结语

笔者斗胆做一个揣测——从文章内容看,原作者显然是获得了和胡老师近距离交流的机会,很有可能,在采访胡伟武老师时候,胡老师的话是——国内某些IC设计公司,虽然从国家获得了非常大的资金,但是一不注重基础软硬件研发,在硬件上拿国外芯片穿马甲,或买国外IP核授权就宣称自主知识产权,在软件上忽视基础软件的开发。二不注重产业联盟构建。三不注重软件生态构建。这样一来,虽然耗资不菲,但技术成果却乏善可陈,而且根本用不起来,只能依赖国家经费的输血。

但因专业知识和理解能力相对有限,原作者脑海中形成了“龙芯之痛:国产芯片陷烧钱怪圈”的神奇概念。

有些人问我,在现有的语言里面,有什么好的推荐?我说:“Java。” 他们很惊讶:“什么?Java!” 所以我现在来解释一下。

(题图来自:staticworld.net)

Java 超越了所有咒骂它的“动态语言”

也许是因为年轻人的逆反心理,人们都不把自己的入门语言当回事。很早的时候,计算机系的学生用 Scheme 或者 Pascal 入门,现在大部分学校用 Java。这也许就是为什么很多人恨 Java,瞧不起用 Java 的人。提到 Java,感觉就像是爷爷那辈人用的东西。大家都会用 Java,怎么能显得我优秀出众呢?于是他们说:“Java 老气,庞大,复杂,臃肿。我更愿意探索新的语言……

某些 Python 程序员,在论坛里跟初学者讲解 Python 有什么好,其中一个原因竟然是:“因为 Python 不是 Java!” 他们喜欢这样宣传:“看 Python 多简单清晰啊,都不需要写类型……” 对于 Java 的无缘无故的恨,盲目的否认,导致了他们看不到它很重要的优点,以至于迷失自己的方向。虽然气势上占上风,然而其实 Python 作为一个编程语言,是完全无法和 Java 抗衡的。

在性能上,Python 比Java 慢几十倍。由于缺乏静态类型等重要设施,Python 代码有 bug 很不容易发现,发现了也不容易 debug,所以 Python 无法用于构造大规模的,复杂的系统。你也许发现某些 startup 公司的主要代码是 Python 写的,然而这些公司的软件,质量其实相当的低。在成熟的公司里,Python 最多只用来写工具性质的东西,或者小型的,不会影响系统可靠性的脚本。

静态类型的缺乏,也导致了 Python 不可能有很好的 IDE 支持,你不能完全可靠地“跳转到定义”,不可能完全可靠地重构refactor Python 代码。PyCharm 对于早期的 Python 编程环境,是一个很大的改进,然而理论决定了,它不可能完全可靠地进行“变量换名”等基本的重构操作。就算是比 PyCharm 强大很多的 PySonar,对此也无能为力。由于 Python 的设计过度的“动态”,没有类型标记,使得完全准确的定义查找,成为了不可判定undecidable的问题。

在设计上,Python,Ruby 比起 Java,其实复杂很多。缺少了很多重要的特性,有毛病的“强大特性”倒是多了一堆。由于盲目的推崇所谓“正宗的面向对象”方式,所谓“ late binding ”,这些语言里面有太多可以“重载”语义的地方,不管什么都可以被重定义,这导致代码具有很大的不确定性和复杂性,很多 bug 就是被隐藏在这些被重载的语言结构里面了。因此,Python 和 Ruby 代码很容易被滥用,不容易理解,容易写得很乱,容易出问题。

很多 JavaScript 程序员也盲目地鄙视 Java,而其实 JavaScript 比 Python 和 Ruby 还要差。不但具有它们的几乎所有缺点,而且缺乏一些必要的设施。JavaScript 的各种“WEB 框架”,层出不穷,似乎一直在推陈出新,而其实呢,全都是在黑暗里瞎蒙乱撞。JavaScript 的社区以幼稚和愚昧著称。你经常发现一些非常基本的常识,被 JavaScript “专家”们当成了不起的发现似的,在大会上宣讲。我看不出来 JavaScript 社区开那些会议,到底有什么意义,仿佛只是为了拉关系找工作。

Python 凑合可以用在不重要的地方,Ruby 是垃圾,JavaScript 是垃圾中的垃圾。原因很简单,因为 Ruby 和 JavaScript 的设计者,其实都是一知半解的民科。然而世界就是这么奇怪,一个彻底的垃圾语言,仍然可以宣称是“程序员最好的朋友”,从而得到某些人的爱戴……

Java 的“继承人”没能超越它

最近一段时间,很多人热衷于 Scala,Clojure,Go 等新兴的语言,他们以为这些是比 Java 更现代,更先进的语言,以为它们最终会取代 Java。然而这些狂热分子们逐渐发现,Scala,Clojure 和 Go 其实并没有解决它们声称能解决的问题,反而带来了它们自己的毛病,而这些毛病很多是 Java 没有的。然后他们才意识到,Java 离寿终正寝的时候,还远得很……

Go语言

关于 Go,我已经评论过很多了,有兴趣的人可以看这里。总之,Go 是民科加自大狂的产物,奇葩得不得了。这里我就不多说它了,只谈谈 Scala 和 Clojure。

Scala

我认识一些人,开头很推崇 Scala,仿佛什么救星似的。我建议他们别去折腾了,老老实实用 Java。没听我的,结果到后来,成天都在骂 Scala 的各种毛病。但是没办法啊,项目上了贼船,不得不继续用下去。我不喜欢进行人身攻击,然而我发现一个语言的好坏,往往取决于它的设计者的背景,觉悟,人品和动机。很多时候我看人的直觉是异常的准,以至于依据对语言设计者的第一印象,我就能预测到这个语言将来会怎么发展。在这里,我想谈一下对 Scala 和 Clojure 的设计者的看法。

Scala 的设计者 Martin Odersky,在 PL 领域有所建树,发表了不少学术论文( 包括著名的《The Call-by-Need Lambda Calculus》),而且还是大名鼎鼎的 Niklaus Wirth 的门徒,我因此以为他还比较靠谱。可是开始接触 Scala 没多久,我就很惊讶的发现,有些非常基本的东西,Scala 都设计错了。这就是为什么我几度试图采用 Scala,最后都不了了之。因为我一边看,一边发现让人跌眼镜的设计失误,而这些问题都是 Java 没有的。这样几次之后,我就对 Odersky 失去了信心,对 Scala 失去了兴趣。

回头看看 Odersky 那些论文的本质,我发现虽然理论性貌似很强,其实很多是在故弄玄虚(包括那所谓的“call-by-need lambda calculus”)。他虽然对某些特定的问题有一定深度,然而知识面其实不是很广,眼光比较片面。对于语言的整体设计,把握不够好。感觉他是把各种语言里的特性,强行拼凑在一起,并没有考虑过它们是否能够“和谐”的共存,也很少考虑“可用性”。

由于 Odersky 是大学教授,名声在外,很多人想找他拿个 PhD,所以东拉西扯,喜欢往 Scala 里面加入一些不明不白,有潜在问题的“特性”,其目的就是发 paper,混毕业。这导致 Scala 不加选择的加入过多的特性,过度繁复。加入的特性很多后来被证明没有多大用处,反而带来了问题。学生把代码实现加入到 Scala 的编译器,毕业就走人不管了,所以 Scala 编译器里,就留下一堆堆的历史遗留垃圾和 bug。这也许不是 Odersky 一个人的错,然而至少说明他把关不严,或者品位确实有问题。

最有名的采用 Scala 的公司,无非是 Twitter。其实像 Twitter 那样的系统,用 Java 照样写得出来。Twitter 后来怎么样了呢?CEO 都跑了 😛 新 CEO 上台就裁员300多人,包括工程师在内。我估计 Twitter 裁员的一个原因是,有太多的 Scala 程序员,扯着各种高大上不实用的口号,比如“函数式编程”,进行过度工程,浪费公司的资源。花着公司的钱,开着各种会议,组织各种 meetup 和 hackathon,提高自己在 open source 领域的威望,其实没有为公司创造很多价值……

Clojure

再来说一下 Clojure。当 Clojure 最初“横空面世”的时候,有些人热血沸腾地向我推荐。于是我看了一下它的设计者 Rich Hickey 做的宣传讲座视频。当时我就对他一知半解拍胸脯的本事,印象非常的深刻。Rich Hickey 真的是半路出家,连个 CS 学位都没有。可他那种气势,仿佛其他的语言设计者什么都不懂,只有他看到了真理似的。不过也只有这样的人,才能创造出“宗教”吧?

满口热门的名词,什么 lazy 啊,pure 啊,STM 啊,号称能解决“大规模并发”的问题,…… 这就很容易让人上钩。其实他这些词儿,都是从别的语言道听途说来,却又没能深刻理解其精髓。有些“函数式语言”的特性,本来就是有问题的,却为了主义正确,为了显得高大上,抄过来。所以最后你发现这语言是挂着羊头卖狗肉,狗皮膏药一样说得头头是道,用起来怎么就那么蹩脚。

Clojure 的社区,一直忙着从 Scheme 和 Racket 的项目里抄袭思想,却又想标榜是自己的发明。比如 Typed Clojure,就是原封不动抄袭 Typed Racket。有些一模一样的基本概念,在 Scheme 里面都几十年了,恁是要改个不一样的名字,免得你们发现那是 Scheme 先有的。甚至有人把 SICP,The Little Schemer 等名著里的代码,全都用 Clojure改写一遍,结果完全失去了原作的简单和清晰。最后你发现,Clojure 里面好的地方,全都是 Scheme 已经有的,Clojure 里面新的特性,几乎全都有问题。我参加过一些 Clojure 的 meetup,可是后来发现,里面竟是各种喊着大口号的小白,各种趾高气昂的民科,愚昧之至。

如果现在要做一个系统,真的宁可用 Java,也不要浪费时间去折腾什么 Scala 或者 Clojure。错误的人设计了错误的语言,拿出来浪费大家的时间。

Java 没有特别讨厌的地方

我至今不明白,很多人对 Java 的仇恨和鄙视,从何而来。它也许缺少一些方便的特性,然而长久以来用 Java 进行教学,用 Java 工作,用 Java 开发 PySonar,RubySonar,Yin 语言,…… 我发现 Java 其实并不像很多人传说的那么可恶。我发现自己想要的95%以上的功能,在 Java 里面都能找到比较直接的用法。剩下的5%,用稍微笨一点的办法,一样可以解决问题。

盲目推崇 Scala 和 Clojure 的人们,很多最后都发现,这些语言里面的“新特性”,几乎都有毛病,里面最重要最有用的特性,其实早就已经在 Java 里了。有些人跟我说:“你看,Java 做不了这件事情!” 后来经我分析,发现他们在潜意识里早已死板的认定,非得用某种最新最酷的语言特性,才能达到目的。Java 没有这些特性,他们就以为非得用另外的语言。其实,如果你换一个角度来看问题,不要钻牛角尖,专注于解决问题,而不是去追求最新最酷的“写法”,你就能用 Java 解决它,而且解决得干净利落。

很多人说 Java 复杂臃肿,其实是因为早期的 Design Patterns,试图提出千篇一律的模板,给程序带来了不必要的复杂性。然而 Java 语言本身跟 Design Patterns 并不是等价的。Java 的设计者,跟 Design Pattern 的设计者,完全是不同的人。你完全可以使用 Java 写出非常简单的代码,而不使用 Design Patterns。

Java 只是一个语言。语言只提供给你基本的机制,至于代码写的复杂还是简单,取决于人。把对一些滥用 Design Patterns 的Java 程序员的恨,转移到 Java 语言本身,从而完全抛弃它的一切,是不明智的。

结论

我平时用着 Java 偷着乐,本来懒得评论其它语言的。可是实在不忍心看着有些人被 Scala 和 Clojure 忽悠,所以在这里说几句。如果没有超级高的性能和资源需求(可能要用 C 这样的低级语言),目前我建议就老老实实用 Java 吧。虽然不如一些新的语言炫酷,然而实际的系统,还真没有什么是 Java 写不出来的。少数地方可能需要绕过一些限制,或者放宽一些要求,然而这样的情况不是很多。

编程使用什么工具是重要的,然而工具终究不如自己的技术重要。很多人花了太多时间,折腾各种新的语言,希望它们会奇迹一般的改善代码质量,结果最后什么都没做出来。选择语言最重要的条件,应该是“够好用”就可以,因为项目的成功最终是靠人,而不是靠语言。既然 Java 没有特别大的问题,不会让你没法做好项目,为什么要去试一些不靠谱的新语言呢?

概述

KDE – 史上功能最强大的桌面环境之一;开源且可自由使用。19年前,1996年10月14日,德国程序员 Matthias Ettrich 开始了这个美观的桌面环境的开发。KDE 提供了用户界面以及其他很多日常使用的程序。今日,KDE 被成千上万人在 Unix 和 Windows 上使用。19年,一个对软件项目而言极为漫长的年岁。现在是时候让我们回到最初,看看这一切肇始于何处。

K Desktop Environment(KDE)有很多创新之处:新设计,美观,一致的体验,易于使用,对普通用户和专业用户都足够强大的应用库。“KDE”这个名字是对单词“通用桌面环境”Common Desktop Environment玩的一个简单谐音游戏,“K”即“Cool”。 第一代 KDE 在双许可证授权下使用了 Trolltech 公司专利的 Qt framework(现 Qt 的前身),这两个许可证分别是开源的 QPL(Q public license)和商业专利许可证proprietary commercial license。在2000年 Trolltech 公司让一部分 Qt 软件库开始发布在 GPL 证书下; Qt 4.5 发布在了 LGPL 2.1 许可证下。自2009起 KDE 桌面环境由三部分构成:Plasma Workspaces(用做交互界面),KDE Applications,作为 KDE Software 编译的 KDE Platform。

各发布版本

预发布版本 – 1996年10月14日

当时名称为 Kool Desktop Environment;“Kool”这个单词在很快就被弃用了。最初,所有 KDE 的组件都是被单独发布在开发社区里的,它们并没有被一个大的项目所贯穿起来。开发组邮件列表中的首选通信是发往 [email protected] 邮件列表。

KDE 1.0 – 1998年7月12日

这个版本受到了颇有争议的反馈。很多人反对使用 Qt 框架,因为当时的 FreeQt 许可证和自由软件许可证并不兼容,他们建议开发组使用 Motif 或者 LessTif 替代。尽管有着这些反对声,KDE 仍然被很多用户所青睐,并且成功作为第一个 Linux 发行版的环境被集成了进去。

28 January 1999

1999年1月28日

有一次升级,K Desktop Environment 1.1,更快,更稳定的同时加入了很多小的改进。这个版本同时也加入了很多新的图标,背景和材质纹理。和这些全面翻新同时出现的还有 Torsten Rahn 绘制的全新 KDE 图标—-一个放在齿轮前的字母 K ;这个图标的修改版也一直沿用至今。

KDE 2.0 – 2000年10月23日

重大更新:

  • DCOP (Desktop COmmunication Protocol),一个端到端的通信协议
  • KIO,一个应用程序 I/O 库
  • KParts,组件对象模型
  • KHTML,一个符合 HTML 4.0 标准的渲染绘制引擎。

26 February 2001

2001年2月26日

K Desktop Environment 2.1 首次发布了媒体播放器 noatun,它使用了模组化、插件设计。为了便利开发者,K Desktop Environment 2.1 打包了 KDevelop。

15 August 2001

2001年8月15日

KDE 2.2版本在 GNU/Linux 上加快了50%的应用启动速度,同时提高了 HTML 渲染、JavaScript 稳定性和性能,同时还增加了一些 KMail 的功能。

12345下一页
查看其它分页: