bhupesh

I am in the middle, neither a dogmatic skeptic nor a full-blown prompt engineer, but I lost it when the author compared a junior developer (a human) to a SaaS subscription.

Tells you what you need to know about the AI culture.

How do you find readers

I don't, that's what search engines are for. If people know what keywords to lookup, and are willing to go an extra mile (browse all pages of the Google search) they will eventually find your blog. If you have done a good job, it may land on the first page of search results.

Where do you share your content?

Random short off-topic ramblings on X. Discussion oriented stuff on Reddit. Personal long-form opinion/perspectives on personal blog & knowledge base.

why do you keep writing

For myself, I do not owe anyone anything, I don't plan to "build a brand" (or rather I have failed to do that), writing is a form of expression, that's it.

Whenever my gut says, this "thought" needs to get out of your head because you have been wasting a lot of time thinking about it, that's usually my cue to draft a post.

Folks at gitbook are kind enough to give me a LLM over my notes https://til.bhupesh.me

Soul of erlang got me hooked to Elixir recently, trying to get my hands dirty as well.

Other than distributed/concurrent system use-cases, could you share what kind of products are best when built with elixir/erlang compared to easier to write languages like Go, for example.

Out of all of my abandoned side-projects, this was the one that made me think differently. Even if I would never actually use the end 'deliverable', working on the project still indirectly achieved what I'd set out to do. That led me to an important realisation: we talk a lot about abandoned side-projects as "failed", but their success is really a matter of perspective.

Very much agreed here, abandoning things helps us eventually priortise other things that we learned from the exercise of building the original thing. I briefly wrote about a similar experience on how thinking too much about maintaining a project for a longer period of time is not really a good idea.

https://buttondown.email/bhupesh/archive/why-its-ok-to-aband...

Here's a solution that compresses everything into a single 8.7MB layer using tar and an intermediate staging stage: https://gist.github.com/carlosonunez/b6af15062661bf9dfcb8688...

Hey this looks interesting, will try it out. Thanks for writing it!

That said, in a real-world scenario where I care about readability and maintainability, I'd either write this in Go with gzip-tar compression in the middle (single statically-compiled binaries for the win!) or I'd just use Busybox (~5MB base image) and copy what's missing into it since that base image ships with libc.

Agreed, rewriting was not the option (as mentioned in the beginning). Moreover, It would have taken longer to build a nice TUI interface then it took to dockerize it.

I think it would be more accurate to say, in the Alpine ecosystem, it is generally not advised to pin versions of packages at all. Actually, this is not so much a recommendation as it is a statement of impossibility: You can't pin package versions (without your Docker builds starting to fail in a week or two), period. In other words: Don't use Alpine if you want reproducible (easily cacheable) Docker builds.

Agreed, should have been clear with my sentiment there. Thanks for stating this :)

Personally, I'm very excited about snapshot images like https://hub.docker.com/r/debian/snapshot where all package versions and the package sources are pinned. All I, as the downstream consumer, will have to do in order to stay up-to-date (and patch upstream vulnerabilities) is bump the snapshot date string on a regular basis.

This is really helpful, thanks for sharing. Looks like it will be a good change, fingers crossed.

How would I use this? Say I just made a bad commit in my terminal. How would I run this container to fix it? The container doesn't have my working directory does it? Or is that the idea, to mount a volume with the working for or something?

You can refer to usage guidelines on dockerhub https://hub.docker.com/r/bhupeshimself/ugit

So if you do that and just give me a one liner install command to copy paste then I guess this actually makes sense. A small docker container could eliminate a lot of potential gotchas with trying to install dependencies in arbitrary environments.

Yes, that was also an internal motivation behind doing this.

Why does it need fzf? Is it intended to run the container interactively?

Hey fzf is required by ugit (the script) itself. I didnt want to rely on cli arguments to give ability to users undo command per a matching git command. Adding a fuzzy search utility makes it easier for people to search what they can undo about "git tag" for example.

Oh, wasn't aware about UsrMerge, thanks for sharing.

Yes, the size of env closes to 2mb. I maybe wrong here, though. Seems something is wrong.

I wasn't able to dig deep enough on why that was the case, considering the "env" utility was coming from busybox which on copy averages close to 900Kb.

Thanks, appreciate the help!

Author here

copying the various standardized CLI tools and related library files into the image versus installing them with APK can introduce _many_ compatibility challenges down the road as new base Alpine versions are released which can be difficult to detect if they don't immediately generate total build errors

I'm maybe missing some context here, so you are saying that the default location of these binaries can change (the one's that get copied directly)? Or is it about the shared libraries getting updated and the tools depending on these libraries will eventually break?

Hey author here.

I understand that you might have some context about package managers that I am missing. Would genuinely like some resources about your comment or maybe a bit of explanation.

Thanks

Can vouch for dive, the final system tree was generated by dive (should have acknowledged it, my bad)

Hey author here

True, 31.4 MB is definitely a stopping point. But my the nerd inside me kicked in and wanted to know what "exactly" is required to run ugit. It was a fun experience.

Off-topic, but was anyone able to locate Part 3 of this series?

Anyone wants memes on their profile? https://github.com/Bhupesh-V

Ugit (undo git): https://github.com/Bhupesh-V/ugit/blob/master/ugit

I got this idea from a Twitter discussion which eventually blew up a year later after its initial release.

  Location: India
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Python, SQL, GraphQL, Docker, Microservices
  Résumé/CV: [request on contact]
  Email: varshneybhupesh@gmail.com

that's cool, but shouldn't the best way to solve this would be to ship the changelog with the CLI itself? Something like `cli --changelog`? I mean I don't understand why its not a general practice with CLI authors

I occasionally use the Trending page, but I agree with the OP on projects getting attraction because someone who has 12k followers on twitter shared a static page website.

Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time.

because we are going to make editors using JAVASCRIPT, which was never meant to be used this way