The statement regarding the better option is as it stands today and does not account for all possible futures.
Reg. hiking it again, they'd have to either be extremely anti-competitive and selectively apply the pricing OR apply the hike uniformly by about double the current value to match our pricing while making it completely unviable for any large co to use self-hosted github actions in the first place.
IIUC, on EC2, the disk (EBS)is one service, and snapshots are in another service (S3). Taking a snapshot involves copying the entire disk to S3, while restoring a snapshot pages blocks in from S3 as the VM accesses the disk.
Thanks for writing the blog post; it was a fascinating read!
I was curious about a couple of things:
* Have you considered future extensions where you can start the VM before you completed the FS copy?
* You picked XFS over ZFS and BTRFS. Any reason why XFS in particular?
* You casually mention that you wrote 'otterlink', your own hypervisor. Isn't that by itself a complicated effort worthy of a blog post? Or is it just mixing and matching existing libraries from the Rust ecosystem?
sorry for not responding to your email, I was swamped.
I looked through the sourcecode, but I can only find UI (ie. browser) code. Does this do anything beyond delivering a more functional and prettier UI on top of an existing zoekt deployment? If no, everybody would be better served if you tried to improve the UI inside Zoekt, which currently is a live demonstration of (my lack of) web app programming skills.
Have you thought of how you will achieve your further goals (eg. semantic search)? That will require server-side changes, but you currently have no Go code at all.
Yea that is correct - in its current state, it's functionally a UI wrapper on top of the zoekt-webserver api. One of the reasons why we decided to go with a separate app is that we have much more experience with Typescript, React, and NextJS (the web framework we are using), so it felt like we could move allot quicker using what we know.
In terms of semantic search, that is still very early days - my intuition is that having a separate "semantic code indexer" server written in Python would again allow us to move quickly (since all of the ML libraries are written in Python).
Different parts of the bird take different times to cook, so for food quality, cooking a bird as a whole makes no sense: either the breasts are overcooked, or the thighs are undercooked. There is just one reason, which is that cooking the animal whole makes for an arresting presentation. Then, you'd carve the animal tableside (like is done for Peking duck, see one of the other comments).
This requires having waitstaff that can carve a bird or having cooks that are presentable to the guests, and extra space in the dining room.
Clearly, David Chang is taking a shortcut already by carving the chicken in the kitchen.
Developer infrastructure at google reported into cloud from 2013 to 2019, and we (i was there) tried to do exactly that: building products for gcp customers based on our experience with building interval developer tools. It was largely a disaster. The one product I was involved with (git hosting and code review) had to build an
MVP product to attract entry level GCP customers, but also keep our service running for large existing internal customers, who were servicing billion+ users and continuously growing their load. When Thomas Kurian took over GCP, he put all the dev products on ice and moved the internal tooling group out of cloud.
