bhupesh

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

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.

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.

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

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.

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.

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.

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.

> 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?

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

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.

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

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