h*i
发帖数: 3446 | 1 GCP的问题，是以为人们真的需要云，什么都按云来做， 结果基本的都作不好。
比如，我改一个文件，重启以后，这个文件居然还没被改，还是以前的某个版本，这样
的事情，发生过很多次了，简直是日了鬼了。把最基本的假设都可以推翻，这让人怎么
能信任。
再说一遍，没有人需要云。你Google的需求不是大家的需求。OK？
不要嘲笑的你的客户不懂，他为啥要懂你这些愚蠢的东西，他是付钱的，OK？ |
p*u
发帖数: 2454 | 2 啥意思，大家用云不是为了节省数据库和网管等等的IT开支嘛？
【在 h*i 的大作中提到】
: GCP的问题，是以为人们真的需要云，什么都按云来做， 结果基本的都作不好。
: 比如，我改一个文件，重启以后，这个文件居然还没被改，还是以前的某个版本，这样
: 的事情，发生过很多次了，简直是日了鬼了。把最基本的假设都可以推翻，这让人怎么
: 能信任。
: 再说一遍，没有人需要云。你Google的需求不是大家的需求。OK？
: 不要嘲笑的你的客户不懂，他为啥要懂你这些愚蠢的东西，他是付钱的，OK？
|
h*i
发帖数: 3446 | 3 你说的这个是大家的用法，不是GCP想像的用法。
GCP想象的是大家都用k8s，一切资源都是可以从code里面重建的，一切都不是
permenent的，所以连他妈一个文件都不能permenent，真是日了狗了。
【在 p*u 的大作中提到】
: 啥意思，大家用云不是为了节省数据库和网管等等的IT开支嘛？
|
S***s
发帖数: 104 | 4 gcp不是也有和ec2差不多的compute engine么？你如果没需要干嘛非用k8s啊
杀鸡用牛刀啊
【在 h*i 的大作中提到】
: 你说的这个是大家的用法，不是GCP想像的用法。
: GCP想象的是大家都用k8s，一切资源都是可以从code里面重建的，一切都不是
: permenent的，所以连他妈一个文件都不能permenent，真是日了狗了。
|
h*i
发帖数: 3446 | 5 我就是没用啊。说的就是gcp的compute engine，文件改动都可能存不下来。
还有啊，compute engine vm里面run一大堆google自己的东西，这不是浪费客户的钱么？
【在 S***s 的大作中提到】
: gcp不是也有和ec2差不多的compute engine么？你如果没需要干嘛非用k8s啊
: 杀鸡用牛刀啊
|
h*i
发帖数: 3446 | 6 gcp啥都跟aws学，但学不像，因为本来就不是设计来作IaaS的，而是设计来作PaaS的。
大部分人用云来是作IaaS的，所以就各种不舒服。
么？
【在 h*i 的大作中提到】
: 我就是没用啊。说的就是gcp的compute engine，文件改动都可能存不下来。
: 还有啊，compute engine vm里面run一大堆google自己的东西，这不是浪费客户的钱么？
|
x*******1
发帖数: 28835 | 7 对了，大多数人拥云，就是用instance，VM的， |
a*****g
发帖数: 19398 | 8 我在 windows one drive发生过类似情况，再也不用了
dropbox重来都很稳定，就一直用的。
google 只用它的 online文档/spreedsheet之类的，也非常好。
【在 h*i 的大作中提到】
: GCP的问题，是以为人们真的需要云，什么都按云来做， 结果基本的都作不好。
: 比如，我改一个文件，重启以后，这个文件居然还没被改，还是以前的某个版本，这样
: 的事情，发生过很多次了，简直是日了鬼了。把最基本的假设都可以推翻，这让人怎么
: 能信任。
: 再说一遍，没有人需要云。你Google的需求不是大家的需求。OK？
: 不要嘲笑的你的客户不懂，他为啥要懂你这些愚蠢的东西，他是付钱的，OK？
|
S***s
发帖数: 104 | 9 你说的这种情况可能还是比较少见
可能是用了云化的块存储且是在极端io场景下才会碰到
用物理硬盘的vm也会碰上硬盘failure的,但那种场景大部分人都不陌生了
么？
【在 h*i 的大作中提到】
: 我就是没用啊。说的就是gcp的compute engine，文件改动都可能存不下来。
: 还有啊，compute engine vm里面run一大堆google自己的东西，这不是浪费客户的钱么？
|
a****a
发帖数: 98 | 10 Aws不也是这样吗？如果你不snapshot就直接重启的话？ |
|
|
h*i
发帖数: 3446 | 11 No. It's entirely different. I have never ever experienced such data loss in
AWS. I have used AWS much longer.
I suspect the data loss has something to do with the bunch of google clouds
stuff running in my VMs. In AWS VMs, there's no AWS code running that needs
constant updating. Running your code in my VM is just stupid and wrong.
root 11161 0.0 0.3 55600 20896 ? Ss Jan27 0:42 /usr/bin/
python /usr/bin/google_network_daemon
root 11162 0.0 0.3 55732 21052 ? Ss Jan27 0:17 /usr/bin/
python /usr/bin/google_clock_skew_daemon
root 11163 0.0 0.3 63960 21140 ? Ss Jan27 1:08 /usr/bin/
python /usr/bin/google_accounts_daemon
ls /usr/bin/goolge*
google_accounts_daemon google_clock_skew_daemon google_metadata_script_
runner google_optimize_local_ssd google_oslogin_nss_cache
google_authorized_keys google_instance_setup google_network_daemon
google_oslogin_control google_set_multiqueue
WTF are those? Written in python? You guys are so stupid that you cannot
write these in a system oriented language? Also, who is this stupid
architect that think it is a good idea to run these in customer's VMs to
begin with? He should be fired.
Why every time it's about Google, there are always bunch of apologists
coming out?
Curious how this works.
【在 a****a 的大作中提到】
: Aws不也是这样吗？如果你不snapshot就直接重启的话？
|
h*i
发帖数: 3446 | 12 很明显，gcp原本就不是设计来给外来客户用的，否则不会这样的设计，需要运行
Google自己的东西在客户的VM里面，还是python写的，这完全不合理。
in
clouds
needs
【在 h*i 的大作中提到】
: No. It's entirely different. I have never ever experienced such data loss in
: AWS. I have used AWS much longer.
: I suspect the data loss has something to do with the bunch of google clouds
: stuff running in my VMs. In AWS VMs, there's no AWS code running that needs
: constant updating. Running your code in my VM is just stupid and wrong.
: root 11161 0.0 0.3 55600 20896 ? Ss Jan27 0:42 /usr/bin/
: python /usr/bin/google_network_daemon
: root 11162 0.0 0.3 55732 21052 ? Ss Jan27 0:17 /usr/bin/
: python /usr/bin/google_clock_skew_daemon
: root 11163 0.0 0.3 63960 21140 ? Ss Jan27 1:08 /usr/bin/
|
t*****n
发帖数: 2578 | 13 google drive现在不知道改了些啥
以前我upload一个文件，drive里马上就看到了。
现在不这样，upload了一个小时后都看不到，不知道发生了啥。一般到半天或一天后才
出现。
因为不知道upload成了没，有时候我只好再upload一次，结果还是看不到。到第二天一
看，里面两个一摸一样的文件。
奶奶的google drive不知道在瞎折腾个啥，最基本的功能都不可靠了。 |
S***s
发帖数: 104 | 14 激动啥，gcp不好用还用说么，市场上基本都失败了
只是你说的那个硬盘问题还真没碰到过
in
clouds
needs
【在 h*i 的大作中提到】
: No. It's entirely different. I have never ever experienced such data loss in
: AWS. I have used AWS much longer.
: I suspect the data loss has something to do with the bunch of google clouds
: stuff running in my VMs. In AWS VMs, there's no AWS code running that needs
: constant updating. Running your code in my VM is just stupid and wrong.
: root 11161 0.0 0.3 55600 20896 ? Ss Jan27 0:42 /usr/bin/
: python /usr/bin/google_network_daemon
: root 11162 0.0 0.3 55732 21052 ? Ss Jan27 0:17 /usr/bin/
: python /usr/bin/google_clock_skew_daemon
: root 11163 0.0 0.3 63960 21140 ? Ss Jan27 1:08 /usr/bin/
|
r****t
发帖数: 10904 | 15 文件只是一个local concept， 如果本地打开和读写文件的开销比较大，就有用云的刚
需了。
云上都是资源，资源 host 起来一直处在 ready 的状态，就可以免去本地开关文件开
销。
【在 h*i 的大作中提到】
: GCP的问题，是以为人们真的需要云，什么都按云来做， 结果基本的都作不好。
: 比如，我改一个文件，重启以后，这个文件居然还没被改，还是以前的某个版本，这样
: 的事情，发生过很多次了，简直是日了鬼了。把最基本的假设都可以推翻，这让人怎么
: 能信任。
: 再说一遍，没有人需要云。你Google的需求不是大家的需求。OK？
: 不要嘲笑的你的客户不懂，他为啥要懂你这些愚蠢的东西，他是付钱的，OK？
|
