【原创】Linux下 － 工作并娱乐着

aningstar

确实，不要在讨论linux和windows的优缺点了，没有什么意思。用什么都无所谓，只要能达到利益最大化就可以了，更通俗的说，用你最熟悉，最有把握的技术达到客户的要求，同时，让自己得到最大的利益。所以，如果是一般的学习或者自己用，用盗版的windows和盗版的软件都可以接受，但是如果是商业开发，特别是和老外打交道的时候，就一定要考虑到版权问题，正版的软件和os都要考虑到成本里去的

[ Edited by  aningstar on 2008-2-9 03:25 ]

Roamvalley

好像不只我是夜猫子。
刚刚查到，Linux下有gEDA这个东西，看介绍是作电子电路的套件。
http://www.geda.seul.org/
在Fedora的RPM package中，“工程科学”子包中有这个软件的安装。
这个要请上面几位看看了，我不懂。

刚装了一个

[ Edited by  Roamvalley on 2008-2-9 03:54 ]

liyang6688

这个不错  一会在台式机上研究一下，谢谢了  
先收回部分刚才评论的缺点

Roamvalley

在Linux下，安装各种所需的程序有几大类途径：
1。使用RPM包或者其它类似方式
2。下载代码并编译安装
3。使用类似YUM之类的自动安装方式，这种方式是基于方式1的
4。厂商直接提供了bin的可执行文件安装方式

方式2我并不推荐，但要分情况，一种是为服务器安装的必备程序，比如我们的数据库系统Postgresql，它装上后基本不卸载了，这个适合使用2，因为方式2的编译过程中会自动对本机的系统状况作出基本分析并选择一个较优化的方式安装最终系统。
另一种情况是我们常用的工作生活系统，经常要装很多应用，不像服务器要求那么精炼，所以有些东西装装删删，由于方式2不记录安装过程的信息，这些东西装了后通常把此程序的一些开发包放这个lib目录，把一些配置文件放那个etc目录，又在一些bin目录下创建执行体的link，非常乱。当你不再需要它们时却根本不记得该如何删除哪些文件，时间久了就会在系统内遗留大量连自己都不清楚的文件，说白了就是可装不可卸，乱。

方法1比较方便，但Linux下的程序特点是所依赖的各种基础包（类似Windows下的系统DLL）很乱，因为开源下的程序员在作这些程序时大都根据自己的喜好随意选择开发包（Linux下对同一种功能提供的开发包本来就很多，这倒怪不上Kernel的开发人员，是开源自身的特色，很多人都希望对开源作些贡献，难免很多人开发同样功能的模块），导致一安装RPM包时最常见的情况就是告诉你少了这个或那个基础包，当你上网再去找到这些包后又发现这些包又依赖于其它你所没有的包，找的烦了后，甚至后面找包时都不再去作MD5，SHA验证了，也随即可能带来种下木马的隐患。

方法3就比较常用了，只要向yum或者apt-get提供要装的应用名，这些程序自身以及所需的依赖包还有安全校验问题都自动交给操作系统。但有时也会碰上点问题，哪就是你要的应用可能在yum或者apt的库里不存在，你不得不用其它方法再去解决这个问题。

方法4比较少见，但我个人经常碰到，比如SUN的JDK，还有些游戏，它们安装过程中会被要求指定安装目录，所有的东西都会扔到这个目录下。

我倒不怕自己工作机器上的东西有多难装，主要是怕服务器上的基础环境安装麻烦。
我对此的策略是能直接拷贝解压安装的东西绝对不用上面任何一种方法作，所以我会在一台干净的机器上先使用4种方法把必须的软件都装好，然后想法单独剥离出，再tar成一个压缩包，当我需要安装新系统时，直接把这个包解压到目标机器上即可，当然，我做不到所有必须程序都这么干，但大部分能如此安装会给我带来很大的方便。

[ Edited by  Roamvalley on 2008-2-10 14:34 ]

aningstar

呵呵，偶倒是一般用第二种方法，不过不make install，然后的也是剥离，或者做link，本质上说来和lz的的剥离差不多

Roamvalley

aningstar:Leopard上的程序是拷贝过来就能用，很不错的使用体验，和我们说的方式估计原理差不多。

再推荐一个游戏，喜欢X-Com的强烈建议装个，战斗场景还是3D的。但对显卡要求不高。

Roamvalley

今天有点喝多了，酒量不如以前了。

Roamvalley

性能是Linux除稳定之外鼓吹的另一项重点。
但对技术人员来说是一条艰难的路。多核CPU为开发带来的不仅是速度，也是挑战。它对应用级技术人员最直观的技术要求是：尽量把程序分解为多进程／线程。但通常人的思维方式显然只喜欢和单流程打交道：一段时间内只集中注意力作一件事。即使多进程／线程并不要求在系统运行期间让设计人员随时面对应付同时发生的各种事件和处理，但就设计和实施过程还是让人觉得麻烦。
我们对服务器端系统的设计中要求利用多线程保证对用户尽快的响应，碰到多线程对设计和编码的要求相对比较高，这不是教科书上用显而易见的范例教学生怎么认识多线程对“数据一致性”的威胁。而且多线程的锁机制还往往拖累线程带来的性能提升。
这里先打断一下，看看目前多CPU系统最自豪的技术：分布式应用。中间件最喜欢在这里插一脚，像DCOM,CORBA之流动不动就号称自己有如何的负载均衡能力，把一个复杂繁重的应用系统切分成多块让多台计算机同时运算。还有些典型的应用级分布式系统比如那个著名的寻找外星生命的程序：SETI，它可以利用所有资源参与的人贡献自己的PC空闲时间为一个统一的目标“分析海量信号并试图找到个别信号可能同外星生命关系”。
看上去，利用多PC，或者多CPU的这类应用很牛，但根本的原因呢？
是这类系统的计算体系可被“分布”，它们正真的技术核型并不是操作系统或是多CPU，而是其算法的并行性。
可回头看看我们的应用，回到我们在CPU多核的情况下多进程／线程所面对的问题，我们的核心算法具备并行性吗？
很多情况下，“人治”的商业系统丝毫没有技术可言，就是因为可能连程序员希望出现的“算法”都不需要，很多情况下某个功能操作过后就是要等待“上级人员”对此操作作进一步的确认，还谈什么
“并行运算”。

[ Edited by  Roamvalley on 2008-2-10 22:44 ]

Roamvalley

但我们总是有机会和这一有前途的技术打交道的，多核CPU正在迅猛发展，INTEL目前的走向就是典型。
我们也许用不上并行算法，但某些应用中的多“功能模块”还是可以利用进程／线程来切分的。
线程技术在这方面考虑的比较多，尤其是JAVA，提供了大量的语言级特性帮助技术人员来利用其优势（C和C＋＋本身不具备多线程能力，需要所应用的操作系统或其它平台来实现多线程能力）。
但以前JAVA的线程也是比较搞笑的，一个JAVA线程并不是一个正真的OS线程，而是JVM内部的“分时”机制实现的假线程，有的JVM实现甚至是用操作系统的多进程来实现的（比如你开了3个JAVA线程，但在linux下ps后却发现N（N>3）个JAVA进程。新版本的JAVA（1.5,1.6,1.7)可能在这方面有不少改进。
在我所参与的项目中，线程解决某些问题是比较轻松的事，但对需要分布的功能间产生的“粘度”很大，设计人员和编码人员的想法有时是不一致的。设计人员希望系统所有的模块都切分的很清晰，而单个编码人员总希望引用其它代码来减少自己的代码量。设计模式中大量的内容都是让技术人员减少或者减弱这些引用。
在多线程的编码中，由于是同一进程内，大量的代码段和数据段可相互引用，所以技术人员会刻意或者不自觉的导致模块和模块间的依赖性，这也导致多线程时需要为这些代码级的问题作很多折衷，线程变得开始不友好了，各种锁和同步机制就是为解决这些问题的。

Roamvalley

好多次我们在为多线程引起的数据不一致问题整夜DEBUG，即使是解决了一时的问题，可谁都清楚，多线程的存在很可能还有其它隐藏的问题没被发现，越是那种不常见的问题我们越是怕，因为它肯定是隐藏的很深。
有次我实在觉得烦了，干脆把某个新模块设计成多进程模式，哈哈，当时被人抱怨，因为数据传输变得麻烦了，他们需要用通讯机制传输模块间的数据，并做到数据的打包和解包，多了一些工作量。但杜绝了他们在代码级的引用和线程问题。的确，后来这个系统就这方面的问题最少。
后来，我看到一个人谈到线程的问题，这个老外比我还彻底，杜绝线程。当然，这个太绝对了，但多进程的确是可以解决一些设计上的问题（线程程序作代码级引用是正常的，不能怪单个模块的编码人员，设计上就应该考虑并适当缓解同步问题）。

[ Edited by  Roamvalley on 2008-2-10 23:48 ]

aningstar

QUOTE:

Posted by Roamvalley on 2008-2-10 23:42
好多次我们在为多线程引起的数据不一致问题整夜DEBUG，即使是解决了一时的问题，可谁都清楚，多线程的存在很可能还有其它隐藏的问题没被发现，越是那种不常见的问题我们越是怕，因为它肯定是隐藏的很深。
有次 ...

呵呵，心有戚戚焉啊，我也曾遇到这个问题，最后也是使用多进程的方法。在C++的标准库中确实没有进程库，我们一般是使用boost库里的进程库。并行计算确实需要算法一级的程序，这也是目前大多数程序在双核上表现没有预想好的原因。

Roamvalley

嘿嘿，这个题头用来吸引眼球不错
我从小爱看反特电影，新中国刚成立，好像满地都是台湾和美帝国特务，看到JC和特务们开枪乱打的时候很兴奋。当然，特务电影最显著的标志是：间谍相机和电台，估计也是那个时候我所能理解的“先进技术应用”了。
这两天晚上实在无聊，我还上网找了些老电影，比如“猎字99”，“羊城暗哨”，竟然还发现了一个细节，某个特务在铁路旁等待，然后一辆列车快速跑过，列车上有人用快速发报机迅速将指令发出，听起来是一串高频啸叫，那个铁路旁的特务用接收装置保存好。我想这个应该是把普通的莫尔斯电报用常速的几倍快速放出，接收方再用减速的方法播放，就可以听到正常的滴滴嗒嗒声了。好处是发／收报只要很短的时间，而且如果是变加速和乱续的过程录制报文的话还有一定的额外保密特效。
现在的特务们应该没这么麻烦了，数字化的装备越来越小而且功能更加强大。再看90后拍摄的一些特工片（再叫特务就老土了，更专业些应该叫NOC)，不看剧情光看装备就能让我兴奋了。

Roamvalley

Bourne'sID，TheJackal,MissionImpossible，EnemyOfTheState等等大片都是我的最爱。
这些片子里大多会出现Hack场景，但Hack并不是特工的唯一展现手段，比如TheJackal里那套远程遥控火炮（好像已经不是mechine gun这个级别了吧）。

[ Edited by  Roamvalley on 2008-2-11 16:06 ]

Roamvalley

控制界面，这个是通过手机（好像是motorola）将控制计算机和火炮连接起来的。
火炮上除了瞄准镜头自带的步进电机外自身至少有两个，一个是水平旋转的，一个是控制仰角的。
控制部分应该很简单，只是控制精度要求很高，看看那个瞄准镜头就知道了。瞄准镜头把拍摄到的图像通过手机调制成数字视频发给控制PC，但我想当时没有GPRS，光靠手机当作猫用的话能不能做到实时传输那么大的图像数据，尽管图像已经是黑白的了，如果两者在数据传输过程中都有强劲的芯片作为压缩和解压也许是可以的，如果图像大小是352*240，采用256级灰度，那么单屏画面是84K左右，而刷新率至少要每秒30帧，总共84x30=2.5MB数据，采用MPEG－1压缩这种动态图像，按照50：1的压缩率，大致能压到大约50K，意思是一妙钟如果这个modem能单向传输50K数据的话，就可以做到实时瞄准了，但显然作不到。
同样，控制台上的摇杆和按钮数据也要实时传送给火炮上的各个步进马达。

[ Edited by  Roamvalley on 2008-2-11 16:06 ]

aningstar

呵呵，偶也喜欢看这种片子，是个美剧迷，《反恐24小时》里面有很多这样的东东，呵呵，不得不承认，美国在这方面确实是最先进的

Roamvalley

今天又喝不少了，我就自由发挥了

Roamvalley

我认为最后Jackal太傻了，为什么要那么近距离控制这们火炮，本来就是remote control，应该至少在在几公里之外，一旦任务失败，只要留得青山在，不愁没柴烧。

而且用手机拨号作数据通信不可靠，中间应该使用类似WIFI这类的东西作中继。

Roamvalley

作案头一天，因该把当天的风向，湿度，温度搞清楚，另外，这门炮的偏差应该提前做好预估，都作为弹道运算的参数。
那台PC也是纯属炒作，应该使用工业PC，哪需要把什么电路板都露出来的，扯淡！
配上高精度的摇杆，采用类似Logitech SpaceExplorer系列的操控系统。火炮的控制系统应该是实时操作系统，我当然推荐实时linux系统了，这样可以更好的支持更多的特性，尽管这类系统首是稳定性，但稳定性不是靠公式算出来的，需要大量的检验！在轰了那个制作火炮基座的工程师之前，做好足够的测试。
使用一个中继的WIFI系统，这个可能带来不稳定因素，但要比那个手机MODEM可靠多了，即使目前的GPRS／CDMA也不可信，因为这类系统目前的状况是：当语音信号增多时，会占用数字信号的通道，这点在我们目前的工作中极为常见！意味着不可靠！不要指望在这么重要的行动中附近的手机基站处于空闲状态。另外延迟（并非速率）也会导致操控变得不可靠。
所以应该使用WIFI之类相对可靠的形式保证基础通信的稳定性。只有通信先搞定了，才能谈remote control。
在遥控的过程中，一定要事先找好一些肉鸡系统，这些是在你结束任务后，避免被追查到IP的有效手段，完成所有操作后，使用“填充数据”的方式把中间的肉鸡全部干净的毁掉，多跳几个这样的肉鸡，就很难反追踪到当时你的原始位置，现在的JC对IP的反追踪很强的！

[ Edited by  Roamvalley on 2008-2-11 20:06 ]

Roamvalley

火炮自身的系统采用汇编或者C编写？NO，我极度推荐在Linux的OS之上架设KVM，这是KJava也就是J2ME之类的适合嵌入式系统的JVM，抛弃J2SDK里那些大而无用的开发包，专门为这类精简的控制系统提供一个简单而高效的开发环境,针对需求改造后的KVM是首选！
其实只需要：
java.lang
java.util
java.io
以及一些针对最终系统的扩展包。
最重要的是能提供一个实时JAVA系统，目前RTSJ正进入实用阶段，尽管它存在很多问题，但肯定是一个发展方向，很多新生事物都要经历这样一个过程。
所谓的稳定系统，并不是一个理论化的设计，而是实测出的经验型系统。

[ Edited by  Roamvalley on 2008-2-11 20:32 ]

Roamvalley

我打算在公作之余，重新阅读JVM的实现代码，并在这个基础上，作些自己喜欢的事情。
作商业系统，作什么网络游戏服务器，都TMD是为了生计，可怜阿。但这些都是不我所希望的。

[ Edited by  Roamvalley on 2008-2-11 20:52 ]

aningstar

QUOTE:

Posted by Roamvalley on 2008-2-11 20:49
我打算在公作之余，重新阅读JVM的实现代码，并在这个基础上，作些自己喜欢的事情。
作商业系统，作什么网络游戏服务器，都TMD是为了生计，可怜阿。但这些都是不我所希望的。

[ Edited by  Roamvalley on 20 ...

佩服，这可是个大工程。偶一直要研究linux的kernel，不过这么几年过去了，研究还是在很表层的地步，惭愧啊！

Roamvalley

前面我说错了一点，应该从KVM的代码开始做起，毕竟，我设想的是能在各种设备上运行一些功能单一的应用，所以需要的是精简的JVM系统，那么KVM就是最合适的。KVM所要做到的功能就是CLDC的具体实现。
这样作的好处是在一些嵌入式设备上不用写C程序了，直接使用KJAVA这个小巧而且有效的平台，但很多情况下需要对KVM作扩充，比如要支持USB设备，这样可以作出很多有趣的东西。
比如在飞机模型上装个USB摄像头，再利用嵌入式Linux和KVM我们可以把这个摄像头在空中拍摄的影像通过WIFI之类的方式，或者用超短波将数据调制后发送给地面的接收系统，那么解调后就可以看到模糊的空中摄像画面了。
我想，军队有更好的技术主要是这些硬件比如更好摄像头，好的遥控飞机，更牛的电池等等，我这么设想作这些东西只是纯粹感觉有趣，我相信很多人都会对这些有兴趣的。

yogibear

楼主好久不见。 拜读好文。

liyang6688

这个很厉害  不过打过枪的人都应该了解一点------那个大东西很容易被震坏  哈哈

zzye

LINUX下的EDA软件最有名的应该是SPB,也就是原来的Allegro. SPB包含了orcad capture CIS, 这个软件原来就是只有UNIX/LINUX版的, 后来为了迁就客户才移植到WIN版的

据小弟所知, 目前还有很多人用LINUX+C 在工作的, 致少我们公司这里就有近一百人

因为嵌入式产品很特殊, 有些地方还要改动LINUX内核, 内核都是C写的, 涉及到底层的东东就得全用C了, 习惯问题, 应用层模块也是用C写的 呵呵, 纯种的GUN C, 基本上是ANSI C 呵呵

Roamvalley

上班了！新项目＋老项目同时开工，很忙。


liyang6688：虽然只是部电影，不过还是可以YY一下
把瞄准系统同射击系统分离，避免射击震动对瞄准系统产生影响。把瞄准系统改为3个以上的瞄准镜，分别布置在位置不同的地点，同时瞄准目标（使用图像识别系统自动指向目标头部），并且要在每个瞄准系统和射击系统上都安装精度很高的GPS，可以根据每个瞄准镜的位置和角度计算目标在3维空间的准确坐标，指引射击系统，这样就可以应付上面讲的那个问题了，不过带来的不稳定因素肯定增加了不少。


zzye：用C好阿。我想到用扩展的KVM是因为现在JAVA程序员好找，真正能做事的C程序员少。作嵌入式系统或者实时系统的还是适合用C。

salutes

10楼拼错了两个license

Roamvalley

我忘了开stardict

salutes

明天在我的ubuntu上也装上stardict（译作星际译王？）。

认真学习了前64楼，还是经验太少，有些东西没接触过。
今天累了，明天继续。

Roamvalley

星际译王，实用。
我写的那些大多是些感受，不是很确切，你最好找本oreilly出的linux技术手册，基本操作写得很清楚的。