5 ms·

> I won't get deep on describing all of the facts, since that's what Wikipedia is good at Sigh. So many links, so much reading, and not one to the USB spec (t

> I won't get deep on describing all of the facts, since that's what Wikipedia is good at Sigh. So many links, so much reading, and not one to the USB spec (that I found by skimming and searching). It's not just this article, but seemingly every 'deep dive does it'. Why do people read everything on the Internet, no matter the source and quality, but skip (what is usually) the best, most important source?

alias1 8y ago
I originally wrote this as a way to collate all of the things I was reading as I went from zero knowledge on the subject. I like to document the path I took, and don't really see the point in reimplementing the wheel when someone else has already done a good job of it. That might not align with everyones style.. but can't please everyone.
- forapurpose 8y ago
  > can't please everyone Absolutely; and pleasing an audience of one (me) isn't a great business move. Thanks for your exceptional effort. > I like to document the path I took I think people learn more from this kind of inductive approach.
mng2 8y ago
To be fair, specs and standards generally aren't written as introductions, so they're kind of hard to make sense of when starting from zero. USB, with its infernal descriptors and endpoints, benefits mightily from third-party explanations.
- forapurpose 8y ago
  > specs and standards generally aren't written as introductions Sometimes, but I often find them to be pretty good, and if I look at third party sources first, I usually wish I'd come to the spec much sooner in the process; the actual spec tends to make most third party sources redundant or plainly erroneous. But of course, not all specs are equal; some are unreadable or poor introductions.
- alias1 8y ago
  Definitely agree here. I tend to like to get the gist of things/cliffnotes from people that have already broken it down, and then deep dive into the spec if I need to know some explicit detail. Most of the time when I want to hack on something, a super high level abstraction is more than sufficient for my needs (eg. don't need to understand the inner workings of a CPU if all I need is an API). But then there are those times when the spec, in all it's verbose rawness, is the perfect tool for the job.

alias1 8y ago

I originally wrote this as a way to collate all of the things I was reading as I went from zero knowledge on the subject. I like to document the path I took, and don't really see the point in reimplementing the wheel when someone else has already done a good job of it. That might not align with everyones style.. but can't please everyone.

forapurpose 8y ago
> can't please everyone Absolutely; and pleasing an audience of one (me) isn't a great business move. Thanks for your exceptional effort. > I like to document the path I took I think people learn more from this kind of inductive approach.

mng2 8y ago

To be fair, specs and standards generally aren't written as introductions, so they're kind of hard to make sense of when starting from zero. USB, with its infernal descriptors and endpoints, benefits mightily from third-party explanations.

forapurpose 8y ago
> specs and standards generally aren't written as introductions Sometimes, but I often find them to be pretty good, and if I look at third party sources first, I usually wish I'd come to the spec much sooner in the process; the actual spec tends to make most third party sources redundant or plainly erroneous. But of course, not all specs are equal; some are unreadable or poor introductions.
alias1 8y ago
Definitely agree here. I tend to like to get the gist of things/cliffnotes from people that have already broken it down, and then deep dive into the spec if I need to know some explicit detail. Most of the time when I want to hack on something, a super high level abstraction is more than sufficient for my needs (eg. don't need to understand the inner workings of a CPU if all I need is an API). But then there are those times when the spec, in all it's verbose rawness, is the perfect tool for the job.