西西河

主题:苹果已死,脸书当立? -- 大山猫

共:💬1049 🌺5083 🌵75
全看树展主题 · 分页首页 上页
/ 70
下页 末页
家园 不侵权,你不能给API上专利
家园 天朝有最多的移动用户

性价比最高的移动互联网终端制造商,移动互联网时代的任何创新对天朝都是无效的。

让老美花大量物力财力、牺牲大量连算数都不达标的可造之才培养出的科技精英们来之不易的一点点小创新,几个月内就被天朝应试化教育培养出的冷血考试机器搞出的山寨撸平。

我怎么看怎么欢喜呢

你不是喜欢创新么,在这个对天朝而言没有护城河的行业,你倒是创啊。

三星、google才在智能穿戴上搞出点眉目,A股马上就有相应的板块,淘宝上中低端的“山寨品”也已经铺满了。

搞的好像爬科技树算什么值得炫耀的事,选错爬的时机被对方的低级兵种淹死的唯科技论者多了。

19世纪上半期和下半期,西欧各国与俄国的之间力量的反转就是现成的例子。事后诸葛亮可以说毛子因为政体僵化、创新不足最后失去了欧洲霸主的地位。但要是19世纪后半叶的科技大爆发与电气化革命晚来30年呢?西欧能保的住莱茵河以东不被斯拉夫化?

老美现在最靠谱的做法不是继续绝望的爬科技书,而应该去拉或者扶植一个可以在中低端抵挡天朝数量优势的大型新兴工业国做盟友。

可惜天朝人口已经占了全球的1/5弱,扶不起的三哥光扫盲就得至少花20年,我看老美是等不起咯。

通宝推:adrupal,技术人生,迷途笨狼,
家园 关于美国创新,中国山寨的现象

其实现在对中美双方都是有益的。现实是:美国的很多创新可以征服全世界,但难以打进中国;而中国山寨的东西基本在国内大行其道,但很难迈出国门。最明显的例子就是古狗VS百度,脸谱推特VS微博等。

所以,对美国的创新来说,损失的只是中国市场,但还能赢利和继续生存下去。对中国的山寨来说,是以最低的成本提高技术和改善生活。美国可以(也不得不)忍受中国的山寨,而中国也暂时不挑战美国的全球地位。

等中国自己的创新逐渐形成势力,并且行销全世界的时候,美国就真的玩不下去了。到那个时候,中美的军事实力也更接近,美国即使想跟中国翻脸也有心无力了。

家园 “病”地图更新速度比不上古狗地图

几个月前美国华盛顿州有个桥塌了,西岸南北大动脉5号高速公路中断。几天后架起一座临时桥梁才重新通车。古狗地图几小时内就更新了地图,而“病”地图一直到高速公路重新通车都没更新过。

家园 所以说Nokia只是理论上好

关键在于二次开发,特别是大数据信息挖掘和终端用户互动。

家园 对企业也是最现实的选择

虽然毁灭未必意味着创新,但创新的背后几乎必然意味着毁灭。创新力度越大,毁灭力越强。

其他的不说,光亚马逊淘宝京东这些就至少毁了出版、贝塔斯曼、零售这些传统行业。

如果只是单纯的创新,缺乏其他因素的推动。传统行业的巨大既得利益往往足以阻碍创新的产业化实现。比如柯达虽然最终被自己发明的数码成像技术给毁了,但如果不是数码成像这种对行业有不可回避颠覆性的技术,只是一般层级的创新,柯达这样的巨头完全可以把它们掐死在摇篮里。

除非对手已经实施成型,并对后发者的传统产业已经构成威胁了。这个时候相应的创新在推行时就比较容易获得公权力的背书,帮它去冲开传统行业既得利益者设置的障碍。

这也是腾讯这种被高端人士鄙视的山寨公司,为什么能成为中国互联网浆糊里最后几个硕果仅存的巨头的主要原因之一。

家园 如果这样的话,计划经济才是社会发展的方向

全社会穿一样的衣服,一个颜色,一个款式,无需广告,最为节约资源。

家园 谁来定义什么是要做的事?
家园 不一样

1.longene大量借鉴了wine的源码

2.毛德操本人表示wine是在“用户空间”作兼容的,效率很难满足要求,longene正是针对这一点做出改进,更多的从内核考虑解决兼容性问题。具体请看《内核差异核内补》http://www.longene.org/techdoc/0531255001224577169.html

3.与wine效率对比:

Longene和Wine的效率测试对比分析

测试方法:

1、选定一台设备。

2、安装Wine,使用测试程序测试,得到测试结果。

3、卸载wine

4、安装Longene,使用测试程序测试,得到测试结果。

测试环境介绍:

model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz

cpu MHz: 2600.000

cache size: 2048 KB

MemTotal: 1032748 kB

MemFree: 857724 kB

Buffers: 7872 kB

Cached: 116800 kB

测试程序介绍:

TestApi针对文件读写、注册表操作,消息操作分别测试。MFC编程。

TestAll将它们整合在一起,完整地测试以上操作。MFC编程。[测试程序打包下载]

测试程序流程:

1) 根据需要测试的文件数量、注册表项数量、消息数量,创建读写进程。

2) 文件测试:

Thread1负责创建一个文件,等待Thread2读取后,再次创建

Thread2负责读取并删除文件,等待Thread1创建后,再次操作

Thread1和Thread2使用Event同步

3) 注册表测试:

Thread3负责创建一个注册表键值,等待Thread4读取后,再次创建

Thread4负责读取并删除注册表键,等待Thread3创建后,再次操作

Thread1和Thread2使用Semaphore同步

4) 消息测试:

Thread5负责发送一个消息,等待主线程接收以后,再次发送

主线程负责接收消息,等待Thread5发送后,再次操作

Thread5和主线程使用Mutex同步

5) 使用的测试函数列表:

CreateFile

WriteFile

DeleteFile

CloseFile

RegCreateKeyEx

RegSetValueEx

RegOpenKeyEx

RegCloseKey

RegQueryValueEx

RegDeleteKey

PostMessage

GetMessage

CreateEvent

SetEvent

CreateSemaphore

ReleaseSemaphore

CreateMutex

ReleaseMutex

CreateThread

CloseHandle

WaitForSingleObject

WaitForMultipleObjects

测试结果:

下面对比数据以毫秒为单位,每100次为一组,共10组。

Longene0.3:

TestApi:

WriteFile ReadFile WriteReg ReadReg MsgTest

34 7 1 1 149

23 6 1 1 157

34 6 1 1 177

44 6 1 0 197

56 6 1 0 216

65 6 1 0 253

73 7 1 0 274

86 6 1 0 297

95 6 1 0 307

91 6 0 0 313

60.10 6.20 0.90 0.30 234.00

TestAll:

FileTest Write Number 100 Read Number 100 Time 20ms

RegTest Write Number 100 Read Number 100 Time 8ms

MesTest Send Number 10000 Recieve Number 10000 Time 184ms

All Time: 207ms

Wine1.0:

TestApi:

WriteFile ReadFile WriteReg ReadReg MsgTest

44 21 7 6 900

35 20 8 7 1147

45 21 7 6 1455

59 19 7 6 1731

69 22 6 6 2007

75 20 7 6 2286

85 21 7 6 2467

97 22 8 7 2467

112 23 7 6 2434

106 20 7 8 2478

72.70 20.90 7.10 6.40 1935.20

TestAll:

FileTest Write Number 100 Read Number 100 Time 73ms

RegTest Write Number 100 Read Number 100 Time 95ms

MesTest Send Number 10000 Recieve Number 10000 Time 1222ms

All Time: 1270ms

性能提升:

WriteFile: 17.33%

ReadFile: 70.33%

WriteReg: 87.32%

ReadReg: 95.31%

MsgTest: 87.91%

Summation: 83.70%

对比分析:

以写文件操作为例(实际上读操作也是一样),从整个过程看,Wine最低限度的操作有这么一些:

1) 客户进程通过进程间通信向服务进程发送get_handle_fd请求。注意这里至少有两次系统调用,一次是通过send_request()调用对于管道的write(),然后又通过wait_reply()调用对于管道的read()。

2) 内核调度服务进程运行。

3) 服务进程根据Handle找到目标文件在客户进程中的打开文件号,并通过进程间通信将其发送给客户进程。这里至少有三次系统调用,一次是通过send_reply()调用对于管道的write(),然后是系统调用poll(),接着又通过read_request()调用对于具体管道的read()。这里的系统调用poll()类似于select()。

4) 内核调度客户进程运行。

5) 客户进程通过系统调用dup()复制一个新的、临时的已打开文件号。

6) 然后用临时的已打开文件号调用write()。

7) 最后通过系统调用close()关闭临时的已打开文件号。

longene没有2和4过程的内核调度,因为longene去掉了WineServer。longene修改了1和3过程send_request和read_request的实现,由进程间通信改为系统调用,大大减少了通信所消耗的时间。

性能的问题在于两次进程调度。当客户进程通过IPC向服务进程发送请求时,服务进程被唤醒,内核则进行进程调度和切换。显然,用户此时希望服务进程能马上被调度运行,这样才能保证快速的响应。可是能否如愿以偿呢?这就不一定了。如果此时有个优先级更高的进程因某种原因(例如中断)而进入了就绪状态,服务进程就只好往后靠了。所以,在上列的第一和第二两个动作不一定是连续的,中间可能会有别的进程插进来。而对于桌面用户,这个优先级更高的进程得倒运行的正面效果也许感觉不到,而负面的效果却感觉到了。同样,当服务进程通过IPC回答客户进程时,客户进程也完全可能一时不能被调度运行。

文件性能测试受磁盘I/O速度的影响。longene只能节省进程调度所花费的时间,但并不能避免同是毫秒级别的磁盘读写所花费的时间。读写文件性能上的差异很好的体现了这一点。在写文件时,每次都要创建新的文件,而在读文件时,每次都是打开已有文件。所以写文件的Disk I/O比读文件的Disk I/O更多,因此性能提升比较小。

注册表性能测试可以体现出两次进程调度带来的性能差异。longene的注册表读写完成时间大概都在一毫秒之内,而进程切换都会消耗几毫秒。相比之下,注册表本身的操作所消耗的时间十分微小。

消息性能测试和注册表性能测试类似。以输入消息为例:

1) Wine需要从X11获得输入消息。

2) Wine获得输入消息后将消息放入WineServer。

3) Wine从WineServer获得输入消息。

虽然PostMessage没有和X11通信的过程,但Wine还是需要两次和WineServer通信才能获得输入消息。 longene无法避免花费和X11的通信时间,却也减少了大量的和WineServer的通信时间。

本次测试前,正好wine发布了新的1.2RC,实际测试wine1.2的结果和wine1.0几乎完全一致,可以看到wine的主要侧重点在于兼容度的提高,而由于架构的关系,在性能方面可提升的空间就很小了。

家园 天朝山寨早已进入了瓶颈

互联网上的创新凡是与人数有关的,天朝早已一马当先通过本土化,官商化牢牢占据了垄断地位。这类本质上不是爬科技树,而是通过控制舆论来控制营销的“创新”企业,天朝是当仁不让的。

但凡有点技术含量的,天朝的山寨主要还是靠西方自己就存在的公开透明部分,比如开源了,下游代工的技术泄露或欧美抛弃的过时产业等来山寨。但是在规模化之后主要仍然是在大陆地区与世界落后地区打开市场,比如电视机,廉价手机等。高端点的山寨产品,不要说进入欧美市场,连大陆内部市场仍然都不能达到互联网企业那个规模的垄断。

话说,一个安卓手机山寨化,这已经是第几个年头了,在美国市场上仍然看不到多少天朝产品,只有ebay上有。相比之下,欧美主动抛弃的PC产业,天朝的联想现在早已在北美成为势头最旺的市场巨头。这里面透露出来的天朝在爬科技树上的艰辛,不是几句YY就可以掩盖的。

日本人从山寨汽车,照相机,先是占据自己国内市场到在西方市场上打主流,也不过一,二十年的光景,韩棒在互联网移动网大潮中走过同样的路,也不超过十年。大陆在顺利的接过日常用品等低端市场之后,走上了自己通过港台代工的帮助爬科技树的“不靠人”的路子,但是结果是形成了一个产品目录齐全,但是普及在低端产品线上的自闭体系。

虽然世界在向两极分化,但这不是最关键的问题,因为大陆积累的财富拥有了数量庞大的高端市场。天朝恐惧的是担心在这个爬科技树的过程中形成代沟,代沟虽然会带来市场颠覆,但是这至少在天朝内部不是问题,前面说过只要天朝的低端市场在天朝手中,这个代沟即使出现也没有威力,这三十年形成的代工产业可以帮助天朝在技术上快速山寨出画虎不成反象猫的低端产品。

而真正的问题是天朝内部的高端市场与外向型经济向世界高端市场的转化。这个压力的存在是因为,第一,低技术廉价产品的生产向东南亚,三哥方向的转移,第二,同时高端山寨产品被日韩的垄断。你所谓的老美最靠谱的做法,其实正在实实在在的发生中,同时老美自己悠哉闲在的开发高科技,扎扎实实的推动代沟。 从低端依靠人工优势压榨中国的低端产品利润,并带动代工业的转移,从高端帮助日韩的规模化领先进入代沟,倾销天朝与世界的高端市场。这里应该睡不着觉的是天朝领导人。

天朝目前不敢稍微懈怠的才是自主爬科技树,但是这个目前比东学一着,西顺一拐在天朝还是难度大的多。好在天朝靠这几十年已经拿到手的技术与在世界市场上的地位,饭还是可以吃的好好的,代工也一天搬不走。老美的目标也没有这里键盘政治局们说的那么凶险,那是有许多维稳的动机在里面。老美不过就是要把天朝嘴里的给世界其他地区分分,同时给天朝科技追赶断奶,不想让天朝发展到日本的水平,天朝当世界工厂难道不是个世界上所有人都喜闻乐见的事么。

再往大里说,扩张也不一定都要靠科技,不要说东欧的斯拉夫如何,就是穆斯林,人家那科技树可是连爬的欲望都没有,不是照样几个世纪一口气的铺的到处都是。前苏联干山寨也有几个世纪了,日本同样,最后都安生了。话说没有西方的支持,前苏在前德的科技领先压迫下,怕早就不用等到戈尔巴乔夫了。如果前德不是科技树爬的太快,最后喷气机,原子弹都搞出来,别说前苏,欧美也都得玩完。这才是欧美要联手搞掂前德的主要动机。

tg教给大家的是辩证主义,科技论但不唯科技论,但是首当要冲的还是科技论,抹杀科技论那就不辩证了是吧。天朝自古以来不在乎科技是不假,就是到了tg的手里仍然把科学技术当成非我族类其心必异,那么拿tg这个态度去比前德,甚至前苏,差距都不是一点半点的,还何来的半点欲望。

通宝推:李寒秋,
家园 微软现在就是给自己画了一张大饼

谁也看不懂微软除了什么都有什么都插一脚外还能做什么。所以这个海选CEO的过程就格外难猜。

似乎的是微软想走苹果+google的路,但同时还惦记着oracle+ibm的方向,加上一手的cash,选择还是真不少。不过就靠这个企业应用里的既有地位,微软的确可以做的不少,但是微软试图成为苹果或google的对手,恐怕是没希望了。

家园 腾讯本身总体上就是令人震惊的巨大创新,这个普通人不知道

有一次跟朋友聊天,讨论腾讯没有创新,怎么能取得成功呢?

朋友说,腾讯其实有创新。

其他的即时通讯产品ICQ,MSN在商业都失败了,只有QQ创造了即时通讯产品的商业模式。

【这种以即时通讯产品为社交基础的商业模式,就是腾讯最大的创新】当年之所以腾讯融资困难,就是因为国外没有这种商业模式的成功先例。

我觉得朋友的看法有道理。

Facebook也是类似的商业模式,只不过把社交基础产品从QQ换成了Facebook而已。

通宝推:月下,樱木花道,
家园 我也很奇怪

现在的诺基亚还有什么是微软自身没有而又必须得到的呢?至于花这么多冤枉钱?诺基亚的武功,渠道、品牌,在智能机时代已经荒废八成,至于设计,微软自己也不差呀!

好像是李开复说,微软过去在收购上很抠,于是错过许多机会,现在矫枉过正,在收购上乱花钱。

退一步说,市场成功靠收购也不能得来。

android之父鲁宾之前也在微软干过,但自己的项目遭到微软安全小组排斥,无疾而终,负气出走。

微软的企业文化可能很难包容移动市场需要的人才和作风。

真有这么多钱,不如花在两个地方:

1.App Store去年收入也不过24亿刀(当然apple只拿一部分钱)。微软应该找到上面排名前500的应用,一个个打电话过去,告诉他们:只要你们做windows phone平台上的app,并且与ios、android体验、功能差距不要太大,我就给你们ios上收入的一半,哪怕一个使用者都没有!

2.宣布windows phone三年甚至五年内免费,并且仿效MTK的turn key做好服务,帮厂商做好适配,降低门槛。

这两条能做成,花两年丢个200亿,看起来是巨亏,但买回来的是命,是微软的未来。这些年失去的先手都能扳回来,哪里还在意华尔街的聒噪?

家园 能在中国活下来并做大本身就是创新的一种

msn在中国不行,比qq或者飞信差得远,本身就是缺乏创新,或者说根本没有创新。

家园 以点概面了

你参与过的淘宝店的运营情况不能代表别的淘宝店亦是如此!绝大部分的淘宝店主都不会像你所举例的那家淘宝店一样在一线城市租房子做仓库!蛇有蛇路、龟有龟路,大家都懂得因地制宜的!

还有绝大多数全职淘宝店主只能挣个打工钱!呵呵,你怎么知道人家只赚个打工钱啊?财不露白是中国人的传统你不知道啊?咱同学朋友这么多,各行各业的都有,见面都是互相诉苦呢!咱觉得,自己给自己打工,自由自在,没人盯着你防着你,这种感受跟给别人打工应该是截然不同的!

最后拿包产到户来相提并论有点搞笑!大道理人人都懂,但涉及到个人就不是如此了!中国农民几千年下来就这个土地情节最严重!49年到80年,指望短短的三十年改变这个过于理想化了,那个时代的农民从内心来说跟以前并无不同!焉知不是因为农民觉悟低,给集体干活没劲,所以上面有意补课呢?

全看树展主题 · 分页首页 上页
/ 70
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河