3 ms·

We didn't work with an ODM: the ODMs were unwilling to contemplate some of the most basic things we needed (e.g., replacing the BMC with a much lighter weight s

We didn't work with an ODM: the ODMs were unwilling to contemplate some of the most basic things we needed (e.g., replacing the BMC with a much lighter weight service processor, having a true root-of-trust, etc.) -- let alone the more things we wanted to do (e.g., our own switch). The compute sled and the switch are both of our own design and look nothing like what you'll find from an ODM; if you're curious in the details, we have discussed them quite a bit in our Oxide and Friends podcast.[0][1][2] [0] https://oxide-and-friends.transistor.fm/episodes/tales-from-the-bringup-lab-2021-12-06 https://oxide-and-friends.transistor.fm/episodes/tales-from-... [1] https://oxide-and-friends.transistor.fm/episodes/the-sidecar-switch-2021-11-29 https://oxide-and-friends.transistor.fm/episodes/the-sidecar... [2] https://oxide-and-friends.transistor.fm/episodes/bringup-lab-chronicles-a-measurement-two-years-in-the-making https://oxide-and-friends.transistor.fm/episodes/bringup-lab...

mst 3y ago
Please consider generating some sort of automated transcript from these. I'd hope your target audience would understand the limitations of such a thing, and I'm probably not the only person who'd rather read than listen even with the obvious caveats. (these days automated transcripts seem to be no harder to mentally fix up the errors in as I read them than "somebody typing fast on a software keyboard and suffering the inevitable tyop and autocorrupt related issues" is, though of course others' mileage may vary)
- actionfromafar 3y ago
  They could probably have someone proofread the transcripts, there aren't that many episodes.
  - mst 3y ago
    I was going for "set up some code once and don't think about it again" to maximise the odds of the idea sounding tempting. Proofreading would set up an expectation on the part of readers that it -had- been proofread and corrected and therefore a commitment to perform a repeated "boring but important" task going forwards for whoever's doing said proofreading. That way would likely lie either delayed transcripts or never getting to initial activation energy to provide anything at all. So I think "add a quick bit of code to your podcast publishing workflow and a CAVEAT IN BIG LETTERS" is better to do first. If it turns out enough people care about the transcript, doing it a more labour intensive nicer way later is something they can decide, well, later. Shipping is feature zero, as ever.
    - actionfromafar 3y ago
      I hate bad transcripts.
      - mst 3y ago
        The automatic transcribers have (pretty recently) reached the point where I'd rather have their output than not. This came as something of a surprise to me - six months ago I'd likely have been enthusiastically agreeing with you. As an example, the transcript tab on https://www.thebulwark.com/podcast-episode/tom-nichols-jack-smith-is-not-screwing-around-2/ https://www.thebulwark.com/podcast-episode/tom-nichols-jack-... was pretty readable to me in spite of the errors. Whether you'll find it the same is, of course, a separate question.

mst 3y ago

Please consider generating some sort of automated transcript from these. I'd hope your target audience would understand the limitations of such a thing, and I'm probably not the only person who'd rather read than listen even with the obvious caveats. (these days automated transcripts seem to be no harder to mentally fix up the errors in as I read them than "somebody typing fast on a software keyboard and suffering the inevitable tyop and autocorrupt related issues" is, though of course others' mileage may vary)

actionfromafar 3y ago
They could probably have someone proofread the transcripts, there aren't that many episodes.
- mst 3y ago
  I was going for "set up some code once and don't think about it again" to maximise the odds of the idea sounding tempting. Proofreading would set up an expectation on the part of readers that it -had- been proofread and corrected and therefore a commitment to perform a repeated "boring but important" task going forwards for whoever's doing said proofreading. That way would likely lie either delayed transcripts or never getting to initial activation energy to provide anything at all. So I think "add a quick bit of code to your podcast publishing workflow and a CAVEAT IN BIG LETTERS" is better to do first. If it turns out enough people care about the transcript, doing it a more labour intensive nicer way later is something they can decide, well, later. Shipping is feature zero, as ever.
  - actionfromafar 3y ago
    I hate bad transcripts.
    - mst 3y ago
      The automatic transcribers have (pretty recently) reached the point where I'd rather have their output than not. This came as something of a surprise to me - six months ago I'd likely have been enthusiastically agreeing with you. As an example, the transcript tab on https://www.thebulwark.com/podcast-episode/tom-nichols-jack-smith-is-not-screwing-around-2/ https://www.thebulwark.com/podcast-episode/tom-nichols-jack-... was pretty readable to me in spite of the errors. Whether you'll find it the same is, of course, a separate question.