到 GitHub 的仓库设置里面，如果是一个 fork 来的仓库，会显示 "You cannot change the visibility of a fork. Please duplicate the repository."

所以，开源项目不可以 Fork 成私有库，也没有然后了。

顺便一说，开源项目在闭源项目里用是允许的，包括 GPL 。到 redistribution 也就是再发布软件的时候才有侵权的问题。比如，在不以 GPL 重新发行新代码的情况下，一家公司可以拿 Linux 内核改一改用在自家内部的机器上，但不能拿 Linux 内核改一改然后拿去重新发布（比如拿去卖，比如把代码公开了但是不用 GPL 授权）。

1. 说到稳定性，我基本上天天都在用 Arch Linux 和 Windows 10，Arch Linux 基本上一周更新一次内核，系统从来没有彻底挂掉过，小问题当然经常有，输入法不能用这个等级的，等一段时间就修好了。我从来没在 x86 上见过 Linux 的 kernel panic 。
我这里还有台装着最新 Windows 10 的 Surface pro 4，小的 bug 一直有，有一个从我买来到现在也没修好的（整个系统卡住没有响应持续若干秒，连我都知道这个问题要怎么修，但微软就是不修）。我还随时可以让它 kernel panic （连上我手头的一个 ax 路由器，10 分钟之内蓝屏）。

你当然可以说 Windows Server 不是这样的，但我没用过 Windows Server，我只能比较最新的 Linux 和 Windows

2. 这种事情上，你不能说我们那个什么厉害的内部系统，对稳定性要求可高了，就用的是 Windows，这种说法无从考证，你得找大家都能查到的信息。
比如大家都知道的 https://www.top500.org/statistics/list/ 已经 100% Linux 了。
比如我随便搜了一个搞什么工业领域的公司，https://waterfall-security.com/solutions/ ，里面说支持四个数据库，Microsoft SQL Server, Oracle, MySQL, PostgreSQL
MySQL 也没那么不堪吧。

@msg7086

2.
楼主的原文里可没有说要检查文件有没有关，而且楼主还给出了文件没关情况下释放磁盘空间的方法。
你觉得应聘者可以有更高级的回答，那当然是好事。但是楼主作为面试官，他给出的答案就是一股脑删了，而且本来在用的文件，用 rm 不会删除的东西，也被删了。我喷的就是他预期的这个答案。

3.
我的原文是
"在我看来这个文件被占用的答案才是实战经验少，估计是刚毕业吧，因为线上服务的日志都是有人专门管理的，我在公司从来没听说过删日志这个操作，在自己的机器上随便玩倒是经常删。"
被你曲解成了
"事情都甩锅给别人来做说明实战经验多，事情自己来做说明实战经验少"

楼主说删了一个日志文件，磁盘空间没被释放，出现这个情况的原因是这个文件还在被占用。

正式服务器被占用的日志文件不能删，运维不可能在工作中发现，欸我删了一个日志文件怎么磁盘没释放结果是日志文件还在被占用。
有专人管理的意思是说他不能让服务器出现日志把磁盘占满的情况，这都有监控的，快满了要报警，报警了就要解决，这是他的工作。如果都已经磁盘满了需要手动 rm 文件或者 echo> 了，那这系统已经病入膏肓了，这是不能允许出现的情况。不是说现在磁盘满了系统挂了这都是运维的事和我没关系。

你玩过十几年 Linux，知道删除一个被打开的文件不会释放磁盘空间，但你大概率不是通过删日志文件学到这件事情的。
但是，楼主已经给定了线上服务器日志文件管理这个场景，在正常操作服务器的前提下，就已经排除掉了文件没关这种可能性。但还说可能是这样，那我只能说是没经验了。


> 请详细描述如何用不同的方式正确地储存和清理日志

这完全是另外一个问题，楼主原本的问题是 "在 Linux 下，如何删除一个目录下的所有 log 文件？"
如果我看到这个问题，我不可能回答 "请详细描述如何用不同的方式正确地储存和清理日志"。
面试官当然可以问 "请详细描述如何用不同的方式正确地储存和清理日志"。
但如果你想问的是这个问题，然后实际问的是 "在 Linux 下，如何删除一个目录下的所有 log 文件"，那这正是我要喷的点。

@msg7086
> 竟然真的有人认为面试的时候问问题是期待别人精确回答？

通常情况下当然不会这么想，但是楼主的原文里面有不少带这种含义的句子。

"令我很意外的是，真的只有很少的应聘者能想到 find 命令"
这里很明白地在表示自己期望别人回答用 find 来查找文件。

3 里面提到说有人回答说可能是删了软链接，这当然是一个正确的回答。

但是楼主随后就断言
"但实际生产上，遇到 “删了 log 文件、但空间不释放” 通常和软 /硬链接没有什么关系。"
明确地否定了这个答案。

"实战经验比较丰富的候选人会知道，这往往是因为 log 文件正被另一个进程打开。"
也就是说回答前面那种答案的人，实战经验少。

在我看来这个文件被占用的答案才是实战经验少，估计是刚毕业吧，因为线上服务的日志都是有人专门管理的，我在公司从来没听说过删日志这个操作，在自己的机器上随便玩倒是经常删。

原文里面有一句 "但如果是线上服务呢？"，然后楼主在下面的回帖说是多人共用的开发机，那这完全是两码事。

如果是你可以随便折腾的开发机，那这个问题的很多前提都不成立。另外开发机上的日志可能更重要，也许是同事若干天的劳动成果。

这种问题，要么是开放的随便怎么回答都可以，那么你出的题目就不能有这么明显的局限性。比如你可以问怎样批量进行文件操作，可以问磁盘满了怎么解决。但是不能把情景人为地组合在一起，因为这样组出来的情景就不合逻辑了。

如果我去面试，你问我要怎么删除日志文件把磁盘空间清出来，估计我会回答

journalctl --vacuum-time=30days

https://www.v2ex.com/t/655096

原来是同一个人发的，怪不得又是这种奇怪的面试题。我再来喷一次。

1. 在 Linux 下，如何删除一个目录下的所有 log 文件？

你需要给定什么叫做 log 文件，如果是文件名以 log 结尾的文件，那当然是 rm *log
删子目录是 rm **/*log

日志文件是日志文件，文件名随便是什么都可以；文件名以 log 结尾的文件是文件名以 log 结尾的文件；文件名以 .log 结尾的文件是文件名以 .log 结尾的文件，这都不一样的。真不知道你的 “log 文件” 到底是啥。

2. find 是一个不常用的命令，原因是这个命令的功能通常能被 shell 的 * 或者 ** 代替。
另外 find 功能很强，用法也很复杂，有几十个参数，参数之间有逻辑关系而且还可以套别的命令，如果不是有很特殊的需求，不会来用 find 。而且 GNU find 和 BSD find 的用法还不完全一样。
你给出的那一行 find 命令是错的，少了一个 .
find . -name \*.log -exec rm -f {} \;
这一行也可以写成
IFS=$'\n'; for f in **/*.log; do rm "$f"; done
这个可能是更常见的用法

3. 删了文件磁盘空间不释放这很正常，还有可能是 btrfs 或者 zfs 上给 dedup 了。
有这么多种可能性，我不知道为什么来面试的人就必须要想到是文件还在被占用。

4. 把日志文件删掉了，因为那个文件还在被使用，所以磁盘空间没释放。
我就想问一句，贵司真是这么删日志的么？
正在被打开的日志文件，意思是还有进程在往里面写日志，我想不到有正常的运维会删一个正在被写入的日志文件。
在我的认知里，删日志都是删若干时间之前，肯定不会再用到的老日志。这全新的还在写的日志文件你这么都随便地删掉了，那当初为啥要记这个日志呢？
能被这种神操作理直气壮地出到面试题里面，贵司确实蛮厉害的。

@594duck
1. 一台电脑，算你满载，算一个 200W 的 CPU 加一个 300 W 的显卡，两小时 1 度电。一天额外 8 度电，总共不到 20 块钱。算你这台满载的电脑没有给公司带来收益，假设工资是一小时 100 块钱，20 块钱已经是 10 分钟的工资了。每天开机关机多花十分钟有点多但也不过分。

2. 如果没关机的电脑能引起火灾，这办公设施的问题已经非常严重了。

3. 工作电脑当然要强制设密码，这是常识吧。另外这个问题和关机不相关，如果不设密码，开机的时候也不用输入密码。

Java 的 finally 也不保证能执行到
https://stackoverflow.com/questions/1410951/how-does-javas-system-exit-work-with-try-catch-finally-blocks

但是 Python 在这个情况下会执行 finally

defer 和其它语言里的 finally 基本上是等价的，直接用就是了

我觉得 panic 和 os.Exit 在正常运行的程序里不多见，出现了就需要改 bug 了，这个问题也没多大影响

这个拆开查就简单了，查一次所有一级代理下面有多少二级代理，再查一次一级代理下面有多少用户，再查一次一级代理下面的二级代理有多少用户，分三次查应该也没什么不好的。

合到一起的话，在第三个查询里面用 count(distinct) 把前面两次查询的结果算出来应该就可以了。

这种事情要看文档的


在 C++ 里，容器上的 const member function 是线程安全的。
然后在这里面 https://en.cppreference.com/w/cpp/container/map

const T& at( const Key& key ) const; 是线程安全的
T& operator[]( Key&& key ); 不是线程安全的，所以从 specification 的角度来说，有两个线程都在 m[key] 也是错的。
insert 当然不是线程安全的，明显不可能

必须所有线程上都只使用 const member function 才没有 data race，所以实际情况通常是这些操作全都要加锁。


Java 的 HashMap，https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html

If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.)

添加删除都需要加锁，修改一个已经存在的 entry 不需要。

@zhangysh1995
如果他发的 SQL 是对的，那个 cte 等价于

SELECT id
FROM A
LEFT JOIN B ON A. id = B. id
LEFT JOIN A AS parent ON B.parent_id = parent. id
WHERE A. uid = 41 AND (A.type = 2 OR (A.type = 3 AND parent. id IS NOT NULL))

然后这个 cte 也不用写 cte，直接和下面的 JOIN 写在一起就好了


另外这个 EXPLAIN 明显不是 PostgreSQL，我也没看出来这是什么数据库

```
创建新回复过程中遇到一些问题：
请不要在每一个回复中都包括外链，这看起来像是在 spamming
```
@Livid 这个外链的检查也太敏感了吧

> D 表的（ DELETE_FLAG,ID,aid ）也加了联合索引

D.ID 在这个查询里就没被用到


这个 SQL 里面，E 就是 A，t 也是 A，最外层写了一个 A INNER JOIN A ON A.id = A.id ，确定是这样的么？


这个 SQL 写得有点奇怪，比如还有一个问题是 cte 里面不用写 UNION，一次 SELECT 就可以了。
先把它整理清楚了再优化吧。

> 客户端 app 的代码是安全的，没有被反编译查看

如果这个假设成立，只要在客户端代码里判断一下服务器的证书是不是你的证书，问题就解决了。

密码学的一个常识是不要自己写代码做加密，不要做额外的加密，没有用。

@dawniii
不让用 JOIN 的话，只能这么拆着查。
而且我也说了用 JOIN 应该更快。

重点其实是不用 JOIN 就不这么建表了。

用不用 JOIN 只是不同的观点，并没有什么优劣之分，如果 JOIN 那么不堪，这些个数据库还做这个功能干啥。
如果表是按照关系型数据库范式设计的，在上面做查询当然要用 JOIN 。不用 JOIN 有不用的玩法，从一开始就不一样。
PostgreSQL 在 2008 年加的 hstore，2012 年加的 JSON，都是反范式的功能。在反范式的表上不用 JOIN 来查询就很正常了。

@dawniii

这种情况不叫一对多，叫多对多。
一对多应该把表做成这样，不需要中间表。
article(id, ...)
tag(id, name, article_id)
author(id, name, article_id)

这种全用中间表不带冗余字段的设计，是符合关系型数据库范式的表结构，在这种表结构上当然要用 JOIN 。
不用 JOIN 的话表就不这么设计了，比如用 PostgreSQL 的 JSONB 数组来存 tag，直接放在 article 表里面，建一个 GIN 索引。

即使是这样的表结构，不用 JOIN 当然是可以查的，只不过比用 JOIN 慢。
SELECT id FROM tag WHERE name = XXX 取出 tag_id
SELECT article_id FROM article_tag WHERE tag_id = xxx 取出 article_tag_ids

SELECT id FROM user WHERE name = XXX 取出 user_id
SELECT article_id FROM article_author WHERE author_id = xxx 取出 article_author_ids

SELECT * FROM article WHERE id IN(article_ids1) AND id IN (article_ids2)

但是，
前两个 SQL 合并成 SELECT article_id FROM tag INNER JOIN article_tag ON tag_id = id WHERE name = xxx 当然会比查两次要快。因为这个 JOIN 没有带来额外的开销。我觉得即使是 MySQL 也能正确地执行这句 SQL
后面两条也一样。

如果全都合在一起，
SELECT article.* FROM article
INNER JOIN article_tag ON article.id = article_tag.article_id
INNER JOIN tag ON tag.id = article_tag.tag_id
INNER JOIN article_author ON article.id = article_author.article_id
INNER JOIN author ON author.id = article_author.author_id
WHERE tag.name = xxx AND author.name = yyy
GROUP BY article.id

这个 SQL 也没什么问题，JOIN 仍然没有引入额外的开销，而且还比上面那 5 句好懂。
但如果用的数据库是 MySQL，这个 SQL 很有可能被用奇怪的方式来执行，那当然就慢了。
这就是很多人说不能用 JOIN 的理由。

@5200
请假天数当然没有限制，只要开得出来医院证明，就能一直请假。
不然真需要长期病假了难道推着病床去上班么。
如果有限制，那是公司自己随便定的，不管用。
病假期间的工资会减少，政*府*有规定下限。

政*府 居然不能发?

@zhongjun96
ORDER BY IF (age=24, id, 2147483647) ASC, id DESC

如果是别的数据库可以用 null 然后 asc nulls last，MySQL 不支持这么写，只能放一个大数字了