I think you're right. Early on I did HPC and scientific computing. No one talked about Big O. Maybe that's because a lot of people were scientists, but still, there was a lot of focus on performance. Really how people were optimized is with a profiler. You talk about the type of data being processed and how and looked for the right way to do things based on this and people didn't do the reductions and simplifications in Big O.
Those simplifications are harmful when you start thinking about parallel processing. There's things you might want to do that would look silly in serial process. O(2n) can be better than O(n) because you care about the actual functions. Let's say you have a loop and you do y[i] = f(x[i]) + g(x[i]). If f and g are heavy then you may want to split this out into two loops y[i] += f(x[i]) and y[i] += g(x[i]) since these are associative (so non-blocking).
Most of the work was really about I/O. Those were almost always the bottlenecks. Your Big O won't help there. You gotta write things with awareness about where in memory it is and what kind of memory is being used. All about how you break things apart, operate in parallel, and what you can run asynchronously.
Honestly, I think a big problem these days is that we still operate as if a computer has 1 CPU and only one location for memory.
What more harmful is probably not having a set of guilds / unions (that both work together, share the same collective bargains, but also compete for members) to cut a lot of the annoying for ALL sides involved interview process out.
Why do they ask about Big O? Because it works as a filter. That's how bad some of the candidates are.
What would I rather they do? Have a non-trivial but obviously business unrelated puzzle that happens to include design flaws and the interviewee is given enough time and latitude to 'fulfill the interface, but make this the best it can be'.
Hah, same. I recently started getting many more back to back meetings than usual and, by lunchtime, I had a headache most days. It took me a while to realize that, while I’m at my desk, I keep drinking from the huge water bottle that I keep there, but when I go to meetings, I don’t. I started carrying the bottle with me (when I remember) and the headaches are gone.
About a year ago, I wrote https://open.substack.com/pub/blogsystem5/p/a-cli-text-edito... , which covered the history of editors in DOS and Windows. The article was sparked precisely by the GitHub issue in which Microsoft was proposing re-adding a text editor to Windows and the heated debate that followed.
I’ve seen a ton of this “#define private public” in a previous team that was forced to write unit tests in a rush due to the whims of leadership. It hurt to see, and the resulting white box tests were useless.
I don’t understand: what makes this “DOS-like”? Not even the command names match DOS, except for dir and cls, and the architecture and feature set are completely different.
Ultimately, it's an eye of the beholder type thing, but it seems very fair to call it DOS-like to me. The DOS inspiration is pretty blatant all throughout it from its aesthetic, commands (more than just dir and cls is shared), booting from a 1.44 floppy, etc. And if you are coming from a primarily windows computing background, then "DOS-like" is entirely appropriate to me.
You are right, it goes way ahead the first iteration. I call it DOS-like because of its resemblance to the Text mode-only operating systems (and to MS-DOS especially). On the other hand, it shares very little as the architecture, command set, or hardware utilization approach are concerned when compared to MS-DOS.
* The SD card I'm using in there is not the fastest. Easy fix.
* The kernel has some annoying pauses, particularly in WiFi initialization, that add a couple of seconds of delay. To fix this, I wanted to do driver loading via modules once the shell is already up and running, but unfortunately NetBSD hasn't modularized those drivers yet and it didn't seem trivial to do. Should be possible though.
* The rc startup framework is sluggish. I've been pondering a rewrite in native code to avoid huge shell scripts and to allow for parallel execution of early boot services, and that should help -- but it isn't done. (Ideally I'd just replace init with my own thingy.)
* The file system is not read only, so there is an initial fsck that adds a bit of a delay. I want to get to a point where it _is_ read only, which would eliminate this pause.
All in all, agree that 10 seconds is very far from "instant boot", but there is a lot of room for improvement.
afaik one bottleneck is the bootloader blob of rpis which can take few seconds by itself and can not be avoided. It's one of the small annoyances of rpis.
This is exactly why I wrote https://jmmv.dev/2023/09/performance-is-not-big-o.html a few years back. The focus on Big O during interviews is, I think, harmful.