▲ 284 points
back
76 comments
I dreamed of that type of content since I’ve been a teenager. Thank you for sharing, it’s fantastic to see more and more programmers streaming themselves working on fairly advanced projects. That removes so much layers of magic and complexity once you can peek behind the curtain this way
I envy kids today to be able to look up pretty much anything what they want to learn. It was not like that back in the day.
I (not the programmer in the video) started programming 2 years or so during the pandemic during sophomore year of high school. I can affirm - there is a lot to wade throughm it's hard to know what's relevant, easy to learn and useful in real life.
That said, despite the availability of content online I tend to only watch the videos where something is a) summarized or b) something very advanced is broken down (e.g. the micro-gpt from scratch series). Imo, the best way to learn programming is to get excited about bringing your ideas to life, and choosing ideas small enough (at the start) to accomplish.
I am worried though about the rise of machine learning which may increase the barrier to entry in industry jobs and require more expertise to get ones "foot in the door". Additionally I find it hard to resist learning new technologies that are not as widely used / changing quickly do to their ease of use (Svelte, Tauri, V lang, etc).
Anyways, just thought I'd chime in as a kid learning to code
Begging my parents to drive me to every library in the county so I could try and find books on computer graphics and AI in the 1980s. Not very many around then :(
Alternatively, our routes back in the day was relatively linear, whereas today kids have to wade through so much more to find their paths
i feel this is a sentiment shared by every generation. “Now with printing presses, kids have access to tombs of knowledge”
Conversely, you used to look at a line of OS code and knew how that translated to registers within a processor. Now i barely know which kubernetes cluster the code is currently deployed in
I too have dreamed of the same. But I still think it's harder to find such content that is great and deep and technical.
Since it would be great to learn about sharing such channels, I would love if others can share other such channels as well.
Here's another I know: https://www.youtube.com/@LowLevelLearning Not stritly programming, but big fan of this channel as well: https://www.youtube.com/@StuffMadeHere (Amazing engineering channel)
Check out Marcan's channel. The Apple ARM silicon Linux bring up is epic, almost 12hours, Apple used a fair amount of custom hardware. https://www.youtube.com/live/GxnWuXgj3JI?si=lUJ_7KdkylzXLryj
I wrote a USB host driver for the STM32F4 a couple months ago, and the most difficult part was the lack of good documentation - the peripheral had r/w registers mapped as read-only in the SVD, there was a bit you had to set that wasn't mentioned in the documentation, and then the whole USB bulk-only-transport pointing to a non-existent SCSI spec. I ended up finding a blog post stating that you have to basically copy what Windows does in order for USB drives to work.
Luckily I had an oscilloscope that could decode USB frames to save me a whole bunch of time to understand why things weren't working.
USB seems to depend on a whole lot of tribal knowledge, which makes it impressive that it is so ubiquitous and works out of the box for the most part.
May I ask which oscilloscope you used for USB decoding?
Not OP, but for USB "full speed" devices (12 Mbps), you can use a saleae logic analyzer clone ($12) with the opensource pulseview which can decode USB frames and streams rather well.
Even with faster devices, you can usually force them down to 12 Mbps with a USB 1.1 hub for analysis and bugfixing of the driver/firmware, and then have the exact same code work fast without the hub.
On desktop, wireshark also has the ability to monitor USB data transfers for a software-only approach.
Have you considered streaming such content?
Intel USB controllers are extremely forgiving of control software bugs. Extremely
In a way that makes it worse because while you might get it "working" sooner, you'll never be sure if it's because you got it right, or if you're skating across the ice of a "quirks mode" that you hope will work in the next silicon rev.
Then again, if you don't need to follow the spec for your to work, maybe the spec is overly restrictive and a Vernacular Protocol is more effective.
I started contributing to a decompilation project and while I’m not the best decompiler by any stretch of the imagination I’ve thought about streaming while I’m working.
Is there interest in content like this? Are people curious about tells for when assembly is affected by variable sign, struct vs array access, the bonkers things even 30 year old compilers do with control structures, register reuse, etc. and how to coax code into byte equivalent assembly from classic consoles.
Made an account to say yes, this would be awesome to watch. I’ve been trying to accumulate esoteric reversing knowledge like this but it’s hard to know where to even look!
I am interested. I learned some basic 8086 assembly during university, read some books on reverse engineering, but never went anywhere further. BTW, are you working on a open source project?
Making an OS and have thought about streaming my sessions a few times, maybe I'll start doing that if this is indeed interesting to people.
The fascinating thing about watching people doing hard things is peering into their thought process. Writing an OS certainly qualifies as difficult. So if you really have the time to do it, please do. I will donate to your cause.
The loud sound of fans whirring in the background is the perfect ambiance for this video!
The most interesting thing to me is that font for a terminal/coding
And no color highlights either!
Font is Comic Code
No line numbers, either!
...after numerous more hours of understanding how things work.
Not mentioned in this title is that this is a USB device driver, for a relatively simple device, with existing code available. This is essentially a code-to-code "translation" task. I can see how this looks very impressive, but IMHO it's like watching anyone else skilled at their profession.
> ...after numerous more hours of understanding how things work.
>
> Not mentioned in this title is that this is a USB device driver, for a relatively simple device, with existing code available. This is essentially a code-to-code "translation" task. I can see how this looks very impressive, but IMHO it's like watching anyone else skilled at their profession.
Yeah - the title is a little off. My apologies! I'm not super knowledgeable about the kernel myself and while I did gain some knowledge from watching the video a lot of it looked like pure magic.
If a mod wants to edit the title to remove the "from scratch" and add that it's a device driver that would be great but otherwise, no worries
One that barely has a reason to exist, a front panel is probably better served being managed by some libusb application in userspace..
As much as I love this kind of video, a deep dive tutorial, "from scratch" is kind of a misnomer. "From 10 years of experience doing exactly this" doesn't have the same ring
The USB spec is like, what, 500 pages?
That is impressive.
You don't need to read the nitty-gritty of the USB spec itself, having a general idea of its capabilities is enough. The kernel gives you a bunch of functions to work with. You can learn it by simply reading the code of the most simple driver that you can find in the kernel source. Then you can step up, and find a more difficult one.
I couldn't even transcribe 500 pages in three hours.
A good driver API will hide that all and make sure an individual USB driver does not have to care about the USB spec - that’s the job of the shared USB core code.
...and also mostly irrelevant here.
Why is this a video?
Not sure why everyone is stuck on "from scratch" part. This is from scratch in all practical terms to me. They would be wasting their and viewer time if not done this way.
Because there are us who have actually done USB device drivers "from scratch", i.e. using the specs or gone through the RE process for an unknown device, while this is basically porting existing code to a new API. Thus it's rather clickbaity.
Not quite from scratch...
Ok, we've scratched that bit from the title above.
This. Why use the the explicit term "from scratch" when it's not even closely true.
You mean he didn't invent the universe? (Thanks to Carl Sagan)
I wonder if this video is painful to watch for people who claim "10x programmers are a myth!"
As an eng manager who's overseen teams at several top FAANGs, I can say without a doubt that most of those engineers would have taken 1-2 months to implement a driver.
This is confusing lack of experience with a specific discipline with productivity.
If you have the specialized knowledge, you’ll know that “writing a driver” is an overloaded term to start.
This guy isn’t going from a blank slate “scratch” either. There is tremendous amount of boiler plate being started with (in addition to the tremendous amount of core driver and USB “library” code in the base kernel)
And for those with experience in writing device drivers nothing here is super human or even not mundane. This is a well documented (existing code) hardware with a simple interface. If you’re already experienced with Linux kernel device drivers, this is not a terribly complex incremental task.
I have to point out that if you're the consistent factor over all these seemingly mediocre engineers, then that really might say more about the manager roasting their own employees on a public forum than them?
If you've never written a driver before, of course it's going to take weeks or months to get somewhere (speaking from experience, having written a few of my own as early tasks at a new job)
However, once you understand the APIs presented by your OS, and/or the underlying standard you need to implement, that time will easily reduce to a few days (or hours, in this case). If I've just written a USB driver for one set of hardware, it's almost certainly going to be trivial to write a driver for some other hardware.
You have to look at the total time (crucially including future maintenance and bug fixes) not just the time to get to a basic working prototype.
I don't think you can compare the productivity of someones passion with someone who's writing code they're told to write at a job.