虽然吧 MS 也整了 z3 和 Lean 这些牛逼的学术向开源项目，但是和 Windows 都没啥关系，毕竟也不是同批人搞的，最主要的是目前还没有啥新闻说下版 Windows 经过形式化验证，bug 减少 80% 啥的。苹果整的这些至少 macOS 上都看得到。
Windows开源了1990年份的30年陈vintage文件管理器
1 个赞
只能说技术的偏见和鄙视链无处不在，希望还是回归到问题本身，而不是从主观臆断。
工作关系各种平台都用。Linux确实是最小众，基本限于开发人员；Windows受众最广，更受垄断调查的关注，处理起来更小心谨慎；macOS 最受设计和视频工作者青睐，最封闭但也最会立牌坊 
苹果开源了不少项目，微软也开源了不少： Microsoft (github.com)。 只是各自的关注点不同罢了。存在偏见的情况下，即使做了很多一样会被喷：你的东西不如xxx……比如，微软在Windows中使用Linux内核，WSL一样被骂得狗血零头。但是，其他哪个操作系统会内置竞争对手的内核玩呢？当然，又会有更多的理由和抨击出现，我只是举例而已。
商业公司搞开源都有自己的商业考量，反之，很多开源项目其实也有自身的商业考虑。比如：Red hat , Spring… 前段最爱的Markdown编辑器之一Typero也开始收费了😭 个人认为，开源不一定都是好的，商业也不都是坏的，不能把开源作为唯一的正义。世界太复杂了，程序员的世界还是太单纯 。。。
结贴。。。。
3 个赞
原先那个帖子里看衰 Linux 桌面的太多, 我觉得没有必要. 顺带自己体验了一下 windows, 被微软好好恶心了一把, 就回了那个帖子, 没想到有人回复我, 然后又写了点, 又有人回复, 又写了一点. 都是真金白银的亲身经历, 给想要升级 Windows 11 的用户提个醒.
微软的东西, 等他们迭代个三五年再用还差不多, 都说微软有"隔代好用"的魔咒, 但 Windows 10 刚出的时候,照样被各种骂, 后来改着改着, 可能用户都习惯了, 风评才好起来. Windows 11 估计也有等个几年, 才能不捏着鼻子用.
开源有是也会这样, 比如 Wayland, 迭代了那么久, 还不能完美替代 X11.
只对比windows系统和macos/ios系统的话，是windows更封闭，macos/ios内置的不少东西都开源了，甚至包括内核 GitHub - apple/darwin-xnu: The Darwin Kernel (mirror). This repository is a pure mirror and contributions are currently not accepted via pull-requests, please submit your contributions via https://developer.apple.com/bug-reporting/ ，相比windows只有个计算器和1990年份的文件管理器是开源的。
spj 之前也是 msrc 的人啊。
当偏见发展到双重标准，就已经多多少少带点“因信称义”的味道了。
感觉得区分一下开源和自由 
。商业公司主导的开源项目和自由软件差别还是挺大的。
还有个我认为比较特殊的场景是云服务相关的开源项目。这个衍生了特殊的许可证，比如OSI并不接受SSPL协议。。另一个就是copilot。。
当开源遇上利益冲突总是一地鸡毛。这时候回头看自由软件，，只能说确实是高瞻远瞩。
3 个赞
我认为 PostgreSQL 就很好的实现了开源和自由的结合
我说的是内置的东西。。。另外windows内置的powershell和开源的是两个东西
以上这些都是Windows11内置的。我没留意开源的Powershell和内置的不完全一样，但它们基于同一个旧版本，所以还是共享很多代码的，将来也可能会合并，就像dotNet core一样。
收到win11升级提示，现在还能选择拒绝，我对win11没有兴趣，但我怀疑会被微软强制升级或因为某它原因只能升级，win的驱动支持是好，但我感觉这已经成为了微软迫使用户不得不升级的方法之一，这种情况我是遇到过的，去年 发过一贴讲过
1 个赞
我的对 PostgreSQL 的印象是发论文用的（误
感觉和社区主导有一定联系。
Win11 用着感觉挺好的。从10升到11，无痛。原以为很多软件要重新安装，结果如丝般顺滑。
1 个赞
什么时候 sway bar 的托盘图标可以弹出菜单了什么时候切过去。
直接在 BOIS 中关闭 TPM 2.0 ，你的电脑就没法升级 Windows 11 了，永远停留在 Windows 10
While reviewing Thomas Munro’s patchset to consider expanding the uses of specialized qsort [1], I wondered about some aspects of the current qsort implementation. For background, ours is based on Bentley & McIlroy “Engineering a Sort Function” [2], which is a classic paper worth studying. 1) the check for pre-sorted input at the start each and every recursion This has been discussed before [3]. This is great if the input is sorted, and mostly harmless if the current partition is badly sorted enough that this check fails quickly, but it’s not hard to imagine that this is mostly a waste of cycles. There have been proposals to base the pre-sorted check on input size [4] or to do it only once at the beginning, but that strikes me as looking for the keys under the lamppost because that’s where the light is. The logical criterion for proceeding to check if the input is sorted is whether we think the input could be sorted. That may sound like a tautology, but consider the case where the partitioning phase didn’t perform any swaps. Then, it makes sense to check, but we can go further. What if we do the check, but towards the end that check fails. If just a couple elements are out of place, does it really make sense to give up, partition, and recurse? If just a few iterations of insertion sort are all that is needed to finish, why not just do that? This way, we dynamically decide to optimistically start an insertion sort, in the hopes that it will occasionally prevent a recursion, and worst case the input is slightly more sorted for the next recursion. All we need is a lightweight way to detect that the partitioning phase didn’t do any swaps. More on this later. 2) cardinality issues can cancel abbreviated keys, but our qsort is not optimized for that Since in this case comparison is very expensive, it stands to reason that qsort could profitably be optimized for a low number of unique keys. The Bentley & McIlroy scheme does take great pains to prevent quadratic behavior from lots of duplicates, but I’ve found something that might have stronger guarantees: Pattern-defeating quicksort (paper: [5] C++ implementation: [6]) claims worst-case runtime of O(nk) for inputs with k distinct elements. This is achieved via an asymmetric partitioning scheme. It’s not complex, but it is subtle, so I won’t try to describe it here. I recommend reading section 3 of the paper for details. Rust and Boost use PDQuicksort in some form, so it has some production use. The partitioning scheme just mentioned also provides an easy way to detect when no swaps have been done, thus solving #1 above. There is one requirement that is a double-edged sword: Recursion to the partitions must happen in order. This has an additional advantage that in every case but one, insertion sort doesn’t need to guard against running off the beginning of the array. The downside for us is that we currently recurse to a partition based on its size as a stack-guarding measure, so that guard would have to be replaced. The C++ implementation of PDQuicksort falls back to heap sort as a last resort to bound runtime, but it would be just as effective at guarding the stack. That’s a bit of a snag for making it production-ready, but not enough to prevent testing the actual qsort part. Does anyone see a reason not to put in the necessary work to try it out? [1] PostgreSQL: Re: A qsort template [2] https://cs.fit.edu/~pkc/classes/writing/samples/bentley93engineering.pdf [3] https://www.postgresql.org/message-id/flat/87F42982BF2B434F831FCEF4C45FC33E5BD369DF%40EXCHANGE.corporate.connx.com#e69718293c45d89555020bd0922ad055 [4] PostgreSQL: Re: Timsort performance, quicksort (was: Re: Memory usage during sorting) [5] https://arxiv.org/pdf/2106.05123.pdf [6] GitHub - orlp/pdqsort: Pattern-defeating quicksort.
–
John Naylor EDB: http://www.enterprisedb.com
我摘取了一份PG社区邮件列表的讨论,个人认为这是一个由纯学术项目向工业化生产成功转型的好范例. 现在PG的核心开发者都是商业公司的. 参见PG贡献者列表.
看起来是关于pdqsort的讨论 
之前看过一点PG的代码，很规整注释也全。（现在看C++简直是灾难。对比隔壁 MySQL 和 MariaDB 。。
我在做的ceph也算学术转商业（虽然性能被商业闭源实现吊打。只是这些面向企业的开源项目和个人关系不那么大的样子。
1 个赞