arXiv moving from Cornell servers to Google Cloud
info.arxiv.org
arXiv moving from Cornell servers to Google Cloud
1–10 of 178 posts
Re: arXiv moving from Cornell servers to Google Cloud
#2I'm sure many are going to hate on this, but a simple k8s setup (just container+deployment+ingress) is going to be good for preventing vendor lock in.
Too bad it's US only, devops is actually a good role for full remote setups. If you can't make it work asynchronously across timezones you are doing it wrong :)
Re: arXiv moving from Cornell servers to Google Cloud
#3Job opening for the rare perl+latex hackers.
Re: arXiv moving from Cornell servers to Google Cloud
#4I'm sure many are going to hate on this, but a simple k8s setup (just container+deployment+ingress) is going to be good for preventing vendor lock in. Too bad it's US only, devops is actually a good role for full remote setups. If you can't make it work asynchronously across timezones you are doing it wrong :)
You deal with emergencies with international on call rotation?
Re: arXiv moving from Cornell servers to Google Cloud
#5Hope they stay vendor unlocked though
Re: arXiv moving from Cornell servers to Google Cloud
#6Job opening for the rare perl+latex hackers.
[deleted]
Re: arXiv moving from Cornell servers to Google Cloud
#7Crap, there goes privacy.
Re: arXiv moving from Cornell servers to Google Cloud
#8They should definitely update UI of the website.
Re: arXiv moving from Cornell servers to Google Cloud
#9Is this related to the federal government's vendetta against Cornell? And is there a risk Cornell becomes unable to operate arXiv because of this?
https://www.npr.org/2025/04/09/g-s1-59090/trump-officials-ha... ("Trump officials halt $1 billion in funding for Cornell, $790 million for Northwestern")
Re: arXiv moving from Cornell servers to Google Cloud
#10I'm sure many are going to hate on this, but a simple k8s setup (just container+deployment+ingress) is going to be good for preventing vendor lock in. Too bad it's US only, devops is actually a good role for full remote setups. If you can't make it work asynchronously across timezones you are doing it wrong :)
You deal with emergencies with international on call rotation?
Not just emergencies but good timezone coverage is nice for oncall, nobody likes getting woken up by a page at 3am.
But I meant things like having good and automated tests, deploys etc so everyone can be productive on their own without multiple people getting involved ("hey can you please deploy X for me when you are here?").