Unix 哲学指软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。
像微服务架构这种现代实践可以认为是这种哲学的应用，其中每个服务很小，集中于做一件特定的事情，由简单的构建块组成复杂的行为。
另外，盖尔定律 (Gall’s Law)也说了：一个复杂系统势必是从一个简单系统发展而来的。
Unix哲学是一套基于Unix操作系统顶级开发者们的经验提出的软件开发的准则和哲学。
McIlroy：A Quarter Century of Unix
UNIX 哲学由 Doug McIlroy 在1978年的《Bell System Technical Journal 》中发表。道格拉斯·麦克罗伊是Unix系统上管道机制的发明者，也是Unix文化的缔造者之一。他归纳的Unix哲学如下：程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流，因为这是一个通用的接口。
更加简化的版本是：做一件事，做好它。虽然只有第三条是特指Unix系统的，但Unix开发者们常常同时强调这三个信条。
Pike：Notes on Programming in C
罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的，但作为Unix哲学丝毫不为过：
- 规则一：你永远不会知道你的程序会在什么地方耗费时间。程序的瓶颈常常出现在意想不到的地方，因此在你确信找到瓶颈后再动手优化代码吧。过早优化是万恶之源
- 规则二：测试代码。只有在你详细测试了代码，并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。
- 规则三：功能全面的算法（fancy algorithm）在处理小规模问题时效率很低，这是因为算法时间效率中的常量很大，而问题往往规模很小。除非你知道你遇到的常常是复杂的情况，否则就让代码丑陋但是简单而高效吧。（即使问题规模确实很大，也首先尝试第二条规则。）根据问题的规模选择对应算法，例如排序算法，在待排序的元素个数很少（两位数）时，使用冒泡排序算法，在待排序的元素个数很多时，使用快速排序算法
- 规则四：功能全面的算法比简单的算法更容易产生Bug，更难实现。尽量使用简单的算法和数据结构。
- 规则五：数据决定一切。如果选择的数据结构能很好的管理数据，算法部分往往不言自明。记住，数据结构，而非算法，才是编程的关键。精心设计的数据结构能达到使用简单算法就解决问题的目的。程序=精心设计的数据结构+尽量简单的算法
- 规则六：没有第六条规则。
Pike的第一、二条规则重申了高德纳的著名格言：“过早的优化是一切罪恶的根源。” Pike的第三、四条规则被肯·汤普逊改述成：“疑惑不定之时最适合穷举。”事实上，这两条规则也是KISS原则的具体表现。则五在之前Fred Brooks的人月神话中也被提及。Jon Bentley的《Programming Pearls》中也有一章阐述了相同的设计哲学。此规则作为“如果你的数据结构很好，那么控制它的算法就无关痛痒了”的例子常常被简化成“简约地写代码，聪明地用数据”。第六条规则当然只是Pike针对蒙提·派森之小品Bruces sketch的幽默发挥而已了。
Mike Gancarz的《UNIX哲学》
1994年，X窗口系统开发组的成员Mike Gancarz根据他自己的Unix系统经验以及和其他领域使用Unix系统的资深程序员们的讨论结果，写成了The UNIX Philosophy，提出了9条训格之言：
一：小即是美。
二：让程序只做好一件事。
三：尽可能早地创建原型。
四：可移植性比效率更重要。现在应该是“可读性比效率更重要”
五：数据应该保存为文本文件。
六：尽可能地榨取软件的全部价值。
七：使用shell脚本来提高效率和可移植性。
八：避免使用可定制性低下的用户界面。
九：所有程序都是数据的过滤器。输入数据->程序->输出数据
此外还有十条原则则并不为所有人认同，甚至还是争论的焦点（如宏内核和微内核之争）：