HN user
I assume that wax uses Apple's ANE to do embeddings (so no third-party services like OpenAI are needed). Did you happen to compare search quality when using ANE embeddings vs. OpenAI's text-embedding-3-large (or another commonly used online embedding)?
Would wax also be usable as a simple variant of a hybrid search solution? (i.e., not in the context of "agent memory" where knowledge added earlier is worth less than knowledge added more recently)
oci.dag.dev is fantastic. You can also self-host it, because it's just a Golang CLI.
I compared it with various other registry browser tools, and it was clearly the best one. See here for more details: https://www.augmentedmind.de/2025/03/30/the-9-best-docker-re...
I'm German myself. To me this looks like a category of problem where you can no longer translate the word in the literal sense, because chances are low that the consumer understands the word ("Bremsschwelle" or whatever you end up picking).
Wouldn't it make sense to rather think of a completely different analogy? One that is really well-known by the target audience? From what I understand, you are building an app that inhibits people from doomscrolling. That is a well-established "German" word, too. Using that, people immediately understand what you mean, rather than trying to follow a broken analogy.
This guide looks really nice, targeting novice Git users.
I've also written a guide, targeting devs with basic Git experience. It is much shorter, maybe you or your team can benefit from it [1]
[1] https://www.augmentedmind.de/2024/04/07/ultimate-git-guide-f...
I found two ideas / techniques helpful in this context:
1) Conventional comments (https://conventionalcomments.org/) as an (agreed-upon) language to be used in PR comments
2) Ship / Show / Ask (https://martinfowler.com/articles/ship-show-ask.html), where "Show" and "Ship" are non-blocking PRs (or even directly committing to trunk, if you use trunk-based development), since not every(!) PR needs reviewing and/or should block the PR creator
Looks nice. I'm a Clockify fan myself. Your app and homepage also remind me a lot of https://timemator.com/ (which I ended up not using because it was unable to generate reports that show me the percentage(!) of time spent on different projects throughout the day).
I agree.
Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because
a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)
b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park
The only option I know is to use network shares/disks, but you need to make sure that each share/disk is only used by one BuildKit process at a time.
I took a detailed look at Docker's caching mechanism (actually: BuildKit) in this article https://www.augmentedmind.de/2023/11/19/advanced-buildkit-ca...
There I also explain that IF you use a registry cache import/export, you should use the same registry to which you are also pushing your actual image, and use the "image-manifest=true" option (especially if you are targeting GHCR - on DockerHub "image-manifest=true" would not be necessary).
Sounds really interesting, and I'd also love a Firefox version :)
I also looked at this topic, see [1]. Some points are similar to the article posted by OP. My findings were:
- Docker Desktop and Docker engine (CE) behave differently, e.g. bind mounts, or file system ownerships.
- CPU/Platform differences (ARM vs. AMD64): many devs don't realize they use ARM on their mac, thus ARM images are used by default, and tools you run in it (or want to install) may be have differently, or may be missing entirely
- Incompatible Linux kernel APIs (when containerized binaries make syscalls not supported by the the host's kernel, for whatever reason)
- Using the same version tags, expecting the same result (--> insanity, as you know it :D)
- Different engines (e.g. Docker Desktop vs. colima) change the execution behavior (RUNNING containers)
- Different build engines (e.g. kaniko vs. BuildKit vs. buildah) change the BUILD behavior
For anyone who is interested: more details in [1].
[1] https://www.augmentedmind.de/2023/04/02/docker-portability-i...
It took me a while to understand what your tool is doing. It looks like an abstraction layer for concrete monitoring/alerting solutions.
What confuses me is:
- You introduce Keep like this "Think of Keep as Prometheus Alertmanager but for all observability tools", but then there is no Alertmanager provider. Is this planned?
- You mention that you support the 3 hyperscaler clouds (AWS, ...), yet I do not see any examples or code that backs this up
- You mention that Keep can be used to _test_ alerts. How? Examples? Otherwise make it clear that you _plan_ that Keep can do this at some point.
In general though it looks very interesting :).
containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code] and GitHub Codespaces). Tool vendors (of IDEs) decided to go to war, instead of collaborating, it seems. XKCD's "standards" comic seems to apply [0] here.
As I've blogged about here [1], there are other specs such as Devfile.io or GitPod's proprietary gitpod.yml file.
[1] https://www.augmentedmind.de/2022/10/30/container-based-deve...
To record "bookmarks" for interesting sections of podcast episodes (that I want to revisit some time later), I use my own (Android-only) app called "Stop It!" [0]. The mechanism that creates a bookmark is to pause and immediately unpause the playback (works with any headset). For each bookmark, the app records the audio player's Android package name, the artist / album / track name, the time code (in seconds) and other meta-data (if available). For selected audio players, the user can resume playback for bookmarks at a later time.
I have not worked on the app for a while, because it (still) works on my (old) Sony Android phone.
I simply have such a kind of notebook placed in my shower (with a run-of-the-mill pencil) to jog down any ideas I have while under the shower. I have a variant that encourages ripping out pages.
Teaching Git to others (e.g. company-internal workshops). You learn so much from teaching, and also from questions others ask, helping you discover your unknown knows and unknown unknowns.
I found this blog article to be a good introduction to sigstore and the related projects (such as Fulcio): https://www.giantswarm.io/blog/securing-the-software-supply-...
How would Dagger compare to Toast? https://github.com/stepchowfun/toast
I found getting started with Podman on Windows is utterly confusing:
1) Podman has two documentation entry points (https://docs.podman.io and https://podman.io/getting-started/) because... ? It is confusing to the user at first. It makes more sense to have everything in one place.
2) Podman does not _actually_ offer binary releases (but claims to do so here: https://podman.io/getting-started/installation#windows and https://github.com/containers/podman/blob/main/docs/tutorial...) because... ? They want me to compile it myself?
3) The Windows installation tutorial links to another article (https://www.redhat.com/sysadmin/podman-windows-wsl2) that is, by today's measurements, _very_ old, because... ? I cannot imagine that things have not changed since then, I refuse to believe it :D
From what I understand, Podman will become an _actually_ easy to use and viable solution to Docker for Desktop once Podman 4.1 has been released, and we have host volume mount support, which is a must-have feature for development.
I agree. I would say that the reason for using docker-slim should be motivated more by security considerations, than trying to reduce the overall image size. If you want to uphold the highest security, you would very regularly (e.g. every couple of days) invalidate the very first (or second layer), because you would be re-pulling the latest base image, and additionally run something like "apt-get update && apt-get upgrade".
So, in the end, using docker-slim does make image downloads (and container start-up time) _less_ efficient in those specific cases where you are releasing new images very often (e.g. daily, or even multiple times per day), assuming that the base image is released less often (e.g. weekly of monthly, as is e.g. the case for Python).
Just push it to some image registry (e.g. the one that comes with GitLab), and then use it as image on the next job.
You can also use tags to enforce that it is the same runner who runs the two jobs, so that pulling the image becomes instant
Knowing many keyboard shortcuts in your IDE (or other tools) is very useful. I advocate to create your own cheat sheets. I've written about it here, also covering PyCharm: https://www.augmentedmind.de/2020/04/26/boost-development-pr...
I've successfully built apps with Python and Qt (PyQt6 and PySide6 are both working fine). The overall file size of the resulting folder is about 60-80 MB on Windows, mostly due to all the Qt DLLs/plugins you'll need to ship. By manually deleting non-necessary DLLs, you might save maybe up to 20 MB. Just considering the file size, this might not a huge gain compared to Electron, I suppose?
However, keep in mind that desktop apps have the major disadvantage of figuring out distribution (separately for each platform!!), which includes the following two steps: 1) packaging the application in some format (e.g. an MSI installer for Windows and a Disk Image Bundle for macOS), and 2) distributing that package (including auto-updates). I have written a number of articles about this topic, see https://www.augmentedmind.de/2021/05/30/distributing-windows... and https://www.augmentedmind.de/2021/06/13/distributing-macos-a... . You get rid of all that if you just built a PWA or other kind of web app.
In addition, if you use Python, you also need to choose a "freezing" solution, such as PyInstaller (more details at https://www.augmentedmind.de/2021/05/16/distribute-python-ap... ).
Wow, mynoise is impressive. I do also like https://www.noisli.com which is less customizable than mynoise, though.
When I had access to surveying equipment (a Trimble R10 with RTK and sub-centimeter(!) accuracy, basically delivering ground truth), I tested the accuracy of Google Maps: in the region where I tested it, the projection of the aerial image was off by more than 2 meters!!
Fortunately, the author points this out in the article.
In my experience (I have over 10k flashcards in Anki and SuperMemo) it takes a lot of time to create the cards (vs. repeating/learning them). But the main reason is because I have to take time to think about and understand the content first, reformulate it in my own words (otherwise it won't stick well!), and cut it into bite-sized cards. What helped me most were articles "teaching" how to do this, or generally the experiences of others [1] [2].
From scanning your product's landing page, it seems you focus a lot on the time-savings during card creation, by relying on copy-and-paste. I'm not sure this is the best way to learn more complex topics, but may work fine for very clear things that are already bite-sized in the source material (e.g. chemical formulas, or language vocabulary). Are you focusing on these use cases?
[1] https://andymatuschak.org/prompts/ [2] https://news.ycombinator.com/item?id=24878171
I really like Vagrant. However, it is extremely(!) slow, and every command takes 3-30 seconds (including commands that should take 50 ms). You also know about this, and chose not to act on it :( [0]. Would the transition to Go remove this impediment?
I've found Vagrant very useful to test (or develop) GUI-based applications, especially on platforms which Docker cannot run as container, such as macOS. I've also collected further thoughts on when to choose which (and how they can be combined) here: https://www.augmentedmind.de/2020/08/02/vagrant-vs-docker/
I built an Android app that lets you create bookmarks for any kind of Android audio track (e.g. played by some music player or podcatcher app). My app, "Stop It!", captures which player app was used, which track/artist was playing, as well as the exact timestamp. I create bookmarks whenever I hear something I like (but I don't have time to pause the playback and make notes). Stop It lets me get back to that particular track and time stamp easily, hours or days later, and avoids that nice things fall through the cracks. The bookmark creation mechanism is to pause playback and immediately resume it, which you can do with any Bluetooth headset - no need to unlock your screen. The app is open source, but not on the Play store. I built it because nothing like this exists... More details here: https://www.augmentedmind.de/2020/08/16/stop-it-create-audio...