n卡的驱动在ubuntu里是比较好的。a卡问题稍微多些。一般源里的驱动就挺好的如果追求新的话可以编译驱动。如果没有用源的驱动而是自己编译安装的那么在内核升级后会有比较多的麻烦，需要重新安装驱动而这时候只能在字符环境下。

[ 本帖最后由 eos 于 2010-11-6 00:36 编辑 ]

codelite，codeblock还是差很远，用它来管理工程只比makefile好点，事实上很多时候都是自己写makefile然后用自定义编译。用过的IDE里面没有比MSVC更好用的了，再加上现在express已经免费（当然需要感谢GCC它们）

话说现在国内做软件的，除了大公司，都是面向windows用户为主吧，还是全套MS的东西比较给力。期望能看到GCC在windows优化方面有较大的改进，现在编译windows目标代码又慢又臃肿

posted by wap, platform: iPhone

扯b淡，xcode怎么就让你泪流慢面了。

引用:

原帖由 xphi 于 2010-11-5 23:31 发表


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

这个我承认， 但是一般人谁会用这些？至于硬盘仓库我记得有专门支持linux的raid卡，而且sun原来的那个硬盘格式貌似可以当raid用？

引用:

原帖由 xphi 于 2010-11-5 23:24 发表


客观地说，Linux下面可以向Debian这样搞包管理器主要原因是开源软件居多，要是像Windows下面大多是有版权软件，怎么搞得起来，这些年像360，XX软件管理器，云端什么的不都是想走这条路么，但是那个不是偷偷摸摸， ...

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

如果你用过ubuntu，你应该知道还有很多第三方源甚至是某某软件自己的官方源这样的东西存在。即便连源都不想加，直接官网下deb包，那么无论多么庞大的软件都可以打成一个deb包双击安装，安装过程不需要你做任何操作，且这样的deb包任何人都可以打，且所需依赖的包会先自动下载安装

引用:

原帖由 离神最近的人 于 2010-11-6 00:43 发表
codelite，codeblock还是差很远，用它来管理工程只比makefile好点，事实上很多时候都是自己写makefile然后用自定义编译。用过的IDE里面没有比MSVC更好用的了，再加上现在express已经免费（当然需要感谢GCC它们）

...

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

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

引用:

原帖由 xphi 于 2010-11-5 23:31 发表


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

你把intel搁哪儿去了？

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

引用:

原帖由 利多卡因 于 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 编辑 ]

对于程序员来说不错，对于一般人来说不行

引用:

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

历史包袱这个词用得好，我来告诉你为什么微软根本不可能整出rpm和deb这样的包管理系统，因为从一开始windows或者说dos就没有遵循FHS标准，正是这个历史遗留问题造成了今天几乎每个人的windows系统的目录结构都不相同，在这样的环境下，你让包管理器怎么去装软件？所有软件全部扔c盘program files里吗？几兆十几兆的小软件也就算了，百兆至数G数十G的软件也全扔c盘？那用户非跟你拼命不可。windows那操蛋的目录结构也致使了windows本身不能把用户本身的配置信息从系统盘隔离开来，当然这是题外话了

另外，虽然ubuntu的老板财大气粗，但是全球那么多源服务器可并不都是他出钱整的，任何一个人用台pc机装个ubuntu开个apache就能搭建源服务器，所需操作包括安装apache不足5条命令。可以是官方源镜像，也可以是自己维护的ppa，软件公司可以有自己的ppa，比如opera这类非开源的软件，供用户加源条目以实现自动维护更新

注意源是需要key认证的，杜绝了非法源服务器捣乱，如果你想问如何杜绝，说明你已经被windows下一些习以为常的不安全习惯蒙蔽了双眼，呵呵

引用:

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

我前面就说了，slickedit可以设置成vim和emacs style，也就是兼容它们所有快捷键
至于Makefile，其实我一般是不和没有将Makefile拼写正确的人讨论关于它的话题的。Makefile为啥是半成品？我问个问题，你如何实现当修改一个头文件后重新编译时，只选择性地编译那些与该头文件有关的源码文件，注意这不仅涉及到单纯地将头文件时间戳与包含该文件的源码文件的比较，还涉及到头文件内部的包含关系。你可以看看官方GNUmake手册给出的方案。如果你不知道我在说什么，那我可以问个基础问题，Makefile是如何处理复杂的源码目录树生成最终的目标文件的？

引用:

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

驱动的问题，你算撞我枪口上了。。。

很多驱动不是官方发布的，而是黑客们根据手册自己写的，只要愿意开源，你就可以提交给kernel.org，进入mainline，这样kernel.org发布的标准内核里就会有这样的驱动。厂商自己发布，不提交，绝大部分原因是不想开源，打闷包，没关系，你完全可以打包发布deb包或rpm包，甚至直接进ubuntu官方源服务器，再被全球的爱好者架设的源服务器镜像。gcc版本，我从来是用最新的稳定版本，所有有活力的发行版都是如此，作为一个程序员，这是起码的要求，这也是为什么程序员不用rhel，centos等发行版的原因

另外，驱动不依赖你的编译环境，不使用glibc，它依赖的是你当前kernel的源码树。所以你觉得搞死人，要么是你的驱动太古老没跟着kernel的api维护（不进mainline你就得自己维护），要么是你的kernel太老

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

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

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

posted by wap, platform: GoogleChrome

前一段时间在linux里写c代码，发现最靠谱的还是vim。IDE这种东西和linux的风格根本格格不入。

我的使用体验来说。我觉得不如FEDORA

我就说一句：假设咱们天朝计算机课上学的就是Linux系的操作系统，IT厂商开发的软件也优先考虑Linux系下面的版本，论坛的PC区讨论的也都是Linux系操作系统的问题…十年以后还会有多少人抱怨Linux不好用呢？

玩啥操作系统都一样，玩熟了啥都不难折腾

[ 本帖最后由 宅兔 于 2010-11-6 17:11 编辑 ]

引用:

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

拼错Makefi ...

嗯，dos所采用的文件系统和分区挂载的方式，已经决定了不可能出现一种标准去统一规范了，因为分区和目录的关系被颠倒了过来。unix和linux之所以能够遵循FHS标准，和分区挂载的方式有很大关系

生成.d文件的原因就是因为Makefile是半成品，没有提供相关机制，只好用这种愚蠢至极的方法曲线救国，要知道在你在磁盘驱动器上频繁创建和删除如此大规模的小文件是一件十分费时费力不讨好的事情

头文件里包含的内容不需要修改吗？真的不需要？我举个例子，你的项目是多平台的，这时你需要编译面向另一个平台的目标文件，于是执行Makefile的某个标签创建了面向该平台的一整套头文件的软链接，你觉得你头文件修改了没？不同平台soc的寄存器完全不同，这些信息都在头文件里，这些头文件会被粘贴到源码文件里，头文件变了自然要重新编译。“仅仅依赖时间戳就可以独立编译修改后的实现部分而不用考虑其他使用了该接口的代码”，这没有什么神奇的地方，编译是以文件为单位的，没有改过内容的源码文件当然不需要重编，只需要重新链接就可以了

“必须在某版本的GCC下编译”，知道我为什么说作为一个程序员，使用最新编译器和库是最起码的要求吗？程序员发布的产品必须保证兼容性，必须在某版本的GCC下编译的东西根本是不合格的，gcc的参数一直在变，但是基本都做到了向下兼容，如果程序员自己都在用老版本的编译环境，自然会在参数选择上出现这种操蛋问题

同样的，如果你拿到的驱动也是只对应老版本的kernel，那么这份驱动同样是缺乏维护的、不合格的，合格的驱动应该打包成deb包或rpm包，双击安装或进入官方源服务器维护。如果你不幸碰上这样的东西，很简单，你下个老版本的kernel，编译运行即可，不要跟我说你分不清什么事kernel什么是rootfs