Linux Mint 13 ‘MAYA’值得注意的5件事情

最近备受瞩目的Canonical公司最近发布的Ubuntu Linux12.04“Precise Pangolin”现在有新伙伴了,那就是Linux Mint 13 代号’MAYA’。

就在几个星期前,我们看到了Fedora 17 beta版的发布,最终版将会在半月来临。现在Linux Mint发布了自己的Linux Mint13,或者叫”MAYA”.

1.两个版本

 Mint有全新的Cinnamon桌面,Maya会提供一个基于此桌面的OS。因此用户可以选择成熟和稳定的MATE 1.2或者全新的,令人期待的Cinnamon 1.4。

2.长期支持

Ubuntu Linux 12.04是一个长期支持(LTS)版本,Linux Mint 13也是基于此的,因此也是长期支持的。所有的软件将支持到2017年4月,这对企业用户来说是很有优势的。

3.新的显示管理器(Display Manager)

MDM,一个新的显示管理器,基于GNOME 显示管理器2.20。图形化配置工具,远程,自动,定时登录,事件脚本,语言选择,它比现有的任何显示管理器都要强大。

4.yahoo

对于在美国,加拿大,英国,爱尔兰,德国,法国,意大利和西班牙的用户,雅虎现在是默认的搜索引擎。当然,任何人要使用不同的搜索引擎,可以很容易的自己选择设置。

5.更漂亮的界面

有最新的Mint—X和Mint-Z主题的支持,Linux Mint 13有了一个爱尔兰艺术家优美照片的背景集合。

现在还不确定最终版将会何时发布,届时,它将可以从网站上直接下载。

Android,在争议中逃离 Linux 内核的 GPL 约束

为这个题材起名,我思考了许久,GPL 是著名的开放源代码许可协议,Linux 内核开源项目正是在 GPL 的庇佑之下,十多年来在服务器、PC 端以及各种嵌入式设备上成绩斐然,是当之无愧的当代计算机软件的基石,说 GPL 代表着 Linux 的开源精神,毫不为过。然而,现实世界中,GPL 开源乌托邦和商业社会的丛林法则之间存在剧烈的冲突,其中犬牙交错,艰难成长,从中引发的思考,与大家共享。

Linux 内核的 GPL 约束

总所周知,Linux 内核以 GNU 通用公共许可证第二版(GPL V2)的授权使用协议下发行。GNU 通用公共许可证是一种 “Copyleft” 形式的“版权”,保障任何人都能够对 Linux 内核以及其衍生产品的使用、修改和重新发布的权力,前题是不能修改发布条款。什么意思呢,任何 Linux 内核的衍生产品(Derived Work)必须遵循 GPL 协议进行发布。然而问题的核心在于什么是 Linux 内核的衍生产品,其中有几个致命问题,业界争论了十年有多。

1、使用 Linux 内核的头文件定义,进行系统调用的程序是否会被定性为衍生产品?

2、链接使用了其他 GPL 的类库的程序是否会被定性为衍生产品?

3、Linux 内核动态载入的模块 LKM(Loadable Kernel Modules)是否会被定性为衍生产品,以 LKM 形式开发的 Linux 驱动程序是不是衍生产品?

如果上述问题答案均为“是”,GPL 将为 Linux 打造一个的“封闭” 的开源世界,什么意思呢?一个 Linux GPL的操作系统核心运行在 “ 内核空间 ” ,上层的类库、框架、服务、应用运行在 “ 用户空间 ” 。用户空间上的任何服务不可避免的需要Linux 内核的头文件,进行系统调用,因此,中间层服务必须遵循 GPL 进行开放源代码。调用中间服务层的框架或者其他服务使用了 GPL 的类库,因此,也必须是 GPL 的。同理,上层应用也被 “ 传染 ” ,必须是 GPL 的。于是,从内核到驱动到中间服务到上层应用,形成了一个 GPL 一体化软件授权的软件发布整体。可以认为,这个整体上任何开发成果都是 GPL 的,除非极少数的例外程序能够证明自身独立于系统的GPL环境。这样的一个“软件闭包”排斥的商业化的软件模块以及“想要钱”普通开发者,将整个软件世界 划分为“ GPL 与 GPL 兼容的”的和非 GPL 的,每个开发从业者面临着选择,要么 Linux+GPL ,要么 Linux 与你无关。

重新回到这三个问题,第一个问题,曾经被 Linux 内核的作者 Linus Torvalds 以及内核开发人员多次澄清普通系统调用为非 GPL 的作用范围,甚至固化在 Linux 内核的源码 COPYING 文档中,为 Linux 用户空间的程序采用非 GPL 的授权许可证打下了基础。

第 二个问题,具有明确的答案,是。这也是为何 GPL 被抨击为具有“病毒感染”的特性,一旦程序使用了 GPL 的模块,本身即被传染,程序必须成为 GPL。如果主程序与 GPL 类库是静态链接(Static Link)的关系,业界一般认为主程序必须限定为 GPL。而对主程序动态链接(Dynamic Link)GPL类库主程序一般认为也必须是GPL的,若要打赢官司,必须证明主程序与GPL模块之间具有“独立性和可区分性”(Separate and Independent),才能逃离 GPL 的约束。GPL 官方网站上的有这样的 FAQ:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the software as it is actually run includes the library.

 如果一个类库以 GPL 的许可证授权进行发布(不是 LGPL),是否意味着任何使用该类库的软件必须以 GPL 或者 GPL 兼容的许可证下进行发布?

是,因为软件包含了该类库才能运作。

第 三个问题,是硬件厂商和 Linux 内核开发社区之间一场旷日持久的争论的中心。最著名的,莫过与图形显示设备厂商 AMD/ATI、NVidia 出自硬件规格保密以及知识产权的考虑,长期以二进制软件包的方式独立发布图形驱动,涉嫌违反了Linux内核开放源代码的软件授权协议 GPL,至今仍是 Unity 与 Gnome 3 等依赖于硬件图形加速的新型桌面技术发展上的一大阴影。主要的 Linux 内核维护者 Greg Kroah-Hartman 曾经严厉的批判过,内核中的二进制软件包发布的模块是非法的不道德的

说 到此处,可以看到 GPL 下的 Linux,存在着开源精神和商业机密以及知识产权保护相关的商业精神存在尖锐对立,对硬件厂商以及其他商业软件开发者来说,既不能忽视Linux广阔的 商业市场,也不能放弃产品规格以及知识产权保护,两者都会伤害其立命之本。在早年的一份嵌入式操作系统选型的研究报告指出,Linux 相对于其他的 BSD 的 Unix Like 操作系统,由于 GPL 的约束限制,不具有商业优势。(参见引用3)。一言以蔽之,业界有 GPL 的恐惧症。

然 而,在移动互联网蓬勃发展的今天,一个 Linux 的发布版本,Android 在各种智能嵌入式设备上面大放异彩。据说,Android 之父 Andy Rubin 极度厌恶 GPL(James Bottomley,Linux SCSI 子系统的维护者说其人“Working from an extreme dislike of the GPL”),然而 Android 向世人展示了采用 GPL 授权代码的手机也能获得巨大的市场成功。

Android:把 GPL 局限在内核空间

下图是 Openfoundry 绘 制的 Android 的授权许可证结构,可以看到在 Android 多层软件栈中,仅仅最核心的 Linux 内核使用了 GNU 通用公共许可证,在这个层次上,Google 对 Linux 内核的所有修改必须反馈回 Linux 主版本树(Android 的内核将在 Linux 3.3 版本进行回归,两个版本的 Linux 内核进行融合)。

其上层的类库以及应用框架以及所谓用户空间部分,大部分使用 了“ 温和 ”的 Apache-2.0 软件许可授权,允许 Android 上的开发商基于 Android 的源代码进行开发而不向社区反馈。基于上文讨论 GPL 的第一个问题,用户空间的类库以及程序使用 Linux 内核的系统调用不被视为是Linux内核的衍生产品,因而得以自由采用 Apache-2.0 的软件授权进行发布。GPL 世界和非GPL世界的分界线在于一个叫做 Bionic Libc 的类库。Bionic Libc 的关键之处在于如果 Bionic Libc 受到内核 GPL 的“感染”,将会波及非 GPL 的用户空间的各个模块。

Android 的 Bionic Libc 的类库,采用 BSD 的许可证授权。在 2008 年 Google IO大会上,一份著名的 PPT:“ Android Anatomy And Physiology ”讲到 Android 使用 Bionic Libc 类库替换Linux常用的 Gnu glibc ,其中一个主要原因是 “ We want to keep GPL out of user-space ”。 (这其实有点难理解,毕竟 Gnu glibc 采用的是 LGPL 而非 GPL,并基于上文 GPL 第一点的讨论,使用系统调用的程序不再被视为 Linux 内核的衍生产品,并不需要遵循 GPL,有兴趣者请看下文用户空间驱动部分的分析) 。Bionic Libc 充满着非议,Bionic Libc 拷贝内核头文件的行为,并在源码中声明的版权信息均遭到了 “ 侵犯 Linux 内核 GPL 约束 ” 的质疑。这是 Bionic 头文件的版权信息,许多人认为是非法的:

“This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information.”

头文件由Linux内核的同名头文件自动生成,用来获取完成用户空间系统调用的必要的信息。它只包含原头文件中的常数、结构和宏定义,因此,不包含版权信息。

不管如何,从目前的情况看,让 GPL 止步于内核空间的做法是成功的,并已经得到很大一部分内核开发者的认同。James Bottomley,Linux SCSI 子系统的维护者在 2011年 LinuxCon 大会日本站上谈到  Android 的商业成功与 GPL 恐惧的时候说:

We should also design more “bright line” systems which make the question of GPL compliance clear. The kernel’s user-space ABI is one such system; developers know that user-space code is not considered to be derived from the kernel. Making the boundary easy to understand helps to make the GPL less scary.

在遵守 GPL 的问题上,我们必须澄清一些界线。内核的用户空间 ABI(应用二进制接口)就是一种 GPL 的作用边界,能让开发者意识到用户空间的代码,不被定性为内核的衍生产品,如果 GPL 的界线清晰而易懂,可以帮助大家消除对 GPL 的恐惧。

缓解 Linux 驱动的 GPL 困境

Android 的发展离不开硬件设备厂商的支持,硬件设备厂商最关注的是 Linux 驱动的 GPL 约束问题,公开驱动程序源代码将会泄漏设备的硬件规格和泄漏核心知识产权,这是硬件厂商 GPL 恐惧的缘由。Google 不遗余力的为硬件设备厂家排忧艰难,保驾护航。上文提到的 “ Android Anatomy And Physiology  ”,文中清晰的讲到 Android 在用户空间与内核空间之间存在着硬件抽象层  HAL(Hardware Abstraction Layer),HAL 类库本质上一种用户空间的驱动,其中的主要用途之一:规避 GPL

用户空间的驱动

Linux 是单内核操作系统(Macrokernel),这种操作系统的一大特点是驱动存活在内核,优点是驱动与系统内核共生在相同的地址空间,运作的效率比较高, 缺点是当驱动有问题的时候,容易危及内核的工作安全。用户区间驱动的思路是将驱动的主要业务逻辑剥离出来放到用户空间的主驱动模块中,内核中的驱动是个 “影子”驱动,只有透传控制命令和数据的功能。

Android 的 HAL 相当于上图中的主驱动,其在内核中的驱动相当于上图中的影子驱动。规避 GPL 的硬件厂家把需要保护的商业机密以及知识产权相关的逻辑放在 HAL 层,以二进制包的方式发布,不需要公开源代码。

这种机制看上去很美,然而,同样面临着巨大的争议。HAL 类库与内核驱动之间通过普通的系统调用能够完成么?如果不是普通的系统调用,用户空间的驱动就违反了上文中的第一条,用户空间的驱动不能获得 GPL 例外的豁免。Edward J. Naughton 2011 年 3 月撰文认为,普通的系统调用应 被理解为 gnu glibc 向外暴露的系统调用接口,而 Android 通过 Bionic libc 类库暴露了更多的接口,包括原来在内核空间才能使用的接口,其目的是为了让用户空间的驱动能够充分的利用内核和硬件资源。如果情况果真如此,Bionic libc类库是 Google 的后门,这也可能 Android 抛弃使用 gnu glibc 重写 Bionic libc 的其中一个主要原因。Edward J. Naughton 说:

Some of the calls exposed by Bionic are ordinarily not available to userspace because they’re excluded by the use of the #ifdef __KERNEL__ … #endif guards. If Google can define any call to the kernel from userspace as a “normal system call” (even those system calls ostensibly guarded by kernel matainers) simply by including it in its new C library, then a “normal system call” becomes whatever Google (or Oracle or Microsoft) wants it to be.

Bionic 暴露了原来在用户空间不能使用的函数调用,这些调用原本在代码中被 __KERNEL__ 的宏定义保护其运行在内核状态。如果Google 只要将在 Bionic 添加暴露的接口就可以自由的暴露 Linux 系统调用(这些系统调用明显应该由 Linux 内核社区维护),那么难免被其他人效仿。

总结

总 得说来,Android 为 GPL 下的 Linux 如何与商业社会并存与共赢提供了一个成功的范本,尝试为 Linux 生态系统上的各种角色划清彼此的作用范围,梳理了各方在版权上的权利和义务,目前看来获得了惊人的商业成功。然而,这种工作模式也面临着巨大的版权争议, 理论上存在一种可能,一旦版权模式被否决,将面临被全盘否定的灾难。

题图来自 bzatreeza

几种常用 HTML5 移动应用框架的比较

 

对于Mobile Web来说,现在是快速成长时代。由于采用了HTML5和CSS3技术,移动浏览器的性能加强了许多,同时,移动app的框架也扩展了,这意味着为移动设 备创建丰富的互动的web体验的可行性又提升了。采用诸如PhoneGap这样的封装软件,您就可以使用native app Store以及单个代码库,就可以分布式部署iPhone,iPad和Android等不同的目标平台了。

对于Mobile Web的开发人员来说,切换框架代价很高:因为动画的转换,工具栏,按钮,列表的显示,以及线下存储等都很麻烦。因为大部分上述功能都是新技术,以及这些 领域的技术还在迅速地改变。作者玩转了许多Mobile Web的框架并且对它们进行了分析比较,下面将为您讲解他的研究发现。

 

jQTouch

jQTouch易用性强,相关文档也很全面。它的特色是在 使用HTML,CSS和JavaScript创建iPhone App方面拥有出色的能力。jQTouch使用渐进增强的方案,在您相应的HTML顶层来实现像iPhone那样的用户体验。它简单易用,提供了一个基础的小工具集以及动画方案,开发人员只需要编程控制其动态行为即可。

不过在作者的简单测试中发现app的性能存在一定的问题,页面在转换时可能出现跳转或者缺失的情况,以及在响应tap事件的时候还有周期性延迟。该项目在技术上还活跃着,不过原作者的进展和部署都显得太慢了。

只需要遵守MIT的license许可就可以使用jQTouch了,MIT lic是作者最喜欢的开源许可之一。

 

jQueryMobile

jQuery Mobile是这个领域的新丁,2010年8月才正式宣布成立,但是已经迅速进展到功能丰富的阿尔法2测试版本了。jQuery Mobile跟jQTouch相比很相似,但是更加标准,更有适应性,感觉很像jQTouch的后继版本,对用户接口和style的支持范围更加宽广了。

jQuery Mobile的性能是不稳定的,(虽然比jQTouch好一些)特别是在响应TAP事件的动画延迟补偿的时候。此外,还缺少一些关键的程序hook,所以 不能轻松地让app更加具有动态性能。例如:当一个页面启动的时候事件触发了,这时候却无法通知响应的代码页面将转向哪个用户接口,也不能传递附加的信息 给处理模块。针对上述问题,创建工作区来解决还是可行的,但是在这里作者希望其将来的版本能从jQTouch那里学习一下,并把现在的功能缺陷处理掉。

jQuery Mobile的相关文档资料很零散但是有所改进,作者很希望它们能变得像核心jQuery库那样具有鲁棒性。(请注意,jQuery Mobile是和jQuery UI相辅相成的,并不是建在单纯jQuery之上的)

想获得jQuery Mobile只需获得MIT或者GPL2 license。

Sencha Touch

这是个与Ext JS框架完全不同的产物,其方案与jQTouch/jQuery完全不同:Sencha生成自己的DOM(基于用JavaScript创建的对象)代替了 先前存在的HTML增强方式。如此,使用Sencha工作的感觉不像是web编程,而更像是使用Java或者Flex等技术来做app的样子。比起 jQuery来,Sencha的感觉更像是YUI。作者个人比较偏好渐进增强的方案,尽管其性能还真有些不尽人意的地方。

sencha跟其竞争对手们相比,扩展性强了很多:它拥有大量的用户接口组件,直接的iPad支持,拥有JSON和HTML5线下存储技术使得存储 和数据绑定更加方便。(使用Sencha的数据结构来操作app的数据十分酷~它可以实时响应列表的更新)此外,Sencha还是唯一在工具栏上支持内嵌 的对象支持,其他方式都是滚轮列表的样子。

在作者的测试程序中,使用Sencha与jQTouch/jQuery相比,虽然app很明显地不那么轻量级,但是其性能和可靠性方面明显提高了,不过其初始化加载时间略慢。

当您使用库library或者框架frame进行开发的时候,不遵守框架或者用你自己的方式通常都不会获得成功。但Sencha的支持范围足够宽 广,这意味着您可以使用Sencha的开发方式来实现任何需求。作者最开始用的是WebKit的内嵌SQLite数据库来做线下存储,但是最终还是因为其 复杂性和各种bug问题的烦恼而放弃了,转而使用了Sencha数据存储的功能。

在文档方面,Sencha做的不太好,虽然很广泛,但是又有很多旧版本的老漏洞没有及时更新,作者就在这些框架中与bug作斗争,调试过程浪费了很 多时间,因为文档不够健全,很多问题难以追踪或理解。而在开发者论坛响应作者提问的频率还算较高,不过最终感觉还是不太够。Sencha提供的付费技术支 持起价是$300每年,作者很强烈地打算付费了,但是Sencha的回应是很好奇地打听为啥这么急着给他们送钱,真搞不懂。

获取Sencha需要遵守GPL3 license,以及在某种不是GPL标准又很相似LGPL的授权下也能用,以及遵循非商业license也可以获得。

 

TitaniumMobile

与Sencha Touch很相似,Appcelerator公司的Titanium Mobile可以让您使用Javascript API来编写app。不过与Sencha不同的是,Titanium把你的代码编译成Native的iPhone或Android app,这意味着它并不是一个真正的Web框架,而是一个兼容层或者编译器。(请注意Titanium Mobile的近亲Titanium Desktop是一个基于web的,让您可以使用HTML /js来编写桌面封装的本地应用的一款软件)

这么说来Titanium允许web开发人员使用JavaScript和一点点XML之类的其他相关技术,可以实现高性能、更换皮肤很方便的 Native App,而不需要额外去学习Objective-C或者Cocoa Touch等技术了。作者的简单测试表明其性能不错,吹散了框架方面的疑云,而且整合起来也不是太难。

不过这个优点也是其致命的缺点,您只能作出Titanium所支持的平台上面的应用,你被它们的开发工具限制住了。作者想证明这一点只需要换一个不 是iPhone的平台上来跑一下就知道了。同时,Titanium的调试器也不怎么样,不能使用XCode方式运行或者调试,就算在其仿真器上面程序跑的 还算不错,还是需要作者自己去实际机器上自己再找问题。

 

分析

作者在这4个框架上面挑选了3种并编造了自己的app来试一试,过程虽然很冗繁,但是收获也颇丰。作者很喜欢jQTouch,但是不太相信它会在现 有版本上再前进多少了。对于jQuery Mobile,很赞赏其简单易用性以及其以web为中心的开发方法,不过它的缺点是缺少核心特色,跟Sencha比性能差很多。

用一个阿尔法2版本的产品来跟一个1.0版本的正式版相比或许有失公平,但是在用户具有很强烈的刚性用户需求时就必须做出选择了,于是作者选择了 Sencha Touch。作者最初被其强大的性能和宽广的支持程度所吸引,最终更喜欢其开发风格。随着开发的深入,其文档的漏洞让作者十分沮丧,但是其广泛的支持程度 依旧吸引着作者,渐渐适应了其开发风格。如果他们愿意回复邮件的话,作者很有意向付费以获取技术支持。不过现在,Pints的发布已经是一个基于 Sencha的app了。

 

结论

作者还没有回答最大的问题呢:一个基于web的app在没有本地app的情况下能否hold住局面?如果可以的话,实现这样的技术是否值得舍弃原来那种单一代码库方式所带来的代价呢?

鉴于两星期以来Pints的实际应用,作者倾向于说不。Pints在性能和bug方面陷入僵局,平均每隔10-15秒页面就乱跳,在滚动页面的时候容易乱跳,动画效果也不是很连贯。

 

原文地址:http://www.dzyngiri.com/?p=752

翻译:范小虎

热点争议:Web 设计师需要编程知识吗?

Web设计师是否应该学习编写代码是个充满争议的问题。通常,在完成了一件网页设计后他们把创建网页代码的繁重工作都留给了程序员们。这种现象不只出现在网络开发行业,在软件及游戏开发业也是如此。 在本篇文章中,作者Deepu Balan 和大家分享了一些为什么Web设计师需要学习编写代码的理由,这会使广大的Web设计师们受益匪浅。

 

Deepu Balan 是个自学成才的Web UI设计师和Web开发者,他对Web设计相关的工作充满热情,你可以通过他的Twitter@bdeepu来关注他。

我们假想一下,如果所有的Web设计师对开发一窍不通,而Web开发人员对设计一无所知,情况会有多么糟糕?偏偏我这样的怪人既希望网站能够设计得非常漂亮,运行也非常流畅。

很抱歉以这样一段话作为本篇文章的开头,但是每当我看到很多Web设计师对HTML和CSS基础一窍不通的时候,都禁不住感到奇怪。不要误会我的意思,但是,一个精通Photeshop的设计师,在跟一些简单的HTML或CSS标签打交道的时候都很吃力,这听上去非常别扭。你肯定不会把“我是个设计师,我对HTML和CSS一窍不通”这种话当成一种炫耀。不管怎么说,这种情况存在争议,有人赞成不学习HTML和CSS是因为它们不像Photoshop那样具有很强的创造力;但是当这和学习编码的优势出现矛盾的时候,这些争议就明朗了。

设计师不谙编程带来的问题

我们假设一下,这是个美好的世界,和平永存,对于设计师来说,图片的导入过程很简单,并能够把它轻而易举地转化成一个引人注目的网站,或App。但是现实世界很少出现这种情况,你需要先使用Photoshop把图片设计好,再通过Dreamweaver或类似的工具把这些图片转换成网站的前台,由于设计师认为HTML和CSS不在自己的工作范畴之内,因此,设计师需要和程序员协作按时完成项目。

这就是最基本的团队合作,某个团队成员的缺席,整项工作就都无法开展。如果设计师可以扮演兼职的开发人员的角色,保证工作按时完成岂不是更好?实际上,我想说得更极端一些,每个设计师都需要有编码能力。并且,学习HTML和CSS基础也非常有趣,这意味着,你没有拖延学习的理由。相信我,你不会后悔学习HTML和CSS,永远不会。

编码是设计师不可推卸的责任
并不是每个设计师都能那么幸运,一些设计师不仅要完成登陆页面设计的工作,还需要在项目中承担起协调的作用,并且,有时候,老板相信他们有把所有想法呈现在浏览器中的潜力。相信我,这并不是一件糟糕的事,你只需要一到两个月时间钻研HTML和CSS,就可以让你的简历更加出彩。好了,说实在的,CSS虽然表面有点复杂难懂,你在元素的位置上花些功夫,是非常值得的。

不管怎么说,如何你仍然意志坚定地不想知道为什么自己要学习HTML的原因,那么下面我给出了你需要考虑学习编码基础的5大理由:

1.更完善的知识体系让设计更加可行

大多数用户都会抱有这种观点:设计师精通编码,这意味着,他们希望参与开发过程以期得到满意的结果。这听起来是个好主意,但是作为设计师来说,你不得不应付更多的干扰,更甚者,还可能需要忍受荒谬的建议,这些建议很有可能搞砸整个设计过程。但是如果你有相关的HTML和CSS知识,客户便不敢对你随便指点,项目也会按期完工,多方皆大欢喜。

2.完整的创作过程

把编码和设计过程拆分开来,不可避免地会出现开发人员胡乱对待设计问题,因为开发人员认为在调整色调或更换渐变效果这样的小问题上没有必要去打扰设计师。所以说,最完美的解决方案就是设计师能够提高编码的能力,这样会大大提高工作效率。

3.编码与设计之间的差别并不大

相信我,编码与设计之间的差别并不大。实际上,在一些专家看来,HTML和CSS本就是设计师的份内事。而且,HTML和CSS会让你的设计更加完美。因此,可以公平地说,HTML和CSS是设计师应该完成的工作。你只需要跨出一小步,你就可以稳稳地抱着自己的“金饭碗”了。

4.节省时间

由于你知道把网站的哪个部分做的更有创造性,在使用HTML和CSS进行设计的时候就会留心。这些工作你都得心应手,这就意味着,整个设计,编码成HTML的过程会在最短的时间内完成。而且,如果你一个人完成所有的工作,就不用在文件传送和让其他人参与开发上浪费时间了,整个过程对你来说轻而易举。

5.源源不断的机会

如果你想让自己拥有更强的竞争力,你需要同时拥有设计和编程的能力。没有人会喜欢开发人员完成的工作,而把奖励给予设计师的这种想法。这就是为什么拥有编程能力的设计师会大受欢迎的原因。

原文出处:Do web designers need to know coding?

MSN 遭中国用户痛批 被指存三大罪状

MSN账号被黑,用户企图通过MSN公司找回自己的账号,却发现这个过程比账号被黑本身更让人崩溃。“很崩溃,几度想放弃,又不甘心。可能就是微软本身的战略问题,也许不能指望了。”一位账号被黑的MSN忠实用户,向记者道出了自己的绝望心态。

5月24日,本报刊发《MSN入华遭遇七年之痒》调查报道,对上述现象进行了剖析,引发众多MSN用户的共鸣。多位业内专家接受南都记者采访时表示,MSN在微软体系中位置尴尬,姥姥不疼舅舅不爱,对中国市场不重视,使得MSN在中国市场越来越边缘化。

著名IT评论家贾敬华更是一针见血地指出:“如果按照MSN现在的产品改进情况,以及MSN的服务态度,MSN未来几年有可能会退出中国市场。”

网友一边倒批MSN

产品好不好用,用户最有发言权!

本报的《MSN入华遭遇七年之痒》报道刊出后,在网络上引发了围观效应。在网易、新浪等门户网站上,上千网民“起楼”(跟帖),用自己的亲身使用体验感受,一边倒地批评MSN.记者通过对网友反馈信息的归纳,总结出MSN不得人心的“三大罪状”

“罪状一”:容易中毒,垃圾信息满天飞。在 投诉MSN的意见中,容易中毒最受“瞩目”。很多网友都反映,自己的账号莫名其妙地被黑,莫名其妙地向好友传播垃圾信息。网民“李晓华”的网友在留言中 称:“MSN账号安全管理懈怠,太多用户账号被黑后,因不甘成为肉鸡而离去。我的MSN天天收到众多朋友账户发来的恶意链接,便知道这些朋友账户中招了, 这些朋友也可能再也不会使用MSN了。”除了网友反映,记者本人及身边朋友也有多人曾遭遇这一问题的困扰。

“罪状二”:用户体验差,垃圾邮件多。除 了中毒、盗号这些硬伤之外,用户体验差也是MSN被投诉的“重灾区”。登录难、广告多、垃圾邮件多、添加好友看不到对方信息等等问题,在网友投诉中屡屡被 提及。网友“汤好赛”就表示,“IM界面和用户个人空间的整合太差了,用户自己都找不到自己的东西。MSN就是微软的弃儿,维护差,各种bug……”

“罪状三”:客服让人崩溃。账 号被盗被黑,用户自然着急,希望尽快解决问题。然而,拥有4000万左右活跃用户的MSN,在中国竟然没有客服电话。北京网友“eddie”在上留言: “我也早不用MSN了,一个是老是有病毒报错,另外就是找回个密码那叫一个费劲啊。找不到就不用了。反正选择多的是。”记者的一位朋友最近也为找回密码伤 透了脑筋:“要想找回密码,需要按系统提示,填写一大堆的资料。好不容易填好,提交后,系统却认为我不是账号的主人,没有办法给我找回密码。”

对 中国市场不够重视,对中国用户需求不重视,使得MSN在中国市场越来越边缘化。本报24日刊发《MSN入华遭遇七年之痒》报道后,由于收到更多读者投诉, 记者就读者投诉集中的问题,向MSN方面做出反馈,希望MSN方面对此做出回应。但截至昨日,MSN方面对此依然毫无反应。

“国外的高富帅来到中国成为了纯屌丝,只因不懂得咱们中国网民需要什么。”网名为“唐点点是我的小名是唐点点”分析。

MSN在华份额渐减

网友的批评强调的是个人感受,但来自专业人士的批评,则直指表象背后的本质。

互 联网业内知名人士、著名IT评论家贾敬华接受南都记者采访时强调,MSN在中国水土不服,很大原因就是MSN并不懂得中国市场,不重视中国市场,也不了解 中国用户需求。最近几年,MSN体积越来越臃肿,垃圾信息越来越多,致使MSN与白领用户群距离越来越远。“如果按照MSN现在的产品改进情况,以及 MSN的服务态度,MSN未来几年很可能会退出中国市场。就国内即时通讯市场的情况来说,MSN根本没有翻身的可能。“

中国移动互联网产业 联盟常务副理事长兼秘书长李易告诉南都记者,MSN中国所处的位置十分尴尬,它是合资的企业,不完全是微软旗下的公司,加上MSN在微软的业务版图中占比 太小,微软不会投入太多精力放在这上面。此外,微软中国区总裁的话语权很小,很难推进微软在中国的发展。

“假设MSN真的退出中国市场,我 个人认为也不会产生什么影响。一方面,类似QQ已经成为了中国互联网发展的一个重要标志。网民对它的使用习惯和接受程度都比以前大大提高了,MSN即使退 出,网民们也有其他的更多更好的选择。另一方面,就产品本身功能而言,腾讯比MSN强太多了。MSN在技术上没有真正的进步,得不到业界和消费者的认可, 那它就算离开中国市场,也不会有太多人去怀念它的。”

爱蜂窝网媒体策划总监、知名IT博主周新宁也表示,“MSN统一用国际市场战略来进入中国,在产品上得不到中国用户习惯的认可,所以未能占领市场是必然的。由于产品更新速度缓慢和水土不服,相信两年后,MSN在中国的市场份额将逐步减少,逐渐被其他产品替代。”

声音

“本人还在用MSN,OUT了!”

———北京《电脑爱好者》杂志社社长杨富强

“MSN面对QQ的竞争,反应太慢了。中国的市场,往往不是大鱼吃小鱼,而是快鱼吃慢鱼。火云邪神说过,天下武功,无坚不摧,唯快不破。”

———易传媒高级产品总监何沛

“能把这么个领导地位的必需品玩残,这是个奇迹。”

———IBM中国研究院王仕

“MSN的Mac版简直就是不合格软件,功能弱不说,还动不动就崩溃(crash)。”

———前天涯社区高级副总裁叶萌

“Sinofsky不重视中国因为盗版猖獗,这次Ballmer(微软CEO)强迫Win8重视中国,希望可以让MSN Messenger改观。第一步,MSN需要一个中文名字!”

———微软必应搜索资深项目经理李明章

(本文来源:南方都市报 作者:高凌云)