2019年7月

Delete A Repository And GPG Key In Ubuntu

前几天我们讨论了如何在基于 RPM 和 DEB 的系统中列出已安装的仓库。今天,我们将学习如何在 Ubuntu 中删除仓库及其 GPG 密钥。对于不知道仓库的人,仓库(简称 repo)是开发人员存储软件包的地方。仓库的软件包经过全面测试,并由 Ubuntu 开发人员专门为每个版本构建。用户可以使用 Apt 包管理器在他们的 Ubuntu 系统上下载和安装这些包。Ubuntu 有四个官方仓库,即 Main、Universe、Restricted 和 Multiverse。

除了官方仓库外,还有许多由开发人员(或软件包维护人员)维护的非官方仓库。非官方仓库通常有官方仓库中不可用的包。所有包都由包维护者用一对密钥(公钥和私钥)签名。如你所知,公钥是发给用户的,私钥必须保密。每当你在源列表中添加新的仓库时,如果 Apt 包管理器想要信任新添加的仓库,你还应该添加仓库密钥(公钥)。使用仓库密钥,你可以确保从正确的人那里获得包。到这里希望你对软件仓库和仓库密钥有了一个基本的了解。现在让我们继续看看如果在 Ubuntu 系统中不再需要仓库及其密钥,那么该如何删除它。

在 Ubuntu 中删除仓库

每当使用 add-apt-repository 命令添加仓库时,它都将保存在 /etc/apt/sources.list 中。

要从 Ubuntu 及其衍生版中删除软件仓库,只需打开 /etc/apt/sources.list 文件并查找仓库名字并将其删除即可。

$ sudo nano /etc/apt/sources.list

正如你在下面的截图中看到的,我在我的 Ubuntu 系统中添加了 Oracle Virtualbox 仓库。

virtualbox 仓库

要删除此仓库,只需删除该条目即可。保存并关闭文件。

如果你已添加 PPA 仓库,请查看 /etc/apt/sources.list.d/ 目录并删除相应的条目。

或者,你可以使用 add-apt-repository 命令删除仓库。例如,我要删除 Systemback 仓库,如下所示。

$ sudo add-apt-repository -r ppa:nemh/systemback

最后,使用以下命令更新软件源列表:

$ sudo apt update

删除仓库密钥

我们使用 apt-key 命令添加仓库密钥。首先,让我们使用命令列出添加的密钥:

$ sudo apt-key list

此命令将列出所有添加的仓库密钥。

/etc/apt/trusted.gpg
--------------------
pub rsa1024 2010-10-31 [SC]
3820 03C2 C8B7 B4AB 813E 915B 14E4 9429 73C6 2A1B
uid [ unknown] Launchpad PPA for Kendek


pub rsa4096 2016-04-22 [SC]
B9F8 D658 297A F3EF C18D 5CDF A2F6 83C5 2980 AECF
uid [ unknown] Oracle Corporation (VirtualBox archive signing key) <[email protected]>
sub rsa4096 2016-04-22 [E]


/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg
------------------------------------------------------
pub rsa4096 2012-05-11 [SC]
790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32
uid [ unknown] Ubuntu Archive Automatic Signing Key (2012) <[email protected]>


/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
------------------------------------------------------
pub rsa4096 2012-05-11 [SC]
8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092
uid [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>


/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
------------------------------------------------------
pub rsa4096 2018-09-17 [SC]
F6EC B376 2474 EDA9 D21B 7022 8719 20D1 991B C93C
uid [ unknown] Ubuntu Archive Automatic Signing Key (2018) <[email protected]>

正如你在上面的输出中所看到的,那串长的(40 个字符)十六进制值是仓库密钥。如果你希望 APT 包管理器停止信任该密钥,只需使用以下命令将其删除:

$ sudo apt-key del "3820 03C2 C8B7 B4AB 813E 915B 14E4 9429 73C6 2A1B"

或者,仅指定最后 8 个字符:

$ sudo apt-key del 73C62A1B

完成!仓库密钥已被删除。运行以下命令更新仓库列表:

$ sudo apt update

资源:


via: https://www.ostechnix.com/how-to-delete-a-repository-and-gpg-key-in-ubuntu/

作者:sk 选题:lujun9972 译者:geekpi 校对:wxy

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

近日,笔者聆听了 VMware 大中华区高级技术总监李刚先生一场精彩演讲,他就企业 IT 的发展之路探讨了 VMware 企业云 2.0 的发展。

VMware 眼中的行业趋势

李刚谈到,从 VMware 的愿景可以看出整个企业 IT 正在发生的三个深刻的变化:

VMware 认为,首先,私有云演进为混合云,也就是说, 云基础架构可以自建也可以去当作服务购买,而提供给用户的是统一技术栈,统一运维管理的融合环境;其次,IT 和 CT 会融合成电信云~电信网络会形成云的形态;而边缘计算会成为一个新的基础架构形态。

从行业角度来看,也和 VMware 的愿景高度契合, VMware 称之为三波产业重大变革:

  • 第一个就是通过重构企业云,整个企业 IT 会全面转型以适应新的变化,拥抱变化创造新的机遇。当今的企业正处于从私有云和公有云阶段迈向混合云、多云的阶段,既保有了私有云的安全性,也利用到了公有云的开放性,使得企业可以以最佳成本获得业务快速发展的基础设施服务。而新的企业云,正承担着这一数字化转型的重任。
  • 第二个是云网融合,就是整个 IT 生态会以云和网络融合的形态来包容在企业的外围。在多云战略进一步深化之后,企业将协调处于多云环境中的数据、服务和应用,通过云和网络的融合,能将这些融为一体。未来,随着基础设施的进一步发展,流经多云之间的网络的流量必将占到更多的份额。
  • 第三个是拓展到边缘,边缘计算以后将会是更大的想象空间。越来越多的数据和应用将来自于边缘设备、迫切地需要在利用边缘设备的计算能力、存储能力以满足业务需求。这些迅速增长的边缘设备极大地拓展了计算的范围和领域,而它们的爆发式增长也给企业带来了更多压力和广阔的前景。

这三个变化和由此发展而来的三波浪潮,给企业计算带来全新的挑战和机遇,只有不断地变革企业云基础设施,升级企业的数字化技术,才能应对数字化转型 2.0 的进化,而这就是 VMware 重构企业云,推出企业云 2.0 的原动力。

重构企业云

VMware 认为,对于大中型企业而言,其战略方向无疑是重构企业云,通过建设新一代企业云(EnterpriseCloud 2.0),完成企业 IT 的重塑,让 IT 真正从资源供给的角色到创新平台的转变。

李刚谈到,所谓“重构企业云,实际上就是重构企业IT的核心,企业IT要做大的转型。用一句话来说,企业IT要从资源供给到创新平台。”

传统的企业,私有云的模式就是一个比较先进的企业IT模式了,但是私有云实际上关注的还是以资源为核心,而且做的主要工作就是两个:一个是资源池化,另一个是资源交付流程化和自动化。所有这些对业务来说的价值就是节省成本。对 IT 自身的价值是变得自动化简易和简单。

新一代企业云我们把它起个名字叫企业云 2.0。新一代企业云才会真正改变企业IT的形式、定位和价值。

企业云 2.0

什么是新一代企业云?李刚从四个方面阐述了这一概念:

第一,对于新一代企业云来说,它把资源转化成服务、而且是全栈式服务。所谓“全栈服务”就是说它,包括 IaaS、SaaS、PaaS 等完整的服务能力,企业IT要有能力提供各个层面的服务。这个叫全栈资源服务化

第二,从传统企业 IT 来说,用户的概念是相对比较弱的。传统企业 IT 严格意义上讲没有特别强烈的用户的概念——谁是你的用户,或者直接一点说,谁是你的云的用户?很多企业建了云,云的用户是谁?这个概念并没有得到强化。

在未来,对于企业云来说会有非常明显的用户的概念。

企业云的第一大用户就是你的业务创新团队,或研发团队。真正企业IT做的很好的,都已经大量的开始把研发从外包转向内包,甚至于能力的对外输出。第二类用户,即传统的业务线用户,当你的应用越来越丰富,也需要强化给用户提供服务的概念,而不是站在一个个单独的应用角度给用户提供服务,因为你的很多应用流程都会通过服务的方式提供出来,所以就有了所谓的应用门户的概念。这就是强化用户的概念

第三,新一代企业云里面不强调公有云、私有云,事实上,无论是公有云还是私有云都是你的资源。公有云和私有云只不过是你建设资源管理资源的一个方式和选择。至于怎么选有很多方面,比如安全性、可靠性、成本等等,此外还包括服务的种类。比如说现在公有云服务相对会比私有云多一些,有些服务在私有云上还没有建成,需要公有云提供支持。而这些都是你的资源。最重要的是,要能够融合资源,以安全可控可管理的方式为我所用。

第四个,云本身具有非常强烈的迭代发展的概念,并不像传统的数据中心建设有一期、二期那么明确的阶段性。云服务必须不断的推出、升级,要能积淀这些服务,让它能力不断的增强。

企业 IT 演进战略

谈及了企业云 2.0,就不能不提到企业IT演进战略,李刚把它分成三个方面进行了阐述:云战略、服务战略、应用战略。

所谓云战略,就是把基础架构往前推,包括私有云跟同构公有云如何在资源上做分配,原生公有云和公有云之间如何做整合,企业应用怎么上云,公有云的技术怎么导入企业 IT 等等,这是讲云的战略。

其次是服务战略,之前它的服务非常弱化,在企业云 2.0 的实际建设里,最核心的部分之一就是怎么样把这些资源变成服务,提供给开发团队,这是很重要的能力。

第三是应用战略,就是应用怎么变得敏捷、创新,从外包到内包,怎么去思考这些问题。之前在这个层面上做的很多工作都是在建设一个传统的池化资源,采用私有云的模式。而到了企业云 2.0 阶段,从应用来看就是怎么定位你的应用,哪些应用可以退出了,哪些应用可以重新放在云上,哪些应用不用理它,哪些应用重新按照新的模式做设计,你的应用开发模式要做转变。

基础架构即代码

当你开始架构你的应用的时候,同时也会规划基础架构怎么部署,而且是代码的方式进行规划和部署。在真实部署之前会做配置管理,然后采用基础架构代码的方式来管理。在每一步,当你需要基础架构提供支持的时候,它会帮你部署和调整基础架构,这里是由代码自动提供的。

这个基础架构的概念包括 IaaS、PaaS 等,包括各种各样的服务。通过在企业内部实现企业云 2.0,知道企业内部有哪些资源可供被调用,然后把来自不同云的、包括私有云的这些服务组装成企业所需要的基础架构的元配件,再用代码的方式编写成应用所需要的基础架构描述,然后,研发团队会自动的调用这些代码生成基础架构。一个真正的应用,比如 VMware公司 内部在做的云管产品的应用,每天会做几十次的持续集成、自动化测试和持续交付,整个的迭代速度非常快,发现错误的速度也非常快,整个开发的进度就是之前十几倍、几十倍的提升。

这里有个非常核心的部分,第一个,你会发现它充分体现了应用驱动,应用在驱动整个基础架构在变动。第二点,这些如果不是软件定义的,不是真正可以代码化的,应用根本没法驱动,它需要完全高度代码化,然后就可以通过应用驱动转起来了。所以,在软件定义之上,有了应用驱动,使得价值充分发挥出来,IT基础架构变得高度灵活。

与 Intel 携手

而李刚先生在演讲中也提及,VMware 行业领先的云计算技术和 Intel® 技术可以帮助客户充分利用混合云,并连接和管理本地部署与远程部署的工作负载,从而提高敏捷性、容量、透明度、可见性和恢复能力。

借助一系列私有云、公有云和混合云解决方案,企业可以随心所欲地实施支持其云计算战略的云计算解决方案,以推动其独特业务的发展。他们既可以自由选择,又能保持可控力。

云的未来

早在 2015 年时,VMware 发布的企业愿景“一云承万象”,其核心是通过软件定义的基础设施,在一体化的混合云平台上,支持任何类型的应用和对不同类型的终端平台做交付服务。如今, VMware 的这一愿景得到了再次升华,在迎合新的变化的同时,深耕于企业云计算领域,也将自身转化为了一家“数字技术基础设施”供应商。而新的企业云 2.0 也正是这家软件巨头向未来迈出的坚实一步。

系统管理员和网站可靠性工程师(SRE,下同)对于任何组织来讲都很重要。本篇将介绍下两者的不同之处。

在 IT 行业,成为多面手或是专家的争议一直存在。99% 的传统系统管理员都被归到了多面手这类。 网站可靠性工程师 site reliability engineer (SRE)的角色则更加专精,并且在如 Google 般有着一定规模的头部公司中对其的需求不断增加。但总的来说这两者对于跑着应用的基础设施有着同样的目标:为应用的消费者提供良好的体验。然而两者的出发点却截然不同。

系统管理员:中立善良的化身

系统管理员一般都是从基础的桌面或网络支持成长过来的,并一路习得大多数系统管理员都会掌握的广泛的技能。此时这些系统管理员会对他们所负责的系统和应用了如指掌。他们会知道一号服务器上的应用每隔一个星期二就需要重启一次,或是九号服务器周三会静默的崩溃。他们会对服务器的监视作出微调以忽略无关紧要的信息,尽管那个被标记为 致命 fatal 的错误信息每个月第三个周日都会显示。

总的来讲,系统管理员了解如何照料那些跑着你核心业务的服务器。这些系统管理员已经成长到开始使用自动化工具去处理所有归他们管的服务器上的例行任务。他们虽然喜欢使用模板、 黄金镜像 golden images 、以及标准,但同时也有着足够的灵活度去修改一个服务器上的参数以解决错误,并注释为什么那个服务器的配置与众不同。

尽管系统管理员很伟大,但他们也有着一些怪癖。其中一项就是没有他们神圣的授权你永远也获取不了系统的 root 访问权限,另一项则是任何不是出于他们的主意的变更都要在文档中被记录为应用提供方的要求,并仍然需要再次核对。

他们所管理的服务器是他们的地盘,没有人可以随意干涉。

SRE:灭霸将为之自豪

与成为系统管理员的道路相反,从开发背景和从系统管理员背景成长为 SRE 的可能性相近。SRE 的职位出现的时长与应用开发环境的生命周期相近。

随着一个组织的发展而引入的类似于持续集成持续发布 (CI/CD) 的 DevOps 概念,通常会出现技能空缺,以让这些 不可变 immutable 的应用部署到多个环境并随着业务需求进行扩展。这将是 SRE 的舞台。的确,一个系统管理员可以学习额外的工具,但大体上成为一个全职的职位更容易跟的上发展。一个专精的专家更有意义。

SRE 使用如 代码即基础设施 infrastructure-as-code 的概念去制作模板,然后调用它们来部署用以运行应用的环境,并以使用一键完整重现每个应用和它们的环境作为目标。因此会出现这样的情况:测试环境中一号服务器里的一号应用的二进制文件与生产环境中十五号服务器的完全一致,仅环境相关的变量如密码和数据库链接字串有所不同。

SRE 也会在配置发生改变时完全销毁一个环境并重新构建它。对于任何系统他们都不带一点感情。每个系统只是个被打了标记和安排了生命周期的数字而已,甚至连例行的对服务器打补丁也要重新部署整个 应用栈 application stack

总结

对于一些情况,尤其是运维一些大型的基于 DevOps 的环境时,一个 SRE 所能提供的用于处理各种规模的业务的专业技能当然更具优势。但每次他们在运气不好走入死胡同时都会去寻求他的系统管理员友人或是 来自地狱的混蛋运维(BOFH) ,得到他那身经百战的故障排除技能,和那些用于给组织提供价值的丰富经验的帮助。


via: https://opensource.com/article/19/7/sysadmins-vs-sres

作者:Vince Power 选题:lujun9972 译者:vizv 校对:wxy

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

要在 Ubuntu LTS 上获得的最新 Nvidia 驱动程序,你不必再使用 PPA 了。最新的驱动程序现在将在 Ubuntu LTS 版本的存储库中提供。

你可能已经注意到在 Ubuntu 上安装最新和最好的 Nvidia 二进制驱动程序更新的麻烦。

默认情况下,Ubuntu 提供开源的 Nvidia Nouveau 驱动程序,这有时会导致 Ubuntu 卡在启动屏幕上。

你也可以轻松地在 Ubuntu 中安装专有的 Nvidia 驱动程序。问题是默认 Ubuntu 存储库中的 Nvidia 驱动程序不是最新的。为此,几年前 Ubuntu 引入了一个专门的 PPA以解决这个问题。

使用官方 PPA 仍然是安装闭源图形驱动程序的一个不错的解决方法。但是,它绝对不是最方便的选择。

但是,现在,Ubuntu 同意将最新的 Nvidia 驱动程序更新作为 SRU(StableReleaseUpdates)的一部分提供。所以,你将在使用 Ubuntu LTS 版本时也拥有 Nvidia 驱动程序了。

好吧,这意味着你不再需要在 Ubuntu LTS 版本上单独下载/安装 Nvidia 图形驱动程序。

就像你会获得浏览器或核心操作系统更新(或安全更新)的更新包一样,你将获得所需的 Nvidia 二进制驱动程序的更新包。

这个最新的 Nvidia 显卡驱动程序可靠吗?

SRU 字面上指的是 Ubuntu(或基于 Ubuntu 的发行版)的稳定更新。因此,要获得最新的图形驱动程序,你应该等待它作为稳定更新释出,而不是选择预先发布的更新程序。

当然,没有人能保证它能在所有时间内都正常工作 —— 但安装起来比预先发布的更安全。

怎样获得最新的 Nvidia 驱动程序?

Software Updates Nvidia

你只需从软件更新选项中的其他驱动程序部分启用“使用 NVIDIA 驱动程序元数据包……”。

最初,The Linux Experiment 通过视频分享了这个消息 —— 然后 Ubuntu 的官方 Twitter 作为公告重新推送了它。你可以观看下面的视频以获取更多详细信息:

支持哪些 Ubuntu LTS 版本?

目前,Ubuntu 18.04 LTS 已经可用了,它也将很快在 Ubuntu 16.04 LTS 上可用(随后的 LTS 也将次第跟上)。

总结

现在你可以安装最新的 Nvidia 二进制驱动程序更新了,你认为这有何帮助?

如果你已经测试了预先发布的软件包,请在下面的评论中告诉我们你对此的看法。


via: https://itsfoss.com/ubuntu-lts-latest-nvidia-drivers/

作者:Ankush Das 选题:lujun9972 译者:wxy 校对:wxy

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

使用 Scribus 的 Python 脚本编写器功能,开发一个显示 RGB 色谱的 3D 立方体。

 title=

当我决定这个夏天要玩色彩游戏时,我想到通常色彩都是在色轮上描绘的。这些色彩通常都是使用色素而不是光,并且你失去了任何对颜色亮度或光度变化的感觉。

作为色轮的替代,我想在立方体表面使用一系列图形来显示 RGB 频谱。色彩的 RGB 值将在具有 X、Y、Z 轴的三维图形上展示。例如,一个平面将会保持 B(蓝色)为 0,其余的坐标轴将显示当我将 R(红色)和 G (绿色)的值从 0 绘制到 255 时发生的情况。

事实证明,使用 Scribus 及其 Python 脚本编写器 功能实现这一点并不困难。我可以创建 RGB 颜色,使矩形显示颜色,并以 2D 格式排列它们。我决定设置颜色值的间隔为 5,并让矩形按 5 个点(pt)进行绘图。因此,对于每个 2D 图形,我将使用大约 250 种颜色,立方体的一个边有 250 个点(pt),也就是 3.5 英寸。

我使用下面这段 Python 代码完成了绿 - 红图的任务:

x = 300
y = 300
r = 0
g = 0
b = 0

if scribus.newDoc(scribus.PAPER_LETTER, (0,0,0,0),scribus.PORTRAIT, 1,                  scribus.UNIT_POINTS, scribus.NOFACINGPAGES, scribus.FIRSTPAGERIGHT):
    while r < 256:
        while g < 256:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '0_0_0':
                newcolor = 'Black'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + g, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            g = g + 5
        g = 0
        r = r + 5
        y = y – 5

这个脚本在 300,300 位置开始绘制图形,这个位置大约是一个美国信件大小的纸张的水平中心,大概是垂直方向从顶部到底的三分之一位置;这是图像的原点,然后它沿着 X 轴(绿色值)水平构建图形,然后返回到 Y 轴,向上移动 5 个点,然后绘制下一条矩形线。

 title=

这看起来很简单;我只需要调整一下数字就可以把立方体的另一面画出来。但这不仅仅是再画两个图,一个是蓝 - 绿色,另一个是红 - 蓝色的问题。我想创建一个展开的立方体,这样我就可以打印、剪开然后折叠它,创建一个 RGB 的 3D 视图。因此,下一部分(向下的页面)的原点(黑色的角落)需要在左上角,其水平方向是绿色,垂直方向是蓝色。

“调整数字”最终或多或少变成了试错,从而得到我想要的东西。在创建了第二个图之后,我需要第三个图,它是红 - 蓝色的,原点位于左上角,红色向左递增,蓝色向下递增。

下面是最终效果图:

 title=

当然,这只是这个立方体的前半部分。我需要做一个类似的形状,除了原点应该是白色(而不是黑色)来表示高值。这是我希望自己更聪明的时候之一,因为我不仅需要做出一个类似的整体形状,还需要以镜像的方式与第一个形状交互(我认为)。有时候,尝试和错误是你唯一的朋友。

结果是这样的;我使用了一个单独的脚本,因为在一个美国信件大小的页面上没有足够的空间同时容纳这两个图案。

 title=

现在,是时候轮到打印机了!在这里,你可以直观了解彩色打印机如何处理 RGB 颜色到 CMYK 颜色的转换以及打印颜色密集空间。

接下来,朋友们,是剪切粘贴时间!我可以用胶带,但我不想改变表面的外观,所以我在切割的时候在两边留下了一些空间,这样我就可以把它们粘在里面了。根据我的经验,在复印纸上打印会产生一些不需要的皱纹,所以在我的复印纸原型完成后,我把立方体打印在了更厚的纸上,表面是哑光的。

 title=

请记住,这只是 RGB 空间边界的一个视图;更准确地说,你必须做出一个可以在中间切片的实心立方体。例如,这是一个实心 RGB 立方体在蓝色 = 120 的切片。

 title=

最后,我做这个项目很开心。如果您也想参与其中,这里有两个脚本。

这是前半部分:

#!/usr/bin/env python
# black2rgb.py
"""
Creates one-half of RGB cube with Black at origin
"""

import scribus

x = 300
y = 300
r = 0
g = 0
b = 0

if scribus.newDoc(scribus.PAPER_LETTER, (0,0,0,0),scribus.PORTRAIT, 1, scribus.UNIT_POINTS, scribus.NOFACINGPAGES, scribus.FIRSTPAGERIGHT):
    while r < 256:
        while g < 256:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '0_0_0':
                newcolor = 'Black'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + g, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            g = g + 5
        g = 0
        r = r + 5
        y = y - 5
       
    r = 0
    g = 0
    y = 305

    while b < 256:
        while g < 256:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '0_0_0':
                newcolor = 'Black'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + g, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            g = g + 5
        g = 0
        b = b + 5
        y = y + 5
       
    r = 255
    g = 0
    y = 305
    x = 39
    b = 0

    while b < 256:
        while r >= 0:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '0_0_0':
                newcolor = 'Black'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            r = r - 5
            x = x+5
        b = b + 5
        x = 39.5
        r = 255
        y = y + 5
       
scribus.setRedraw(True)
scribus.redrawAll()

后半部分:

#!/usr/bin/env python
# white2rgb.py
"""
Creates one-half of RGB cube with White at origin
"""

import scribus

x = 300
y = 300
r = 255
g = 255
b = 255

if scribus.newDoc(scribus.PAPER_LETTER, (0,0,0,0),scribus.PORTRAIT, 1, scribus.UNIT_POINTS, scribus.NOFACINGPAGES, scribus.FIRSTPAGERIGHT):
    while g >= 0:
        while r >= 0:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '255_255_255':
                newcolor = 'White'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + 255 - r, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            r = r - 5
        r = 255
        g = g - 5
        y = y - 5
       
    r = 255
    g = 255
    y = 305

    while b >= 0:
        while r >= 0:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '255_255_255':
                newcolor = 'White'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + 255 - r, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            r = r - 5
        r = 255
        b = b - 5
        y = y + 5
       
    r = 255
    g = 0
    y = 305
    x = 39
    b = 255

    while b >= 0:
        while g < 256:
            newcolor = str(r) + '_' + str(g) + '_' + str(b)
            if newcolor == '255_255_255':
                newcolor = 'White'
            scribus.defineColorRGB(newcolor,r, g, b)
            rect = scribus.createRect(x + g, y, 5, 5)
            scribus.setFillColor(newcolor, rect)
            scribus.setLineColor(newcolor, rect)
            g = g + 5
        g = 0
        b = b - 5
        y = y + 5
       
scribus.setRedraw(True)
scribus.redrawAll()

由于我创建了大量的颜色,所以当看到 Scribus 文件比我用它创建的 PDF 文件大得多的时候,我并不感到惊讶。例如,我的 Scribus SLA 文件是 3.0MB,而从中生成的 PDF 只有 70KB。


via: https://opensource.com/article/19/7/rgb-cube-python-scribus

作者:Greg Pittman 选题:lujun9972 译者:zianglei 校对:wxy

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

创新是一种混乱的过程,但是关于创新的故事却很有条理。我们不应该把两者搞混了。

如果说 传统的规划方法已经消亡了,为什么这么多机构还在孜孜不倦地运用那些针对工业革命所设计的规划方法呢?

其中的一个原因是,我们错误地认为创新是可以通过结构化的、线性的过程实现的。我觉得这样做是在混淆关于创新的 故事 和创新这个 过程 本身 —— 两者是截然不同的东西。

创新的过程是混乱和不可预测的,并不遵循井然有序的时间线。过程中充满了重复迭代、突然的改变方向、各式各样的启动和终止、死胡同、失败(但愿是有用的失败),以及很多不可知的变量。创新是混乱的。

但是关于创新的故事却让事情显得很简单,从讲述伟大发明的书籍和文章,到我们(简化了整个过程之后)讲述自己在工作上的成功都是这样。想想你在社交媒体上读的帖子里,有多少都只写了最好的、最愉快的部分吧。

好故事就是这样。我们把一些原本分散的时间点干净利落地整理到一起,有开头、有发展、也有结尾。尽管我们一路上经历了很多没有把握、恐慌、甚至是绝望的时刻,在故事里这些坎坷却都被抹平了,让事情看起来像是从一开始就注定是成功的。

我们不应该把混乱的过程和简化了的故事搞混。否则,我们会错误地认为可以使用在简单线性过程中所使用的同样的方法迎接创新的挑战。换句话说,我们将适用于一种类型的活动(比较偏死记硬背、机械和规则性的任务)的管理技术应用在了并不适用的另一种类型的活动(更加有创造性的、非线性的工作,需要自主性和试验)上。

一个创新的故事

下面这个故事可以很好地说明这一点。这是我 最喜欢举的例子 之一。

在 1970 年代,英国的摩托车行业怎么也想不明白为什么他们在美国的市场份额急剧下降,而本田公司的市场份额却急速攀升。他们雇佣了波士顿咨询公司(刚好是我之前的雇主)帮助他们找出问题所在。波士顿咨询搜集了一些历史数据,回看了二十年的历史事件,总结出了一个井井有条的、线性的故事,可以很好地解释本田公司的成功。

波士顿咨询的结论是,本田公司使用了一个巧妙的策略:通过一种可以以更低价格销售的偏小型摩托车进入美国市场,并且借助于他们在日本本土市场发展出来的规模经济,在美国市场使用低价策略发展市场份额,然后等到需求进一步增长的时候,再利用更大的规模经济发展他们在美国的市场份额。在所有人的眼中,本田公司都表现得非常出色,不仅发挥了自己的优势,还非常透彻和精准地理解了新的目标顾客:美国消费者。他们智胜一筹,通过一个执行得很好的计划占领了先机,胜过了竞争对手们。

这个故事 听上去 很厉害,但是实际情况没有这么简单。

没错,本田公司 确实 是想进入美国摩托车市场。他们最初是想 效仿在美国的竞争对手,也制造美国人似乎更喜欢的大型摩托车。但是大型摩托车并不是本田公司的强项,他们生产的大型摩托车存在可靠性上的问题。更糟的是,他们的产品和市面上的其它产品没有什么差别,所以并不能脱颖而出。简单来说,他们的产品销售额表现平平。

但是在一次奇妙的巧合里,本田公司出访美国的日本代表们带了几辆自己开的摩托车。这些摩托车和本田公司试图在美国市场上销售的摩托车完全不同,它们更为小巧灵活、不那么笨重、更有效率,并且一般来说也更便宜。西尔斯公司(LCTT 译注:美国零售业巨头)注意到了这些小巧的摩托车,并且和日本代表达成了一项协议,让西尔斯公司可以在他们在美国的商店里出售这种被称为“超级幼兽”的新型摩托车。

剩下的故事已经载入史册。超级幼兽成为了 史上最畅销的机动车,并且本田公司 至今仍然在生产超级幼兽

事后看来,将超级幼兽带到美国的一连串事件似乎很有逻辑,近乎无聊了。但是本田公司的成功和“巧妙的计划”没有什么关系,而更应该归功于一些(大多数人不愿意承认的)机缘巧合。

开放(并且混乱的)创新

机构(特别是领导们)喜欢把成功说成是一件计划之内的事情 —— 好像成功人士可以驾驭混乱,并且几乎可以预测未来。但是这些言论都是事后诸葛亮罢了,他们在讲述自己充满偶然性的经历的时候会刻意将无序的事情整理一番,对于毫无确定性的事情也会说“我们就是想要那么做的”。

但是正如我前面说的,我们不应该相信这些故事是创新过程的真实还原,也不应该在这种错误的假设的基础之上去构建未来的方案或者实验。

试想有另一家摩托车制造商想要复制本田公司在超级幼兽上的成功,就逐字逐句地照搬波士顿咨询总结的故事。由于本田公司成功的 故事 听上去是如此有逻辑,并且是线性的,这家新公司也许会假定他们可以通过类似的程序得到同样的结果:制定目标、谋划行动,然后针对可预期的结果进行执行。但是我们知道本田公司并不是真的靠这种“制定、谋划、执行”的方式赢得他们的市场份额的。他们是通过灵活性和一点运气获得成功的 —— 更像是“尝试、学习、修改”。

当我们可以真正理解并且接受“创新过程是混乱的”这个事实的时候,我们就可以换种方式思考如何让我们的机构实现创新了。与其将资源浪费在预先制定的计划上,强迫 创新以一种线性时间线的方式发生,我们不如去构建一些开放并且敏捷的机构,可以 在创新发生的时候做出及时的响应

几年前红帽公司发布一个包含了重大技术升级的产品的新版本的时候,我就看到了这样的方法。红帽企业级 Linux 5.4 版本 首次完全支持了一种被称为基于内核的虚拟机(KVM)的技术。这对于我们来说是一个重大的创新,不仅可以为顾客和合作伙伴带来巨大的价值,也有望为开源社区带来巨大的价值。

这项技术正在快速演进。幸运的事,因为我们是一个开放的机构,我们具有足够的适应能力,可以在这项创新发生的时候做出响应,从而帮助我们的顾客和合作伙伴可以更好地利用它。这项技术太重要了,并且竞争格局也太不稳定了,以至于我们没有理由要等到像 6.0 版本这样的里程碑时刻才出手。

如果你回看红帽企业级 Linux 已经存档的发行说明,你会发现它读起来并不像一个典型的软件创新的故事。一次改变游戏规则的进展突然出现在一个没有预测到的、并不起眼的时刻(5.4 版本),而不是一个事先计划好的重要里程碑时刻(6.0 版本)。事后看来,我们现在知道 KVM 这种“大爆炸”级别的进步是足够担得起 “6.0 版本”这样的里程碑式的名字的。但是创新并不是按照这样的剧本发生的。

不要误解我,机构仍然需要保持出色的运转,高效完成执行性的任务。但是 不同的挑战需要不同的方法去应对,我们需要能够更好地建立灵活的机构,以及对 意想不到和不可知的事情 能够做出更好的响应。

一个在计划工作(以及按照计划执行)上做得很出色的公司很可能会得到他们计划要得到的结果。但是如果成功还取决于我们没有预测或者无法预测的的事情,那么仅仅精准地按照计划执行是不是就不够了?


via: https://opensource.com/open-organization/19/6/innovation-delusion

作者:Jim Whitehurst 选题:lujun9972 译者:chen-ni 校对:wxy

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