document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/LCTT/TranslateProject into translating

Browse Source
This commit is contained in:
geekpi 2023-01-18 08:59:38 +08:00
commit b1ec187747
6 changed files with 325 additions and 323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
published/20230111.0 ⭐️⭐️ Linux is All Set to Disable Microsoft's RNDIS Drivers.md Normal file
View File

@ -0,0 +1,77 @@
[#]: subject: "Linux is All Set to Disable Microsoft's RNDIS Drivers"
[#]: via: "https://news.itsfoss.com/linux-disable-microsoft-rndis/"
[#]: author: "Sourav Rudra https://news.itsfoss.com/author/sourav/"
[#]: collector: "lkxed"
[#]: translator: "wxy"
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-15452-1.html"
Linux 已准备好禁用微软的 RNDIS 驱动程序，但是……
======
> Linux 内核将不再支持 RNDIS 驱动程序。这是一个好的举措吗？这对你意味着什么？在这里了解一下。
![Linux 已经准备好禁用微软的 RNDIS 驱动程序][1]
微软的 RNDIS 协议（即 <ruby>远程网络驱动接口规范<rt>Remote Network Driver Interface Specification</rt></ruby> 的简称），是一个专有的 USB 协议，用于计算机上的虚拟以太网功能。
这方面最常见的使用情况是通过连接到电脑上的 USB，使用手机的移动网络连接互联网，也称为 <ruby>[系连][2]<rt>Tethering</rt></ruby>。
尽管它主要在 Windows 上工作，但它成为 Linux 内核的一部分已经有一段时间了。
但这种情况很快就会改变。
### 向 RNDIS 协议说再见？
![][3]
**发生了什么？** 周一，[Greg Kroah-Hartman][4] 创建了 [usb.git rndis-removal][5] 分支，其中他提到禁用 Linux 上所有 RNDIS 协议驱动程序的实现。
在该提交中他提到：
> 微软的 RNDIS 协议按照设计是不安全的，在任何连接不信任的主机或设备的系统上使用它都是脆弱的。因为该协议不可能变得安全，所以只要禁用所有的 RNDIS 驱动，就可以防止任何人再使用它们。Windows 只在 XP 和更新一些的系统中需要用它，比这更早的 Windows 系统可以使用正常的 USB 类协议来代替，没有这些问题。
正如最初由 [Phoronix][6] 报道的那样，一旦这个协议在 Kconfig 选项中被标记为 “损坏”，它将再保留一段时间，最终从内核中删除。
但是**为什么呢？**
众所周知，RNDIS 在 Windows 之外的平台上的实现是一团糟，并带来了相当多的安全风险。此外，RNDIS 并不像以前那样广泛使用了，它带来的安全风险可能是作出这一决定的主要原因之一。
**这对目前的用户有影响吗？你应该担心吗？**
如果我们看一下对这一即将到来的变化的 [Reddit 讨论][7]，我们会发现许多用户仍然很担心**这是否会破坏大家的 USB 连接**。
考虑到许多安卓手机仍然使用 RNDIS 而不是 CDC NCM（一种较新的协议），用户似乎对这一举措感到困惑 😕；不只是用户，一位 [谷歌的内核网络开发人员][8] 也提出了这个议题，但我们还没有看到对此的回应。
**但不是每个人都使用主线 Linux 内核？如果你不想受到这种变化的影响，你是否应该坚持使用 LTS 版本的内核？**
此外，用户希望更清楚地了解这是否会影响到所有人。
但是，从目前来看，Greg 可能并没有给出更多的细节来说服一些相关用户。
🤔 当然，我们不是 Linux 内核维护者。所以，最好等这个提交通过时，我希望 Linux 内核维护者能比我们知道更多的信息。
💭 你对这个计划中的 Linux 内核的变化有什么看法？请在下面的评论中分享你的想法。
--------------------------------------------------------------------------------
via: https://news.itsfoss.com/linux-disable-microsoft-rndis/
作者：[Sourav Rudra][a]
选题：[lkxed][b]
译者：[wxy](https://github.com/wxy)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://news.itsfoss.com/author/sourav/
[b]: https://github.com/lkxed
[1]: https://news.itsfoss.com/content/images/size/w2000/2023/01/linux-to-disable-ms-network-drivers.png
[2]: https://en.wikipedia.org/wiki/Tethering
[3]: https://news.itsfoss.com/content/images/2023/01/kernel-patch-rndis.jpg
[4]: https://twitter.com/gregkh
[5]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=rndis-removal&id=5eb127bb9741c1480aff95ffa4e1bd4cd9b5b16d
[6]: https://www.phoronix.com/news/Linux-Disabling-RNDIS-Drivers
[7]: https://www.reddit.com/r/linux/comments/108avzx/linux_preparing_to_disable_drivers_for_microsofts/
[8]: https://lkml.org/lkml/2022/11/23/1502

77
sources/news/20230111.0 ⭐️⭐️ Linux is All Set to Disable Microsoft's RNDIS Drivers.md
View File

@ -1,77 +0,0 @@
[#]: subject: "Linux is All Set to Disable Microsoft's RNDIS Drivers"
[#]: via: "https://news.itsfoss.com/linux-disable-microsoft-rndis/"
[#]: author: "Sourav Rudra https://news.itsfoss.com/author/sourav/"
[#]: collector: "lkxed"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
Linux is All Set to Disable Microsoft's RNDIS Drivers
======
The Linux Kernel will no longer support RNDIS drivers. A good move? What does this mean for you? Find out here.
![Linux is All Set to Disable Microsoft's RNDIS Drivers][1]
Microsoft's RNDIS protocol, short for Remote Network Driver Interface Specification, is a proprietary USB protocol for virtual Ethernet functionality on computers.
The most common use case of this would be using your phone's mobile network to connect to the internet on your computer via USB, also known as [Tethering][2].
Even though it mainly works on Windows, it has been part of the Linux kernel for a while now.
But that is set to change soon.
### Say Goodbye to RNDIS Protocol?
![][3]
**What is happening?:** On Monday, [Greg Kroah-Hartman][4] created the [usb.git rndis-removal][5] branch, where he mentions disabling the implementation of all RNDIS protocol drivers on Linux.
With the commit, he mentions:
> The Microsoft RNDIS protocol is, as designed, insecure and vulnerable onany system that uses it with untrusted hosts or devices. Because theprotocol is impossible to make secure, just disable all rndis drivers toprevent anyone from using them again.Windows only needed this for XP and newer systems, Windows systems older than that can use the normal USB class protocols instead, which do not have these problems.Android has had this disabled for many years so there should not be anyreal systems that still need this.
As initially reported by [Phoronix][6], once this protocol is marked 'BROKEN' in the Kconfig option, it will stay there for a while and ultimately be removed from the kernel.
But **why?**
The implementation of RNDIS is known to be a mess on platforms apart from Windows and poses quite a few security risks. In addition, RNDIS is not being used as widely as before, and the security risks it presents might be one of the main reasons for this decision.
**Does this have an impact on current users? Should you be worried?**
If we look at a [Reddit thread][7] discussing this upcoming change, we would see that many users remain curious **if this would break USB tethering for everyone.**
Users seem confused about this move, considering many Android phones still use RNDIS instead of CDC NCM (a newer protocol) 😕 Not just users; a [Kernel Networking Developer at Google][8] also flagged this issue, but we do not see a response to that yet.
**But not everyone uses mainline Linux Kernel? Should you stick to an LTS version of the kernel if you do not want to be impacted by this change?**
Furthermore, users wanted more clarity on how this does not impact everyone.
But, as of now, **Greg** may not have mentioned a lot of details to convince some of the concerned users.
🤔 Of course, we aren't Linux Kernel maintainers. So, it is best to wait until this commit gets through, and I hope that the Linux Kernel maintainers shed more light on it than we already know.
💭 _What are your thoughts on this planned change for the Linux Kernel? Share your thoughts in the comments down below._
--------------------------------------------------------------------------------
via: https://news.itsfoss.com/linux-disable-microsoft-rndis/
作者：[Sourav Rudra][a]
选题：[lkxed][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://news.itsfoss.com/author/sourav/
[b]: https://github.com/lkxed
[1]: https://news.itsfoss.com/content/images/size/w2000/2023/01/linux-to-disable-ms-network-drivers.png
[2]: https://en.wikipedia.org/wiki/Tethering
[3]: https://news.itsfoss.com/content/images/2023/01/kernel-patch-rndis.jpg
[4]: https://twitter.com/gregkh
[5]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=rndis-removal&id=5eb127bb9741c1480aff95ffa4e1bd4cd9b5b16d
[6]: https://www.phoronix.com/news/Linux-Disabling-RNDIS-Drivers
[7]: https://www.reddit.com/r/linux/comments/108avzx/linux_preparing_to_disable_drivers_for_microsofts/
[8]: https://lkml.org/lkml/2022/11/23/1502

145
sources/talk/20190331 Codecademy vs. The BBC Micro.md
View File

@ -1,145 +0,0 @@
[#]: subject: "Codecademy vs. The BBC Micro"
[#]: via: "https://twobithistory.org/2019/03/31/bbc-micro.html"
[#]: author: "Two-Bit History https://twobithistory.org"
[#]: collector: "lujun9972"
[#]: translator: "CanYellow"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
Codecademy vs. The BBC Micro
======
In the late 1970s, the computer, which for decades had been a mysterious, hulking machine that only did the bidding of corporate overlords, suddenly became something the average person could buy and take home. An enthusiastic minority saw how great this was and rushed to get a computer of their own. For many more people, the arrival of the microcomputer triggered helpless anxiety about the future. An ad from a magazine at the time promised that a home computer would “give your child an unfair advantage in school.” It showed a boy in a smart blazer and tie eagerly raising his hand to answer a question, while behind him his dim-witted classmates look on sullenly. The ad and others like it implied that the world was changing quickly and, if you did not immediately learn how to use one of these intimidating new devices, you and your family would be left behind.
In the UK, this anxiety metastasized into concern at the highest levels of government about the competitiveness of the nation. The 1970s had been, on the whole, an underwhelming decade for Great Britain. Both inflation and unemployment had been high. Meanwhile, a series of strikes put London through blackout after blackout. A government report from 1979 fretted that a failure to keep up with trends in computing technology would “add another factor to our poor industrial performance.”[1][1] The country already seemed to be behind in the computing arena—all the great computer companies were American, while integrated circuits were being assembled in Japan and Taiwan.
In an audacious move, the BBC, a public service broadcaster funded by the government, decided that it would solve Britain’s national competitiveness problems by helping Britons everywhere overcome their aversion to computers. It launched the _Computer Literacy Project_, a multi-pronged educational effort that involved several TV series, a few books, a network of support groups, and a specially built microcomputer known as the BBC Micro. The project was so successful that, by 1983, an editor for BYTE Magazine wrote, “compared to the US, proportionally more of Britain’s population is interested in microcomputers.”[2][2] The editor marveled that there were more people at the Fifth Personal Computer World Show in the UK than had been to that year’s West Coast Computer Faire. Over a sixth of Great Britain watched an episode in the first series produced for the _Computer Literacy Project_ and 1.5 million BBC Micros were ultimately sold.[3][3]
[An archive][4] containing every TV series produced and all the materials published for the _Computer Literacy Project_ was put on the web last year. I’ve had a huge amount of fun watching the TV series and trying to imagine what it would have been like to learn about computing in the early 1980s. But what’s turned out to be more interesting is how computing was _taught_. Today, we still worry about technology leaving people behind. Wealthy tech entrepreneurs and governments spend lots of money trying to teach kids “to code.” We have websites like Codecademy that make use of new technologies to teach coding interactively. One would assume that this approach is more effective than a goofy ’80s TV series. But is it?
### The Computer Literacy Project
The microcomputer revolution began in 1975 with the release of [the Altair 8800][5]. Only two years later, the Apple II, TRS-80, and Commodore PET had all been released. Sales of the new computers exploded. In 1978, the BBC explored the dramatic societal changes these new machines were sure to bring in a documentary called “Now the Chips Are Down.”
The documentary was alarming. Within the first five minutes, the narrator explains that microelectronics will “totally revolutionize our way of life.” As eerie synthesizer music plays, and green pulses of electricity dance around a magnified microprocessor on screen, the narrator argues that the new chips are why “Japan is abandoning its ship building, and why our children will grow up without jobs to go to.” The documentary goes on to explore how robots are being used to automate car assembly and how the European watch industry has lost out to digital watch manufacturers in the United States. It castigates the British government for not doing more to prepare the country for a future of mass unemployment.
The documentary was supposedly shown to the British Cabinet.[4][6] Several government agencies, including the Department of Industry and the Manpower Services Commission, became interested in trying to raise awareness about computers among the British public. The Manpower Services Commission provided funds for a team from the BBC’s education division to travel to Japan, the United States, and other countries on a fact-finding trip. This research team produced a report that cataloged the ways in which microelectronics would indeed mean major changes for industrial manufacturing, labor relations, and office work. In late 1979, it was decided that the BBC should make a ten-part TV series that would help regular Britons “learn how to use and control computers and not feel dominated by them.”[5][7] The project eventually became a multimedia endeavor similar to the _Adult Literacy Project_, an earlier BBC undertaking involving both a TV series and supplemental courses that helped two million people improve their reading.
The producers behind the _Computer Literacy Project_ were keen for the TV series to feature “hands-on” examples that viewers could try on their own if they had a microcomputer at home. These examples would have to be in BASIC, since that was the language (really the entire shell) used on almost all microcomputers. But the producers faced a thorny problem: Microcomputer manufacturers all had their own dialects of BASIC, so no matter which dialect they picked, they would inevitably alienate some large fraction of their audience. The only real solution was to create a new BASIC—BBC BASIC—and a microcomputer to go along with it. Members of the British public would be able to buy the new microcomputer and follow along without worrying about differences in software or hardware.
The TV producers and presenters at the BBC were not capable of building a microcomputer on their own. So they put together a specification for the computer they had in mind and invited British microcomputer companies to propose a new machine that met the requirements. The specification called for a relatively powerful computer because the BBC producers felt that the machine should be able to run real, useful applications. Technical consultants for the _Computer Literacy Project_ also suggested that, if it had to be a BASIC dialect that was going to be taught to the entire nation, then it had better be a good one. (They may not have phrased it exactly that way, but I bet that’s what they were thinking.) BBC BASIC would make up for some of BASIC’s usual shortcomings by allowing for recursion and local variables.[6][8]
The BBC eventually decided that a Cambridge-based company called Acorn Computers would make the BBC Micro. In choosing Acorn, the BBC passed over a proposal from Clive Sinclair, who ran a company called Sinclair Research. Sinclair Research had brought mass-market microcomputing to the UK in 1980 with the Sinclair ZX80. Sinclair’s new computer, the ZX81, was cheap but not powerful enough for the BBC’s purposes. Acorn’s new prototype computer, known internally as the Proton, would be more expensive but more powerful and expandable. The BBC was impressed. The Proton was never marketed or sold as the Proton because it was instead released in December 1981 as the BBC Micro, also affectionately called “The Beeb.” You could get a 16k version for £235 and a 32k version for £335.
In 1980, Acorn was an underdog in the British computing industry. But the BBC Micro helped establish the company’s legacy. Today, the world’s most popular microprocessor instruction set is the ARM architecture. “ARM” now stands for “Advanced RISC Machine,” but originally it stood for “Acorn RISC Machine.” ARM Holdings, the company behind the architecture, was spun out from Acorn in 1990.
![Picture of the BBC Micro.][9] _A bad picture of a BBC Micro, taken by me at the Computer History Museum
in Mountain View, California._
### The Computer Programme
A dozen different TV series were eventually produced as part of the _Computer Literacy Project_, but the first of them was a ten-part series known as _The Computer Programme_. The series was broadcast over ten weeks at the beginning of 1982. A million people watched each week-night broadcast of the show; a quarter million watched the reruns on Sunday and Monday afternoon.
The show was hosted by two presenters, Chris Serle and Ian McNaught-Davis. Serle plays the neophyte while McNaught-Davis, who had professional experience programming mainframe computers, plays the expert. This was an inspired setup. It made for [awkward transitions][10]—Serle often goes directly from a conversation with McNaught-Davis to a bit of walk-and-talk narration delivered to the camera, and you can’t help but wonder whether McNaught-Davis is still standing there out of frame or what. But it meant that Serle could voice the concerns that the audience would surely have. He can look intimidated by a screenful of BASIC and can ask questions like, “What do all these dollar signs mean?” At several points during the show, Serle and McNaught-Davis sit down in front of a computer and essentially pair program, with McNaught-Davis providing hints here and there while Serle tries to figure it out. It would have been much less relatable if the show had been presented by a single, all-knowing narrator.
The show also made an effort to demonstrate the many practical applications of computing in the lives of regular people. By the early 1980s, the home computer had already begun to be associated with young boys and video games. The producers behind _The Computer Programme_ sought to avoid interviewing “impressively competent youngsters,” as that was likely “to increase the anxieties of older viewers,” a demographic that the show was trying to attract to computing.[7][11] In the first episode of the series, Gill Nevill, the show’s “on location” reporter, interviews a woman that has bought a Commodore PET to help manage her sweet shop. The woman (her name is Phyllis) looks to be 60-something years old, yet she has no trouble using the computer to do her accounting and has even started using her PET to do computer work for other businesses, which sounds like the beginning of a promising freelance career. Phyllis says that she wouldn’t mind if the computer work grew to replace her sweet shop business since she enjoys the computer work more. This interview could instead have been an interview with a teenager about how he had modified _Breakout_ to be faster and more challenging. But that would have been encouraging to almost nobody. On the other hand, if Phyllis, of all people, can use a computer, then surely you can too.
While the show features lots of BASIC programming, what it really wants to teach its audience is how computing works in general. The show explains these general principles with analogies. In the second episode, there is an extended discussion of the Jacquard loom, which accomplishes two things. First, it illustrates that computers are not based only on magical technology invented yesterday—some of the foundational principles of computing go back two hundred years and are about as simple as the idea that you can punch holes in card to control a weaving machine. Second, the interlacing of warp and weft threads is used to demonstrate how a binary choice (does the weft thread go above or below the warp thread?) is enough, when repeated over and over, to produce enormous variation. This segues, of course, into a discussion of how information can be stored using binary digits.
Later in the show there is a section about a steam organ that plays music encoded in a long, segmented roll of punched card. This time the analogy is used to explain subroutines in BASIC. Serle and McNaught-Davis lay out the whole roll of punched card on the floor in the studio, then point out the segments where it looks like a refrain is being repeated. McNaught-Davis explains that a subroutine is what you would get if you cut out those repeated segments of card and somehow added an instruction to go back to the original segment that played the refrain for the first time. This is a brilliant explanation and probably one that stuck around in people’s minds for a long time afterward.
I’ve picked out only a few examples, but I think in general the show excels at demystifying computers by explaining the principles that computers rely on to function. The show could instead have focused on teaching BASIC, but it did not. This, it turns out, was very much a conscious choice. In a retrospective written in 1983, John Radcliffe, the executive producer of the _Computer Literacy Project_, wrote the following:
> If computers were going to be as important as we believed, some genuine understanding of this new subject would be important for everyone, almost as important perhaps as the capacity to read and write. Early ideas, both here and in America, had concentrated on programming as the main route to computer literacy. However, as our thinking progressed, although we recognized the value of “hands-on” experience on personal micros, we began to place less emphasis on programming and more on wider understanding, on relating micros to larger machines, encouraging people to gain experience with a range of applications programs and high-level languages, and relating these to experience in the real world of industry and commerce…. Our belief was that once people had grasped these principles, at their simplest, they would be able to move further forward into the subject.
Later, Radcliffe writes, in a similar vein:
> There had been much debate about the main explanatory thrust of the series. One school of thought had argued that it was particularly important for the programmes to give advice on the practical details of learning to use a micro. But we had concluded that if the series was to have any sustained educational value, it had to be a way into the real world of computing, through an explanation of computing principles. This would need to be achieved by a combination of studio demonstration on micros, explanation of principles by analogy, and illustration on film of real-life examples of practical applications. Not only micros, but mini computers and mainframes would be shown.
I love this, particularly the part about mini-computers and mainframes. The producers behind _The Computer Programme_ aimed to help Britons get situated: Where had computing been, and where was it going? What can computers do now, and what might they do in the future? Learning some BASIC was part of answering those questions, but knowing BASIC alone was not seen as enough to make someone computer literate.
### Computer Literacy Today
If you google “learn to code,” the first result you see is a link to Codecademy’s website. If there is a modern equivalent to the _Computer Literacy Project_, something with the same reach and similar aims, then it is Codecademy.
“Learn to code” is Codecademy’s tagline. I don’t think I’m the first person to point this out—in fact, I probably read this somewhere and I’m now ripping it off—but there’s something revealing about using the word “code” instead of “program.” It suggests that the important thing you are learning is how to decode the code, how to look at a screen’s worth of Python and not have your eyes glaze over. I can understand why to the average person this seems like the main hurdle to becoming a professional programmer. Professional programmers spend all day looking at computer monitors covered in gobbledygook, so, if I want to become a professional programmer, I better make sure I can decipher the gobbledygook. But dealing with syntax is not the most challenging part of being a programmer, and it quickly becomes almost irrelevant in the face of much bigger obstacles. Also, armed only with knowledge of a programming language’s syntax, you may be able to _read_ code but you won’t be able to _write_ code to solve a novel problem.
I recently went through Codecademy’s “Code Foundations” course, which is the course that the site recommends you take if you are interested in programming (as opposed to web development or data science) and have never done any programming before. There are a few lessons in there about the history of computer science, but they are perfunctory and poorly researched. (Thank heavens for [this noble internet vigilante][12], who pointed out a particularly egregious error.) The main focus of the course is teaching you about the common structural elements of programming languages: variables, functions, control flow, loops. In other words, the course focuses on what you would need to know to start seeing patterns in the gobbledygook.
To be fair to Codecademy, they offer other courses that look meatier. But even courses such as their “Computer Science Path” course focus almost exclusively on programming and concepts that can be represented in programs. One might argue that this is the whole point—Codecademy’s main feature is that it gives you little interactive programming lessons with automated feedback. There also just isn’t enough room to cover more because there is only so much you can stuff into somebody’s brain in a little automated lesson. But the producers at the BBC tasked with kicking off the _Computer Literacy Project_ also had this problem; they recognized that they were limited by their medium and that “the amount of learning that would take place as a result of the television programmes themselves would be limited.”[8][13] With similar constraints on the volume of information they could convey, they chose to emphasize general principles over learning BASIC. Couldn’t Codecademy replace a lesson or two with an interactive visualization of a Jacquard loom weaving together warp and weft threads?
I’m banging the drum for “general principles” loudly now, so let me just explain what I think they are and why they are important. There’s a book by J. Clark Scott about computers called _But How Do It Know?_ The title comes from the anecdote that opens the book. A salesman is explaining to a group of people that a thermos can keep hot food hot and cold food cold. A member of the audience, astounded by this new invention, asks, “But how do it know?” The joke of course is that the thermos is not perceiving the temperature of the food and then making a decision—the thermos is just constructed so that cold food inevitably stays cold and hot food inevitably stays hot. People anthropomorphize computers in the same way, believing that computers are digital brains that somehow “choose” to do one thing or another based on the code they are fed. But learning a few things about how computers work, even at a rudimentary level, takes the homunculus out of the machine. That’s why the Jacquard loom is such a good go-to illustration. It may at first seem like an incredible device. It reads punch cards and somehow “knows” to weave the right pattern! The reality is mundane: Each row of holes corresponds to a thread, and where there is a hole in that row the corresponding thread gets lifted. Understanding this may not help you do anything new with computers, but it will give you the confidence that you are not dealing with something magical. We should impart this sense of confidence to beginners as soon as we can.
Alas, it’s possible that the real problem is that nobody wants to learn about the Jacquard loom. Judging by how Codecademy emphasizes the professional applications of what it teaches, many people probably start using Codecademy because they believe it will help them “level up” their careers. They believe, not unreasonably, that the primary challenge will be understanding the gobbledygook, so they want to “learn to code.” And they want to do it as quickly as possible, in the hour or two they have each night between dinner and collapsing into bed. Codecademy, which after all is a business, gives these people what they are looking for—not some roundabout explanation involving a machine invented in the 18th century.
The _Computer Literacy Project_, on the other hand, is what a bunch of producers and civil servants at the BBC thought would be the best way to educate the nation about computing. I admit that it is a bit elitist to suggest we should laud this group of people for teaching the masses what they were incapable of seeking out on their own. But I can’t help but think they got it right. Lots of people first learned about computing using a BBC Micro, and many of these people went on to become successful software developers or game designers. [As I’ve written before][14], I suspect learning about computing at a time when computers were relatively simple was a huge advantage. But perhaps another advantage these people had is shows like _The Computer Programme_, which strove to teach not just programming but also how and why computers can run programs at all. After watching _The Computer Programme_, you may not understand all the gobbledygook on a computer screen, but you don’t really need to because you know that, whatever the “code” looks like, the computer is always doing the same basic thing. After a course or two on Codecademy, you understand some flavors of gobbledygook, but to you a computer is just a magical machine that somehow turns gobbledygook into running software. That isn’t computer literacy.
_If you enjoyed this post, more like it come out every four weeks! Follow [@TwoBitHistory][15] on Twitter or subscribe to the [RSS feed][16] to make sure you know when a new post is out._
_Previously on TwoBitHistory…_
> FINALLY some new damn content, amirite?
>
> Wanted to write an article about how Simula bought us object-oriented programming. It did that, but early Simula also flirted with a different vision for how OOP would work. Wrote about that instead!<https://t.co/AYIWRRceI6>
>
> — TwoBitHistory (@TwoBitHistory) [February 1, 2019][17]
1. Robert Albury and David Allen, Microelectronics, report (1979). [↩︎][18]
2. Gregg Williams, “Microcomputing, British Style”, Byte Magazine, 40, January 1983, accessed on March 31, 2019, <https://archive.org/stream/byte-magazine-1983-01/1983_01_BYTE_08-01_Looking_Ahead#page/n41/mode/2up>. [↩︎][19]
3. John Radcliffe, “Toward Computer Literacy,” Computer Literacy Project Achive, 42, accessed March 31, 2019, [https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/media/Towards Computer Literacy.pdf][20]. [↩︎][21]
4. David Allen, “About the Computer Literacy Project,” Computer Literacy Project Archive, accessed March 31, 2019, <https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/history>. [↩︎][22]
5. ibid. [↩︎][23]
6. Williams, 51. [↩︎][24]
7. Radcliffe, 11. [↩︎][25]
8. Radcliffe, 5. [↩︎][26]
--------------------------------------------------------------------------------
via: https://twobithistory.org/2019/03/31/bbc-micro.html
作者：[Two-Bit History][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://twobithistory.org
[b]: https://github.com/lujun9972
[1]: tmp.zNBs2lK4Ca#fn:1
[2]: tmp.zNBs2lK4Ca#fn:2
[3]: tmp.zNBs2lK4Ca#fn:3
[4]: https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/
[5]: https://twobithistory.org/2018/07/22/dawn-of-the-microcomputer.html
[6]: tmp.zNBs2lK4Ca#fn:4
[7]: tmp.zNBs2lK4Ca#fn:5
[8]: tmp.zNBs2lK4Ca#fn:6
[9]: https://twobithistory.org/images/beeb.jpg
[10]: https://twitter.com/TwoBitHistory/status/1112372000742404098
[11]: tmp.zNBs2lK4Ca#fn:7
[12]: https://twitter.com/TwoBitHistory/status/1111305774939234304
[13]: tmp.zNBs2lK4Ca#fn:8
[14]: https://twobithistory.org/2018/09/02/learning-basic.html
[15]: https://twitter.com/TwoBitHistory
[16]: https://twobithistory.org/feed.xml
[17]: https://twitter.com/TwoBitHistory/status/1091148050221944832?ref_src=twsrc%5Etfw
[18]: tmp.zNBs2lK4Ca#fnref:1
[19]: tmp.zNBs2lK4Ca#fnref:2
[20]: https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/media/Towards%20Computer%20Literacy.pdf
[21]: tmp.zNBs2lK4Ca#fnref:3
[22]: tmp.zNBs2lK4Ca#fnref:4
[23]: tmp.zNBs2lK4Ca#fnref:5
[24]: tmp.zNBs2lK4Ca#fnref:6
[25]: tmp.zNBs2lK4Ca#fnref:7
[26]: tmp.zNBs2lK4Ca#fnref:8

101
sources/tech/20230105.1 ⭐️⭐️ 6 tips for building an effective DevOps culture.md
View File

@ -1,101 +0,0 @@
[#]: subject: "6 tips for building an effective DevOps culture"
[#]: via: "https://opensource.com/article/23/1/tips-effective-devops-culture"
[#]: author: "Yauhen Zaremba https://opensource.com/users/yauhen-zaremba"
[#]: collector: "lkxed"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
6 tips for building an effective DevOps culture
======
Why would you want to build a [DevOps][1] culture? There are many benefits to the streamlined collaboration of the development and operations teams. A major goal is efficiency: Increasing the speed of new software deployments and reducing idle time for workers. Fostering trust between colleagues can improve employee satisfaction, produce new innovations, and positively impact profitability.
[DevOps][2] is a broad philosophy with a range of interpretations. In other words, you can visit 40 companies and find 40,000 different ideas about using DevOps effectively in the workplace. This diversity of opinion is actually a good thing–so many perspectives are useful for building stronger teams. This guide will look at the top tips for encouraging better collaboration between colleagues within a DevOps culture.
Each section offers a different aspect of DevOps culture and looks at ways to introduce it into your workforce.
![DevOps includes collaboration, workflow, infosec, and iteration.][3]
### Continuous development of processes
This core tenet of DevOps culture sets it apart from many other types of workplace ethos. The DevOps philosophy says that it is essential to make mistakes because it shows you are trying out new ideas.
The heart of DevOps culture is a commitment to evolving creativity. Practically, that means not yelling at your direct reports when test results show that things were better before they changed it. It means recognizing that progress is not linear and success is never a straight line.
DevOps expert [Gene Kim][4] advocates for risk-taking and experimentation. This implies letting your team work on unusual tasks to find new insights.
Should your organization be profit-driven? Can you allow your teams to try something new? I'm talking about something other than unrelated passion projects. Continuous process development means being open to upgrading present methods. Great sales leaders appreciate that results matter more than presenteeism, so it is always crucial to focus on how teams are working rather than how much.
### Readily give feedback and actively seek it
Increased trust between individuals is another key feature of a thriving DevOps culture. Whether your staff is learning how to build affiliate network contacts or trying to design their next [UX][5] survey, everyone should be open to feedback on their work. But this will never happen until your teammates respect each other's opinions and trust that feedback is given in a spirit of good intention.
This culture may sound impossible to cultivate; indeed, some companies will struggle to achieve this more than others. Granted, a large part of the success of giving and receiving feedback depends on the personalities of your employees. It is possible to screen for this during the recruitment process.
Before you expect staff to readily offer feedback to colleagues and seek it in the first place, you should lead by example. Members of the C-suite should be modeling this behavior, openly asking members of the company to pose probing questions about their strategic decisions, and providing balanced feedback.
![DevOps is the intersection of development, quality assurance, and operations][6]
### Always look for improvements
Building on increased intellectual trust between colleagues, your team should look for ways to improve its work. The nature of DevOps means the software development team will be producing deployments more rapidly than with traditional approaches.
However, this culture of openness to improvement can positively impact departments beyond development and operations. Ask yourself what other areas of your business could do with a burst of optimism.
Be on the lookout for training and upskilling opportunities. Even if a training course is less salient than advertised, the chance to network with industry professionals and build contacts for the future can only enhance the diversity of ideas within your organization.
### Save ideas for later development
Part of your DevOps toolchain should be a heavily used account on [Git][7]. You can use Git as a common repository for scripts produced during software development and other related projects. Known as "version control," Git allows programmers to save iterations of their work and reuse or improve the work of others.
You're aiming for the ability to keep hold of good ideas for future use. A certain pathway did not work out for specific reasons. However, just because that set of ideas was wrong for the time it was conceived does not mean it can never become helpful in the future.
As the entire focus of DevOps rests on end-to-end ownership of software in production, saving iterations of developments truly supports this principle. You want to see an improved focus on and commitment to the software testing project at hand.
A simple way to incorporate this is to request that developers include ideas for future work in the developer contract and final project report. Make sure tech services managers know they should ask for examples of side-branching ideas that cropped up during the build. The more minds aware of these little innovations, the more likely someone will remember one when needed.
### Sit close together (physically or virtually)
The goal is to share a common understanding of one another's job roles and how they interrelate. You can achieve this in a few simple ways, summarized by three words: Sit close together. Invite other teams to your meetings and share user feedback reports in their entirety. Have lunch together, plan virtual happy hours together, and generally make sure your colleagues are in close proximity. About 90% of teams with a mature DevOps protocol report a clear understanding of their responsibilities to other teams compared to only about 46% of workers in immature DevOps teams.
Although it can be tempting to form cliques with like-minded folk and only hang out with staff hired to carry out the same tasks as you, this is terrible for the business as a whole. Whether you like it or not, all humans are multi-faceted and capable of contributing their unique talents to a whole host of scenarios.
The idea of closer collaboration is to honor the ability of anyone to suggest improvements to the products or work processes going on around them. If you only ever sit at a distance from the other departments within the company, you will miss countless opportunities to share intelligent ideas. After all, you often learn best in the free flow of ideas during a conversation.
### Commit to automation
You should be looking to automate mundane and repetitive tasks in the name of efficiency and process acceleration. Every industry has boring–and quite frankly, silly–exercises carried out daily or weekly.
Whether this is manually copying data from one page to another or typing out audio transcripts by hand, staff at every level should insist that machines take on such burdens where possible. The reality is automation technology advances every single year, and operational processes should, too. [Automation testing][8] is so crucial to DevOps that it is the second principle of the CALMS framework (the "C" of which stands for "culture").
How can you make this happen? Invite staff to openly express which aspects of their job they feel could be automated and then–here is the crucial part–support the facilities needed to automate them. That might mean a $600 annual subscription to a software program, a complete enterprise application modernization, or two days of developers' time to build a new tool to use in-house.
Either way, you should assess the benefits of automation and consider how much time you could save for everyone. DevOps statistics continually indicate just how much better off modern companies are by integrating these beneficial principles year after year.
### Explore new ways of working successfully
A culture shift doesn't happen overnight. The sooner you start, though, the sooner you see results. In my experience, people embrace change when it's a genuine improvement on what has gone before. DevOps provides a framework for such improvements. Whether you're just getting started with DevOps in your organization or simply want to improve your existing culture, consider the above points and how they relate to your organization's future.
--------------------------------------------------------------------------------
via: https://opensource.com/article/23/1/tips-effective-devops-culture
作者：[Yauhen Zaremba][a]
选题：[lkxed][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/yauhen-zaremba
[b]: https://github.com/lkxed
[1]: https://opensource.com/resources/devops
[2]: https://opensource.com/article/22/2/devops-documentation-maturity
[3]: https://opensource.com/sites/default/files/2022-12/devop.png
[4]: https://enterprisersproject.com/user/gene-kim
[5]: https://opensource.com/article/22/7/awesome-ux-cli-application
[6]: https://opensource.com/sites/default/files/2022-12/devop-venn.png
[7]: https://opensource.com/article/22/11/git-concepts
[8]: https://opensource.com/article/20/7/open-source-test-automation-frameworks

146
translated/talk/20190331 Codecademy vs. The BBC Micro.md Normal file
View File

@ -0,0 +1,146 @@
[#]: subject: "Codecademy vs. The BBC Micro"
[#]: via: "https://twobithistory.org/2019/03/31/bbc-micro.html"
[#]: author: "Two-Bit History https://twobithistory.org"
[#]: collector: "lujun9972"
[#]: translator: "CanYellow"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
[BBC Micro][T2] 比之 [Codecademy][T1]
======
20世纪70年代末期，计算机突然成为了某种普罗大众能够买回家的商品；而此前的几十年间，它一直只是听命于企业霸主的神秘而笨重的机器。少数狂热的爱好者注意到了这是多么吸引人并争相购买了属于自己的计算机。对更多的人而言，微形计算机的到来引发了对未来的无助焦虑。同时期的杂志上的一则广告承诺一台家用计算机将“让您的孩子在学校享有不公平的优势”。广告中展示了一位打着领带，身着时髦的西装外套的男孩子急切地举手回答问题，在他身后，他的显得不那么聪明的同学们闷闷不乐地望着他。这则广告以及其它与之类似的广告表明世界正在疾速改变，而如果你不立即学习如何使用这些令人生畏的新设备之一，你和你的家人就会被时代所抛弃。
在英国，这些焦虑转化为政府高层对国家竞争力的担忧。从各种意义上，20世纪70年代对英国来说都是平平无奇的十年，通胀与失业率高企。与此同时，一系列的罢工让伦敦陷于一次又一次的停电中。一篇1979年的政府报告焦虑：没有跟上计算机技术浪潮将“为我们糟糕的工业表现平添又一个影响因素”[1][1]。英国似乎已经在计算机技术的角逐中落后了——所有的大型的计算机公司都是美国的，而集成电路则在日本和中国台湾制造。
BBC（英国广播公司）——由政府建立的公共服务广播公司——作出了一个大胆的举动，决定通过帮助英国人战胜他们对计算机的反感来解决英国的国家竞争力问题。BBC 发起了 [_Computer Literacy Project(计算机认知计划)_][T3]，该计划包括多个教育方向的努力：几部电视系列片，一些相关书籍，一张支持团队网络以及一款名为 BBC Micro 的特别定制的微型计算机。该项目是如此成功以致于到1983年[ BYTE 杂志][T4]的一名编辑写道：“与美国相比，有更多的英国人对微型计算机感兴趣。”[2][2] 这名编辑惊讶于英国的 Fifth Personal Computer World Show(第五届个人电脑世界展) 比当年的西海岸电脑展的人数更多。超过六分之一的英国人观看了由 _Computer Literacy Project_ 制作的第一部电视系列片的一集并最终售出了150万台 BBC Micro 微型计算机。[3][3]
去年，一份包括了由 _Computer Literacy Project_ 出版的所有材料与制作的每一部电视系列片的[档案][4]发布在了互联网上。我抱着极大的兴趣观看这些电视系列片并试图想象在20世纪80年代早期学习电脑使用是什么图景。不过我发现更有兴趣的是时年是如何教授电脑使用的。今天，我们仍然担心技术发展使人们落伍。富有的科技企业家与政府花费大量的资金试图教孩子们“编程”。我们拥有诸如 Codecademy 这样的通过新技术的运用进行交互式编程教学的网站。我们可能假定这种方式比80年代的呆板的电视系列片更高效，不过真的是这样吗？
### [Computer Literacy Project][T3] (计算机认知计划)
微型计算机革命始于1975年 [Altair 8800][5] 的发布。两年后，Apple II，TRS-80 以及 Commodore PET 都相继发布。全新的计算机的销量爆发式增长。1978年，BBC 在一部名为["Now the Chips Are Down"][T5]（《芯片来了》）（译者注：对于非英国区域的读者，可以在[这里][T6]观看该纪录片） 的纪录片中探讨了这种新的机器必将带来的剧烈的社会变革。
该纪录片充满担忧。在前5分钟内，解说员提到这种微电子器件将“彻底改变我们的生活方式”。随着诡异的合成音乐的播放以及屏幕上绿色的电脉冲在放大后的芯片上起舞，解说员进一步说这种芯片“正是日本放弃造船业的原因，也将成为我们的孩子们长大后失业的原因”。纪录片继续探讨了机器人如何用于汽车自动化组装以及欧洲的手表工业如何在与美国的电子表工业竞争中败下阵来。它斥责了英国政府在应对未来的大规模失业的准备上做得不够。
该纪录片据信可能在英国议会上展示过。[4][6] 包括工业署和人力服务委员会在内的一些政府代表开始有兴趣尝试提高英国公众对计算机的认识。人力服务委员会为来自 BBC 的教育部门的一个团队到日本、美国以及其他国家的实地考察提供了资助。该研究团队完成了一份历数微电子技术在工业制造、人力关系与办公室工作等领域最终将意味着哪些方面的重大改变的研究报告。70年代末，BBC 决定制作一部帮助普通英国人“学习如何使用和控制计算机，避免产生被计算机支配的感受”的十集电视系列片[5][7] 。这一努力最终成为了一个与_Adult Literacy Project_（成人扫盲计划）相似的多媒体项目。_Adult Literacy Project_是 BBC 此前进行的一项涉及电视系列片以及辅助课程的帮助两百万人提高他们的阅读能力的项目。
_Computer Literacy Project_ 背后的制作方热衷于以“实操”示例为特色的电视系列片。这样如果观众拥有一台微型计算机在家里，他们就可以亲自动手尝试。这些例子不得不都是基于 BASIC 语言的，因为这是在几乎所有的微型计算机上都使用的编程语言 (实际是整个交互界面(shell)）。但是制作方面临一个棘手的问题：微型计算机制造商均拥有他们自己的 BASIC 方言，因此不论他们选择哪一种方言，他们都不可避免地疏远大部分的观众。唯一切实可行的方案是创造一种全新的 BASIC 方言——BBC BASIC——以及与之配合使用的微型计算机。英国公众就可以购买这种全新的微型计算机并依照示例操作而不需要担心软硬件上的差异带来的问题。
BBC 的制作人与节目主持人并不具备自行制造微型计算机的能力，因此他们汇总了一份他们预期的计算机的规范并邀请英国的微型计算机公司推出满足该规范要求的新机器。这份规范要求一种相对更强劲的计算机，因为 BBC 的制作方认为相应的设备应当能够运行真实有用的应用程序。_Computer Literacy Project_的技术顾问也是如此建议：如果必须要教授全体国人一种 BASIC 方言的话，那么最好选择表现良好的(他们可能没有完全那样说，不过我认为这就是他们的真实想法)。BBS BASIC 通过允许递归调用与局部变量弥补了一些 BASIC 语言的常见缺点。[6][8]
BBC 最终决定由坐落于剑桥的 Acorn Computers 公司(中文网络译名：艾康电脑)制造 BBC Micro 计算机。在选择 Acorn 公司的时候，BBC 并未考虑来自经营 Sinclair Research 公司的 [Clive Sinclair][T7] 的申请，Sinclair Research 公司凭借 Sinclair ZX80 微型计算机的推出在1980年将微型计算机的大众市场引入了英国。Sinclair 公司的新产品，ZX81，虽然更便宜但是性能不足以满足 BBC 的要求。Acorn 的新型的内部称为 Proton 原型计算机更加昂贵但是性能更好，更具备扩展性，BBC 对此印象深刻。该型号的计算机从未作为 Proton 进行营销与销售，Acorn 公司代之以 BBC Micro 的名称在1981年12月发布。BBC Micro 又被亲切地称为“The Beeb”，你可以以235英磅的价格购得其16k内存的版本或者以335英磅的价格获得其32k内存的版本。
1980年，Acorn 是英国计算机工业的失败者，但是 BBC Micro 成就了 Acorn 公司的传统。时至今日，世界范围内最流行的微处理器指令集是 ARM 架构，“ARM”如今表示“Advanced RISC Machine”(先进 RISC 架构设备)，然而最初它代表的是“Acorn RISC Machine”(Acorn RISC 架构设备)。ARM 架构背后的 ARM Holding(ARM 公司) 就是 Acorn 公司在1990年之后的延续。
![Picture of the BBC Micro.][9] _BBC Micro 的一幅拙劣图片，我摄于美国加州山景城(Mountain View)的计算机历史博物馆(Computer History Museum)_
### 名为“The Computer Programme”(计算机程序)的电视系列片
十几个不同的电视系列片最终作为_Computer Literacy Project_的一部分创作出来。第一部作品是一部名为 _The Computer Programme_(计算机程序) 的十集电视系列片。该系列片在1982年初播出了十周。一百万人每周晚上收看该节目，另有25万人收看该节目在每周日与周一下午的重播。
这一电视节目有两名主持人，Chris Serle 和 Ian McNaught-Davis。Serle 扮演初学者，而 McNaught-Davis 扮演具有大型计算机编程职业经验的专家，这是一个启发性的配置。该节目造就了[略显尴尬的过渡][10]——Serle 经常直接从与 McNaught-Davis 的对话中过渡到面向镜头的边走边说的讲述，此时你不禁会疑惑 McNaught-Davis 是否还站在画面之外。不过这意味着 Serle 可以表达观众肯定会有的关注。他可能会惊恐地看着满屏的 BASIC 语言并提出类似“这些美元符号是什么意思”的问题。在节目中的某些时刻，Serle 与 McNaught-Davis 会坐在电脑前进行事实上的结对编程。McNaught-Davis 会在不同的地方留下一些线索，而 Serle 则试图将它们弄清楚。如果这一节目仅仅由一个无所不知的讲述者主持，它将更难以理解。
该节目也在努力展示计算在普通人生活中的实际应用。到80年代早期，家庭电脑已经开始与小孩子和电子游戏联系在一起。_Computer Literacy Project_ 的制作方试图避免采访“令人印象深刻的有能力的年轻人”，因为这可能会“加剧老年观众的焦虑”，而该节目正是试图吸引这一人群对计算感兴趣[7][11]。在该系列的第一集中，该节目的“现场”记者 Gill Nevill 采访了一名购买了一台 Commodore PET 电脑用于辅助管理她的糖果店的女性。这名名叫 Phyllis 的女性受访者看上去大约60多岁，她在使用 PET 完成她的会计工作上不存在任何问题，甚至开始使用 PET 为其他企业做计算工作，这听上去像是一个有前途的自由职业的开端。Phyllis 说她并不介意电脑工作逐步取代她的糖果店生意，因为她更喜欢电脑工作。画面接着变成了对一名青少年的采访，他介绍了他是如何修改 _[Breakout][T8]_ 这款电子游戏以使之运行更快并更具挑战性，不过这几乎鼓舞不了任何人。另一方面，如果人群中的 Phyllis 也会使用电脑，那么你当然也可以。
虽然该节目的特色是大量的 BASIC 编程，不过它实际想要教给观众的是计算机通常是如何工作的。该节目通过类比的方法解释了其中的一般原则。在第二集中有一个关于[Jacquard][T9]织机(译注：中文网络译为雅卡尔提布机)的讨论。Jacquard 织机实现了两件事。其一，它揭示了计算机并不仅仅基于过去发明的神秘技术——计算的一些基本原则可以上溯到两百年前，就跟你可以在纸上打孔来控制纺织机的想法一样简单。其二，经线与纬线的交织用于解释选择二进制（即纬线是从上方还是下方穿过经线）是如何在重复了一次又一次之后足以产生巨大变化的。当然，节目接下来继续讨论信息是如何使用二进制存储的。
在该节目中接下来是有关一件能够播放在一卷长长的分段的打孔卡片上编码的音乐的蒸汽风琴的小节。这个类比用以解释 BASIC 中的子程序。Serle 与 McNaught-Davis 将整卷的打孔卡片摊开在工作室的地板上，然后指出看上去像是重复的副歌的分段。McNaught-Davis 解释说，如果你将这些重复的卡片分段剪下而插入一个回到第一次播放副歌的分段的指令，这就是子程序。这是一个绝妙的解释并将可能在听众的脑海中久久挥之不去。
我仅仅摘录了一些例子，不过我认为总的来看该节目尤为擅长通过解释计算机实现功能所依赖的原则使计算机不再神秘。这一节目本可以致力于 BASIC 教学，不过它并没有这样做。这被证明是一个相当明智的选择。在1983年写就的一篇回忆文章中，_Computer Literacy Project_的总制作人 John Radcliffe 如是写道：
> 如果计算机将如我们所相信的那样重要，对这一主题的真正理解对每个人都很重要，可能会几乎与文字读写能力同等重要。不管是在我们这里还是在美国，在计算机认知的主要路线上的早期思路均集中于编程上。然而随着我们思想的发展，我们意识到“亲自”体验在个人计算机上的价值，我们开始降低对编程的重视，而更多的强调广泛的理解，将微型计算机与大型计算机联系起来，鼓励人们获取一系列应用程序与高级语言的经验，并将这些经验同现实世界中的工业与商业活动中的经验联系起来…… 我们相信一旦人们掌握了这些原则，简单地说，它们将可以进一步深入该主题。
接下来， Radcliffe writes 又以类似的方式写道：
> 围绕着这一电视系列片的主要阐释目标有很多的争论。一个思想流派认为在使用微型计算机上的实用细节上给予建议对本项目而言尤为重要。但我们已经有了结论，如果这一电视系列片能够拥有可持续性的教育价值，它必须成为一条通过解释计算原则来进入真实的计算世界的路径。这必须通过对微型计算机的室内演示，通过类比方式解释其中的原则，真实生活中的实际应用的影片展示这三者的结合实现。不仅仅是微型计算机，小型机以及大型机也将被展示。
我喜爱这一系列片，尤其是其中关于小型机与大型机的部分。_Computer Literacy Project_ 背后的制作方旨在帮助英国找准定位：计算身处何处又去向何方？计算机现在能做什么，未来又能做什么？学习一些 BASIC 语言是回答这些问题的一个部分，但是仅仅理解 BASIC 语言似乎是不足以使人们认知计算机的。
### 今天的计算机认知
如果你现在搜索“学习编程”，你看到的排在第一的是指向 Codecademy 网站的链接。如果要说存在一个“计算机认知计划”的现代替代品——存在相同的影响与目标，那就是 Codecademy。
对于普通人而言“Learn to code”（学习编程）是 Codecademy 的口号。我认为我不是第一个指出这一点的人——事实上我曾经在某个地方见到过这一点，只是现在拿来用而已。但是这里使用的是“code”（代码）而非“编程”，这说明了一些问题。这表明你学习的重要内容是如何读懂代码，如何阅读满屏的 Python 代码的价值而不是目光呆滞、不知所云。我能够理解为什么对于普通人而言这似乎是成为专业程序员的主要障碍。专业程序员整日盯着布满编程术语的电脑屏幕，如果我想要成为一个专业程序员，我最好确保我能够理解这些术语。但是理解语法并不是成为程序员的最大的挑战。面对更多更大的障碍，它很快将变成微不足道的。仅仅以掌握一门编程语言的语法为目标，你可能能够 _阅读_ 代码但是无法做到 _编写_ 代码解决全新的问题。
我最近浏览了 Codecademy 的 “Code Foundations”(编程基础) 课程。如果你对编程感兴趣(而不是网页开发或者数据科学)并且没有任何编程经验，这是 Codecademy 推荐你学习的课程。里面有几节关于计算机科学史的课时，不过都是流于表面而没有深入研究。（感谢上帝，一位高尚的互联网秩序义务维护者指出了其中存在的一个特别恶劣的错误）。该课程的主要目的是教授你编程语言的通用结构要素：变量、函数、控制流、循环等。换句话说，该课程聚焦于为了开始理解编程术语中的模式你所需要知道的内容。
公平地看，Codecademy 也提供其他内容深入的课程。但是即使是如 “Computer Science Path”(计算机科学之路) 这样的课程也几乎只仅仅专注于编程以及程序中表达的概念。有人可能会反驳说这就是重点—— Codecademy 的主要特点就是提供给你一些交互式的带有自动反馈的编程课程。在有限的自动化课程中能够灌输给学员的内容只有这么多，因此学员的脑海里也没有更多的空间容纳更多其他的内容。但是负责启动 _Computer Literacy Project_ 的 BBC 的制作人也面临同样的问题。他们意识到受限于他们的传播媒介，“通过电视节目所能获得的学习内容的容量也是受限的”[8][13]。虽然在他们所能传达的信息总量上存在相似的限制，但是 BBC 的制作人选择强调在学习 BASIC 语言上的一般原则。Codecademy 就不能将其中一两节交互式可视化的课时替换为编织经线与纬线的 Jacquard 织机的案例吗？
我一直在大声鼓吹“一般原则”，因此让我再解释下我认为的一般原则是什么以及为什么它们如此重要。J. Clark Scott 出了一本有关计算机的书，书名为 _But How Do It Know?_（但是它怎么知道）。这个书名来自书的序言里的一则笑话：一个店员向人群推销保温瓶，说保温瓶可以让热食始终是热的，冷食始终是冷的。一名听众对这个新发明感到惊讶，问道，但是它怎么知道（根据你给它的食物类型的不同选择做相应的事情呢）？笑点在于保温瓶当然不能感知食物的温度然后据此做出决定——保温瓶仅仅制作成保证冷食必然保持冷的，热食必然保持热的就可以了。人们也以(笑话中的那个听众)一样的方式看待计算机，相信计算机就是能够基于提供给它们的代码“选择”做一件事或者另一件事的数字大脑。但是了解一些有关计算机如何工作的知识，哪怕是很初级水平的理解，也能让（人们理解中的）计算机摆脱（做判断的）侏儒。这就是为什么 Jacquard 织机是一个很好的有助理解的例子。一开始它似乎是一种难以置信的设备，它读取打孔卡片，然后以某种方式“知道”编织正确的样式。现实是显而易见的：每一行孔都对应一根线，而一行中有孔的地方对应着提起的线。理解了这些虽然不会有助于你用电脑完成新的事情，但是将使你自信于你不是在跟某些神秘事物打交道。我们应当尽快将这种自信的感受传授给初学者。
唉，真实存在的问题是可能没有人想要了解 Jacquard 织机。根据 Codecademy 如何强调他们教授的专业应用来判断，很多人开始使用 Codecademy 可能是因为他们相信这有助于“提升”他们的职业生涯。他们没有来由地相信首要的问题是理解编程的专业术语，因此他们才想要 “Learn to code”。他们想要在他们所拥用的每天晚上晚餐与就寝之间的一两个小时里尽快做这件事。Codecademy 毕竟只是一门投其所好的生意而非一些有关18世纪就发明了的机器的间接说明。
另一方面，_Computer Literacy Project_ 是供职于 BBC 的一群制作人与公务员所认为的将电脑使用教给国民的最好的方式。我承认因为这一群人教会大众他们无法以己之力所能求得的事物而赞美这一群人的建议多少有点精英主义。但我情不自禁认为他们做对了。许多人使用 BBC Micro 第一次学会了使用电脑，他们中的很多人进而成为了成功的软件开发者或游戏设计师。[正如我曾经所言][14]，我怀疑在计算机已经变得相对简单的时代里学习使用电脑是一个巨大的优势。不过或许这群人所拥有的另一个优势在于有像 _The Computer Programme_ 这样的尽己所能不仅仅教授编程而且教授计算机是为什么又是如何运行程序的节目。在看完 _The Computer Programme_ 之后，你可能并不能理解电脑屏幕上的所有编程术语，但是实际上你并不需要，因为你知道无论“代码”是什么样子，计算机总是在重复做基础的事情。在完成了 Codecademy 上的一到两个课程之后，你可能理解了编程术语的一些味道，但是对你来说一台电脑仍然只是一台能够以某种方式将编程术语转化为运行的软件的魔法机器。这并不是计算机认知。
1. Robert Albury and David Allen, Microelectronics, report (1979). [↩︎][18]
2. Gregg Williams, “Microcomputing, British Style”, Byte Magazine, 40, January 1983, accessed on March 31, 2019, <https://archive.org/stream/byte-magazine-1983-01/1983_01_BYTE_08-01_Looking_Ahead#page/n41/mode/2up>. [↩︎][19]
3. John Radcliffe, “Toward Computer Literacy,” Computer Literacy Project Achive, 42, accessed March 31, 2019, [https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/media/Towards Computer Literacy.pdf][20]. [↩︎][21]
4. David Allen, “About the Computer Literacy Project,” Computer Literacy Project Archive, accessed March 31, 2019, <https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/history>. [↩︎][22]
5. ibid. [↩︎][23]
6. Williams, 51. [↩︎][24]
7. Radcliffe, 11. [↩︎][25]
8. Radcliffe, 5. [↩︎][26]
--------------------------------------------------------------------------------
via: https://twobithistory.org/2019/03/31/bbc-micro.html
作者：[Two-Bit History][a]
选题：[lujun9972][b]
译者：[CanYellow](https://github.com/CanYellow)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://twobithistory.org
[b]: https://github.com/lujun9972
[1]: tmp.zNBs2lK4Ca#fn:1
[2]: tmp.zNBs2lK4Ca#fn:2
[3]: tmp.zNBs2lK4Ca#fn:3
[4]: https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/
[5]: https://twobithistory.org/2018/07/22/dawn-of-the-microcomputer.html
[6]: tmp.zNBs2lK4Ca#fn:4
[7]: tmp.zNBs2lK4Ca#fn:5
[8]: tmp.zNBs2lK4Ca#fn:6
[9]: https://twobithistory.org/images/beeb.jpg
[10]: https://twitter.com/TwoBitHistory/status/1112372000742404098
[11]: tmp.zNBs2lK4Ca#fn:7
[12]: https://twitter.com/TwoBitHistory/status/1111305774939234304
[13]: tmp.zNBs2lK4Ca#fn:8
[14]: https://twobithistory.org/2018/09/02/learning-basic.html
[15]: https://twitter.com/TwoBitHistory
[16]: https://twobithistory.org/feed.xml
[17]: https://twitter.com/TwoBitHistory/status/1091148050221944832?ref_src=twsrc%5Etfw
[18]: tmp.zNBs2lK4Ca#fnref:1
[19]: tmp.zNBs2lK4Ca#fnref:2
[20]: https://computer-literacy-project.pilots.bbcconnectedstudio.co.uk/media/Towards%20Computer%20Literacy.pdf
[21]: tmp.zNBs2lK4Ca#fnref:3
[22]: tmp.zNBs2lK4Ca#fnref:4
[23]: tmp.zNBs2lK4Ca#fnref:5
[24]: tmp.zNBs2lK4Ca#fnref:6
[25]: tmp.zNBs2lK4Ca#fnref:7
[26]: tmp.zNBs2lK4Ca#fnref:8
[T1]: https://www.codecademy.com/
[T2]: https://bbcmicro.computer/
[T3]: https://clp.bbcrewind.co.uk/history
[T4]: https://archive.org/details/byte-magazine?tab=about
[T5]: https://www.bbc.co.uk/iplayer/episode/p01z4rrj/horizon-19771978-now-the-chips-are-down
[T6]: https://archive.org/details/BBCHorizon19771978NowTheChipsAreDown
[T7]: https://en.wikipedia.org/wiki/Sinclair_Research
[T8]: https://en.wikipedia.org/wiki/Breakout_(video_game)
[T9]: https://www.scienceandindustrymuseum.org.uk/objects-and-stories/jacquard-loom

102
translated/tech/20230105.1 ⭐️⭐️ 6 tips for building an effective DevOps culture.md Normal file
View File

@ -0,0 +1,102 @@
[#]: subject: "6 tips for building an effective DevOps culture"
[#]: via: "https://opensource.com/article/23/1/tips-effective-devops-culture"
[#]: author: "Yauhen Zaremba https://opensource.com/users/yauhen-zaremba"
[#]: collector: "lkxed"
[#]: translator: "lxbwolf"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
构建高效的 DevOps 文化的 6 个技巧
======
你为什么要构建 [DevOps][1] 文化？开发和运营团队的精简协作有很多好处。效率是首要目标：提高新软件部署的速度，减少等待的时间。培养同事之间的信任可以提升员工的满意度，激发新的创新，并对盈利能力产生积极的影响。
[DevOps][2] 是一个很广泛的范畴，大家的理解也见仁见智。每个公司对于如何实行 DevOps 也各不相同。这种意见的多样性实际上是一件好事--这么多的观点对于建立更强大的团队是很有用的。本指南将探讨在 DevOps 文化中鼓励同事之间更好地合作的最高技巧。
下面每个部分从不同的视角介绍 DevOps 文化，并争取将它引入你的工作中去。
![DevOps includes collaboration, workflow, infosec, and iteration.][3]
### 流程的持续开发
DevOps 文化的这一核心原则使它与许多其他类型的工作区别开来。DevOps 哲学说，犯错是有积极意义的，因为这表明你在尝试新的想法。
DevOps 文化的核心是不停地创造。实际上，这意味着当测试结果显示事情由于你的改动而变坏时，不要懊恼。我们要认识到，进化的过程不是线性的，通往成功的道路也从来不是一条直线。
DevOps 专家[Gene Kim][4] 主张勇于承担风险和进行实验。鼓励你的团队尝试不寻常的任务，以得到新的领悟。
你的组织应该以利润为导向吗？你能允许你的团队尝试一些新东西（非指个人兴趣项目）吗？持续的流程开发意味着对升级目前的方法持开放态度。优秀的销售领导懂得，结果比出勤率更重要，因此，关注团队的工作方式而不是工作量的多少始终是关键。
### 随时提供反馈并积极寻求反馈
成员之间增加信任是蓬勃发展的 DevOps 文化的另一个关键特征。无论你的员工是在学习如何建立联盟网络联系，还是试图设计他们的下一个 [UX][5] 调查，每个人都应该对他们工作的反馈持开放态度。但是，除非你的团队成员尊重彼此的意见，并相信反馈是本着善意的精神提出的，否则这永远不会发生。
这种文化听起来可能是很难培养的；事实上，一些公司会比其他公司更努力地实现这一点。诚然，给予和接受反馈的成功很大程度上取决于员工的个性。在招聘过程中，也可以对此进行筛选。
在你期望员工随时向同事提供反馈并主动寻求反馈之前，你应该以身作则。高管应该以身作则，公开要求公司成员对其战略决策提出探究性问题，并提供相应的反馈。
![DevOps is the intersection of development, quality assurance, and operations][6]
### 不断改进
在同事之间增加智力信任的基础上，你的团队应该寻找方法来改善其工作。DevOps 的性质意味着软件开发团队将比传统方法更迅速地进行部署。
这种开放的改进文化可以对开发和运维以外的部门产生积极的影响。你也可以自己去探索，企业还有哪些领域会受到积极的影响。
留意培训和提高技能的机会。即使一个培训课程没有广告上说的那么突出，但有机会与行业专家建立联系，并与未来建立联系，这可以提高你的组织内的思想多样性。
### 为以后的开发保存当前的想法
频繁使用的 [Git][7] 账户应该是你的 DevOps 工具链的一部分。你可以用 Git 作为软件开发和其他相关项目中产生的脚本的共同仓库。Git 作为 "版本控制" 工具而被熟知，Git 允许程序员保存他们工作的迭代、复用或改进其他人的工作。
你的目标是有能力保留好的想法供将来使用。某个方法由于某种原因没有成功。然而，那套想法在当时是错误的，并不意味着它在未来永远无法成为有用的东西。
由于 DevOps 的整个重点在于生产环境中的软件的端到端所有权，因此保存开发的迭代真正支持这一原则。你希望看到对手头的软件测试项目的持续关注和投入。
一个简单的方法是要求开发者在开发者合同和最终项目报告中包含对未来工作的想法。确保技术服务经理知道他们应该要求提供在建设过程中出现的旁门左道的想法的例子。意识到这些小创新的人越多，在需要的时候就越有可能有人记住一个。
### 坐在一起（物理上或逻辑上）
目标是对彼此的工作角色以及它们之间的相互关系有一个共同的理解。你可以通过几个简单的方法实现这一目标，用一句话概括：坐在一起。邀请其他团队参加你们的会议，完整地分享用户反馈报告。一起吃午饭，一起计划虚拟的快乐时光，一般来说，要确保你的同事都在一起。大约 90% 的拥有成熟的 DevOps 协议的团队报告说，他们清楚地了解自己对其他团队的责任，而在不成熟的 DevOps 团队中，只有大约 46% 的工作者清楚地了解自己的责任。
虽然与志同道合的人结成小团体，只与被雇来执行与你相同任务的员工一起玩耍是很诱人的，但这对整个企业来说是很糟糕的。无论你喜欢与否，所有的人都是多面手，能够在一系列的情况下贡献自己的独特才能。
密切协作的想法是尊重任何人对其周围正在进行的产品或工作流程提出改进建议的能力。如果你与公司内的其他部门保持一定的距离，你将会错过无数次分享智慧想法的机会。毕竟，你往往在交流中学习得最好。
### 致力于自动化
你应该以提高效率和加速流程的方式，将单调的和重复的任务变为自动化。每个行业都有无聊的--说得直白一点，愚蠢的--每天或每周都要进行的工作。
无论是手工将数据从一页复制到另一页，还是手工打出音频记录，每个级别的工作人员都应该坚持让机器在可能的情况下承担这些负担。现实是自动化技术每年都在进步，操作流程也应该如此。[自动化测试][8] 对 DevOps 非常关键，它是 CALMS 框架的第二个原则（其中的 “C”代表“文化”）。
你怎样才能实现这一点？邀请员工公开表达他们认为工作的哪些方面可以自动化，然后--这里是关键的部分--支持实现自动化所需的设施。这可能意味着每年花 600 美元订阅一个软件程序、一套完整的企业应用现代化解决方案或开发人员的两天时间来建立一个新的工具在内部使用。
无论哪种方式，你都应该评估自动化的好处，考虑你可以为每个人节省多少时间。DevOps 的统计数据不断表明，现代公司通过整合这些有益的原则，年复一年地得到了很大的改善。
### 探索成功的新工作方式
文化转变不会在一夜之间发生。不过，你越早开始，就越早看到结果。根据我的经验，当变化是对以前的真正改进时，人们会接受它。DevOps 为这种改进提供了一个框架。无论你是刚刚在你的组织中开始使用 DevOps，还是仅仅想改善你现有的文化，请考虑以上几点以及它们与你组织的未来的关系。
--------------------------------------------------------------------------------
via: https://opensource.com/article/23/1/tips-effective-devops-culture
作者：[Yauhen Zaremba][a]
选题：[lkxed][b]
译者：[lxbwolf](https://github.com/lxbwolf)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/yauhen-zaremba
[b]: https://github.com/lkxed
[1]: https://opensource.com/resources/devops
[2]: https://opensource.com/article/22/2/devops-documentation-maturity
[3]: https://opensource.com/sites/default/files/2022-12/devop.png
[4]: https://enterprisersproject.com/user/gene-kim
[5]: https://opensource.com/article/22/7/awesome-ux-cli-application
[6]: https://opensource.com/sites/default/files/2022-12/devop-venn.png
[7]: https://opensource.com/article/22/11/git-concepts
[8]: https://opensource.com/article/20/7/open-source-test-automation-frameworks