Paper Help! thanks! - 未名空间MITBBS历史存档

l*m2018-04-19 07:04

1 楼

谢谢
我老板的全部学生都是8年甚至9年拿到学位
他死活拖着不叫毕业不管你发了多少PAPER
我在他那里读了4年就工作了因为我知道不管我呆多久他也是不回痛快叫我走的
与其浪费时间不如早赚钱。我现在已经离开学生3年了
我发了5个J 10个会议他还是不满意，非说我做的不够，
导致我一边工作晚上还要做他新接的PROJECT 还要指导新生
我该怎么半啊
他已经有4个学生放弃学位渡了5年拿了MS就不要PHD了
现在有3个在工作中受他折磨就是不叫毕业
他老早已经是全职教授啊为什么这样啊靠
现在我找到国内大学的一个职位，想赶紧拿了博士学位走人了
他托了我一年了一会说没时间一会说这个那个 TMD
真实希望这种垃圾赶紧死掉啊靠

n*f2018-04-19 07:04

2 楼

填完160, 签证需要带着Proof of SEVIS registration and fee payment, 这个怎么付
, 多谢

i*i2018-04-19 07:04

3 楼

要求：
北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
中心节点的部分数据。
中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
题的时候，可以临时切换到中心节点上，接替子系统工作。
必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
24小时。
最好实现简单，比如，最好自带同步功能。
use case：
可以认为是一个办公软件，平时只和总部（本地）打交道。有时候出差，和总部有联系
，但是主要还是和出差当地打交道。要是某天当地的服务器挂了，可以连上中心服务器
接着玩。
这个系统支持好几千家公司使用这个办公软件。
问题：
1 有神马公司有类似的功能要求，如何解决的？
2 要是你老人家实现这个功能，如何选择技术？
总结一下目前的选择（以牛逼程度排序）：
1. （还木有）

l*y2018-04-19 07:04

4 楼

https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.103.166101
Paolo Lacovig, Monica Pozzo, Dario Alfè, Paolo Vilmercati, Alessandro
Baraldi, and Silvano Lizzit
Phys. Rev. Lett. 103, 166101 – Published 12 October 2009; Erratum Phys. Rev
. Lett. 103, 179904 (2009)
谢谢！

B*G2018-04-19 07:04

5 楼

中国人你也别在这个版上爆，美国人你在这里爆了也没啥用，没毕业大家都是用的pre-
OPT？还是都有绿卡了？pre-OPT用不了很久吧

【在 l***m 的大作中提到】

: 谢谢
: 我老板的全部学生都是8年甚至9年拿到学位
: 他死活拖着不叫毕业不管你发了多少PAPER
: 我在他那里读了4年就工作了因为我知道不管我呆多久他也是不回痛快叫我走的
: 与其浪费时间不如早赚钱。我现在已经离开学生3年了
: 我发了5个J 10个会议他还是不满意，非说我做的不够，
: 导致我一边工作晚上还要做他新接的PROJECT 还要指导新生
: 我该怎么半啊
: 他已经有4个学生放弃学位渡了5年拿了MS就不要PHD了
: 现在有3个在工作中受他折磨就是不叫毕业

w*g2018-04-19 07:04

6 楼

没看出来为啥需要一个城市运行一个子系统。大家都连北京不就得了？
google doc规模肯定比你大，也没见要在每个城市设点啊。

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

m*s2018-04-19 07:04

7 楼

https://www.sendspace.com/file/7xmkb9

a*d2018-04-19 07:04

8 楼

可以找committee或者系里其他教授，给他们看看你已经做出来的东西和论文稿，如果
他们也觉得你的确可以毕业了，再跟老板交涉，还不行的话就走grievance procedure
。

i*i2018-04-19 07:04

9 楼

几方面的考虑:
1 子系统是可以独立运行的。
2 假定到北京的网速度时快时慢。
就当是要求好了。

【在 w***g 的大作中提到】

: 没看出来为啥需要一个城市运行一个子系统。大家都连北京不就得了？
: google doc规模肯定比你大，也没见要在每个城市设点啊。

l*m2018-04-19 07:04

10 楼

她们都是用MS找的工作

pre-

【在 B*G 的大作中提到】

: 中国人你也别在这个版上爆，美国人你在这里爆了也没啥用，没毕业大家都是用的pre-
: OPT？还是都有绿卡了？pre-OPT用不了很久吧

w*g2018-04-19 07:04

11 楼

坐等goodbug等牛人回帖。不过我目测10个包子的奖励有点太少，还不如去掉算了。

【在 i**i 的大作中提到】

: 几方面的考虑:
: 1 子系统是可以独立运行的。
: 2 假定到北京的网速度时快时慢。
: 就当是要求好了。

a*s2018-04-19 07:04

12 楼

俺也遇到了类似的情况,答辩完了,非说你论文写得不好,还威胁说可能拿不到学位。
我还是他的第一个PhD啊，心里觉得好郁闷！

【在 l***m 的大作中提到】

: 谢谢
: 我老板的全部学生都是8年甚至9年拿到学位
: 他死活拖着不叫毕业不管你发了多少PAPER
: 我在他那里读了4年就工作了因为我知道不管我呆多久他也是不回痛快叫我走的
: 与其浪费时间不如早赚钱。我现在已经离开学生3年了
: 我发了5个J 10个会议他还是不满意，非说我做的不够，
: 导致我一边工作晚上还要做他新接的PROJECT 还要指导新生
: 我该怎么半啊
: 他已经有4个学生放弃学位渡了5年拿了MS就不要PHD了
: 现在有3个在工作中受他折磨就是不叫毕业

w*z2018-04-19 07:04

13 楼

一天才同步一次？你这要求太低了吧。MySQL cross DC replication应该在几秒之内。
C*可以设read/write, consistency, 可以基本保证data cross DC consistent.
NNetflix 都做到Dc 间的无缝切换了。

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

h*d2018-04-19 07:04

14 楼

Our department has a standard policy on graduation years in writing. A
doctoral student must graduate in 5.5 years. Otherwise it needs a special
petition from advisors or students. I heard some cases in which students got
PhD in a long time. But most of them are from industry. They cannot
maintain full-time status for most of time. If the students in the same
group maintain full-time status, 8-9 years are unbelievable and unacceptable.

【在 l***m 的大作中提到】

: 谢谢
: 我老板的全部学生都是8年甚至9年拿到学位
: 他死活拖着不叫毕业不管你发了多少PAPER
: 我在他那里读了4年就工作了因为我知道不管我呆多久他也是不回痛快叫我走的
: 与其浪费时间不如早赚钱。我现在已经离开学生3年了
: 我发了5个J 10个会议他还是不满意，非说我做的不够，
: 导致我一边工作晚上还要做他新接的PROJECT 还要指导新生
: 我该怎么半啊
: 他已经有4个学生放弃学位渡了5年拿了MS就不要PHD了
: 现在有3个在工作中受他折磨就是不叫毕业

n*w2018-04-19 07:04

15 楼

any database replication, prefer rmdb transactional replication

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

r*e2018-04-19 07:04

16 楼

挺奇怪的
8-9年老板有那么多钱吗？
我们系基本是RA，做不出来东西基本上2年老板就会劝你走人断stipend

got
unacceptable.

【在 h*********d 的大作中提到】

: Our department has a standard policy on graduation years in writing. A
: doctoral student must graduate in 5.5 years. Otherwise it needs a special
: petition from advisors or students. I heard some cases in which students got
: PhD in a long time. But most of them are from industry. They cannot
: maintain full-time status for most of time. If the students in the same
: group maintain full-time status, 8-9 years are unbelievable and unacceptable.

i*i2018-04-19 07:04

17 楼

1. 没有更频繁同步的要求。
2. 非多中心的replication.
数据的局部性很强，并且是保密的。一般来说，在一个地方的数据，其他地方不关心。
在偶尔共享的时候，pub-sub就够用了。

【在 w**z 的大作中提到】

: 一天才同步一次？你这要求太低了吧。MySQL cross DC replication应该在几秒之内。
: C*可以设read/write, consistency, 可以基本保证data cross DC consistent.
: NNetflix 都做到Dc 间的无缝切换了。

c*d2018-04-19 07:04

18 楼

我老板也是啊，我去年5月份开题，我们系一般开题后一个学期答辩，我跟他说今年暑
假毕业，他先答应，后来反悔，然后我怒了，他勉强答应，不知道会不会还出什么问题。
lz我觉得你换老板2年内都能毕业了。

i*i2018-04-19 07:04

19 楼

包子算个彩头，几位大牛才不惜的几个包子呢。
还是请大伙评出来“最靠谱”比较刺激。

【在 w***g 的大作中提到】

: 坐等goodbug等牛人回帖。不过我目测10个包子的奖励有点太少，还不如去掉算了。

c*d2018-04-19 07:04

20 楼

做不出东西老板当然让你走人啊。
我们实验室现在就我能做出东西，还总帮老板做别的，老板就想拖我，我已经第5年了
。我原来一个师姐本科过来的，3年，老板当时着急评恬妞，就把她放走了，做的东西
不及我1/5多。

【在 r***e 的大作中提到】

: 挺奇怪的
: 8-9年老板有那么多钱吗？
: 我们系基本是RA，做不出来东西基本上2年老板就会劝你走人断stipend
:
: got
: unacceptable.

p*22018-04-19 07:04

21 楼

跟wdong一个问题搞到一起算了 security是另外一个话题了

【在 i**i 的大作中提到】

: 包子算个彩头，几位大牛才不惜的几个包子呢。
: 还是请大伙评出来“最靠谱”比较刺激。

r*e2018-04-19 07:04

22 楼

我的意思是说，我们系都是RA
RA基本上不可能让你拖8-9年的，因为一个grant基本是3年就完了

【在 c********d 的大作中提到】

: 做不出东西老板当然让你走人啊。
: 我们实验室现在就我能做出东西，还总帮老板做别的，老板就想拖我，我已经第5年了
: 。我原来一个师姐本科过来的，3年，老板当时着急评恬妞，就把她放走了，做的东西
: 不及我1/5多。

p*o2018-04-19 07:04

23 楼

类似google doc的文件数据直接git最简单, 还可以留历史数据，分部定时往中心
push --mirror就好。

【在 i**i 的大作中提到】

: 1. 没有更频繁同步的要求。
: 2. 非多中心的replication.
: 数据的局部性很强，并且是保密的。一般来说，在一个地方的数据，其他地方不关心。
: 在偶尔共享的时候，pub-sub就够用了。

l*m2018-04-19 07:04

24 楼

因为我读了4年就走了啊
但是我修的学分发的PAPER完全符合学校的要求
可是他就是说你不完成你以前的工作就不要想毕业
我只好先区工业界工作因为我知道不管我呆10年 9年他也不会叫我毕业
因为他有无数的事情叫我做
我傻就傻在我对他知无不言言无不尽
他问我什么我就告诉他对我不熟悉的技术我也努力的去学最后弄好
导致他每次有事情就叫我解决我一边工作8小时晚上还得做他的新项目
在 hondaaccord (hondaaccord) 的大作中提到: 】
got
unacceptable.

i*i2018-04-19 07:04

25 楼

有点意思，算一个答案。不过数据不只是文件，更多的是离散数据。
对pptwo的方案重新理解一下就是: 中心是github，同样支持用户和project。子系统是
一个working directory. 文件是json格式。
子系统独立工作，修改json文件。完事把数据push到中心。中心用fswatch监视文件变
化，对变化的数据更新index.
实际上，数据存在nosql数据库里，文件倒不多。
期待更好答案。

【在 p***o 的大作中提到】

: 类似google doc的文件数据直接git最简单, 还可以留历史数据，分部定时往中心
: push --mirror就好。

g*g2018-04-19 07:04

26 楼

你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
份只需要切换DNS。

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

i*i2018-04-19 07:04

27 楼

标准答案。
就是记录带修改时间戳。然后把修改过的记录dump到中心。
但是非常难调试，经常莫名其妙不对，莫名其妙又好了。
有高招没？

【在 g*****g 的大作中提到】

: 你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
: 份只需要切换DNS。

g*g2018-04-19 07:04

28 楼

不要手写，用数据库自带的就容易。你的子系统是source of truth，半夜做个
snapshot扔到中心系统上import，哪需要merge. 需要merge数据库utility也有一堆。

【在 i**i 的大作中提到】

: 标准答案。
: 就是记录带修改时间戳。然后把修改过的记录dump到中心。
: 但是非常难调试，经常莫名其妙不对，莫名其妙又好了。
: 有高招没？

c*e2018-04-19 07:04

29 楼

为啥要dump在sync,直接sync不行么？

【在 g*****g 的大作中提到】

: 你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
: 份只需要切换DNS。

c*e2018-04-19 07:04

30 楼

我朋友公司是一个小时同步一次。就是手写个sql,没啥难的。这是dba的活，和程序员
没啥关系。

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

n*n2018-04-19 07:04

31 楼

同问

【在 c*********e 的大作中提到】

: 为啥要dump在sync,直接sync不行么？

c*e2018-04-19 07:04

32 楼

有个问题你必须考虑，如果sync的中间突然断电或者失去internet联系了怎么办，要
roll back吗？

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

w*z2018-04-19 07:04

33 楼

用MySQL 自带master slave replication 不就行了？

【在 c*********e 的大作中提到】

: 我朋友公司是一个小时同步一次。就是手写个sql,没啥难的。这是dba的活，和程序员
: 没啥关系。

i*i2018-04-19 07:04

34 楼

没有mysql. 用的是一种nosql数据库。高大上的功能一个也木有。
这里所要求的和master slave正好反向吧。

【在 w**z 的大作中提到】

: 用MySQL 自带master slave replication 不就行了？

i*i2018-04-19 07:04

35 楼

等数据齐了再merge.

【在 c*********e 的大作中提到】

: 有个问题你必须考虑，如果sync的中间突然断电或者失去internet联系了怎么办，要
: roll back吗？

i*i2018-04-19 07:04

36 楼

子系统的数据量也是很大的，不能完全dump再sync。
直接以record为单位sync就可以接受了。再细的话应用部分就复杂得一塌糊涂了。

【在 c*********e 的大作中提到】

: 为啥要dump在sync,直接sync不行么？

g*g2018-04-19 07:04

37 楼

如果量很大批量不好做，那就应该走event based呀，就像wwzz说的master slave
replication。如果你不需要merge，子系统是single source of the truth，应该可以
做snapshot然后直接在文件级别上替换中心系统上的backup，那样就很快。

【在 i**i 的大作中提到】

: 子系统的数据量也是很大的，不能完全dump再sync。
: 直接以record为单位sync就可以接受了。再细的话应用部分就复杂得一塌糊涂了。

i*i2018-04-19 07:04

38 楼

master/slave 还是要全部数据复制。每个节点和其他节点的数据最终是要同步的。难
道不是吗？
这里的子系统可以很小，但是中心比较大。
不过倒是可以试试拿子系统的journal file在中心上搞一下，看中心能不能被更新。应
该可行。

【在 g*****g 的大作中提到】

: 如果量很大批量不好做，那就应该走event based呀，就像wwzz说的master slave
: replication。如果你不需要merge，子系统是single source of the truth，应该可以
: 做snapshot然后直接在文件级别上替换中心系统上的backup，那样就很快。

n*j2018-04-19 07:04

39 楼

http://docs.mongodb.org/manual/replication/
每个子系统建一个 DB 做 primary ，中心系统做所有 DB 的secondary

i*i2018-04-19 07:04

40 楼

没看见两个primary的用法。

【在 n****j 的大作中提到】

: http://docs.mongodb.org/manual/replication/
: 每个子系统建一个 DB 做 primary ，中心系统做所有 DB 的secondary

n*j2018-04-19 07:04

41 楼

为啥要 2 个 primary 啊？primary 和 secondary 是热备份的啊，你还可以设定多个
secondary，甚至可以从 secondary 读，写到 primary。

【在 i**i 的大作中提到】

: 没看见两个primary的用法。

h*c2018-04-19 07:04

42 楼

这种纸上谈兵，来瞎说说吧
bt two decades ago has accomplished what you want to do in a relexed form
but satisfying plus md5 shaxxx validation.
I also say it is really CHEAP.

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：

k*n2018-04-19 07:04

43 楼

瞎想的：
中心用mongoDB shard, 每个（或几个）shard server 对应一个地方server（s）。每
夜同步或备分。这样中心有所有数据，地方有自己数据。

【在 i**i 的大作中提到】

: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：