虽然天天VNC在CentOS上工作，但是主体还是生活在Windows 7下面，真是觉得Linux不争气，搞了这么多年了，还是只能在服务器和超算领域混饭吃。乌班图确实有了很大的提高，但是个人觉得仍然只能达到XP的水准，和Windows 7，OS X 还有不小的差距。

Linux有时候真的是让人爱不起来，举例来说，要找个稍微为好点的C++ IDE都找不到，别提Emacs这样的古董，用Eclipse吧，区区几W行代码，索引一下要10分钟，还是3GHz的Nehalem 至强EP，我真是服了。后来Samba代码目录到Windows下面，用Visual Studio + VAX编辑，流畅得一塌糊涂，编辑完后再SSH过去make，比直接在Linux下面工作效率高N倍。

[ 本帖最后由 xphi 于 2010-11-4 21:49 编辑 ]

没有用过slickedit，似乎是个Eclipse的查件？回头找一个试试。

嗯，看了看slickedit的官方Review，似乎还不错，不过看起来代码完成和代码重构功能还是比较欠缺，有空试用一下再评价。

平时用Linux就是自己找折腾啊，用Wine更加纯粹是找折腾，既然买的机器带来了正版Win7，还是用Win7吧。话说现在能买到学生版的话Win7和Office2010也蛮便宜，除了网银唯一需要Windows的就是Office了。

没有Office的压力一般的工作确实可以移到Linux下，话说Tex写东西比Word给力多了，可惜收到的文档全是doc/docx。

引用:

原帖由 利多卡因 于 2010-11-5 18:44 发表
显卡驱动的问题，反正我没有碰到过，也没有去官网下过神马驱动，我什么都不知道

ubuntu下使用包管理器的方式统一管理软件的安装、依赖、更新和卸载，对用户来说，只需要知道软件名，或者从软件排行上找到软件，点 ...

客观地说，Linux下面可以向Debian这样搞包管理器主要原因是开源软件居多，要是像Windows下面大多是有版权软件，怎么搞得起来，这些年像360，XX软件管理器，云端什么的不都是想走这条路么，但是那个不是偷偷摸摸，藏头露尾，生怕踩过了版权这根红线。而且这种东西一有用户群就有利益，广告、流氓什么的马上就跟着上来了，自然不可能像Linux下面那么清爽。这次字母大战数字的最早起因不就是从XX软件管理器那时来的么。

[ 本帖最后由 xphi 于 2010-11-5 23:27 编辑 ]

引用:

原帖由 Mozi 于 2010-11-5 23:26 发表

难道你家ubuntu不给你自动找出proprietary hardware driver?
相比win 7， 自带驱动一个给我1024x768，一个在live disc上就能基本实现所有功能， 也是不小的差距。

ubuntu显卡驱动能搞定很大程度上是现在就两家显卡厂，而且主流还在用的显卡就那几个系列。相比几乎已经标准话显卡和声卡，各种杂七杂八的扩展卡，Raid卡，在Linux下面装驱动简直就是要死人。

引用:

原帖由 利多卡因 于 2010-11-6 01:26 发表

非也，ubuntu官方源里不留非开源软件是一回事，不代表所有源服务器都要遵循这样的法则。另外，事实上N卡和A卡的驱动恰恰就是不开源的，但是都在源服务里，只是需要你手工点一下确认协议

如果你用过ubuntu，你应 ...

开源是我所想到的一个方面，纯粹从安装方式优劣来说的话，Debian包确实不应该是Linux值得骄傲的地方，微软实际上屡次三番的出Install的SDK试图统一，不过Windows下可选的Install工具太多导致现在也没有统一起来。我还是觉得只有小众而没有历史包袱才敢一刀切的统一安装工具，要是微软哪天也说大家都把软件放到我的更新服务器上吧，多半比TX这次还要被骂得惨，多么严重的“劫持用户”啊，多么严重的“垄断”啊。

引用:

原帖由 利多卡因 于 2010-11-6 01:33 发表

真正的大型工程不会只用Makefile，丫就是个半成品，通常我们会加入大量shell脚本辅助，更常见的是直接用cmake来自动化构建Makefile

linux下，没有多少人习惯使用IDE这种东西

Linux死忠当然都用VI和Emacs，但是我仍然宁愿用有可以加速工作的代码完成工具和重构功能的IDE，如果能够支持多显示器更加好，如果我哪天能啃完Emacs的无数手册，记住Emacs无数快捷键，学会了Emacs的无穷强脚本语言，说不定我也会喜欢Emacs，不过现在看来遥遥无期。
make永远都是核心，其他都是辅助，不是make半成品，而是make的基本设计思想就只是制定规则依赖，具体每条规则怎么操作当然要写脚本。

引用:

原帖由 利多卡因 于 2010-11-6 01:43 发表

你把intel搁哪儿去了？

各种冷门外设不是说装驱动要死人，而是厂家根本没发布驱动。能跑的驱动，大多是直接集成在标准内核里的（显卡驱动这种反而是特殊的），要么直接编译进二进制内核要么是作为模块放在文件系 ...

Intel我确实搞漏了，因为基本没有听说还要要鼓捣Intel的显卡驱动。不过鼓捣驱动基本不是因为厂家没有发布，要真没有发布驱动我就直接换硬件了，鼓捣驱动干啥。Linux驱动最烦躁的在于编译，无数的Linux发行版，每种发行版的无数版本，各种不同的gcc版本，glibc版本……。乱七八糟的版本依赖之烦躁，之恶心，加上各种冷门驱动本身开发不够好，常常依赖特定编译环境，搞死人。

[ 本帖最后由 xphi 于 2010-11-6 02:27 编辑 ]

有DOS的时候还没有FHS，那时的DOS没有理由去借鉴Unix的文件系统，所以不要乱用“一开始……就”这样的句式。我也没有说Windows的安装方式好过rpm或者deb，我只是说源服务器这种做法没什么值得夸耀的。

拼错Makefile的人不是我，此外我的确不知道你在说什么，用make的过程中靠gcc生成.d依赖文件已经是一个基本常规操作，不知道你说的复杂源码树指的是啥。顺便说一句，写程序过程中常常修改头文件不是个好习惯，make和C系列语言是绝配的一个很重要原因就是头文件分离，make仅仅依赖时间戳就可以独立编译修改后的实现部分而不用考虑其他使用了该接口的代码。常常要考虑“修改一个头文件后重新编译时，只选择性地编译那些与该头文件有关的源码文件”这样的问题，说明代码组织或者结构设计多半有问题。

虽然我不知道你做什么，但是我看你处处提到程序员，容我说一句，就像前面操版说的，Linux的很多毛病，程序员觉得很爽，用户多半觉得很操蛋。作为一个程序员，当让可以追新，跟着喜欢的发行版跑，但是用户并不是这样的。看你提到你用altium，所以猜想你能理解这个例子：某厂商提供的一个库必须在某特定版本的DC下才能综合，而这个DC必须使用某特定版本的内核，甚至只能使用某特定的Linux发行版；又或者厂商提供一套SystemC的验证框架，必须在某版本的GCC下编译；然而为了调试某FPGA，我必须链接一款特定的扩展卡，但是这个卡的厂商却没有提供该特定版本内核Linux的驱动，我于是立刻陷入版本依赖的漩涡中。不是每个人都总处于喜新厌旧的程序员角色中的。

引用:

原帖由 利多卡因 于 2010-11-6 19:22 发表

说实话这个实在是真不能接受了。。。我觉得我被侮辱了，随便找个像样的项目，开关某些宏，这些操作都是改在头文件里的啊

开关某些宏恰好应该是放在Makefile里面，在不同的规则下由gcc的开关传进去的，过了调试期后，需要发布版的时候才实际写进头文件里面去，每次调试make的时候都要修改头文件，等待缓慢的编译无数源文件，那还要头文件作甚。

引用:

原帖由 利多卡因 于 2010-11-6 19:50 发表

我明白了，你并不发布源码，只发布二进制文件，用户看不见源码，所以用户不会修改头文件

源代码发布版也是含Makefile一起发布的……，而且需要在本库调试中不断修改的宏开关一般很少需要下级用户修改，除非是不能确定，需要反复试验的常量等等，但是那样的东西为什么要放在宏里面，那些东西应该放在配置文件里面。
用户即便要修改头文件，也不会常常去修改，除非决定大改，即使要大改也应该有一个预先的设计和计划，不是在每次make的时候才来调来调去。

当然，这个属于软件设计的思想问题，每个人都有不同的风格，不必强求。

[ 本帖最后由 xphi 于 2010-11-6 20:01 编辑 ]

引用:

原帖由 利多卡因 于 2010-11-6 20:07 发表
你把宏作为编译参数传入源码比用头文件传入到底高明在什么地方呢？连编译参数都修改的话，难道还不用重新编译？我实在是困惑。宏是在预处理阶段就处理掉的，远远早于编译流程

这个我确实记错了，跟着你的关于宏的用法跑偏了，通常情况下头文件里面用预处理宏，要不是和编译环境相关的开关，要不就是Debug本身的开关，这些都是不需要在每次调试时修改的。所以我说不应该在头文件中包含了需要在每次调试时都需要修改的开关，如果有那样的开关，要么避免出现在头文件中，要么放在配置文件里，这就是我为什么说存在程序结构设计上不合理的地方。

[ 本帖最后由 xphi 于 2010-11-6 20:21 编辑 ]

没有配置文件也有很多办法获得全局支持的，虽然全局变量有点丑陋，但是仍然是可以用的；就算是在板子上跑程序，至少还有几块ROM地址可供放配置数据把。

引用:

原帖由 利多卡因 于 2010-11-6 20:28 发表
说来说去还是鸡同鸭讲啊，你没有接触过裸板程序

我再举个例子好了，就拿debug开关来说，假设我们现在只调试某一个模块，所以只需要打开这个模块的debug开关就可以了，这当然是代码中该模块设的宏。你说这种情况下 ...

是的，我们谈的不是一种情况，从一开始我只是想谈谈关于make是不是半成品这个问题。我并不针对你的这种裸板程序，虽然我也看过几个裸板程序，不过我确实没有写过，不知道我们写裸板程序的小组是不是也这么郁闷。

引用:

原帖由 利多卡因 于 2010-11-6 20:41 发表
其实拿linux kernel作为例子就更好说了，比如说spin_lock这个宏，在单核非抢占的情况下，丫就是一个空宏，只有在多核或开抢占的情况下spin_lock才是有意义的。那么这个宏的内容本身就是被宏所选择的，而且这个选择权 ...

在游戏论坛讨论旋转锁是在是有点蛋痛，我觉得这已经基本说明我的看法了，我没有说头文件中不能用宏，说是说在头文件不能有总要在调试的时候修改的宏，头文件不应该是需要经常改来改去的东西，就算是旋转锁，我的调试机也不是一会多路一会单路吧。而且make可以流畅的处理这所有的头文件依赖问题，没有任何半成品的样子。