nit: type actually originates from the Greek word τύπος https://en.m.wiktionary.org/wiki/τύπος (Google definition‘s origin based on oxford dict also confirms that).
Long time Murakami fun here, have read all his books and recently re-read the Rat Trilogy (Wild Sing + Pinball, A Wild Sheep Chase, Dance Dance Dance). I agree that there is indeed repetitiveness in his most recent work but I still find a lot of his work insightful and somewhat relatable. One of the best imo ranking of his work can be found in [0].
[0]https://www.reddit.com/r/murakami/comments/3q28p4/to_those_w...
I second that statement. I know at least two people who failed their viva in the UK and ended up getting an MPhil instead of a PhD. In both cases the candidates were told by their advisor not to go with the defense but they decided to go for it anyway. I know several more that got “major corrections„ which meant a lot of extra work and another review six months later.
edit: typo
100% this! The work life balance section in particular was an eye opener.
I’m sure the Waze employees that were part of the acquisition have a _completely_ different perspective, and I bet they‘ve been much better off after the acquisition.
Excellent article, thank you!
I really like the analysis and profiling part of the evaluation.
I also have some experience in I/O performance in linux -- we measured 30GiB/s in a pcie Gen3 box (shameless plug[0]).
I have one question / comment: did you use multiple jobs for the BW (large IO) experiments? If yes, then did you set randrepeat to 0? I'm asking this because fio by default uses the same sequence of offsets for each job, in which case there might be data re-used across jobs. I had verified that with blktrace a few years back, but it might have changed recently.
Looks interesting! I wonder whether there'd be interesting new database applications on NVMe when doing as small as 512 byte I/Os (with more efficient "IO engine" than Linux bio, that has too high CPU overhead with such small requests).
I mean, currently OLTP RDBMS engines tend to use 4k, 8k (and some) 16k block size and when doing completely random I/O (or, say traversing an index on customer_id that now needs to read random occasional customer orders across years of history). So you may end up reading 1000 x 8 kB blocks just to read 1000 x 100B order records "randomly" scattered across the table from inserts done over the years.
Optane persistent memory can do small, cache line sized I/O I understand, but that's a different topic. When being able to do random 512B I/O on "commodity" NVMe SSDs efficiently, this would open some interesting opportunities for retrieving records that are scattered "randomly" across the disks.
edit: to answer your question, I used 10 separate fio commands with numjobs=3 or 4 for each and randrepeat was set to default.
Funny how status.slack.com has reported Incidents and Outages for a while now, but still the "Uptime for the current quarter" is reported at 100% on the bottom right of the status table.
(And if you're saying that according to the legal blah blah blah of the SLA that this isn't technically "down", then there might as well not be an SLA.)
> And if you're saying that according to the legal blah blah blah of the SLA that this isn't technically "down", then there might as well not be an SLA.
I am because Ive had these exact conversations with cloud hosted providers/products. Never once have we been refunded according to the SLA in our contracts. Never really down (according to legal).
It may depend on how they define the "quarter". If they take the quarter as the last 91 days and round the number to the closest percent, you might not see it changed unless the outages go more than 91x24x0.5% or 10.92 hours.. It's quite subjective and a guess.
