jmmv

Please elaborate on what those "some stock standard static analysis tools" are.

If you work on a well-modularized codebase, with small and individual Go modules, or Rust crates or NPM packages or whatever you call them... you do not live in an alternate reality. You are doing essentially the same as I was describing because the package managers for those tools force you to express cross-dependencies explicitly in a separate "metadata file". You are just doing so via a different, language-specific tool.

The problem appears when: 1. you have a significant number of people working on the project and 2. one of these "modules" has become too big internally where it's hard to make sense of its internal structure. Having a monorepo makes the problem even more likely. At that point, you'll probably want to start breaking up that gnarly module into pieces so that you can see its structure again, right?

The problem is that anything that's _apparent_ and not _enforced_ will be messed up over time. Maybe not in a project with few people where everyone is an expert on how "things are supposed to be", but it will inevitably happen when you add more and more people.

And the whole point of the article is to say that import statements do actually _not_ solve this issue, because import statements are at the file level, not at the module level (whatever module means in your mind).

In any case. As I mentioned in the article en passing, other languages _do_ provide similar features to Bazel's build files though, and I explicitly called out Rust as one of them. When you are defining crates and expressing dependencies via Cargo, you are _essentially doing the same_ as what I was describing in the article. Same with Go if you are breaking your code apart into multiple modules

But then we all know that there are some huge repos out there that are just "one module" and you can't make anything out of their internal structure. Hence you start breaking them apart into Crates, Go modules, NPM packages, you name it or... you know, add Bazel and build files. They are the same tool -- and that's why I didn't write Bazel in the title, because I imagined "build files" more generically. I guess I needed to be clearer there.

You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.

I recently got an Apple Watch for my kids and… OMG the setup process was painful. So. Many. Questions. I couldn’t believe it and I could tell when the whole ordeal was going to end.

Same here. I removed Disqus a while back due to how obnoxious it became. Then, I built my own commenting platform and, while it was a fun thing to do... I think it's worthless. People don't comment on blogs anymore, and when they do, the value is too low. Discussions happen elsewhere now. I've been tempted to just remove the comments altogether but haven't gotten to it.

Missed chance to do something like:

  class User:
    def calculateCoworkers() = {
      this.coworkers.clear()
      for { d <- this.departments }
        this.coworkers ++ d.employees
    }

and then, somewhere else...

  user.calculateCoworkers()
  ... many lines after ...
  for { c <- user.coworkers }
    ... do something ...

Yes, I've seen code like this many, many, many times where class members are used as "global variables" to pass state across functions. And I've noticed AI likes to generate code like this too (possibly because of the former (large presence of this "pattern" in the training data), which means I'm encountering this now in pull requests...

Right, so you need to end up creating a container to package the glibc with the binary. Which is not very different from having sysroots.

But what about any tools compiled from source and used during the build? Those can also suffer from these issues.

You need that glibc on the target system, and glibc doesn’t like static linking. How do you ship the built binary?

Because those Bazel toolchains don’t come with a glibc? How could they?

Bazel is complex, yes, and in my opinion not suitable for small, one language projects.

But I’ve seen many builds, outside of FAANG, that are too slow and that also break frequently after a simple “git pull”. Which other systems promise to improve those, and how do they do it?

The article goes through an unbelievably amount of fluff to just say that. Thanks for confirming my own read.

Hey, thanks for sharing!

I’ll add that the project page is at https://www.endbasic.dev/endbox.html and that the disk images are now available for download. Have fun!

The content in the article is good and important. That said, I don’t find it “practical” enough so… I’ll link to my own tips on preparing and giving presentations ;-)

https://jmmv.dev/2020/07/presentation-tips.html

https://jmmv.dev/2020/07/presentation-preparation.html

(These were originally Twitter threads so apologies for the abuse of emojis hehe.)

I used to dread speaking in public but have come to enjoy it, and all of the above tips have made it easier over time. I think the vast majority of them came to me from more experienced presenters (and even a class I took in college about public speaking).

As others have mentioned in the discussion below, keeping it fun and providing the motivation for the talk are important. And my pet peeve is to remind people that “your slides are not the presentation: what you say is”.

> Grab a fucking profiler, it is more important than your Big O

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.

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.

Discussed at length back in 2021: https://news.ycombinator.com/item?id=27456222

This was originally a Twitter thread where emojis are customary. But you don’t have to read it.

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.

Ah yes, the first version does indeed sound DOS-like. The second one diverges quite a bit though.

Fun project indeed.

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.

There are a few factors to the slow boot:

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

EndBASIC (the desktop version) is open source and I plan to keep it that way. I wouldn't want you to be "locked out" of any code you write in EndBASIC.

However, I'm not planning on open-sourcing what goes into packaging it for the EndBOX (the bindings for NetBSD and the release building scripts) because that's very specific to this project and I see no benefit in publishing them.

It’s all NetBSD underneath. The WiFi was only difficult because of missing DTBs for the Pi Zero 2.

There is a config file that you can edit within BASIC to set the WiFi up though.

There is no accident here.

Huh, I didn't know about Maximite, and reading their intro to the Colour Maximite 2 at https://geoffg.net/maximite.html... well, I feel like I read their minds years later and I'm trying to recreate the same thing.

One difference I can sense is in the interpreter. In the case of the EndBOX, I'm creating a computer to run EndBASIC on, but EndBASIC has already existed for 5 years and is multiplatform: you can write a program and have it run in your browser via WASM, in the desktop version of the interpreter, or now in this new small form factor format. In the case of Micromite, it sounds like MMBasic is specifically designed for this machine.

Which brings me to something I have been thinking about recently: I think BASIC is the least interesting aspect to the EndBOX and the thing that might hurt the concept the most (because BASIC is old, limited, legacy, who cares about it, blah blah blah). I'm starting to think that the more interesting parts of this project are what I have built to take a Rust app that uses some APIs to talk to a "generic graphical console" or to "the hardware", and have that exact same app run on the web, on the desktop, and now natively on a small computer. And for the later case, I think the pipeline I developed to take the app and generate a full SD card disk image with a trivial command to run it in a standalone manner is interesting too. Stay tuned for a follow up blog post as I elaborate on these ideas...

Many of the files I checked have a 2-BSD clause stamped at the top, but I don’t know what the resulting combination of the project plus its dependencies becomes.

Hey, thanks for sharing. Just FYI, I had sent this yesterday via Show HN (https://news.ycombinator.com/item?id=44203326) but... not much interest. I've now added a video to the post though!

I spent years packaging software (mostly Gnome 2.x) for NetBSD. I almost-always tried to upstream the local patches that were needed either for build fixes or improvements (like flexibility to adapt to non-Linux file system hierarchies or using different APIs).

It was exhausting though, and an uphill battle. Most patches were ignored for months or years, with common “is this still necessary?” or “please update the patch; it doesn’t apply anymore” responses. And it was generally a lot of effort. So patches staying in their distros is… “normal”.