虽然我知道只要一个命令就好了，但是设计一个GUI对于不愿意／害怕面对终端的用户是很有价值的。应该收费！而且创业家精神本来就应该提倡

支持支持！

kernel ABI/API很稳定。glibc静态链接好了

你的项目只是在初级阶段而已，把photoes(注意复数形式)表拆成两个意义不大，不如就用方案2。你现阶段的首要任务是初版上线，不是去优化数据库。目前阶段，情愿设计地过于简单而不是过于复杂，因为你迟早要根据需求的细节重构

以后随着你的需求变化，自然要拆表、反范式化、用文件系统储存BLOB等等

@fdgogogo 两年前跟你的想法是一样的。后来发现Mac/OSX不爽的地方越来越多，正如我说的“对别人而言的just works，对自己来说也许就是脑残，还修改不了“ “智能和弱智只有一步之遥”

Mac/OSX确实有优点，但是宣传把它描述成完美的OS了，很明显不是这样的

你两年以后再回来看这个帖子

很多C语言的初学者以为malloc()是最底层的函数之一。很遗憾，不是。malloc()只是OS提供的user land内存管理API的二道贩子而已

@Sherlockhlt 原因有好几种
1. 标准的malloc()不够优化。对于openssl这种lib来说，自己搞一套内存管理器，甚至关键路径用汇编都很正常
2. 库函数已经静态链接某一特定版本的malloc()了，用户代码自己可以用另一个版本。一个进程里存在两套以上的内存管理器互不干扰，虽然C语言的入门书不会提，但是是完全正常的。而且实际中的复杂应用中也很常见
3. 库函数实际上是OS的API。Kernel里的内存管理器和User land的自然不一样，想一样也不可能

补充一下，有时候库函数确实需要返回大小在调用前不确定的数据，由于大小不确定，所以调用方很难提前分配

方法有二
1. 提供一个查询函数，查询返回数据有多大，还是由调用方分配
2. 提供一个释放内存的函数，这样库函数可以安心用自己的内存管理器来动态分配内存

库函数不要返回自己"malloc"出来的数据，原因是客户代码和库函数有可能不使用一致的内存管理器

如果是自己的代码内部，又都使用标准的C的malloc()，可以用第一种方式返回数据

@clowwindy putty只有500KB，而且还是GUI程序

举一两个应用的例子抬杠也没有意思，Windows和OSX早就证明了每个应用自带依赖没什么问题，硬盘空间照样够用。吃硬盘的不是应用而是媒体文件。这点也不用跟我争，去问问Win/OSX的用户就行

本来软件包就该由开发方维护、发布，由发行版维护到底有什么好处呢？打一行apt-get install xyz就能用上看似很惬意，实际上问题很大。不能指定安装路径、不能指定版本、不能同时安装多个版本、配置文件、应用文件分散到不同的目录里不好找，不同的发行版使用的配置文件格式还不一样，要不停得学习新格式，这些不都是给用户找麻烦么

二进制库的大小真不是问题。putty, winscp这些用到openssl的应用都很小巧。除了巨型软件套装(如Adobe CS、Visual Studio、MS Office之类)，Win下的常见应用的大小基本都在10MB这个量级

C++程序由于模板，展开后编译出上百MB的目标文件很正常。这是C++的设计缺陷。而且由于模板都是在客户代码（即最终应用）中展开，换用包管理器也无济于事（因为没有别的应用会和你共享实例化以后的模板）

Linux的包管理把整个系统的代码库串联起来，缺少冗余，从结构上来说很脆弱。一个库有bug或者出现regression，所有相关应用都遭殃

@haohaolee 说得好!

@est DLL hell是历史了。目前的Windows应用都推荐做成支持XCOPY的。话说回来, dll hell就是没有严格执行“每个应用自带依赖”造成的

MSI至少是个操作系统支持的规范，好处是用户如果安装msi型的软件，他永远都能找到卸载的入口。OSX的pkg格式没有规范，就导致反安装方式无法八门

另外，无需提OSX的.app(bundle)格式。自带依赖并支持XCOPY部署本来不就应该是理所当然的么？？

@est MSI跟winsxs没有关系。Winsxs是side-by-side assembly用的。标准的windows应用是支持XCOPY部署的，需要反安装包的用户给他们提供个msi包装的版本

@wliment 自带依赖根本不会让软件膨胀多少。C/C++库都是百KB ~ 几十MB级别而已。当然，巨型软件总是很大的，但是膨胀的部分往往不是库而是资源文件、帮助文档之类，反正瞎搞是没下限的

Windows、OSX下这么多年下来也没有多少人表示软件包的平均大小让人吃不消吧

这年头居然有人认为Windows下卸载程序一定会留下残留，真是让人无语。这是要分installer的作者有没有用心去写的好不好，写的好的软件，卸载自然不会有垃圾残留的

@fox000002 软件包应该自带依赖。这样就不需要一个全局包管理器了。用户也可以安装同一个软件的多个版本实例，互不干扰。目前msi的做法就很好，用户指定一个安装目录就行了。

@likuku 我从2007年就使用mac作为主力开发机器，中间不知道折腾了多少东西，也曾经是坚定的苹果信者。不过目前我看透了，Mac/OSX实际的问题很多，绝对被大众媒体高估和神话了。别人眼里的"just works"对我来说远远不够好用。

我已经换回Linux作为主力OS了，Windows用来补充，OSX基本不用了

为什么非要包管理器呢。像Windows那样做成.msi类型的installer是最好的

@zhonghua 没那么简单，Mac这两年被神话了。“智能”和“弱智”只有一步之遥。对别人来说"just works"的设定，对自己来说也许是脑残，而且还改不了