Merge remote-tracking branch 'LCTT/master'

This commit is contained in:
Xingyu Wang 2020-09-13 23:18:01 +08:00
commit 4cea1b6f9b
6 changed files with 213 additions and 225 deletions

View File

@ -1,24 +1,25 @@
[#]: collector: (lujun9972) [#]: collector: (lujun9972)
[#]: translator: (geekpi) [#]: translator: (geekpi)
[#]: reviewer: ( ) [#]: reviewer: (wxy)
[#]: publisher: ( ) [#]: publisher: (wxy)
[#]: url: ( ) [#]: url: (https://linux.cn/article-12612-1.html)
[#]: subject: (Recognize more devices on Linux with this USB ID Repository) [#]: subject: (Recognize more devices on Linux with this USB ID Repository)
[#]: via: (https://opensource.com/article/20/8/usb-id-repository) [#]: via: (https://opensource.com/article/20/8/usb-id-repository)
[#]: author: (Alan Formy-Duval https://opensource.com/users/alanfdoss) [#]: author: (Alan Formy-Duval https://opensource.com/users/alanfdoss)
利用这个 USB ID 仓库识别更多 Linux 上的设备 利用这个 USB ID 仓库识别更多 Linux 上的设备
====== ======
一个包含了所有已知 USB 设备 ID 的开源项目。
![Multiple USB plugs in different colors][1]
市场上有成千上万的 USB 设备:键盘、扫描仪、打印机、鼠标和其他无数的设备都能在 Linux 上工作。它们的供应商详情都存储在 USB ID 仓库中。 > 这是一个包含了所有已知 USB 设备 ID 的开源项目。
![](https://img.linux.net.cn/data/attachment/album/202009/13/225426zpfbfopxhjxomuxf.jpg)
市场上有成千上万的 USB 设备:键盘、扫描仪、打印机、鼠标和其他无数的设备,都能在 Linux 上工作。它们的供应商详情都存储在 USB ID 仓库中。
### lsusb ### lsusb
Linux `lsusb` 命令列出了连接到系统的 USB 设备的信息,但有时信息不完整。例如,我最近注意到我的一个 USB 设备的品牌没有被识别。设备是可以使用的,但是在列出我所连接的 USB 设备的详情中没有提供任何识别信息。以下是我的 `lsusb` 命令的输出: Linux `lsusb` 命令列出了连接到系统的 USB 设备的信息,但有时信息不完整。例如,我最近注意到我的一个 USB 设备的品牌没有被识别。设备是可以使用的,但是在列出我所连接的 USB 设备的详情中没有提供任何识别信息。以下是我的 `lsusb` 命令的输出:
``` ```
$ lsusb $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
@ -29,12 +30,11 @@ Bus 001 Device 005: ID 051d:0002 American Power Conversion Uninterruptible Power
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
``` ```
正如你在最后一栏中看到的,有一个设备没有制造商描述。要确定这个设备是什么,我必须对我的 USB 设备树进行更深入的检查。幸运的是,`lsusb` 命令有更多的选项。其中一个选项是 `-D device`,来获取每个设备的详细信息,正如手册页面所解释的那样 正如你在最后一栏中看到的,有一个设备没有制造商描述。要确定这个设备是什么,我必须对我的 USB 设备树进行更深入的检查。幸运的是,`lsusb` 命令有更多的选项。其中一个选项是 `-D device`,来获取每个设备的详细信息,正如手册页面所解释的那样
> “不会扫描 /dev/bus/usb 目录,而只显示给定设备文件所属设备的信息。设备文件应该是类似 /dev/bus/usb/001/001 这样的文件。这个选项会像 **v** 选项一样显示详细信息,但你必须是 root 用户才行。" > “不会扫描 `/dev/bus/usb` 目录,而只显示给定设备文件所属设备的信息。设备文件应该是类似 `/dev/bus/usb/001/001` 这样的文件。这个选项会像 `v` 选项一样显示详细信息,但你必须是 root 用户才行。"
我认为如何将设备路径传递给 lsusb 命令并不容易但在仔细阅读手册页和初始输出后我能够确定如何构造它。USB 设备驻留在 UDEV 文件系统中。它们的设备路径始于 USB 设备目录 `/dev/bus/usb/`。路径的其余部分由设备的总线 ID 和设备 ID 组成。我的非描述设备是 Bus 001、Device 002被翻译成了 001/002完成路径 `/dev/bus/usb/001/002`。现在我可以把这个路径传给 `lsusb`。我还会用管道传给 `more`,因为这里往往有很多信息:
我认为如何将设备路径传递给 `lsusb` 命令并不容易但在仔细阅读手册页和初始输出后我能够确定如何构造它。USB 设备驻留在 UDEV 文件系统中。它们的设备路径始于 USB 设备目录 `/dev/bus/usb/`。路径的其余部分由设备的总线 ID 和设备 ID 组成。我的无描述设备是 `Bus 001 Device 002`,被翻译成了 `001/002`,完成的路径为 `/dev/bus/usb/001/002`。现在我可以把这个路径传给 `lsusb`。我还会用管道传给 `more`,因为这里往往有很多信息:
``` ```
$ lsusb -D /dev/bus/usb/001/002 |more $ lsusb -D /dev/bus/usb/001/002 |more
@ -78,17 +78,15 @@ Device Descriptor:
        HID Device Descriptor:         HID Device Descriptor:
``` ```
不幸的是,这里并没有提供我希望找到的细节。初始输出中出现的两个字段 `idVendor``idProduct` 都是空的。这里有些帮助,因为往下扫描一下,就会发现 **Mouse** 这个词。所以,这个设备就是我的鼠标。 不幸的是,这里并没有提供我希望找到的细节。初始输出中出现的两个字段 `idVendor``idProduct` 都是空的。这有些帮助,因为往下看一下,就会发现 `Mouse` 这个词。所以,这个设备就是我的鼠标。
## USB ID 仓库 ### USB ID 仓库
这让我不禁想知道如何才能填充这些字段,不仅是为了自己,也是为了其他 Linux 用户。原来已经有了一个开源项目:[USB ID Repository][2]。它是一个公共仓库,它包含了 USB 设备中使用的所有已知 ID。它也被用于各种程序中包括 [USB Utilities][3],用于显示人类可读的设备名称。 这让我不禁想知道如何才能填充这些字段,不仅是为了自己,也是为了其他 Linux 用户。原来已经有了一个开源项目:[USB ID 仓库][2]。它是一个公共仓库,它包含了 USB 设备中使用的所有已知 ID。它也被用于各种程序中包括 [USB Utilities][3],用于显示人类可读的设备名称。
![The USB ID Repository Site][4] ![The USB ID Repository Site][4]
(Alan Formy-Duval, [CC BY-SA 4.0][5]) 你可以从网站上或通过下载数据库来浏览特定设备的仓库。也欢迎用户提交新的数据。我要为我的鼠标提交数据,因为它没有在里面。
你可以从网站上或通过下载数据库来浏览特定设备的仓库。也欢迎用户提交新的数据。这是我为我的鼠标做的,它是没有的。
### 更新你的 USB ID ### 更新你的 USB ID
@ -96,14 +94,12 @@ USB ID 数据库存储在一个名为 `usb.ids` 的文件中。这个文件的
在 Ubuntu 18.04 中,这个文件位于 `/var/lib/usbutils`。要更新数据库,使用命令 `update-usbids`,你需要用 root 权限或 `sudo` 来运行。 在 Ubuntu 18.04 中,这个文件位于 `/var/lib/usbutils`。要更新数据库,使用命令 `update-usbids`,你需要用 root 权限或 `sudo` 来运行。
``` ```
`$ sudo update-usbids` $ sudo update-usbids
``` ```
如果有新文件,它就会被下载。当前的文件将被备份,并被替换为新文件: 如果有新文件,它就会被下载。当前的文件将被备份,并被替换为新文件:
``` ```
$ ls -la $ ls -la
total 1148 total 1148
@ -113,8 +109,7 @@ drwxr-xr-x 85 root root   4096 Nov  7 08:05 ..
-rw-r--r--  1 root root 551472 Jan 15 00:34 usb.ids.old -rw-r--r--  1 root root 551472 Jan 15 00:34 usb.ids.old
``` ```
最新版本的 Fedora Linux 将数据库文件保存在 `/usr/share/hwdata` 中。而且,没有更新脚本。相反,数据库被维护在一个名为 `hwdata` 的包中。 最新版本的 Fedora Linux 将数据库文件保存在 `/usr/share/hwdata` 中。而且,没有更新脚本。而是,数据库由一个名为 `hwdata` 的软件包维护。
``` ```
# dnf info hwdata # dnf info hwdata
@ -129,7 +124,7 @@ Source       : hwdata-0.332-1.fc31.src.rpm
Repository   : @System Repository   : @System
From repo    : updates From repo    : updates
Summary      : Hardware identification and configuration data Summary      : Hardware identification and configuration data
URL          : <https://github.com/vcrhonek/hwdata> URL          : https://github.com/vcrhonek/hwdata
License      : GPLv2+ License      : GPLv2+
Description  : hwdata contains various hardware identification and configuration data, Description  : hwdata contains various hardware identification and configuration data,
             : such as the pci.ids and usb.ids databases.              : such as the pci.ids and usb.ids databases.
@ -137,7 +132,6 @@ Description  : hwdata contains various hardware identification and configuratio
现在我的 USB 设备列表在这个之前未命名的设备旁边显示了一个名字。比较一下上面的输出: 现在我的 USB 设备列表在这个之前未命名的设备旁边显示了一个名字。比较一下上面的输出:
``` ```
$ lsusb $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
@ -162,8 +156,8 @@ via: https://opensource.com/article/20/8/usb-id-repository
作者:[Alan Formy-Duval][a] 作者:[Alan Formy-Duval][a]
选题:[lujun9972][b] 选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID) 译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID) 校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出

View File

@ -1,17 +1,18 @@
[#]: collector: (lujun9972) [#]: collector: (lujun9972)
[#]: translator: (silentdawn-zz) [#]: translator: (silentdawn-zz)
[#]: reviewer: ( ) [#]: reviewer: (wxy)
[#]: publisher: ( ) [#]: publisher: (wxy)
[#]: url: ( ) [#]: url: (https://linux.cn/article-12611-1.html)
[#]: subject: (Military looks to ultraviolet networks for secure battlefield communication) [#]: subject: (Military looks to ultraviolet networks for secure battlefield communication)
[#]: via: (https://www.networkworld.com/article/3572372/military-looks-to-ultraviolet-networks-for-secure-battlefield-communication.html) [#]: via: (https://www.networkworld.com/article/3572372/military-looks-to-ultraviolet-networks-for-secure-battlefield-communication.html)
[#]: author: (Patrick Nelson https://www.networkworld.com/author/Patrick-Nelson/) [#]: author: (Patrick Nelson https://www.networkworld.com/author/Patrick-Nelson/)
美国军方正探索战场保密通信用紫外网络 美国军方正探索战场保密通信用紫外网络
====== ======
美国军方想以开放空间传输的紫外线为载体,为士兵开发新的更安全的通讯网络。
智库 > 美国军方想以开放空间传输的紫外线为载体,为士兵开发新的更安全的通讯网络。
![](https://images.idgesg.net/images/article/2018/02/security_safety_guarding_mobile_laptop_endpoint_protection_thinkstock_906578404-100750806-large.jpg)
美国军方研究者之所以探索战场环境下的紫外光通信的应用,是因为这种技术可能实现敌对方无法侦测的通信。 美国军方研究者之所以探索战场环境下的紫外光通信的应用,是因为这种技术可能实现敌对方无法侦测的通信。
@ -21,11 +22,9 @@
这个研究由美军作战能力发展司令部 [军队研究实验室][2] 主导,其重点是开发一个基础架构,为未来研究提供可量化环境,在该环境下,己方既可以使用紫外通信,也能够避免敌对方的侦测。研究过程中他们还有另外两个发现: 这个研究由美军作战能力发展司令部 [军队研究实验室][2] 主导,其重点是开发一个基础架构,为未来研究提供可量化环境,在该环境下,己方既可以使用紫外通信,也能够避免敌对方的侦测。研究过程中他们还有另外两个发现:
* 最差情况,即敌对方探测器与己方发射器在视线范围内,但方接收器不在视线范围内,问题不像想象中严重。 * 最差情况,即敌对方探测器与己方发射器在视线范围内,但方接收器不在视线范围内,问题不像想象中严重。
* 转换紫外线发射器的发射方向不是降低敌对方探测到通信信号可能性的有效方式。 * 转换紫外线发射器的发射方向不是降低敌对方探测到通信信号可能性的有效方式。
研究者计划分析下面四种场景,场景中涵盖了己方紫外发射器、友方接收器、敌对方探测器相对位置关系: 研究者计划分析下面四种场景,场景中涵盖了己方紫外发射器、友方接收器、敌对方探测器相对位置关系:
* 友方接收器、敌对方探测器都在发射器的视线范围内。 * 友方接收器、敌对方探测器都在发射器的视线范围内。
@ -33,17 +32,13 @@
* 敌对方探测器在发射器的视线范围内,但友方接收器不在视线范围内(最差条件)。 * 敌对方探测器在发射器的视线范围内,但友方接收器不在视线范围内(最差条件)。
* 友方接收器、敌对方探测器均不在视线范围内。 * 友方接收器、敌对方探测器均不在视线范围内。
假定敌对方试图通过时域上的光子计数来发现相干通信信号,进而判定正在进行通信。 假定敌对方试图通过时域上的光子计数来发现相干通信信号,进而判定正在进行通信。
科学家们承认这么一个事实,即越靠近发射器,信号越容易被侦测。所以紫外通信中发射器的有效使用依赖于对敌对方探测器位置的准确感知。 科学家们承认这么一个事实,即越靠近发射器,信号越容易被侦测。所以紫外通信中发射器的有效使用依赖于对敌对方探测器位置的准确感知。
我们提供了一个基础框架,使得对紫外通信系统实际可探测性与期望性能间差距的根本限制因素的研究得以进行。 研究者之一Robert Drost 博士如是说。 我们提供了一个基础框架,使得对紫外通信系统实际可探测性与期望性能间差距的根本限制因素的研究得以进行。 研究者之一Robert Drost 博士如是说。
“我们的研究确保了团队O紫外波段用于通信的潜力及有限性有了根本上的理解。我坚信这种理解将影响到未来军队网络通信能力的发展。” “我们的研究确保了团队对紫外波段用于通信的潜力及有限性有了根本上的理解。我坚信这种理解将影响到未来军队网络通信能力的发展。”
欢迎通过 [Facebook][3] 和 [LinkedIn][4] 加入 Network World 社团,点评顶级话题。
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
@ -51,8 +46,8 @@ via: https://www.networkworld.com/article/3572372/military-looks-to-ultraviolet-
作者:[Patrick Nelson][a] 作者:[Patrick Nelson][a]
选题:[lujun9972][b] 选题:[lujun9972][b]
译者:[silentdawn-zz](https://github.com/译者ID) 译者:[silentdawn-zz](https://github.com/silentdawn-zz)
校对:[校对者ID](https://github.com/校对者ID) 校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出

View File

@ -1,140 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (JonnieWayy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Leaving Google: Five Years On)
[#]: via: (https://theartofmachinery.com/2020/08/04/leaving_google.html)
[#]: author: (Simon Arneaud https://theartofmachinery.com)
Leaving Google: Five Years On
======
About five years ago now, I handed in my Google employee badge and walked out of the Sydney Google office to start a new life of self-employment. I figured I should write up this story because I got a lot out of reading [Michael Lynchs][1]. As you can see, its still taken me a couple of years to get around to writing this post, but I finally told myself that if I dont write it for the fifth anniversary, I never will.
This post is kind of long, but I hope it has something useful for new developers who are interested in working at a big tech company, or for big company employees who are wondering what its like to quit. Ill talk about my story of getting into, working at and quitting Google, and what Ive done since. Feel free to ask if you want more detail about something, though I already have a lot of blog posts to write, so I cant promise anything in-depth straight away.
Also, at the risk of labouring the obvious: I havent worked at Google for five years, so dont take this story as a literal description of Google today or what all Google employees experience. However, I think a lot of its still relevant to tech careers in general.
### The windy road to Google
I got my first paid programming job in 2005. It was working at the local power company, taking some old Pascal code and making it work on a different OS with a different compiler. It was basically just a summer job for extra money while doing the maths and physics degree Id started that same year. They were happy to have an undergraduate who could do the job; I was just blown away that these grown ups were not only interested in my programming hobby, but actually going to give me real money for it.
I kept doing stuff like that until I graduated in 2007. I liked programming work, and Google was a cool company doing cool programming stuff, so I applied for an internship. The Google interview process was famous for being tough, so I spent weeks practising on all the Google interview problems I could find online. I dont think the process has changed much in 13 years: I submitted a résumé, and I got invited to a few rounds of phone interviews that were mostly algorithmic problems (I remember a dynamic programming one and a divide-and-conquer geometric one). I passed the initial interviews, and got invited to come to Sydney for a day of on-site interviews with Google engineers. I went home and waited for what felt like an eternity for the phone call from Google HR. I got rejected.
Its natural to feel bad about our rejections and failures, so we dont talk about them much. But for the same reason, other people dont talk about theirs, which only makes things worse. When I _did_ get into Google later, I felt like there must be something a bit wrong with me as a “ex-reject”, but one day I was at a table with a bunch of colleagues and the conversation came up. Thats when I discovered that actually a lot of people around me had been rejected at least once. I wasnt even the “worst”. One guy joked that he must have only got in because Google HR got tired of rejecting him. Im talking about some pretty impressive engineers, as well — some were responsible for code I use all the time, and I bet you use, too.
Companies that do interviews usually interview two or more candidates for each hire. That means there are more rejections around than acceptances, so the average interviewee gets rejected more often than not. Yet we keep forgetting that. Four developers go into an interview; one gets hired, the other three rant on social media about how the interview was totally flawed because they personally got rejected. Sure, interviews are far from perfect, but we need to stop taking them so personally.
Rejection and failure arent so bad as long as you can figure out what went wrong and how you could improve yourself. The Google interviews were heavily algorithm-oriented, and I fumbled through a lot of them but definitely didnt come out shining.
After the Google rejection, I got two things and took a kind of sabbatical year. The first thing was an Australian Business Number (ABN) that I used to do maths and science tuition, as well as tech job contracts. The other thing I got was a library card at the university science and tech library. I wasnt planning to interview at Google again, but the interview experience told me there was a lot I didnt know. Id give tutorials in the library and read books in between. By the way, a few people thought I was weird for doing all that accounting and stuff for my tuition business, when most tutors just did it cash-in-hand. But I learned a lot thats helped me later in life, so I dont regret a thing.
In 2009, I did a maths honours year (a.k.a, bachelors fourth year) based on the work of a magician-turned-mathematician called Persi Diaconis. The computer science department let me take one of their algorithms units as part of it.
As I said, I hadnt planned to interview for Google again, but let me fast forward to how it happened. Id been studying Japanese since high school, so in 2012 I decided to try living in Tokyo. That mostly worked out, except I made one pretty big mistake: I didnt have any paper qualifications in Japanese, so it was really hard to get job interviews. Eventually, a friend of mine who had been accepted at Google suggested I give it another try. Like all Google offices, the official business language at Google Tokyo is English, so they didnt require me to have Japanese qualifications.
### Google interviews, again
My friend gave me a recommendation to Google HR. That definitely helps, but dont get too excited if you get a recommendation, yourself. It ensures your résumé gets noticed (not trivial) and cuts one of the phone interviews, but you still have to pass the remaining phone and on-site interviews.
This time I practised using problems from [Project Euler][2] and [Google CodeJam][3]. I had to do some live programming in a Google Doc during the phone interview, which was a bit awkward, but otherwise the phone interviews went okay. Then I got invited to the Mori Tower office in Roppongi for a day of onsite interviews.
![Mori Tower in Tokyo, where I interviewed for Google. It's the sixth tallest building in the city, which means it's huge. \(Photo from here.\)][4]
My first interview went terribly. I got brain freeze. I knew I could solve the problem, but I couldnt think straight until the interviewer walked out of the room. Instantly I relaxed and recognised it as a ternary search problem. That was pretty frustrating, but I decided to just keep going and see how the rest of the interviews went.
Two of the interviews were bad. One is still today the worst interview question Ive ever had. The interviewer said, “You run a program twice with the same input and get different results. Tell me why.” I replied, “When thats happened on modern computers and I didnt expect it, its usually been a race condition.” He just said, “No, its not a race condition,” and looked at me waiting for my next answer. The question could have been a great question if hed been interested in a discussion, but apparently he really did just want to play “guess the secret number”. For almost everything I said, he simply replied, “No.” Apparently the program was fully deterministic, stored no state, and had no dependence on the environment (such as disk or the real time clock), but gave different results each time it was executed. I suspect we had a different understanding of what “stored state” or “environment” meant or something, but I had no way to tell. At one point (getting desperate) I tried asking if temperature changes in the electronic components were having an effect, and he said, “No, that would be a race condition, and Ive already told you its not a race condition.” Eventually the interview ended, and I still dont know what that secret number was.
Im telling that story because Ive heard much tamer horror stories being told as proof that interviewers are terrible people who hate interviewees. But, contrary to popular stereotype, most of the interviews that day were basically okay, and the interviewers were friendly and respectful. Interviewing is genuinely really hard, too, so its good to cut interviewers some slack. Hopefully, the “guess the number” interviewer got feedback from Google HR that his question just wasnt helpful for making hiring decisions.
This time, the interviews resulted in an offer, but with a little catch: the job was in Sydney, working as a site reliability engineer. Id never heard of SRE before, but I had a phone call with a senior Sydney SRE who explained that hed noticed my experience doing embedded engineering in the natural gas industry, and thought SRE would be a good fit because of a similar emphasis on reliability and fitting tight constraints.
Having spent about a year building up a life in Tokyo, I didnt want to drop everything and move to Sydney, but no way in hell was I in a position to turn down an offer from Google. I did make one very stupid mistake when talking with the recruiter: I got asked how much money I was making, and I blurted it right out. [Dont do that.][5] It means it doesnt matter what happens in the interview, or how much you were being underpaid at your previous job, or whatever; youll probably either be rejected or get offered some token amount on top of your old pay and be treated as crazy and unreasonable if you try to negotiate more. In my case, I was making much less than even an entry-level position at Google. I cant say for sure thats the whole story, but in 2013 I moved to Sydney to be a new-grad level SRE on Google Maps.
### Google Maps SRE at Sydney
A product like Maps is really several software projects, each with its own team of developers. Even a feature like route-finding is really multiple software projects — from gathering transport timetable data, to calculating routes, to rendering results, etc. There are two sides to the SRE job: One is being oncall for the various projects, responding in real time to any production incidents. The other side of the job (when there arent any fires to fight) is applying experience from production incidents to other projects and pre-emptively finding ways they could go wrong, or opportunities to make them perform better. Googles SREs also act like an internal consulting group for developers with questions about deployment practices, or automation, or monitoring, or things like that.
The work was pretty intense. As a team, we were expected to deal with at least one production incident a week, or else take on responsibility for more services. Every week, all the SREs in Sydney would get together to swap stories of failures that had happened, or new tips for how to make things work better. The learning curve felt like being an undergraduate again.
I sometimes get a shocked, “But dont you miss the benefits?!” from people who hear I chose to quit Google. The material benefits (like meals, etc.) are definitely nice, but theyre things that you can buy, so, no, theyre not things I miss. If you ask me what I miss, Id say its the people who worked there. Contrary to what you might have heard, arrogant people dont enjoy working at places like Google. Theres an infamous story of a narcissist who got a job at Google and kept embarrassing himself by pretending to be a top expert in all kinds of things. He lasted less than half a year before leaving. Overall, the culture was very low on arrogance and blame slinging and politics compared to other places Ive worked at. On the other hand, Google doesnt have a monopoly on nice colleagues.
Theres one kind of corporate politics that was a big problem, though. Getting promoted required “demonstrating impact”, and it was well known that the easiest way to do that was to launch some new thing (not the only way, but easiest). The result was Googlers who were more interesting in promoting their own alpha-quality, prototype solutions to problems than improving existing solutions. We had a standing joke in SRE that there were two kinds of software inside Google: old things that worked well but were deprecated and were Ungoogly to even consider using, and hot new things that were the 100% official tools to use today even though they didnt work yet. As SREs, we often saw first hand what went wrong with the new hotness (which sometimes became the old deprecated thing before it even got out of alpha). ([Ive talked more in depth about this kind of thing before.][6])
This isnt something that we cynical SREs just imagined; it was openly recognised as a problem in the company, and I remember being reassured that promotion committees had started looking for evidence of impact through things like maintenance work.
### The promotion application
In 2015, after working at Google for a couple of years, my manager told me it really was about time to apply for a promotion above my new-grad level. The promotion process was centrally managed through promotion committees twice a year. Youd make your application and back it up with a short description of projects youd worked on, supported by references from your colleagues. The committee would do a review and give you the thumbs up or down. Your managers recommendation alone wasnt enough because your manager had an incentive to get you promoted. Having high-ranked staff under you helps your own career advancement.
To cut a long story short, I made my application and the committee said no. Actually, it was a pretty damning no. I dont remember the response in detail, but it felt like the committee had just gone hunting through my application looking for things to be dismissive about. For example, one project Id worked on was an internal tool that was building up a backlog of feature requests. Id looked at the project and figured out that the root problem was that it had outgrown the key-value store it had been built on, and needed a proper database. I argued for switching to a relational DB, and I went ahead and implemented it: schema, data migration, queries, the live site migration, etc. The new queries were much faster, and (more importantly) the new features could be supported efficiently. One problem I had to solve before migrating was that most of the code wasnt covered by tests, and that was because most of the code wasnt testable. I refactored the code using dependency injection and [other tricks Ive talked about before][7], and that let me build a regression test suite. I remember that project was mostly dismissed with the comment that writing unit tests is “new-grad-level work”.
My manager was really supportive and wrote an appeal. He didnt show it to me, but I think it was several pages that could be reduced down to “WTF” (argued more eloquently and with more detail). Here are some of the reasons I also thought this response was a bit WTF:
Google SRE has a concept of “point-personship”. The point person for a project has two roles: One is to know the software project to a greater depth than other SREs, so that you can answer questions they might have. The other role is to be the first point of contact for the devs on the project itself, so that they can get answers to all their SRE questions. The Google job ladder guide said that point-personship wasnt required at the new-grad level, but looked good for promotion. As my application had said, I was point person for three projects.
My point-personships made it easy to find senior developers who agreed to help support my promotion application. They were all shocked when they found out I was new-grad level. Theyd all agreed to support my application assuming I was already at a higher level.
On my application, I mentioned being a mentor for a group of new-grad interns we had. When I made my application, many of them were being hired as permanent employees. I was senior enough to be their mentor, but firmly not enough to be promoted above their level.
The response to my managers appeal took a completely different tack from the original review. This time I was “strongly exceeding expections for my [new-grad] job level”, but the problem was that they just needed a little bit more time to be sure I could be promoted to new-grad-plus-one. I was told I could keep strongly exceeding expectations for another six months until the next promotion cycle, and maybe Id get a promotion then. The appeal was over; that was the deal.
I wrote an email that I was taking another option. Like many tech companies, Google has an employee stock program. Youre given a nominal grant when you start work, and you actually receive real shares at various “vestment” milestones. My next stock vestment was a couple of months away. The day after that, I wouldnt be working for Google any more.
### My reasons for quitting
The decision to quit any job isnt easy, and one day you might face the same decision. Here are some of the factors that helped me make my choice. ([Some of this thinking I explained in more depth in an older post.][8])
If you think about it, given that I wasnt literally a new grad, Googles review should have been something like, “Youre doing some things very wrong. You simply wont get a promotion until you improve at X and Y and Z.” Being told, “Youre strongly exceeding expectations, but we need another six months or so,” didnt make any sense. No one raised concerns about whether I was capable of doing my job. I was getting a lot of excuses, but not any useful feedback to help me do better. (NB: sometimes you have to explicitly ask for feedback. Managers can fall into the trap of defending the performance ratings they give, instead of thinking about the reports need for feedback.)
I also wasnt sure what the promotion committee might see in six months that they hadnt already seen in two years. Why wouldnt they ask for another six months again? If I needed to prove myself for years to get new-grad-plus-one, how old would I be before I got new-grad-plus-two?
When I first started at Google, my job level was irrelevant because I was learning so much and getting a famous company on my résumé. Two years in, the equation was different. The value of the future that Google was offering me was waning, while the value of opportunities outside Google had gone up. Google job levels mean practically nothing outside Google. In the past five years, plenty of people have asked about what I did at Google, but not a single person has asked me what my Google job level was, or called me a new grad. Although I took a financial hit short term, I effectively got a promotion that day I handed in my badge.
Credit where its due, Google didnt do anything like this, but its common in other companies: trying to make employees feel guilty about asking for pay rises. At a place I worked a few years ago, some engineers asked for a payrise after a highly successful launch following a lot of crunch time. Management played the victim and accused the engineers of “twisting their arms”. (About six months later they lost most of their engineering team.) If youre genuinely co-operative about the timing of when you might quit (e.g., after a launch date, not the week before) and willing to document your knowledge and clean up after yourself, etc., youre only twisting your employers arms by as much as theyre underpaying you.
Nominally, I left a large amount of unvested stock behind at Google. But stock isnt yours until its yours. I just had a promise of being paid shares in future, and I could convert it to an equivalent pay rate by dividing it by time required. Working two months for that vestment was worth it. Working years for the remaining vestments wasnt. Dont fall for endowment bias.
When shouldnt you quit? Well, are youre getting a good deal compared to what you could get elsewhere? Corporate career paths arent mandated by heaven; theyre a series of business offers representing what the company estimates youll work for. If you think youre getting a good deal (considering all compensation and intangibles like the work environment), great! Otherwise, its time to think hard about what to do next.
### After Google
I should warn you that I took a strategy that was high growth, at the expense of short-term stability. If stability is more important to you, youll do things differently. My plan A, plan B and plan C all fell apart, and I ended up spending a few months struggling to find a way. Eventually I got a contract at a small web shop, working on [Safety Town][9], a government road safety website for kids. The pay was a big cut from Google, especially considering it was my first work in months. But, you know, I really enjoyed that project. Sure, it wasnt “cool” like Google, and maybe some kids at school didnt think it was cool. On the other hand, at Google I was a tiny part of a huge thing. Safety Town had a small team, with everyone playing a crucial role. For part of the Safety Town project, I was _the_ backend engineer, and Safety Town was the only thing I had to worry about at that time. And, heck, maybe some kids have learned a thing or two about road safety from that website. Ive done plenty of projects since then, most of them bigger, but I still show people Safety Town.
![Screenshot of Safety Town home page, owned by Australian NSW government.][10]
I remember a poster in the Sydney Google office that said, “Shoot for the moon! Even if you miss, youll land among the stars!” Its easy to forget that you can have a quality life even if youre not doing moonshots for famous companies, or doing moonshots for startups.
Heres one trick that helped me get contracts. Id go to Sydney tech events, stand within view of the job board, and wait until I saw someone writing on it. Suppose they were writing about CSS development for an insurance company project. Even if I werent especially interested in CSS or insurance, Id wander over and say, “Hi, what kind of insurance project is that?” Its the easiest conversation starter because their heads full of the project while theyre trying to fit it into a tiny space on the job board. Usually the conversation still wouldnt lead to a job for me, but occasionally Id discover something I could help with. Some events dont have a job board, but the organisers are often glad to offer the microphone to someone for a few minutes. It adds community engagement to their events.
I got a major break after working on a website for government procurement, just because I learned to not be so clueless about government procurement. Its hard to say exactly how much that knowledge was worth, but less than a year afterwards I signed a government contract for about 40% more than I would have hoped was possible before. (I dont do so much government and big enterprise work nowadays, though.)
After about a year and a half, I had my own one-person company. As I built up a reputation, I gradually got more SRE-like work. Basically, doing dev work was my “in”, then several months later Id get contacted by someone who needed SRE/DevOps help and remembered me. I actually like both SRE and pure dev work, but supply and demand means SRE work is good business. I can still do programming in my spare time.
Speaking of which, work/life balance is my favourite thing about my new lifestyle. No one pays me between contracts, but I can make the most of it by learning new things doing side projects. After one long, intense contract, I took a break and did [a month-long backpacking trip exploring rural Japan][11]. It was a trip Id wanted to do for a long time, but before Google I needed more money, and during Google I needed more time. Being self-employed is far from stress free and isnt for everyone, but theres stress that makes you feel dead, and theres stress that makes you feel more alive. For me, self-employment is the second kind, and Id say Ive been less stressed overall in the past five years than I was while at Google. In my case, at least, I can honestly say I dont regret joining Google when I did, and I dont regret leaving when I did, either.
--------------------------------------------------------------------------------
via: https://theartofmachinery.com/2020/08/04/leaving_google.html
作者:[Simon Arneaud][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://theartofmachinery.com
[b]: https://github.com/lujun9972
[1]: https://mtlynch.io/why-i-quit-google/
[2]: https://projecteuler.net
[3]: https://codingcompetitions.withgoogle.com/codejam
[4]: https://theartofmachinery.com/images/leaving_google/mori-tower.jpg
[5]: https://www.kalzumeus.com/2012/01/23/salary-negotiation/
[6]: https://theartofmachinery.com/2019/03/19/hello_world_marketing.html
[7]: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html
[8]: https://theartofmachinery.com/2018/10/07/payrise_by_switching_jobs.html
[9]: https://www.safetytown.com.au/
[10]: https://theartofmachinery.com/images/leaving_google/safetytown.png
[11]: https://theartofmachinery.com/2018/03/23/seto_trip_1.html

View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972) [#]: collector: (lujun9972)
[#]: translator: ( ) [#]: translator: (MjSeven)
[#]: reviewer: ( ) [#]: reviewer: ( )
[#]: publisher: ( ) [#]: publisher: ( )
[#]: url: ( ) [#]: url: ( )

View File

@ -0,0 +1,139 @@
[#]: collector: (lujun9972)
[#]: translator: (JonnieWayy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Leaving Google: Five Years On)
[#]: via: (https://theartofmachinery.com/2020/08/04/leaving_google.html)
[#]: author: (Simon Arneaud https://theartofmachinery.com)
离开 Google五年以来
======
大约五年前的今天,我上交了 Google 员工证,然后走出来悉尼 Google 办公室,开启了一段自谋职业的崭新生活。我认为我应该详述一下这个故事,因为我通过阅读 [Michael Lynch][1] 的作品而收获颇丰。正如你所看到的,我仍然花费了几年时间才开始考虑写这篇文章,但是最终我告诉自己,倘若我不在五周年纪念日写它,我就永远也不会写了。
这篇文章有点儿长,但是我希望它对那些对于在大型技术公司工作感兴趣的新开发人员或是想要离职的大型企业雇员能够有所帮助。我将谈谈我进入 Google在 Google 工作,以及退出 Google 的故事,还有我自开始以来所做的事情。尽管我已经写了很多博文,但是如果想知道更多关于某事的细节的话,随时可以提问,因此我无法立即保证任何深入的事情。
同样地,冒着显而易见的劳工风险:我已经有 5 年不在 Google 工作了,所以请不要以这个故事来作为当今 Google 或是 Google 雇员经历全貌的字面描述。但是,我认为其中的许多内容仍然与一般性的技术职业有关。
### 通往 Google 的艰辛道路
2005 年,我获得了第一份有偿编程工作,是在当地的电力公司工作,采用一些旧的 Pascal 代码并使其能够在另一款具有不同编译器的操作系统上运行。这基本上只是我为了挣外快而做的暑期工,同年我还刚刚开始攻读我数学和物理的学位。他们很高兴有一个本科生能够胜任这份工作。我被这些大人吓了一跳,因为他们不仅只是对我的编程爱好感兴趣,而且真的还会为此给我钱。
直到 2007 年毕业以前,我一直在做类似的工作。我喜欢编程工作,而 Google 是一家从事着很酷的编程工作的很酷的公司,因此我申请了实习。 Google 的面试过程以困难而著称,所以我花了好几个星期时间练习了所有我在网上能够找到的 Google 面试题。我认为 13 年里面试流程并没有发生太大的变化 —— 我提交了简历,受邀参加了几轮电话面试,这些面试问的几乎都是算法问题(我记得有一个动态规划问题和一个分治几何问题)。我通过了最初的几轮面试,然后受邀前往悉尼接受了由 Google 的工程师们进行的为期一天的现场面试。我回到家里,等待 Google HR 的电话,这个过程漫长得像是有一辈子。我被拒绝了。
对于我们收到的拒绝和失败感到难过很自然,因此我们并不会经常谈及它们。但是出于同样的原因,其他人也不会去谈论他们自己的失败,这只会使得情况变得更加糟糕。当我后来真的进入 Google 时,我觉得作为一个此前被拒绝过的人,我一定有哪里做得不对,但是有一天我和一群同事坐在一张桌子旁,开始交谈。那时候我才发现,实际上我身边的很多人都至少被拒绝过一次。我甚至都不是“最差的”。有个家伙开玩笑说,他肯定是因为 Google HR 厌倦了拒绝他才得以进来的。我也在谈论一些相当令人印象深刻的工程师 —— 有些人负责着我一直在用的代码,而我打赌你也在用。
进行面试的公司通常会为每个名额面试两名或更多的候选人。这意味着比起录用,会有更多的拒绝,所以普通的面试参与者被拒绝的可能性要大于被录用。然而我们一直忘记了这一点。四个开发人员参加面试,一个被录用了,其他三个在社交媒体上抱怨这场面试充满了缺陷,因为他们被拒绝了。当然,面试远非完美,但是我们需要停止如此个人化地谈论它们。
只要你能够找到问题所在并知道如何去改进自己,拒绝和失败就没有那么糟糕。 Google 的面试主要针对算法,我在其中磕磕拌拌地摸索,但绝对没有能够脱颖而出。
在被 Google 拒绝以后,我得到了两样东西,并进行了为期一年的休假。第一件东西是 Australian Business Number ABN ),我用它来做数学与科学课程,以及技术工作合同。我获得的另一样东西是一张大学科技图书馆的借书证。我当时并不打算再次去参加 Google 的面试,但是那次的面试经历告诉我还有很多东西是我所不知道的。我会在图书馆开设课程,并在期间阅读书籍。顺便说一句,有些人认为我为我的学费业务所做的所有这些财务工作和其他东西很奇怪,而大多数导数都只收现金。但是我学到了许多对我日后生活很有帮助的东西,所以我一点儿都不后悔。
2009 年,我进行了一个数学荣誉年(又称学士学位四年级),基于一名由魔术师转行的名叫 Persi Diaconis 的数学家的工作。计算机科学系让我将他们的算法单元之一作为其中的一部分。
就像我所说的那样,我本来并没有打算再去 Google 面试,但是让我快速地讲讲这是怎么发生的。我从高中就开始学习日语,因此在 2012 年,我决定尝试住在东京。这基本上行得通,除了我犯了一个相当大的错误 —— 我没有任何日语方面的纸质资质证明,因此很难获得工作面试。最终,我的一个已经被 Google 录用的朋友建议我再试一次。与 Google 所有的办事处一样, Google Tokyo 的官方商务语言是英语,因此他们不要求我具有日语资质证明。
### Google 面试,再一次
我的朋友向 Google HR 推荐了我。这绝对有帮助,但是如果你自己得到了被推荐的机会,也不要太过于兴奋。它所能够确保的是你的简历会被注意到(不太过潦草)并且免去一次电话面试,但你仍然得通过剩下的电话面试和现场面试。
这一次我用来自 [Project Euler][2] 和 [Google CodeJam][3] 的题进行练习。电话面试过程中,我不得不在 Google Doc 上进行一些在线编程,这有点儿尴尬,但是除此以外电话面试一切顺利。然后我受邀前往六本木的 Mori Tower 办公室进行了为期一天的现场面试。
![Mori Tower in Tokyo, where I interviewed for Google. It's the sixth tallest building in the city, which means it's huge. \(Photo from here.\)][4]
我的首个面试非常糟糕。我的脑子僵住了。我知道我能够解出那些题目,但是直到面试官走出房间我才想出答案。我立刻就感到很放松,并且意识到这是一个三元搜索问题。这是在是很令人沮丧,但是我觉得继续前进,看看剩下的面试进展如何。
其中的两次面试很糟糕。其中之一直至今日仍然是我遇到过的最糟糕的面试问题。面试官说:“你用同一输入运行一个程序两次,得到了两个不同的结果。告诉我这是为什么。”我回答道:“当这种情况在现代计算机上发生而且并不在我的预期之中时,通常是竞态条件。”他只说:“不,这不是竞态条件。”然后看着我等着我的下一个回答。如果他有兴趣讨论一下的话,这个问题本该是一个很棒的问题,但是很显然他实际上只想玩“猜猜神秘数”。对于我所说的几乎全部内容,他只是回答:“不。”显然,该程序完全是确定性的,不存储任何状态,并且不依赖于环境(例如磁盘或是实时时钟),但却在每次执行时都给出不同的结果。我怀疑我们对于“被存储的状态”或是“环境”的含义还是某些东西有着不同的理解,但是我无法区分。有一次(变得绝望了)我试着问电子元件的温度变化是否会有影响,而他说:“不,那会是一个竞态条件,我已经告诉过你这不是竞态条件了。”最终,面试结束了,而我仍然不知道那个秘密数字是什么。
我将这个故事的原因是,我听说过许多更为温和的恐怖故事,用以证明面试官是憎恶面试者的坏人。然而,与流行的刻板印象所相反的是,当天的大多数面试基本上都还可以,面试官也很友好并且很尊重人。面试也着实很困难,因此最好减少面试官的工作量。希望那个“猜数字”面试官从 Google HR 那里得到的反馈是,他的问题对于作出聘用决定没什么帮助。
这次,面试带来了一份要约,但是有一个小问题:这份工作在悉尼,担任站点可靠性工程师( SRE )。我以前从未听说过 SRE但是我和一位悉尼的资深 SRE 通了电话,他解释说他注意到了我在天然气行业从事嵌入式工程的经历,并且认为 SRE 会和适合我,由于类似的可靠性与拟合紧密约束方面的重心。
在东京花了大约一年时间来建立起自己的生活,我不想抛弃一切然后搬到悉尼,但是我绝不可能会拒绝一份来自 Google 的要约。与招聘人员交谈时,我确实犯了一个非常愚蠢的错误:我被问到当时能赚多少钱,然后我就脱口而出。[别这么做。][5] 这意味着在面试中发生了什么事情,或是你上一份工作中你的工资有多低,等等都无关紧要。你可能会被拒绝,或者会在原来的薪水基础上得到一些象征性的提升,并且如果你试图进一步协商,会被认为疯狂而又不合理。就我而言,我的收入甚至远远低于 Google 的入门级职位。我无法肯定地说这就是整个故事,但是在 2013 年我搬到了悉尼,在 Google Maps 成为了一名新毕业生级别的 SRE。
### Google Maps SRE 在悉尼
像 Maps 这样的产品实际上是若干个软件项目,每一个都有自己的开发人员团队。甚至诸如路线查找之类的功能实际上也涉及多个软件项目 —— 从交通时刻表数据收集,到线路计算,再到结果渲染,等等等等。 SRE 的工作包含两个方面:一方面是为各个项目提供待命,实时响应任何生产事故;另一方面(在无需救火时)则是将生产事故中所积攒的经验应用到其他项目中去,并且发现其中可能出错的方式,或是发现使其性能更好的机会。 Google 的 SRE 还需要像开发人员的内部咨询小组一样,对部署实践、自动化、监控或是类似的问题提供咨询。
这项工作相当紧张。作为一个团队,我们每周至少需要处理一次生产事故,否则就要承担更多服务的责任。每个礼拜,悉尼的所有 SRE 都会聚在一起,交流发生过的故障事件或是有关如何使事情更好地运转的新技巧。学习曲线感觉就像是再次成为了一名本科生。
我有时会感到震惊,听说我选择离开 Google 的人会问:“但是你不会想念这些好处吗?!”物质上的好处(例如伙食等等)绝对很棒,但是他们是你可以买到的东西,因此,不,他们不是我所想念的东西。如果你问我所想念的是什么,我会说是在那里工作的人们。与你可能听说过的不同,自大的人不喜欢在 Google 之类的地方工作。有一个臭名昭著的有关一个自恋者的故事,他在 Google 找了份工作,并假装自己是各方面的顶级专家,让自己尴尬不已。他待了不到半年就离开了。总的来说,与我工作过的其他地方相比,这里的文化在傲慢、指责以及政治方面很少。另一方面, Google 并没有垄断好同事。
不过,在有一种公司,政治是个大问题。晋升需要“展示影响”,而众所周知的是,要做到这一点最简单的方法是发布一些新事物(不是惟一的方法,但是最简单)。结果是 Googler 们比起改进现有的解决方案,对于推广他们自己质量一流的原型方案更感兴趣。在 SRE 之间,我们经常开玩笑说, Google内部有两种软件运行良好但是已经过时甚至不被考虑使用的旧东西以及现如今正在作为 100% 官方工具使用的热门新东西,即使它们还尚未能正常运行,作为 SRE我们经常亲眼看到新的热点事物出了什么问题有时甚至在脱离 alpha 之前它就已经成了过时的旧东西)。([我此前已经对这类事物进行了更为深入的讨论。][6]
这不是我们愤世疾俗的 SRE 所想象的东西;这在公司中被公认为是一个问题,而我记得令人放心的是促销委员会已经开始通过维护工作等方式寻找关于其影响的证据。
### 晋升申请
2015 年,在 Google 工作了两年之后,我的经理告诉我,现在是时候申请一个高于我新毕业生水准的晋升了。晋升过程每两年一次由晋升委员会进行集中管理。你可以先提出申请,然后加上一份对你所从事过的项目的简短描述,再加上同事的推荐信。委员会将会进行审查,然后给你赞成或反对的意见。仅仅有你经理的推荐是不够的,因为你的经历有想让你获得晋升的动机。手下有高级别的员工有助于你自己的职业发展。
长话短说,我提交了我的申请,而委员会说不。事实上,这是个相当糟糕的拒绝。我不记得详细的答复了,但感觉就像是委员会在我的申请中寻找可以轻视的东西。例如,我从事过的一个项目是一个内部工具,它建立起了功能需求的积压。我查看了这个项目,发现根本问题在于它已经超出了构建它的键值存储,需要一个合适的数据库。我主张切换到关系数据库,并实现了它:模式、数据迁移、查询、实时站点迁移等等。新查询的速度要快得多,而且(更重要的是)可以有效地支持新功能。在进行迁移之前,我必须要解决的一个问题是大部分代码没有被测试所覆盖,而这是由于大部分的代码都不可测试。我使用依赖注入以及[我此前讨论过的其他技巧][7]重构了代码,而这使我能够构建一组回归测试套件。我记得这个项目主要是因为测试单元的编写是“新毕业生水平的工作”而被驳回。
我的经理真的很支持我,并且写了上诉。他没有给我看,但是我认为这是可以被缩减成 “WTF” 的若干页(更雄辩而详尽地论述)。以下是一些我也认为这一回复有点 “WTF” 的原因:
Google SRE 有一种“关键人物( point-personship )”的概念。一个项目的关键人物有两个角色:一个是比起其他 SRE 对于软件项目有着更为深入的了解,以便你能够回答他们可能会提出的问题;另一个角色是作为开发人员在项目本身上的第一联络点,以便他们能够获得对所有 SRE 问题的回答。 Google 的职业阶梯指南说,毕业生水准并不需要扮演关键人物,但是看起来很适合晋升。正如我在申请中所写的,我是三个项目的关键人物。
我的关键人物经历使得想要找到同意支持我的晋升申请的资深开发人员很容易。当他们发现我是新毕业生级别时都十分震惊。他们都同意支持我的申请,假设我已经处在了一个更高的级别。
在我的申请之中,我提到曾担任过一组新毕业实习生的导师。当我提出申请时,他们之中的许多人都已经被聘用为了长期雇员。我足够资深,可以去担任他们的导师,但是还绝不足以晋升到比他们更高的级别。
给我经理上诉的回复与原始评论截然不同。这次,我“大大超出了对于我新毕业生级别工作的期望”,但是问题在于他们需要稍多一些时间来确保我能够晋升到新毕业生加一的级别。我被告知在接下来的 6 个月时间里,倘若我能够继续超出预期,知道下一个晋升周期,也许那时我就会得到晋升。上诉结束了;这就是最终结果。
我写了一封电子邮件,表示我正在采取另一种选择。就像许多科技公司一样, Google 也有员工持股计划。在开始工作时,你会得到一笔象征性的补助金,而在各个“投资”里程碑时刻,你会收到真正的股份。我的下一次股票投资实在几个月之后。从那以后,我将不再为 Google 工作。
### 我离开的原因
辞职的决定并不容易,而某天你或许会面临同样的抉择。以下是一些有助于我作出决定的因素。([我在以前的一篇贴子里对一些这类想法进行了更深入的解释。][8]
如果你思考一下,考虑到我并不是字面意义上真正的应届毕业生, Google 的评价应该是这样的:“你正在做一些非常错误的事情。”在 X、 Y 还有 Z 方面有所改进之前,你根本不会得到晋升。被告知“你远远超出了预期,但是我们还需要 6 个月左右的时间”,这是毫无道理的。没有人关注我是否有能力做好我的工作。我得到了许多接口,但是没有能够帮助我提高的任何有用反馈。(注意:有时候你必须要明确地要求反馈。经理们可能会陷入捍卫自己所给出的绩效评级的陷阱,而不会去考虑报告是否需要反馈。)
我也不确定晋升委员会会在 6 个月里看到什么他们在已经过去的 2 年时间里都没有看到的问题。他们为什么不会在要求 6 个月时间呢?如果我需要花上多年时间来证明自己以获得新毕业生加一的级别晋升,那么我升到新毕业生加二的时候得有多老呢?
刚加入 Google 时,我的工作级别无关紧要,因为我当时学到了那么多东西,并且能在我的简历里写入一家著名的公司。两年过后,方程式变得不同了。 Google 所提供给我的未来所具有的价值正在下降,而 Google 之外机会的价值却正在上升。 Google 的职位实际上在 Google 之外几乎毫无意义。在过去的 5 年间,许多人都问过我在 Google 做过什么,但是没有一个人问我在 Google 是什么职位,或是称我为“新毕业生”。尽管我在短期内受到了财务方面的打击,但实际上在我上交员工证的那天我就已经得到了晋升。
值得称赞的是, Google 没有做过任何类似于以下的事情,但是在其他公司中却很常见:试图让员工对于要求加薪感到内疚。在几年前我工作过的地方,一些工程师在经历了许多紧要关头的成功发布后要求加薪。管理层扮演起了受害者的角色,并且职责工程师们是在“扭曲他们的手臂”。(大约 6 个月时间后,他们失去了自己大部分的工程团队。)如果你真的愿意就辞职时间进行配合(例如,在发布日期之后,而不是前一周),并且愿意记录下你的知识并在自己之后清理等等,那么你仅仅是由于雇主支付给你的工资不足而“扭曲他们的手臂”。
名义上,我在 Google 留下了大量未投资的股票。但是知道你拥有股票时,股票才属于你。我只是得到了未来会有分红的承诺,而我可以将其除以所需的时间来将其转换为同等的工资率。为这项投资工作 2 个月是值得的,为了剩余的投资工作数年不是。不要被禀赋偏见所迷惑。
什么时候不应该辞职呢?嗯,与在其他地方相比,你能得到的很多吗?公司的职业发展道路不是天上掉下来的,他们是一系列的业务报价,代表着你将为什么样的公司评估而工作。如果你认为自己能得到很多(考虑到所有的薪酬和像是工作环境之类的无形资产),很好!否则,是时候认真考虑一下下一步该做什么了。
### Google 之后
我应当警告你的是,我采取了高增长的战略,但是牺牲了短期稳定性。如果对你而言稳定性更为重要,你应该做出不一样的选择。我的 A 计划、 B 计划、 C 计划都失败了,我最终花费了几个月时间苦苦找寻出路。最后,我在一家小型网络商店得到了一份合同,为 [Safety Town][9] 工作,一家面向孩子们的政府道路安全网站。那里的薪水较之于 Google 是一个巨大的缩减,尤其是考虑到这是我几个月以来的第一份工作。但是,你知道,我真的很享受这个项目。当然了,它不像 Google 那么“酷”,而且可能一些学校里的孩子也不觉得它酷。另一方面,在 Google我只是一件大事的一小部分。 Safety Town 有一个小团队,每个人都扮演着至关重要的角色。在 Safety Town 项目中,我是后端工程师, Safety Town 但是我唯一需要费心的事情。而且可能一些孩子已经在这个网站上学到了一两件有关道路安全的事情。从那以后,我做了很多项目,大多数都要更大,但是我仍然会向人们展示 Safety Town。
![Screenshot of Safety Town home page, owned by Australian NSW government.][10]
我记得 Google 悉尼办事处的一张海报,上面写着:“飞向月球吧!即使你错过了,你也会降落在群星之中!”人们很容易忘记,即使你不是在为知名公司或初创公司做“登月计划”,你也可以拥有高质量的生活。
这儿有一个帮助我获得合同的窍门。我会去参加悉尼的科技活动,站在能看到求职公告板的范围之中,等着直到我看见有人在上面写东西。假设他们正在为一个保险公司项目写 CSS 开发方面的信息。即使我对 CSS 或保险不是特别感兴趣,我也会来回徘徊并说:“嗨,这是个什么类型的保险项目?”这是最容易的开启谈话的方式,因为在他们努力往求职公告板上的狭小缝隙中写字的时候,满脑子都是这个项目。通常情况下,这样的谈话仍然不会为我带来一份工作,但是偶尔也会发现一些我能够帮上忙的东西。有些活动没有求职公告板,但是组织者们往往很乐意把麦克风递给别人几分钟。这为他们的活动增添了社区参与度。
在为政府采购网站工作后,我取得了重大的突破,因为我学着不对政府采购一窍不通。很难确切说出这些知识的价值,但是不到一年过后,我签署了一份政府合同,比我此前所期望的要多了 40%。(不过,我如今没有做太多的政府和大型企业工作。)
大约一年半过后,我有了自己的一人公司。随着我声誉的建立,我逐渐获得了更多类似于 SRE 的工作。基本上,从事开发工作是我的“工作”,然后几个月后一个需要 SRE/DevOps 帮助并想起了我的人联系了我。我事实上既喜欢 SRE也喜欢纯开发工作但是供求关系意味着 SRE 工作是个好工作。我仍然可以在空余时间编程。
说起这个,工作与生活的平衡是我在新生活中最喜欢的事情。没有人在两份合同之间给我酬劳,但是我可以通过在业余项目中学习新东西来充分利用这一间隙。在一个漫长而又紧张的合同之后,我休息了一下,[进行了为期一个月的背包徒步旅行,探索了日本乡村][11]。这是我期待了很长时间的一次旅行,但是在入职 Google 之前我需要更多的钱,而在 Google 供职期间我又需要更多的时间。自营职业远非没有压力,也不是适合每一个人的,但是有的压力会让你感到死气沉沉,有的压力则会让你越发充满活力。于我而言,自主营生是第二种,我想说,和在 Google 时相比,过去的 5 年间我的压力总体上有所减轻。对于我来说,至少我能够诚实地说我不后悔当初加入 Google也不后悔当初离开 Google。
--------------------------------------------------------------------------------
via: https://theartofmachinery.com/2020/08/04/leaving_google.html
作者:[Simon Arneaud][a]
选题:[lujun9972][b]
译者:[JonnieWayy](https://github.com/JonnieWayy)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://theartofmachinery.com
[b]: https://github.com/lujun9972
[1]: https://mtlynch.io/why-i-quit-google/
[2]: https://projecteuler.net
[3]: https://codingcompetitions.withgoogle.com/codejam
[4]: https://theartofmachinery.com/images/leaving_google/mori-tower.jpg
[5]: https://www.kalzumeus.com/2012/01/23/salary-negotiation/
[6]: https://theartofmachinery.com/2019/03/19/hello_world_marketing.html
[7]: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html
[8]: https://theartofmachinery.com/2018/10/07/payrise_by_switching_jobs.html
[9]: https://www.safetytown.com.au/
[10]: https://theartofmachinery.com/images/leaving_google/safetytown.png

View File

@ -7,38 +7,38 @@
[#]: via: (https://www.2daygeek.com/install-php-7-on-centos-6-centos-7-rhel-7-redhat-7/) [#]: via: (https://www.2daygeek.com/install-php-7-on-centos-6-centos-7-rhel-7-redhat-7/)
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/) [#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
3 Methods to Install the Latest PHP 7 Package on CentOS/RHEL 7 and CentOS/RHEL 6 在 CentOS/RHEL 7 和 CentOS/RHEL 6 上安装最新 PHP 7 软件包的 3 种方法
====== ======
PHP is the most popular open-source general-purpose scripting language and is widely used for web development. PHP 是最流行的开源通用脚本语言,被广泛用于 Web 开发。
Its part of the LAMP stack application suite and is used to create dynamic websites. 它是 LAMP 栈应用程序套件的一部分,用于创建动态网站。
Popular CMS applications WordPress, Joomla and Drupal are developed in PHP language. 流行的 CMS 应用程序 WordPressJoomla 和 Drupal 都是用 PHP 语言开发的。
These applications require PHP 7 for their installation and configuration. 这些应用程序的安装和配置都需要 PHP 7。
PHP 7 loads your web application faster and consumes less server resources. PHP 7 可以更快地加载您的 Web 应用程序,并消耗更少的服务器资源。
By default the CentOS/RHEL 6 operating system provides PHP 5.3 in their official repository and CentOS/RHEL 7 provides PHP 5.4. 在默认情况下CentOS/RHEL 6 操作系统在其官方存储库中提供 PHP 5.3,而 CentOS/RHEL 7 则提供 PHP 5.4。
In this article we will show you how to install the latest version of PHP on CentOS/RHEL 7 and CentOS/RHEL 6 systems. 在本文中,我们将向您展示如何在 CentOS/RHEL 7 和 CentOS/RHEL 6 系统上安装最新版本的 PHP。
This can be done by adding the necessary **[additional third-party RPM repository][1]** to the system. 这可以通过在系统中添加必要的 **[附加第三方 RPM 存储库][1]** 来完成。
### Method-1 : How to Install PHP 7 on CentOS 6/7 Using the Software Collections Repository (SCL) ### 方法-1如何使用 <ruby>软件集合存储库<rt>Software Collections Repository</rt></ruby>SCL在 CentOS 6/7 上安装 PHP 7
The SCL repository is now maintained by a CentOS SIG, which rebuilds the Red Hat Software Collections and also provides some additional packages of their own. 现在SCL 存储库由 CentOS SIG 维护,该组织不仅重新构建了 Red Hat Software Collections还提供了自己的一些其他软件包。
It contains newer versions of various programs that can be installed alongside existing older packages and invoked by using the scl command. 它包含各种程序的较新版本,这些程序可以与现有的旧软件包一起安装,并可以使用 scl 命令调用。
Run the following **[yum command][2]** to install Software Collections Repository (SCL) on CentOS 要想在 CentOS 上安装软件集合存储库SCL请运行以下 **[yum 命令][2]**
``` ```
# yum install centos-release-scl # yum install centos-release-scl
``` ```
Run the following command to verify the PHP 7 version available in the scl repository. 运行以下命令可以验证 SCL 存储库中可用的 PHP 7 版本。
``` ```
# yum --disablerepo="*" --enablerepo="centos-sclo-rh" list *php # yum --disablerepo="*" --enablerepo="centos-sclo-rh" list *php
@ -54,21 +54,21 @@ rh-php71-php.x86_64 7.1.30-2.el7 centos-sclo-rh
rh-php72-php.x86_64 7.2.24-1.el7 centos-sclo-rh rh-php72-php.x86_64 7.2.24-1.el7 centos-sclo-rh
``` ```
Run the command below to install the PHP 7.2 on your system from scl. 运行以下命令可以从 scl 中安装 PHP 7.2 到你的系统中。
``` ```
# yum --disablerepo="*" --enablerepo="centos-sclo-rh" install rh-php72-php # yum --disablerepo="*" --enablerepo="centos-sclo-rh" install rh-php72-php
``` ```
If you need to install additional modules for PHP 7.2, you can install them by running the command format below. For instance, you can install the **“gd”** and **“pdo”** packages by executing the command below. 如果需要为 PHP 7.2 安装其他模块,则可以通过运行以下命令格式来安装它们。 例如,您可以通过执行以下命令来安装 **“gd”** 和 **“pdo”** 软件包。
``` ```
# yum --disablerepo="*" --enablerepo="centos-sclo-rh" install rh-php72-php-gd rh-php72-php-pdo # yum --disablerepo="*" --enablerepo="centos-sclo-rh" install rh-php72-php-gd rh-php72-php-pdo
``` ```
### Method-1a : How to Install PHP 7 on RHEL 7 Using the Software Collections Repository (SCL) ### 方法-1a如何使用软件集合存储库SCL在 RHEL 7 上安装 PHP 7
For Red Hat 7, enable the following repositories to install the latest PHP 7 package. 对于 Red Hat 7启用以下存储库以安装最新的 PHP 7 软件包。
``` ```
# sudo subscription-manager repos --enable rhel-7-server-extras-rpms # sudo subscription-manager repos --enable rhel-7-server-extras-rpms
@ -76,27 +76,27 @@ For Red Hat 7, enable the following repositories to install the latest PHP 7 pac
# sudo subscription-manager repos --enable rhel-server-rhscl-7-rpms # sudo subscription-manager repos --enable rhel-server-rhscl-7-rpms
``` ```
Run the command below to search the available PHP 7 version from the RHSCL repository. 运行以下命令从 RHSCL 库中搜索可用的 PHP 7 版本。
``` ```
# yum search rh-php* # yum search rh-php*
``` ```
You can easily install PHP 7.3 on the RHEL 7 machine by running the command below from the RHSCL repository. 运行以下命令,您可以轻松地从 RHSCL 存储库中把 PHP7.3 安装到您的 RHEL 7 计算机上。
``` ```
# yum install rh-php73 # yum install rh-php73
``` ```
### Method-2 : How to Install PHP 7 on CentOS 6/7 Using the Remi Repository ### 方法-2如何使用 Remi 存储库在 CentOS 6/7 上安装 PHP 7
The **[Remi repository][3]** stores and maintains the latest version of PHP packages with a large collection of libraries, extensions and tools. Some of them are back-ported from Fedora and EPEL. **[Remi 存储库][3]** 存储和维护着最新版本的 PHP 软件包,其中包含大量的库,扩展和工具。 有一些是从 Fedora 和 EPEL 反向移植的。
This is a CentOS community-recognized repository and doesnt modify or affect any underlying packages. 这是 CentOS 社区认可的存储库,它不会修改或影响任何基础软件包。
As a prerequisite, this installs the **[EPEL repository][4]** if it is not already installed on your system. 作为前提条件,如果您的系统上尚未安装 **[EPEL 存储库][4]**,该操作会首先安装它。
You can easily find the available version of the PHP 7 package from the Remy repository because it adds a separate repo to each version. You can view them using the **[ls command][5]**. 您可以轻松地从 Remi 存储库中找到可用的 PHP 7 软件包版本,因为它会为每个版本添加一个单独的存储库。 您可以使用 **[ls 命令][5]** 查看它们。
``` ```
# ls -lh /etc/yum.repos.d/remi-php* # ls -lh /etc/yum.repos.d/remi-php*
@ -109,41 +109,41 @@ You can easily find the available version of the PHP 7 package from the Remy rep
-rw-r--r--. 1 root root 1.3K Sep 6 01:31 /etc/yum.repos.d/remi-php74.repo -rw-r--r--. 1 root root 1.3K Sep 6 01:31 /etc/yum.repos.d/remi-php74.repo
``` ```
You can easily install PHP 7.4 on the CentOS 6/7 systems by running the command below from the remi repository. 运行以下命令,您可以轻松地从 Remi 存储库中把 PHP7.4 安装到您的 CentOS 6/7 计算机上。
``` ```
# yum --disablerepo="*" --enablerepo="remi-php74" install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo # yum --disablerepo="*" --enablerepo="remi-php74" install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo
``` ```
### Method-2a : How to Install PHP 7 on RHEL 7 Using the Remi Reposiotry ### 方法-2a如何使用 Remi 存储库在 RHEL 7 上安装 PHP 7
For Red Hat 7, install the following repositories to install the latest PHP 7 package. 对于 Red Hat 7请安装以下存储库以安装最新的 PHP 7 软件包。
To install EPEL Repository on RHEL 7 在 RHEL 7 上安装 EPEL 存储库
``` ```
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
``` ```
To install Remi Repository on RHEL 7 在 RHEL 7 上安装 Remi 存储库
``` ```
# yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm # yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
``` ```
To enable the optional RPMS repository. 启用可选的 RPMS 存储库。
``` ```
# subscription-manager repos --enable=rhel-7-server-optional-rpms # subscription-manager repos --enable=rhel-7-server-optional-rpms
``` ```
You can easily install PHP 7.4 on the RHEL 7 systems by running the below command from the remi repository. 运行以下命令,可以轻松地从 remi 存储库中,把 PHP 7.4 安装在 RHEL 7 系统上。
``` ```
# yum --disablerepo="*" --enablerepo="remi-php74" install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo # yum --disablerepo="*" --enablerepo="remi-php74" install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo
``` ```
To verify the PHP 7 installation, run the following command 要验证 PHP 7 的安装版本,请运行以下命令
``` ```
# php -v # php -v
@ -153,19 +153,19 @@ Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies Zend Engine v3.4.0, Copyright (c) Zend Technologies
``` ```
### Method-3 : How to Install PHP 7 on CentOS 6/7 Using the IUS Community Repository ### 方法-3如何使用 IUS 社区存储库在 CentOS 6/7 上安装 PHP 7
IUS Community is a CentOS Community Approved third-party RPM repository which contains latest upstream versions of PHP, Python, MySQL, etc.., packages for Enterprise Linux (RHEL &amp; CentOS) 5, 6 &amp; 7. IUS 社区是 CentOS 社区批准的第三方 RPM 存储库,其中包含 PHP、Python、MySQL 等软件的最新上游版本,以及用于 Enterprise LinuxRHEL 和 CentOS5、6 和 7 的软件包。
**[IUS Community Repository][6]** have dependency with EPEL Repository so we have to install EPEL repository prior to IUS repository installation. Follow the below steps to install &amp; enable EPEL &amp; IUS Community Repository to RPM systems and install the packages. **[IUS 社区存储库][6]** 与 EPEL 存储库具有依赖性,因此我们必须在安装 IUS 存储库之前先安装 EPEL 存储库。 请按照以下步骤将 EPEL 和 IUS 社区存储库安装并启用到 RPM 系统,然后再安装软件包。
EPEL package is included in the CentOS Extras repository and enabled by default so, we can install this by running below command. EPEL软件包包含在 CentOS Extras 存储库中,并默认启用,因此,我们可以通过运行以下命令来安装它。
``` ```
# yum install epel-release # yum install epel-release
``` ```
Download IUS Community Repository Shell script 下载 IUS 社区存储库的 Shell 脚本如下
``` ```
# curl 'https://setup.ius.io/' -o setup-ius.sh # curl 'https://setup.ius.io/' -o setup-ius.sh
@ -174,13 +174,13 @@ Download IUS Community Repository Shell script
100 1914 100 1914 0 0 6563 0 --:--:-- --:--:-- --:--:-- 133k 100 1914 100 1914 0 0 6563 0 --:--:-- --:--:-- --:--:-- 133k
``` ```
Install/Enable IUS Community Repository. 安装/启用 IUS 社区存储库。
``` ```
# sh setup-ius.sh # sh setup-ius.sh
``` ```
Run the following command to check available PHP 7 version in the IUS repository. 运行如下命来检查 IUS 存储库中可用的 PHP 7 版本。
``` ```
# yum --disablerepo="*" --enablerepo="ius" list *php7* # yum --disablerepo="*" --enablerepo="ius" list *php7*
@ -200,7 +200,7 @@ php71u-devel.x86_64 7.1.33-1.el7.ius
php71u-embedded.x86_64 7.1.33-1.el7.ius ius php71u-embedded.x86_64 7.1.33-1.el7.ius ius
``` ```
You can easily install PHP 7.3 on the CentOS 6/7 systems by running the command below from the IUS Community repository. 运行以下命令您可以轻松地从 IUS 存储库中安装 PHP 7.3 到你 CentOS 6/7 系统上。
``` ```
# yum --disablerepo="*" --enablerepo="ius" install php73-common php73-cli php73-gd php73-gd php73-mysqlnd php73-ldap php73-soap php73-mbstring # yum --disablerepo="*" --enablerepo="ius" install php73-common php73-cli php73-gd php73-gd php73-mysqlnd php73-ldap php73-soap php73-mbstring
@ -212,7 +212,7 @@ via: https://www.2daygeek.com/install-php-7-on-centos-6-centos-7-rhel-7-redhat-7
作者:[Magesh Maruthamuthu][a] 作者:[Magesh Maruthamuthu][a]
选题:[lujun9972][b] 选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID) 译者:[gxlct008](https://github.com/gxlct008)
校对:[校对者ID](https://github.com/校对者ID) 校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出