本书被《连线》杂志列为 2017 年出版的最有价值的科技书籍之一。

私有制的时代看起来似乎结束了，在这里我将不仅仅讨论那些由我们中的许多人引入到我们的家庭与生活的设备和软件，我也将讨论这些设备与应用依赖的平台与服务。

尽管我们使用的许多服务是免费的，但我们对它们并没有任何控制权。本质上讲，这些企业确实控制着我们所看到的、听到的以及阅读到的内容。不仅如此，许多企业还在改变工作的本质。他们正使用封闭的平台来助长由全职工作到零工经济的转变，这种方式提供极少的安全性与确定性。

这项行动对于网络以及每一个使用与依赖网络的人产生了广泛的影响。仅仅二十多年前的对开放互联网的想象正在逐渐消逝，并迅速地被一块难以穿透的幕帘所取代。

一种逐渐流行的补救办法就是建立 平台合作社 platform cooperatives ， 即由他们的用户所拥有的电子化平台。正如这本书《Ours to Hack and to Own》所阐述的，平台合作社背后的观点与开源有许多相同的根源。

学者 Trebor Scholz 和作家 Nathan Schneider 已经收集了 40 篇论文，探讨平台合作社作为普通人可使用的工具的增长及需求，以提升开放性并对闭源系统的不透明性及各种限制予以还击。

何处适合开源

任何平台合作社核心及接近核心的部分依赖于开源；不仅开源技术是必要的，构成开源开放性、透明性、协同合作以及共享的准则与理念同样不可或缺。

在这本书的介绍中，Trebor Scholz 指出：

与斯诺登时代的互联网黑盒子系统相反，这些平台需要使它们的数据流透明来辨别自身。他们需要展示客户与员工的数据在哪里存储，数据出售给了谁以及数据用于何种目的。

正是对开源如此重要的透明性，促使平台合作社如此吸引人，并在目前大量已有平台之中成为令人耳目一新的变化。

开源软件在《Ours to Hack and to Own》所分享的平台合作社的构想中必然充当着重要角色。开源软件能够为群体建立助推合作社的技术基础设施提供快速而不算昂贵的途径。

Mickey Metts 在论文中这样形容， “邂逅你的友邻技术伙伴。" Metts 为一家名为 Agaric 的企业工作，这家企业使用 Drupal 为团体及小型企业建立他们不能自行完成的平台。除此以外, Metts 还鼓励任何想要建立并运营自己的企业的公司或合作社的人接受自由开源软件。为什么呢？因为它是高质量的、并不昂贵的、可定制的，并且你能够与由乐于助人而又热情的人们组成的大型社区产生联系。

不总是开源的，但开源总在

这本书里不是所有的论文都关注或提及开源的；但是，开源方式的关键元素——合作、社区、开放治理以及电子自由化——总是在其间若隐若现。

事实上正如《Ours to Hack and to Own》中许多论文所讨论的，建立一个更加开放、基于平常人的经济与社会区块，平台合作社会变得非常重要。用 Douglas Rushkoff 的话讲，那会是类似 Creative Commons 的组织“对共享知识资源的私有化”的补偿。它们也如 Barcelona 的 CTO Francesca Bria 所描述的那样，是“通过确保市民数据安全性、隐私性和权利的系统”来运营他们自己的“分布式通用数据基础架构”的城市。

最后的思考

如果你在寻找改变互联网以及我们工作的方式的蓝图，《Ours to Hack and to Own》并不是你要寻找的。这本书与其说是用户指南，不如说是一种宣言。如书中所说，《Ours to Hack and to Own》让我们略微了解如果我们将开源方式准则应用于社会及更加广泛的世界我们能够做的事。

作者简介:

Scott Nesbitt ——作家、编辑、雇佣兵、 虎猫牛仔 Ocelot wrangle 、丈夫与父亲、博客写手、陶器收藏家。Scott 正是做这样的一些事情。他还是大量写关于开源软件文章与博客的长期开源用户。你可以在 Twitter、Github 上找到他。

via: https://opensource.com/article/17/1/review-book-ours-to-hack-and-own

作者：Scott Nesbitt 译者：darsh8 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

来自 Dice 和 Linux 基金会的“开源工作报告”发现，未来对具有安全经验的专业人员的需求很高。

对安全专业人员的需求是真实的。在 Dice.com 多达 75,000 个职位中，有 15％ 是安全职位。福布斯 称：“根据网络安全数据工具 Cyber​​Seek，在美国每年有 4 万个信息安全分析师的职位空缺，雇主正在努力填补其他 20 万个与网络安全相关的工作。”我们知道，安全专家的需求正在快速增长，但感兴趣的程度还较低。

安全是要关注的领域

根据我的经验，很少有大学生对安全工作感兴趣，所以很多人把安全视为商机。入门级技术专家对业务分析师或系统分析师感兴趣，因为他们认为，如果想学习和应用核心 IT 概念，就必须坚持分析师工作或者更接近产品开发的工作。事实并非如此。

事实上，如果你有兴趣成为商业领导者，那么安全是要关注的领域 —— 作为一名安全专业人员，你必须端到端地了解业务，你必须看大局来给你的公司带来优势。

无所畏惧

分析师和安全工作并不完全相同。公司出于必要继续合并工程和安全工作。企业正在以前所未有的速度进行基础架构和代码的自动化部署，从而提高了安全作为所有技术专业人士日常生活的一部分的重要性。在我们的 Linux 基金会的开源工作报告中，42％ 的招聘经理表示未来对有安全经验的专业人士的需求很大。

在安全方面从未有过更激动人心的时刻。如果你随时掌握最新的技术新闻，就会发现大量的事情与安全相关 —— 数据泄露、系统故障和欺诈。安全团队正在不断变化，快节奏的环境中工作。真正的挑战在于在保持甚至改进最终用户体验的同时，积极主动地进行安全性，发现和消除漏洞。

增长即将来临

在技​​术的任何方面，安全将继续与云一起成长。企业越来越多地转向云计算，这暴露出比组织里比过去更多的安全漏洞。随着云的成熟，安全变得越来越重要。

条例也在不断完善 —— 个人身份信息（PII）越来越广泛。许多公司都发现他们必须投资安全来保持合规，避免成为头条新闻。由于面临巨额罚款，声誉受损以及行政工作安全，公司开始越来越多地为安全工具和人员安排越来越多的预算。

培训和支持

即使你不选择一个专门的安全工作，你也一定会发现自己需要写安全的代码，如果你没有这个技能，你将开始一场艰苦的战斗。如果你的公司提供在工作中学习的话也是可以的，但我建议结合培训、指导和不断的实践。如果你不使用安全技能，你将很快在快速进化的恶意攻击的复杂性中失去它们。

对于那些寻找安全工作的人来说，我的建议是找到组织中那些在工程、开发或者架构领域最为强大的人员 —— 与他们和其他团队进行交流，做好实际工作，并且确保在心里保持大局。成为你的组织中一个脱颖而出的人，一个可以写安全的代码，同时也可以考虑战略和整体基础设施健康状况的人。

游戏最后

越来越多的公司正在投资安全性，并试图填补他们的技术团队的开放角色。如果你对管理感兴趣，那么安全是值得关注的地方。执行层领导希望知道他们的公司正在按规则行事，他们的数据是安全的，并且免受破坏和损失。

明智地实施和有战略思想的安全是受到关注的。安全对高管和消费者之类至关重要 —— 我鼓励任何对安全感兴趣的人进行培训和贡献。

现在下载完整的 2017 年开源工作报告

via: https://www.linux.com/blog/os-jobs-report/2017/11/security-jobs-are-hot-get-trained-and-get-noticed

作者：BEN COLLEN 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

提要：对于开源软件来说，其许可证信息内嵌在源代码中。为了降低复杂性，您可以生成不同的视图。

您可以通过查看源代码找到开源软件的许可证信息。为了满足不同的需求，可以生成关于该许可证信息的不同视图或报告。

尽管直接在源代码中提供许可证信息并不是开源软件的必要条件，但是这样做的实际好处显而易见。由于开源许可证促进了软件的传播，与代码一起传输的许可证信息简化了管理过程，即使代码接收人通过间接方式获得代码，也可以使他随时可以获得权限声明。

什么是许可证条款？

在源码树中嵌入许可证信息的价值被低估了。让我们暂停一下，反思一下这种常见做法是多么有用。

什么是许可证条款呢？ 对于许多开源软件来说，有一个简单的答案：一个许可证文本包含整个软件的所有许可证信息。但是开源的力量在于，它推动了其他开发者在这个起点之上进行构建，而这个过程会使许可证信息复杂化。

开源软件可以被扩展、再利用，或者与其他软件结合使用。与机械设备不同，不同群体之间的合作更具挑战性，复杂软件从许多人的工作中受益是切实可行的。开源许可证提供了促进这种开发动态的权限。具有复杂历史的软件也可能具有复杂的许可证信息。

考虑下面的例子：有人写了一个新的程序，在每个源文件中包含一个版权声明，声明该软件根据 Apache 2.0 版许可证进行许可，并且在源码树的根目录中包含 Apache 许可证文本。之后，添加了一个具有不同的版权声明的文件，以及一个 BSD 2 句版许可证副本的文件。然后，添加了一个新的子目录，其中文件具有 Apache 许可证声明，但具有标识不同版权所有者的版权声明。再之后，一个 MIT 许可证的副本添加到了新的子目录中，该子目录包含了版权声明与 MIT 许可证文件中相同的文件，但没有任何其他许可证指示信息。

这个例子表明，嵌入在源码树中的许可证信息可能很复杂而且很详细。根目录和/或各个子目录中都可能有许可证文本。一些源文件可能有许可证通知；其他源文件可能不会有。也许会有版权声明来识别各种版权所有者。但是，在不丢失信息的前提下将法律文本从代码中分离出来似乎是不可能的。因此，源代码即是许可证。

从源码树的角度来看，上面例子中对许可证信息的解释是非常简单的。但是，要在简单、明确的独立声明中获取许可证信息将是一件困难的事情。截取了源代码中所有许可证信息的许可证声明会比源代码更短，但这将是不方便的——谁会希望得到如此高度详细的单独声明？大多数用户可能会更喜欢一个概要，虽然不完整，但其获取的关键点符合自己的特定意图和敏感性要求。

用视图来概括许可证信息

对于“许可证条款是什么”这个问题，用整个源码树副本来回答可能没什么用，因为它过于庞杂和分散。大多数人只想要一个概要。但这面临一个挑战：当许可证信息比较复杂时，人们需要不同的概要，因为他们对于什么是重要的有不同的定义。

对于某些人来说，对以下问题回答“是”可能是足够的：该软件 1）是否根据一个或多个开源许可证获得许可，2）其被组装和许可后是否使得其分发和使用与所有这些许可证一致？ 其他人可能需要所有许可证的列表，或者他们可能想要查看哪个软件组件对应于哪个许可证。还有一些人可能想要一个逐个组件的列表来标识任何 左版 （ copyleft ） 许可证（也许自己要做深入的左版合规研究）。 有些人可能有兴趣看到所有版权声明和软件组件的相关列表。

单一的概要可能不会满足所有人的利益。简单地将概要具体化可能会减少它对一些人的效用，而对其他人则显得不足。因此，需要将源代码中包含的许可证信息展现为不同的 “视图” （ views ） 。这里使用的“视图”术语可以视为与在数据库中使用它相似。或者，您也可以将“视图”看作是 “报告” （ reports ） 。

考虑将源代码作为许可证有一个优势，并且可以从中提取多个不同的视图。

您可能会尝试创建一个“全能”概要，从中可以创建其他较短的概要。但是以中间状态表达许可证信息至少有三个缺点：

1. 时机：主概要的维护人员可能无法按计划进行更新。
2. 版本：主概要可能基于与您使用的软件不同的版本。
3. 质量：您的视图继承了主概要的错误和评判性。

因此，根据需要直接从您使用的源码树版本生成您的首选视图是有价值的。

有工具可以生成视图。按需视图的生成取决于工具。许可证信息展示的清晰（或混乱）程度会促进（或妨碍）该工具的功效。我们不需要许可证信息的特定机器编码，但是我们应该充分利用众多经验来源，以既可以被人读取，也可以被机器提取的方式来表达信息。

Jeff Kaufman 在他的文章《开源软件许可证合规的经济高效模型》中指出：由于源代码包含许可证信息，因此分发源代码是满足某些许可证要求的有效方式。

将所有许可证信息嵌入到源码树中是最佳实践。如果您发现源码树中没有显示许可证信息，请考虑通过提交错误报告来改进该项目，建议将该信息添加到源码树中。

源代码即是许可证。从完整的记录中，可以生成许可证信息的视图。工具可以将许可证信息提取到各种报告中，以满足特定需求或敏感性要求。

为了获得这个愿景的全部好处，我们还有工作要做。您对工具状态以及许可证信息展现有什么看法呢？

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

想去写一本科技书籍是一个好的想法，但你还需要去了解一下出版业的运作过程。

你有一个写本科技书籍的想法，那么祝贺你！就像在阿巴拉契亚山脉徒步旅行，或者是去学做一种蛋奶酥，写书是人们经常讨论的话题之一，但是却都只停留在思考的初级阶段。那是可以理解的，因为失败的几率是很高的。要想实现它，你需要在把自己的想法阐述给出版商，去探讨是否已经做好充分的准备去写成一本书。要去实现这一步是相当困难的，但缺乏关于如何做这件事的信息会使事情变得复杂。

如果你想和一家传统的出版商合作，那么你需要在他们面前推销你的书稿以期望能够得到出版的机会。因为我是 Pragmatci Bookshelf 的总编，所以经常看到很多的选题，也去帮助作者制作出好的作品。这些选题中有些是好的，有些则不然，但我经常会看到许多不符合我们出版社风格的文稿。我会帮助你找到最适合的出版商，来让你的想法得到认可。

确定你的目标

你的第一步是要找出最适合你的想法的出版商。首先，想想你经常买书的以及你喜欢的出版商，你的书会被像你自己一样的人喜欢的几率是很高的，所以从你自己最喜欢的出版商开始，列出一个简短的列表将会大大缩小你的搜索范围。如果你自己所买的书籍并不多。那么可以去书店逛逛，或者在亚马逊网站上看看。 列一个你自己喜欢的几家出版商的清单出来。

下一步，筛选出你期望的出版商，尽管大多数技术类出版商看起来没什么差别，但他们通常各有不同的读者群体。有些出版商会选择广受欢迎的话题，如 C++ 或者 Java，那么你以 Elixir 为主题的书稿就可能不适合那个出版商；如果你的书稿是关于教授小孩学习编程的，那么你可能就不想让学术出版商来出版。

一旦确定了一些目标，你就可以在他们的商品目录、网站或者亚马逊上对其进行进一步的调查，去寻找有哪些书籍和你的思想是相符的。如果他们能有一本和你自己的书稿主题一样或很相近的书，那么你将很难说服他们和你签约。但那并不意味着已经可以把这样的出版商从你的列表中划掉，你可以将自己的书稿主题进行适当的修改以将它和已经发行的书区别开来：比如定位于不同的读者群体，或者不同层次的技能水平。也许已发行的那本书已经过时了，你就可以专注于该技术领域里的新方法，确保你的书稿能够弥补现有书的不足，更加完善，而不是单纯的竞争。

如果你锁定的出版商没有出版过类似的书籍，也许这将会是个好迹象，但也许是个坏迹象。有时候一些供应商不会选择去出版一些专业技术方面的书籍，或者是因为他们认为自己的读者不会感兴趣，也可能是因为他们曾经在这块领域遇到过麻烦。新的语言或者类库一直在不停地涌现出来，出版商们不得不去琢磨什么样的书籍内容将会吸引他们的读者群体。他们的评估标准可能和你的是不一样的。他们已经有了最终决定，也可能是还在等待合适的选题。判断究竟是哪一种的唯一方法就是提出文稿并找出答案。

建立起你自己的网络

确定一家出版商是第一步；现在你需要与其建立联系。不幸的是，出版需要的仍旧是你认识什么人，而不是你知道什么。你需要认识的那个人是一个去发现新市场、新作者和新选题的策划编辑。如果你认识某个和出版商有关系的人，请他给你介绍一位策划编辑。这些策划编辑往往负责一个专题板块，尤其是在较大的出版商，但你并非一定要找到符合你书稿的专题板块的编辑。各类板块的编辑通常都会很乐意将你介绍给合适的编辑。

有时候你也许能够在一个技术会议上找到一个策划编辑，特别是在出版商同时也是赞助商，而且还有一个展台时。即使当时并没有一个策划编辑在场，展台的其他工作人员也能够帮你和策划编辑建立联系。 如果会议不符合你的主题思想，那就需要你利用自己的社交网络来获得别人的推荐。比如使用 LinkedIn，或者其他非正式的联系方式，去和一个编辑建立联系。

对于小型的出版商，你可能会在公司网站上发现策划编辑的名单，如果你够幸运的话，还可以找到他们的联系信息。如果找不到联系方式的话，可以在推特上搜寻出版商的名字，试试能否找到他们的编辑的信息，在社交媒体上去寻找一位陌生的人，然后把自己的书稿推荐给他，这也许会让你有些紧张，但是你真的不必去担心这些，建立联系也是策划编辑的工作之一。最坏的结果只不过是他们忽视你而已。

一旦建立起联系，策划编辑将会协助你进行下一步。他们可能会立刻对你的书稿给予反馈，或者在他们可能想让你根据他们的指导来修改你的文章，使其变得更加充实。当你经过努力找到了一名策划编辑后，多听从他们的建议，因为他们比你更熟悉出版商的运作流程。

如果其他的方法都失败了

如果你无法联系到一名策划编辑，出版商通常会有一个 书稿盲投 proposal alias 的方式来接受投稿，通常是 proposals@[publisher].com 的格式。 查找他们网站的介绍，找到如何去发送书稿；有的出版商是有特殊的要求的。你需要遵循他们的要求，如果不这样做的话，你的书稿将会被丢弃，它不会被任何人阅读。如果你有疑问，或者不确定出版商的意图，那么你需要再尝试着去找一名编辑进一步地沟通，因为书稿并不能回答那些问题。整理他们对你的要求（一篇独立的主题文章），发给他们，然后你要做的就是期望能够得到满意的答复。

等待

无论你是如何与一个出版商取得联系的，你也得等待着。如果你已经投递了书稿，也许要过一段时间才有人去处理你的稿件，特别是在一些大公司。即使你已经找了一位策划编辑去处理你的投稿，你可能也只是他同时在处理的潜在目标之一，所以你可能不会很快得到答复。几乎所有的出版商都会在最终确认之前召开一次组委会来决定接受哪个稿件，所以即使你的书稿已经足够的优秀，并且可以出版了，你也仍然需要等待组委会开会讨论。你可能需要等待几周，甚至是一个月的时间。

几周过后，你可以和编辑再联系一下，看看他们是否需要更多的信息。在邮件中你要表现出足够的礼貌；如果他们仍然没有回复，也许是因为他们有太多的投稿需要处理，即使你不停地催促也不会让你的稿件被提前处理。一些出版商有可能永远不会回复你，也不会去发一份退稿的通知给你，但那种情况并不常见。在这种情况下你除了耐心地等待也没有别的办法，如果几个月后也没有人回复你邮件，你完全可以去接触另一个出版商或者干脆考虑自出版。

祝好运

如果你觉得这个过程看起来让你感觉有些混乱和不科学，这是很正常的。能够得到出版要在合适的时间地点，与合适的人沟通，而且还要期待他们此时有好的心情。你无法去控制这些不确定的因素，但是更好地了解行业的工作方式，以及出版商的需求，可以帮助你完善它们。

寻找一个出版商只是万里长征的第一步。你需要提炼你的思想，并创建选题，以及其他方面的考虑。在今年的 SeaGLS 上，我对整个过程做了介绍。查看视频可以获取更详细的信息。

关于作者

麦克唐纳先生现在是 Pragmatic Bookshelf 的总编。过去 20 年在技术出版领域生涯中，他是一名编辑、一名作者，偶尔还去客串演讲者或者讲师。他现在把大量的时间都用来和新作者探讨如何更好地表达出他们的想法。你可以关注他的推特@bmac\_editor。

如果这篇文章点燃你写书的热情，但又不知道如何找到合适的途径联系出版商，不如逛逛像异步社区这样的网站，按照上文的步骤尝试一下，也许能够发现新的希望。

via: https://opensource.com/article/17/12/how-find-publisher-your-book

作者：Brian MacDonald 译者：FelixYFZ 校对：wxy, 陈聪聪

本文由 LCTT 原创编译，Linux中国 荣誉推出

在我们开始谈论缺点之前，我要确定的事实是过去 3 年来，我一直是一个忠实的 UC 浏览器用户。我真的很喜欢它的下载速度，超时尚的用户界面和工具上引人注目的图标。我一开始是 Android 上的 Chrome 用户，但我在朋友的推荐下开始使用 UC。但在过去的一年左右，我看到了一些东西让我重新思考我的选择，现在我感觉我要重新回到 Chrome。

不需要的通知

我相信我不是唯一一个每几个小时内就收到这些不需要的通知的人。这些欺骗点击的文章真的很糟糕，最糟糕的部分是你每隔几个小时就会收到一次。

我试图从通知设置里关闭他们，但它们仍然以一个更低频率出现。

新闻主页

另一个不需要的部分是完全无用的。我们完全理解 UC 浏览器是免费下载，可能需要资金，但并不应该这么做。这个主页上的新闻文章是非常让人分心且不需要的。有时当你在一个专业或家庭环境中的一些诱骗点击甚至可能会导致尴尬。

而且他们甚至有这样的设置。将 UC 新闻显示打开/关闭。我也试过，猜猜看发生了什么。在下图中，左侧你可以看到我的尝试，右侧可以看到结果。

而且不止诱骗点击新闻，他们已经开始添加一些不必要的功能。所以我也列出它们。

UC 音乐

UC 浏览器在浏览器中集成了一个音乐播放器来播放音乐。它只是能用，没什么特别的东西。那为什么还要呢？有什么原因呢？谁需要浏览器中的音乐播放器？

它甚至不是在后台直接播放来自网络的音频。相反，它是一个播放离线音乐的音乐播放器。所以为什么要它？我的意思是，它甚至没有好到可以作为主要音乐播放器。即使它足够好，它也不能独立于 UC 浏览器运行。所以为什么会有人运行将他/她的浏览器只是为了使用你的音乐播放器？

快速访问栏

我已经看到平均有 90% 的用户在通知区域挂着这栏，因为它默认安装，并且它们不知道如何摆脱它。右侧的设置可以摆脱它。

但是我还是想问一下，“为什么它是默认的？”。这让大多数用户很头痛。如果我们需要它，就会去启用它。为什么要强迫用户。

总结

UC 浏览器仍然是最大的玩家之一。它提供了一个最好的体验，但是，我不知道 UC 通过在浏览中打包进将越来越多的功能并强迫用户使用它们是要证明什么。

我喜欢 UC 的速度和设计。但最近的体验导致我再次考虑我的主要浏览器。

via: https://www.theitstuff.com/biggest-problems-uc-browser

作者：Rishabh Kandari 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这是我第一次遇到无法翻译的漫画。

#! 是 Unix/Linux 里面用于指示脚本解释器的特定语法，位于脚本中的第一行，以 #! 开头，接着是该脚本的解释器，通常是 /bin/bash、/usr/bin/python 之类。

关于 #! 其英文名称为“shebang”，其中的“she” 来源于 “#”的发音 “sharp”，“bang”来源于“!”，故如此命名。

Linux 中国翻译组核心成员 GOLinux 提议将此专有名称翻译为“释伴”。

回到这幅漫画，作者的原意可能是：我！你！他！ ，以此类推，然后是她（she）！ 即 #!S。（附注：感谢万能的网友指出我没看懂的部分。）

via: http://turnoff.us/geek/shebang/

作者：Daniel Stori 点评：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出