Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Commodity servers have the same specs.

Probably not a coincidence. It would be interesting to know which ODM they partnered with for the hardware.

I've done some work with SuperMicro in the past. Some of their boards come with extensive headers and customization options right out of the box. They're also happy to work on board level customizations with the right contracts in place.



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-...

[1] https://oxide-and-friends.transistor.fm/episodes/the-sidecar...

[2] https://oxide-and-friends.transistor.fm/episodes/bringup-lab...


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)


They could probably have someone proofread the transcripts, there aren't that many episodes.


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.


I hate bad transcripts.


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-... was pretty readable to me in spite of the errors. Whether you'll find it the same is, of course, a separate question.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: