昨天的发现正在用的Site5的服务似乎不是很稳定，下午有一段时间down掉了，大约有十来分钟吧，呵呵，还是Microcat在买买提上发短信告诉我的，所以昨天晚上就顺便看了一下其它的空间服务。前阵子不少人都提到DreamHost的服务（1，2），据说也是Wordpress推荐的空间服务之一，并且现在打折打得很厉害，第一年的服务只需要$22左右，所以就去看了一下。呵呵，说实话这个服务便宜的让人有些担心了，所以有些疑虑，后来果然在桑林志那里看到了问题：

几个礼拜前开始，时不时收到 dreamhost 的邮件，说我的帐户占用的时间太多了。按照他们的统计，最高的时候到了 100 多分钟，而他们规定每个用户不得超过 30 ～ 40 60 分钟。

呵呵，这个是服务提供商的经典借口了，无数的惨痛教训就是从这样的警告开始的。通常的情况下，他们先语焉不详的给你发一些警告，然后就事先不告知的暂停你的帐户。譬如我先前用的Ace-Host的服务，虽然他们的价格很便宜，但是给了两次警告后就无限期的暂停了我的帐户，迫使我仓促的转移到Site5，还差点丢掉了所有的数据；Nick先前用的SmartCompaigns的服务也是同样的问题。所以我也不打算再考虑DreamHost的服务了，因为桑椹不过在DreamHost上安装一个Wordpress就导致了这样的警告，还被迫停止了许多的插件，而我现在在Site5至少还安装了四五个Drupal，并且我主站的流量也不算小，如果选择DreamHost肯定是噩梦了，呵呵。

更巧的是今天在一个一起玩Drupal的同好那里看到了一篇帖子：Why I Love Site5.com，称赞了Site5的服务，特别是比较迅速的客户反应，这点我也比较赞同，当时从Ace-Host迁移过来的时候，因为牵扯到数据的转化，Site5提供的服务还是很及时可靠的。所以比较再三，还是决定继续留在Site5了，呵呵，写blog其实最重要的是空间服务商的可靠性。

拾起drupal的翻译，想起来一段翻译的往事。第一次大规模的做科技翻译是在大三的时候，给朗讯翻译了大概八九十万字的服务器和服务器端软件的说明书。当然不是我一个人翻译的，是我们的team翻译的，我和Jay是组织者，其实到头来我也没有翻译多少东西，只是和Jay一起拿了一笔组织翻译的酬劳，可能有几千块钱吧。Jay翻译了不少，大概后来有几万块钱吧。这件事情的起因其实挺有趣的。它的起因是亚太经合组织（APEC）的会议。按照惯例，一旦在中国召开大的国际会议或是有什么重大事件（譬如克林顿访华），我们就放假参加会议服务，直到会议结束。幸好中国的国际会议不像纽约或是日内瓦那么多，不然的话我们都不用念书了：）

那次APEC的主会场在上海，但是几个部长级会议在北京开，所以我们知道肯定会去服务。因为台湾，日本，美国等都是APEC的成员经济体（hoho，一定记的要用economy而不是state啊），所以我和Jay在一天晚上的卧谈会上就慷慨激昂了一下如何像曹沫劫持齐桓公一样劫持台湾和美国的部长，要求和平统一台湾，本来也想把日本算上的，可惜没人加入我们的敢死队，所以就作罢了。不过根据历史经验，威胁、劫持诸侯的人一般死不了，譬如蔺相如，毛遂之流，所以我们很放心。

呵呵，当然不要相信我们真的要去劫持部长，我们也就这么闲聊的"愤青"一下。但是服务的名单下来后，几乎全系的人都去了，就把我和Jay给撇下了。这个郁闷呐。因为参加大会服务基本上就是玩，可以住豪华的大饭店，还能去人民大会堂蹭国宴，会议结束时各国代表还有礼物送，从笔记本电脑到越南的土产咖啡，不一而足。不过这都是小事儿，主要是所以的同学都走了，只剩下俺哥俩儿在寝室里大眼瞪小眼，极其无聊。想打扑克，凑不齐人，单挑"街霸"，也没个在旁边叫好的，很是没劲儿。于是我们俩儿开始反思为什么不让我们去。最后想到可能是我们俩儿个没去献血的缘故。其实我是献血积极分子，为了献血还去医院检查了眼睛，散了瞳（还顺带出了一次交通事故）。可是献血那天排队去晚了，我想加三儿，早点献完了赶紧去食堂抢午饭，结果被维持秩序的干部揪了出来，剥夺了我献血的资格。sigh，不管怎样，我们哥俩儿就郁闷在寝室了。

参加会议服务还给发一身行头，外交部的裁缝给量身定做的西服，蛮气派的，一时间寝室里衣冠楚楚，只有我和Jay两人蔫巴在窗户前天天看楼底下--得看好什么时候开饭。很多人都去服务了，所以原本就供应不足的食堂现在做的菜就更少了，一旦食堂冒起炊烟，就要赶着去排队打饭。回来以后，一边吃着茄子加米饭，一边听着回学校拿东西的同学描述他们吃的黑胡椒牛排，这个口水流的啊（其实那个时候我和Jay都没有吃过牛排，猜测一定很好吃，所以流口水，其实若干年后，等真正的吃了牛排，才觉得那真叫个难吃，远没有西直门的羊肉串香。）

除了吃饭，我们就闷得发慌。所以决定一起去旅游，暂时离开这个伤心的地方。但是估摸了一下，口袋里的银子只够我们去趟通州的，没奈何我们开始想办法赚钱。Jay找到了一份翻译的活儿，要去面试，在一个酒店的写字楼里。于是一天我骑着破驴带着Jay，顶着早晨七八点钟的太阳按时到达了面试的地方。接待我们的是一个台湾大叔，人还不错，按要求我们先做了试译。俺哥俩儿当时实在是穷聊--既穷又无聊，于是拼出十分内力，很快做完了试稿。交给台湾大叔，他很满意，告诉我们大致有八九十万字的产品说明书需要翻译。朗讯到底是大公司，开出的价码很是丰厚，我们哥俩儿高高兴兴的接受了这份工作，并开始计算要招几个"小工"。回到学校后，和吃黑胡椒牛排的外交官们一说，大家一拍即合，扣除我和Jay的"工头"报酬，余下的按劳分配。于是黑胡椒牛排们晚上闲暇下来也和我们一起赤膊上阵，挥汗如雨的做起了科技翻译。

当时是夏初，很快就是暑假，APEC的会议也结束了，所以整个寝室的人都动员起来做翻译，盛况空前。一时间一个寝室6、7台电脑昼夜运转，飞速翻译着各种高精尖的网络产品。很多术语是没有广泛接受的汉译的，于是我们开始生造，约定俗成嘛，我们就是第一批约定者：）可惜中途我因为旁的事情离开，跟着央视一位PP的女节目主持人跑去采访各国大使，没有把这次翻译做完。呵呵，不过交稿的时候，看着满满几大光盘的文件，还是很有成就感的：）

第一步，我们所需要做的就是把awtags彻底的转换为free tags。权衡再三，觉得还是使用drupal核心提供的tags比较安全，因为在将来我们不知道awtags还会不会更新。另外free tags因为使用了ajax技术，可以方便的给你书写提示，并支持tags中间的空格，还有就是可以自动ping Technorati。awtags好像也声称可以自动ping technorati，但是用了这么久，没见它ping过：）所以我们这里做的第一步就是将awtags彻底转化为free tags，然后我们再通过编辑drupa的主题，使得free tags的显示与awtags一摸一样（也就是说我们仍然保持原来的分类，但是在文章的末尾显示free tags）。

升级的思路其实很简单，我们需要做两件事情，首先是把awtags的tags导入free tags所在的term_data表中，然后再建立起 tags与node之间的关联。注意：建议你先将awtags导入term_data，然后在升级到drupal 4.7beta4，如果先升级再导入的话，牵扯到一个转化MySQL数据库 Char Set的问题，在MySQL中不能直接把lantin1的编码转化为utf-8，必须先转化为binary，所以这样的转化是极为复杂的，因此建议先完成导入导出，然后在升级。

1. 建立一个新的分类，名字叫做 tags （或者什么别的名字都行），这个分类在升级后就起到free tags的作用。
2. 我们需要知道一些基本数据：首先在你的数据库中（phpmyadmin或是命令行）运行：
   
   select vid,name from vocabulary;
   
   因为我们想知道这个新建的tags的vid，运行的结果是各个分类（vocabulary）的id number，我这里的tags的vid是12；然后我们需要知道现在tid的最大值是多少：
   
   select max(term_data.tid) from term_data;
   
   因为在drupal的taxonomy中，每个分类词（term）都会占有一个tid，我们在把awtags的tag导入为term的时候要避开已经在使用中的tid，否则就会因为重叠而出错。我这里tid的最大值是53；
3. 现在开始导入：
   
   insert into term_data (tid,vid,name) select 55+awtags.tid, 12, awtags.tag from awtags;
   
   这里导入的是tag的名称。注意我用红色标记的地方。因为我的tid已经排到53了，为了避免导入的tag与已有的term重复，所以我在前面加了55；12表示的是vid的数字，也就是你新建的tags分类的vid。
4. 然后导入：
   
   insert into term_node (tid,nid) select 55+awtags_node.tid,awtags_node.nid from awtags_node;
   
   这里导入的是tag与node的关联。同样注意这个红色的55。至此转换完毕，你可以放心的升级drupal 4.7-beta4了。
5. 升级之后，记得到 "管理->分类" 中去将编辑术语tags，勾选free tagging这个选项。OK，一切都搞定！

今天的笔记先到这里。明天我再写如何把free tags与分类分开显示。

呵呵，drupal 4.7 应该快出来了（ft，这句话说过无数次了），所以刚才看了一下drupal 4.6里有多少旧的翻译可以用于drupal 4.7的，在Linux里msgmerge了新旧翻译，发现其实大部分的drupal 4.6的翻译其实都是可以用于 drupal 4.7的（见右图，点击放大，如果使用feed访问的，可以点击这里从flickr打开），估算了一下，其实翻译量只有总量的一成左右，所以这个星期想抽空做一下试试看，估计认真的翻一下，可能几个小时就可以完成了，完成以后会上传到drupal的总站，tag为drupal 4.7的release，到时候大家可以下载来试试，看看质量如何。翻译的同时也打算在此校对一下原来drupal 4.6的翻译，前阵子和大伙儿一起聊了聊drupal汉化的标准化翻译的问题，就按照大家讨论的结果再对drupal的汉化翻译做一次校勘。呵呵，希望可以很快地完成。另外，由于我的blog国内似乎仍然访问不了，所以想像原来设想的那样，新建一个 drupalchina.org， 作为drupal中文化的一个社区，已经在大米那里留了言，大致设想是先把网站用drupal架好，然后启动论坛模块，对drupal感兴趣的同志们可以一起去聊聊，看看具体怎么架设这个中文drupal的社区。呵呵，加油尽快把drupal 4.7 的翻译赶出来：）

<

p>

呵呵，作为《武林外传》的粉丝，有义务灌这一瓢纯净水。刚才看了两篇考证七侠镇位置的文章，一说在山西运城，一说在山西朔州山阴县。说运城，是因为七侠镇在关中而不在陕西，加之运城有龙门，所以就运城了；说山阴，主要是因为那里离恒山派的恒山比较近，旁边又有一座翠微山。呵呵，俺大喊一声，两说皆谬。首先，关中仅指八百里秦川，运城乃属关东（山东）河东，与关中无关；其次，莫小贝与莫大有不尽的渊源，而莫大是衡山派而非恒山派的掌门，所以不必牵强恒山。所以说以上二说皆不可信。

那么七侠镇究竟在哪里呢？当然要从地名入手，但是翠微山、西凉河这些地名皆不可靠，为什么？因为山水的名字当地往往有俗称，并非使用官名，譬如我家后面那个土坡，我们都叫它南山，可是土坡另一边的人却称之为北山，而官名似乎叫做周山。所以这些小地名先放下不表，单找大地名，因此老邢当差的十八里铺也先放下，让我们想想七侠镇旁边的大地名，对，一定要是一个大地名，那就是----广阳府，bingo！这广阳府在哪里？熟悉军事历史的你肯定会说这广阳还是在山西，八路军115师和129师在那里打过广阳伏击战... ...很遗憾，错了，那个广阳，只是个小镇子，哪能称得上一个"府"字？这真正的广阳府当然是个大地方，这个地方秦已有之，乃是四十个秦郡之一，西汉有广阳国，东汉时先并入上谷郡，后又辟为为广阳郡，那这个地方在哪里呢？其实就在---北京。广阳郡的治所在北京，当然范围要比北京大，而北京的房山县汉时称为广阳县，考虑到明朝的都城在北京，广阳府应该就是房山县，而七侠镇也应该就在北京西郊一带，这时候看官肯定要恍然大悟了，原来这翠微山就是北京西山八大处的翠微山啊，不只如此，魏公村，白石桥也都解决了。不过看官可能还有最后一个疑问，这关中怎么讲？呵呵，斗转星移，物是人非，到了明代万历年间，还提那函谷关作甚，这关中的关指的乃是山海关。

至此真相大白：七侠镇就是北京西郊的一个小镇子，可能离房山有些近吧：）

<

p>前几天冒冒失的升级到beta-3，但是因为一些错误，又不得不重新降级回drupal 4.6.5，这两天比较闲，又仔细研究了一下drupal 4.7，决定在测试站点上把一切都调配得当，再升级到 drupal 4.7的beta-4，这里是一些研究笔记：

1. drupal 4.7-beta 4的升级没有问题，原来说是有问题其实是我自己的问题，可能是一次执行补丁的时候无意把三个数据表的结构改变了，所以才导致了升级中出错，对比了一下新安装的drupal 4.6.5的数据库，发现我的 node, accesslog, locale_targets三个表的index被补丁改动过，于是手动改回来，现在已经没有问题了，我的测试站点已经在拖着我的一个数据库的备份在运行 drupal 4.7 beta-4了；
2. 升级之后，数据库的vocabulary表仍然少了一个column，导致无法加入新的vocabulary，手动添加了那个叫做targets的column，现在已经没有问题了；
3. 升级之后，可能默认的“主链接”会消失，只需要在“管理->菜单”下选择“重设菜单”就可以了，可以重新编辑主链接。这样的菜单编辑事实上给了Drupal更大的灵活性;
4. flatforum有支持 drupal 4.7 的版本，所以仍然可以保持原来的forum的样子；
5. 打算彻底放弃awtags，改用freetags，传化的方法已经基本完成，现在还在调试，如果成功了就仔细写一下转换的方法。

呵呵，现写这么多，继续试验ing：）

前几天聊到了一个把在服务器端把文字转化为图片的小trick，具体的说，譬如你在你的网站的文字设置了一种字体，但是由于访客的机器在本地没有安装这种字体，导致无法显示，所以就有一种简单的技术，把需要的字体放在服务器端，然后将使用这种字体的文字自动转化为图片，这样访客就可以正常访问了。但是fufu在评论的时候也指出这种trick比较影响SEO（搜索引擎优化）。但是，现在有一种新的技术可以更方便的实现这一功能，并且丝毫无损SEO，这就是sIRF（Scalable Inman Flash Replacement），它使用Flash和JavaScript技术利用你上传到服务器端的字体重新渲染你的文字，可以生成各种你需要的字体，hoho，譬如那天俺兴起把所有的blog都用“九叠篆”显示：）效果可以看这里，注意上面的 The Gothic Times 几个字。当然更令人振奋的是Drupal已经支持了这种技术，因为我们已经有了sIRF模块，安装了这个模块就可以简单的实现了sIRF，不过需要注意的是这个模块现在只支持 drupal 4.7 ，使用 4.7 的同志们可以试一下，我现在也到我的测试站点，显示一下“九叠篆”去：）

呵呵，昨天读新闻，在CNET上看到一个blogger在辞去所有工作专业的写了一年blog后，放弃了这种尝试，因为他最初的打算是利用写blog的收入来维系生计，其收入主要来源于有偿订阅和读者的捐赠，但是现在看来这样的收入是远远不够的，所以他停止了作为专业blogger这份营生。觉得他实在是有些太功利，以至于本末倒置了。依我看来，就像我在blog古今谈里戏谑的blog历史一样，blog其实可以看作是中国古代笔记的延续。

中国古代的笔记，其实就是随笔记录的短篇文章，形式非常随便，也没有什么固定的格式，诸如见闻杂录，考订辩证之类的东西，都可以归入。明人胡应麟曾经对笔记有一个大致的分类（其实他是划分小说的，但实际上是笔记）：志怪、传奇、杂录、丛谈、辨订和箴规等六类，基本上也与现在blog所写的内容暗合。或者，用更大的分类，笔记与blog都可以分为三类：第一类是鬼神仙怪，笔记中的譬如张华的《博物志》，干宝的《搜神记》，段成式的《酉阳杂俎》，洪迈的《夷坚志》以及纪昀的《阅微草堂笔记》，而blog中的，当以芙蓉姐姐的《冰火可儿》为最，其次的，如天涯上的鬼故事高手的blog；第二类是历史掌故，主要记录的是掌故遗事，民情风俗，人物逸闻和山川景物等，这类在古代的笔记中有很多例子，譬如赵璘的《因话录》，司马光的《涑水记闻》，欧阳修的《归田录》，而blog中，譬如谈论IT典故的keso的《对牛乱弹琴》，或是关于旅游的fufu的《网际旅游》；第三类是考据辩证类笔记，也包括读书随笔，笔记中如沈括的《梦溪笔谈》，洪迈的《容斋随笔》，顾炎武的《日知录》等等，blog中，如桑椹的《桑林志》，以及《奇迹笔记》等。我的《kzeng寱语》基本上是后两类吧。

既然blog与笔记类似，那自然也该有笔记的特点。就像前面说的，笔记不过是随笔记录，强调一个“随”字，也就是说是茶余饭后自娱娱人的一种消遣，并非正经的职业，就像古人没有以写笔记为生的，写blog自然也不是一种养家糊口的手段，不过是一时的闲思遐想罢了，譬如读了一段历史，忍不住有些感慨，提笔写下，日后翻起，别是一种情趣，别人读到了，也可以参与评论，一同激昂文字。从这点上讲，blog对于笔记是一个大进步，blog即时发布，可以广泛参与，而笔记则不行，譬如今日读到了《日知录》上的某条，觉得顾炎武老人家说的不在理，想去拍一砖头，可惜顾老夫子早已作古，无缘一叙了。

所以简而言之，blog不过是分享自己的笔记。在古时，只有官宦人家才印得起书，将笔记流传下来；而今日，blog提供了一种简单的发布参与机制，任何人想灌两瓢水，只需弹指之间：）

update: 对了，忘记附上直接访问的url了：）在这里：https://www.google.com/hosted/kzeng.info/

呵呵，在桑林志那里读到一篇关于焰火和火炮的blog以及讨论，觉得挺有趣的，也跟着讨论一下这个问题。问题是这样的：yijun在blog引述了一段利玛窦《中国札记》中关于火药与焰火的记载：

最后，我们应该谈淡硝石；这种东西相当多，但并不广泛用于制备黑色火药，因为中国人并不精于使用枪炮，很少用之于作战.然而，硝石却大量用于制造焰火，供
群众性娱乐或节日时燃放.中国人非常喜欢这类表演，并把它当作他们一切庆祝活动的主要节目。他们制作焰火的技术实在出色，几乎没有一样东西他们不能用焰火
巧妙地加以摹仿。他们尤其擅长再现战争场面以及制做转动的火球,火树、水果等等，在焰火上面，他们似乎花多少钱也在所不惜。我在南京时曾目睹为了庆祝元月
而举行的焰火会，这是他们的盛大节日，在这一场合我估计他们消耗的火药足够维持一场相当规模的战争达数年之久。

然后yijun提出了一个问题：“长久以来就熟悉了火药的中国，没有足够的发展火器技术的动力，都是一件令人迷惑的事情。” 并从功能主义（Functionalism，呵呵，这个标签是我加的）的角度作了解答，认为：“
技术源于需求，需求则源于政治与文化。”并假设“
设想另一个历史。假设能够制造佛朗机火炮的某个小国家是与中国接壤，那么长期的摩擦下很难想象中国不会发展自己的火器技术。”

不过jiyanjiang不同意，以历史事实说明：中国历史上（明朝为例）是很重视火器在军事中的应用的；另外，火器在世界范围内的应用，东方并不比西方落后。因此，应用需求并不是推进科学发展的主导因素，而是在“科学背后支撑科学发展的思想和价值观”。桑椹似乎支持这个观点，并援引了美国物理学会第一任会长亨利·奥古斯特·罗兰1883年所做的《为纯科学呼吁》的演讲，其中以火药的例子说明纯科学的重要性：

我时常被问及这样的问题：纯科学与应用科学究竟哪个对世界更重要。为了应用科学，科学本身必须存在。假如我们停止科学的进步而只留意科学的应用，我们很快
就会退化成中国人那样，多少代人以来他们都没有什么进步，因为他们只满足于科学的应用，却从来没有追问过他们所做事情中的原理。这些原理就构成了纯科学。
中国人知道火药的应用已经若干世纪，如果他们用正确的方法探索其特殊应用的原理，他们就会在获得众多应用的同时发展出化学，甚至物理学。因为只满足于火药
能爆炸的事实，而没有寻根问底，中国人已经远远落后于世界的进步，以至于我们现在只将这个所有民族中最古老、人口最多的民族当成野蛮人。

呵呵，事实上这牵扯到了两个问题：第一，为什么中国的枪炮技术会落后； 第二，为什么中国没有诞生现在科学。第二个问题太大了，短短的一篇blog说不清楚，所以只谈谈第一个问题：为什么中国最早发现了火药，但是最终在火器的使用上会落后于西方。

首先是中国的火器技术的问题，中国并非是只把火药用于娱乐，事实上中国是世界上最早把火药用于战争的国家。其实这个也是显而易见，因为中国古代打仗的习惯，讲求的是谋略，而火攻是一种非常有效的战术。《孙子兵法》里面专门有一篇是《火攻》，火攻也很早就用于实战，譬如田单的火牛阵，周郎的火烧赤壁，但是这些大多用天然的易燃物（譬如油脂干草之类的），这些引火物受气候的影响很大，呵呵，譬如周郎烧曹操的时候，万一借着东风来了一场及时雨，周郎就要郁闷了。但是火攻有时又非常重要，特别是在水军交战的时候，所以最迟在唐末的时候，火药已经用于战争了，最早的用途自然是为了纵火，譬如宋初的火球，用硝、硫、木炭以及其他药料为核心，外面用多层纸或是布包裹，然后涂上沥青，松脂或是黄蜡用以防潮防水，并有引信发火，使用的时候，用人力或是礮（也就是抛石车）投掷到敌营，对于城垒或是车船非常有杀伤力。火球只是火器的雏形，后来很多更为先进的火器的被制造出来，由于我们不是回顾火器史，所以就略去，如果感兴趣，可以看看周纬写的《中国兵器史稿》，1957年三联书店出版的，比较系统，其实在古人写的《武经总要》等书里也有很多关于火器的记载。

纵观中国的火器使用史，火器发展的两个高潮时期是宋与明，其背景都是频繁的战争，而火器技术的没落是从清朝中叶开始的，其背景是康乾盛世，河清海晏。从这个角度，功能主义还是很有说服力的，只有有了技术的需要，才会有技术的创新，否则即便是有了创新，也会被湮没。所以这和清朝愚昧不愚昧关系也不大。举个例子一个国家有10块钱，如果都买了大炮，10块钱就没了；如果都投资在经济上（譬如兴修水利等），那么每一年都会有1块钱的回报，那这个国家该如何选择呢？一个重要的因素是战争的可能性，如果战争明天就会发生，那么自然是买大炮，因为没有了大炮就没有了明天；如果战争在很长一段时间都不会发生，那最优的选择自然是投资经济，这样在将来如果有需要就可以买很多的大炮。但是这个国家不可能很清楚的知道战争会不会发生，这是一个不确定的因素，所以只能根据经验来估计战争的可能性。在宋朝与明朝，战争显然无时不在（明朝前期抗蒙古，中期倭寇，后期后金，战争的规模都较大），而清朝根据经验，以为战争不会很快的到来，国家投资的重点自然不在火器上。直到第一次鸦片战争，在重新update了对战争发生可能性的估计之后，才手忙脚乱的开始发展新军。

技术的发展离不开的纯科学的发展，而科学的发展方向还是缘于技术的需要，是一个物质的需要，而非纯粹的意识上的价值与思想。举个最简单的例子，现在的各门科学中，哪些科学发展的速度最快？申请到funding最多的学科发展最快，怎样才能申请到funding，呵呵，写过proposal的人自然知道各中的诀窍。回到古代，譬如数学，宋元四大家的著作是数学史上的一块丰碑，但是后来居然都没有人能读得懂了，这就是没有物质支持的科学（广义）的结果。技术与科学是相互促进的，是一个双向的关系，而非单向的从科学到技术的关系。