Really appreciate the graphics, in-between summary elements and the progress bar widget. A bit too much colorful font variants my taste as it leans towards distracting, but hey everybody is different. That was a swell read, thanks for sharing!
As far as "app which helps create overview, reduce overwhelm and taks small steps" - I wonder how many of those are out there? I have written about 3 of those already for various use cases and in different flavors. Using them over a longer period of time, once the chaos subsides or the novelty wears off seems to be hard for me personally.
I'm also curious about ways to provide value with a technical project.
The challenge when exploring this topic: the incentive to stay under the radar. Those succeeding don't have much to gain from sharing details here. Worst case: it could invite competitors into their space.
Communities that thrive on growth (e.g., open-source) tend to share freely, but API businesses, especially ones which are easy to execute, often guard their edge.
A recent finding I had, while not necessarily an API: services which help you 24/7 stream a lenghty video file. YouTube live streams seem to work well for those lofi-types of channels, and there are services which are built to enable autopilot live streams.
As a tech person, it is easy to wrongly think that ”anyone can build this” about a prototype you just built.
At the end of the day, it is about what the customer is willing to pay for.
Back when The Pirate Bay was huge, music was essentially free. But Spotify came along and proved people are ready to pay for something better.
ImageMagick is an open source tool for resizing images etc. But some people successfully build API services or SaaS-services on top of it.
It works because people AND businesses pay for convenience.
What space do you have knowledge of? What pains do people have in that domain that can be solved with tech?
Always start with the problem. And start with an industry you know by heart or customer profile you truly care for.
For me that was software developers. I was that customer myself. I programmed a certain kind of solutions, realized there should be an API for this and built that API.
If the cops hadnt also aggressively pursued people "stealing" music (a bullshit proposition to begin with) Spotify would not have won. For most people avoiding a potentially big fine, even if the chance is small, tips the balance into just paying a few bucks (which is itself a huge price concession from the music industry, who would love to charge what CDs used to cost) - but they cant, that would tip the balance back into piracy
True that the full win was due to copyright enforcement by various actors.
However, in the early days of Spotify the ”play any song with a click” was pure magic and nothing piracy could compete with.
A fun anecdote from that time is also that basically the whole Spotify catalogue was full of pirated music — they had not yet secured any music rights and I personally thought they never would succeed with that.
Every company has secrets that few people know. If you know an industry intimately you can reverse engineer what the competition is doing. But generally speaking the “tricks of the trade” are non-obvious and make the business.
I know right this very second exactly how I could do a unique twist on my existing business and conservatively make another $1 million a year in profit within 2 years. But I already work 60+ hours a week on this business and I’m making tons of money, and the risk of revealing my secrets to another person to build the new business is simply too high.
That's the reason why I chose to focus on Go instead of Rust after immersing myself in it for a while.
Rust invites you to aim for brevity and crafting smart solutions whenever you can. Don't get me wrong, sometimes this leads to beautiful code. It can be super satisfying to write. But there is only so much fun in reading yet another 10-step iterator method chain which works due some arcane edge case in the middle of it.
I vastly prefer reading dumb and obvious Go code. It's just easier to understand and to work with.
This is one of the reasons for why I prefer C over Rust for reference implementations. I look at the code and I understand it much better than the Rust version.
I think I agree with this. C is, if nothing else, very simple to read and understand (generally). For reference code, it seems like a good choice. I think you need a stronger argument to use C over any other language for something that is meant to be bullet proof or run in production though.
I wondered about an adjacent topic recently ("what IS the kernel actually") and found out that a great way to understand it, would be to start with the boot process. Once I felt less lost, I tried to capture my learnings [1]
The text is not edited yet, but as I had the benefit of learning about it with fresh eyes, it should be very approachable (and hopefully accurate enough)
The microcode is mostly irrelevant, and is also opaque. It might be doing something but Intel won't give you more details beyond the programmer's reference model.
"Microcode" generally looks more like expanding a CISC instruction into other instructions, rather than something that looks like a program.
Extremely low level paper: https://www.researchgate.net/publication/295010710_Booting_a... ; good to confirm that Intel systems still boot at 0xFFFFFF0 in real (16-bit!) mode. It also points out that microcode updates are applied after execution has started.
There is also the fun of "cache as RAM"; it's usually quite a time consuming operation to get the DRAM controller up and running and "trained" to the particular signal properties of the motherboard, so the early boot phase has no RAM.
There's indeed a lot of firmware (not just microcode). A bunch of code is signature-checked and executed from the boot ROM and firmware flash in order to bring up the CPU and its various auxiliary cores (starting with the security processor/management engine nowadays), the PCH and the DRAM controller - all before the CPU can start executing any bootloader code from RAM.
Way out of my depth! However, the stuff I saw the folks from Oxide [1] talk about comes to mind. Hardware stuff with Rust. If you want to look at a specific project, Hubris [2] is a kernel for "deeply-embedded" systems.
Hubris is a part of booting on our systems in that it executes on both our root of trust and on our service processor -- but both of these execute long before the host CPU. To understand how we boot our host CPU (AMD Milan) on an Oxide compute sled, see my OSFC 2022 talk[0][1], as well as the episode of our Oxide and Friends podcast on holistic boot.[2]
As far as "app which helps create overview, reduce overwhelm and taks small steps" - I wonder how many of those are out there? I have written about 3 of those already for various use cases and in different flavors. Using them over a longer period of time, once the chaos subsides or the novelty wears off seems to be hard for me personally.