人这一生该何去何从？
也许梦想就像信仰一样，在触手而不可及的时候，是最美的。
变得现实并不糟糕，现实可以让你更有效率地计算人生，给自己定下一个个目标，给自己的每一次进步一点点奖励。
没有付出的爱情不会长久，
没有努力过的梦想永远不会成为现实。
2009年2月17日星期二
| [+/-] |
梦想mixed现实 |
2009年2月16日星期一
| [+/-] |
关于博客“墨羽硅”构架的一些想法（未完） |
我对墨羽龟的设想是一个网上的“三室一厅一厨一卫一阳台”豪华精装套房，“羽”是我的房间，“一厅一厨一卫一阳台”的公共设施代表我们的共同空间，基于这个理念，现在的墨鱼龟构架可能还不够完美，所以今天抛砖引玉和两位同居者商讨下改造我们的房子。
“羽”我想再分几个子标签：我的设计-设计眼界-商业合作-关系网（=。=），以后可能还会再细分，问皮：现在我们的标签是一层的，是能再多分几层的吧？（其实现在的标签差不多有我们需要的分类，但是貌似是杂在一起的，没有房间的概念）
墨和硅两位可以自行考虑是否要建子标签。
偶们的“一厅一厨一卫一阳台”，现在来说，动漫空间是不错的，就像客厅摆着一台大液晶和ps3一样。貌似可以再出一个音乐标签，发布一些大家喜欢的音乐做交流。嗯嗯，自己先说这么多，等你们两位的高见了，我会集中整理起来，然后就是大装修了～
2009年2月10日星期二
| [+/-] |
回来了 |
还是人多点好。因为些事情，把163的博客全删了，回到这个单纯的地方，你们还会收留我的吧TAT。博客在IE里显示非常难看，先讨论下整个容吧。偶的要求不高，简单点就好。在这里写写设计和心情～
2009年1月27日星期二
2008年12月15日星期一
| [+/-] |
2008年终致词 |
2008即将过去。这是一个不寻常的年头，对我个人而言。因为这一年中，我从16年的学生身份中破茧而出的，成为了纯粹的一个社会人。也许可喜，也许可悲。仅在这一年即将结束的某晚草草写下致词，作为新一段人生旅程的路标。
致我的父母：
我爱你们，虽然从未说出口。时代赋予的烙印使得我并不能将这句简单而朴素的话语向你们轻易诉说。你们曾经给予我的，我并不能真正回报。生命的珍贵在于，它无法放在天平上称量。那些曾经的痛苦与快乐、眼泪与微笑，我已收藏在名为过去的角落中。将来发生任何事情，我都将会支撑起这个家庭，无论那意味着什么。
致我的朋友们：
如果我的口语曾经伤害了你们，请你们宽恕我。我只是叔本华所说的一只可怜的豪猪，寻找温暖而又害怕刺伤，时刻保持着距离而又不断尝试接近。你们的喜好、习惯和隐藏的秘密都是吸引我接近的原因，虽然有时那会带来疼痛。因为你们的存在使得旅途变得多彩，冬天变得温暖，生活变得丰富。我会履行所有与你们的承诺，甚至在需要时以生命为代价。
致我所关心的人：
也许你会抱怨我不够关心你，也许你会抱怨我并不在意你，也许你会抱怨我总是把想法压抑在心底而不告诉你。实际上，每天我也是会不定时地想起你。在我看来，重要的并不是喜不喜欢，而是我能带给你什么。如果两个人的世界相距太远，结果往往是在浪费时间。如果你给予我一个机会，我会用一生去努力为你追求这世上另一件珍贵之物：幸福。
致我自己：
你已经多次完成了人生的阶段性目标，现在则处于一个更重要的转折点上。明白自己真正的追求，排除噪音和其他繁杂或者不重要的事物。你明白钱绝对不是目的只是方法，最简单和粗俗的方法就是花钱。多看书，保持积极的兴趣爱好，尽可能的锻炼自己（包括心理和生理）。
CursedOctopus
2008.12.15夜
2008年9月12日星期五
| [+/-] |
新的Linux包管理方式与目录结构 |
特性：
模块化
“热插拔”
稳健性
读、写、执行分离
易于访问控制
模块化
整个系统如同拼图版一样拼成。并且呈现一定的层次结构：
微核：由内核+initrd构成，其中initrd的要求是启动、恢复系统的最小集合：
initrd不能依赖除内核、自身以外
能够恢复系统——恢复核心环境（C库、包管理系统...）
含klibc、busybox、必要的模块
核心环境：具备一定完整功能的最小集合：
C库
包管理系统
init
...
其他环境
一个示例的目录结构：
PuzzleFS
PuzzleFS是假象中的实现“热插拔”功能的用户态文件系统(FUSE)。PuzzleFS还是用来实现访问控制的文件系统。
PuzzleFS管理着系统可以执行代码的文件系统命名空间视图。因此，PuzzleFS启动后，对文件系统的读写都交由PuzzleFS进行访问控制，可能地记录到数据库，最后分流到各自源上的原生文件系统实现。
PuzzleFS上的目录结构指定，类似示例目录结构。这样，它和主源的映射关系就比较简单。所不同的是，PuzzleFS是所有源的混合，其某个文件夹下的内容是多个源对应文件夹的并集。
当新的包发现时（新源挂载，或者包下载复制到对应目录——依据配置在执行域中），启动“热插拔”历程。
“热插拔”时，首先读取/验证新包的meta信息。meta信息包括以下：
熟悉Singularity的朋友，可以想象依赖关系和访问控制规则是其相应风格的（MBP...）？
另外，这个方式符合“现代”的安全实现方式：在进行动作前，基于某种描述方式来对动作的影响进行描述，之后验证该动作不违背先前描述。因此，在系统辅助不产生冲突的情形下，软件的安全规则由软件开发者提供（没有人比软件开发者更了解软件的正常行为）
“热插拔”的第二阶段，是可选，为解包阶段。即包如果是压缩，或者需要安装时刻动作（比如编译...），则进行相应动作。包解包后存放的实际地址可以指定源。
第三阶段，为新包分配相关“资源”。包的内容是只读的，并且只有指定目录下的文件可以有可执行的权限（bin、lib）。因此，比如为包分配一个影子etc目录（在System下某个目录中或者用户目录下的某个目录下），当有程序改写etc目录中的内容时，则执行一个COW（Copy On Write），结果在影子etc目录下)
第四阶段，包的注册阶段。包的某些内容写入数据库（Sytem某个目录下）。这样做是因为：
PuzzleFS上的目录结构指定，类似示例目录结构。这样，它和主源的映射关系就比较简单。所不同的是，PuzzleFS是所有源的混合，其某个文件夹下的内容是多个源对应文件夹的并集。
当新的包发现时（新源挂载，或者包下载复制到对应目录——依据配置在执行域中），启动“热插拔”历程。
“热插拔”时，首先读取/验证新包的meta信息。meta信息包括以下：
- 数字签名
- 依赖关系（例如冲突...）
- 访问控制规则（基于路径的正则表达式匹配，可以更复杂地制定主体。当然这意味着对建链接的额外关注）
- 包的所属环境
- 包的分类
- 图标
- ...
熟悉Singularity的朋友，可以想象依赖关系和访问控制规则是其相应风格的（MBP...）？
另外，这个方式符合“现代”的安全实现方式：在进行动作前，基于某种描述方式来对动作的影响进行描述，之后验证该动作不违背先前描述。因此，在系统辅助不产生冲突的情形下，软件的安全规则由软件开发者提供（没有人比软件开发者更了解软件的正常行为）
“热插拔”的第二阶段，是可选，为解包阶段。即包如果是压缩，或者需要安装时刻动作（比如编译...），则进行相应动作。包解包后存放的实际地址可以指定源。
第三阶段，为新包分配相关“资源”。包的内容是只读的，并且只有指定目录下的文件可以有可执行的权限（bin、lib）。因此，比如为包分配一个影子etc目录（在System下某个目录中或者用户目录下的某个目录下），当有程序改写etc目录中的内容时，则执行一个COW（Copy On Write），结果在影子etc目录下)
第四阶段，包的注册阶段。包的某些内容写入数据库（Sytem某个目录下）。这样做是因为：
- 比如，包中lib是公开的，则其下文件等内容数据库索引。对bin下的内容也是，加快相应操作
- 包的meta中的信息，比如实现分类，方便用户分类搜索浏览
- 包的源来分类浏览
- 包是封装的，任何其他包不能访问包中的非公开文件（配置文件)，则在数据库中注册（通用接口的）配置信息，即这是类似注册表或者GConf的。
PuzzleFS实现了“热插拔”、访问控制、包封装、搜索、通用接口的配置功能。
访问控制机制是通过PuzzleFS是对多个原生文件系统统一封装的用户态文件系统的自然结果。
包的封装是指对包的访问，（在访问控制规则许可下）限制只可对bin、lib以及通用配置信息的访问。其他，比如外包不能访问非本包的etc下文件。
搜索。是由于PuzzleFS背后有数据库支持的结果。用于比如加快输入命令，链接库等的查找，分类视图的作用。这是对之前硬盘搜索的自然嵌入（想像微软未曾经计划的WinFS、苹果的spotlight搜索、Novell的beagle...）
通用接口的配置。使得PuzzleFS扮演了注册表(GConf）的角色，用于包配置信息的导出共享等。相比注册表，这里的实现方式更加稳健：所有PuzzleFS数据库中的信息只是一个缓冲，出现问题后可以方便重建的。
2008年9月5日星期五
| [+/-] |
项目 |
- 一个高性能程序编写框架：
- 异步：
- 使用I/O设备、使用其他CPU（主线模型）
- 信号机制
- 调度（优先级）
- 对OpenCL等的封装，易于使用
- 管线对象：
- 一系列串行例程不需要用信号机制连接
- 流水线两个阶段约定数据传递方式（可以是Unix的shell风格）
- 由依赖图生成管线（并被缓冲，参见缓冲对象）
- 期待代替Gstreamer和LLVM编译器驱动
- 缓冲对象：
- 缓冲对象未必在内存中，可以在磁盘...（发布对象?）
- 内存的缓冲（SLAB风格的内存分配）
- 管线缓冲（缓冲由依赖图和状态动态生成的管线）
- 其他...对若干操作得到的结果（立体的）——一个操作就能得到结果（平面化，命中的情形下）
- 与系统资源监视服务互动，调整缓冲大小
- Detective Conan：
- 嵌入在调用中。
- 在收集I/O结果、错误、性能参数。报告某监视进程。
- 用例：web服务器、下载器、启动器<缓冲、日志、收集结果>。
- 非MVC的UI编写框架
- 界面和模型参数的传递是“量子”的而非经典的（需要和控制器无限交互）
- 由ASL库启发
- 解析器等依赖LLVM，依赖图依赖上一框架
- LLVM整合？
- 基于结构化、模式匹配的限制(contrain)模型
- 用于窗口系统对窗口“权限”的限制
- 所见即所得编辑器缺陷的弥补：附加在文字编辑器的模板，对某一域限制的图形化显示，违背限制的图形化显示。比如论文的索引，鼠标移到之上显示某些下拉菜单等的组合，移出恢复”所见所得“模式
- 易用的访问控制模型。结合系统包管理方式
- 包管理方式：
- 分布式<没有中心/usr...，热插拔>、文件系统布局、特性通知（忘了configure...）、访问控制<封装>
- X windows的移除
- 分离功能，一些功能分离到EGL、OpenGL中
- 关注窗口树结构，DOM风格(事件传递、处理)
- wayland now
- LLVM SVA操作系统的设计
- Singularity Like
- ...
将在某个CMS中实践部分
订阅：
博文 (Atom)
