oftenwrong

The caching support is mostly the same. Both Earthly and Dockerfile are BuildKit frontends. BuildKit provides the caching mechanisms.

A possible exception is the "auto skip" feature for Earthly Cloud, since I do not know how that is implemented.

Personal freedom is weighed against the freedom of others. That is why you cannot dispose of your waste in a water reservoir that supplies drinking water. The life of any product has an impact on shared resources that your work has not earned. Policies that aim to protect these shared resources are a logical solution for people who care about their country and the people in it.

text-only version of the article: https://text.npr.org/685533353

One of the authors, Michaeleen Doucleff, also wrote a book called Hunt, Gather, Parent: What Ancient Cultures Can Teach Us About the Lost Art of Raising Happy, Helpful Little Humans. It's interesting, and has some useful points to think about while parenting. However, I felt that a lot of the concepts would be difficult to apply in the WEIRD (Western, Educated, Industrialized, Rich, and Democratic) society I live in. The author acknowledges this, of course.

I associate re-usable bags with caring about not wasting things. You seem to value the ability to waste things. You do not seem to think it's worth preventing your dog from destroying your bags. You do not seem to exercise care to actually re-use the bags, since you say they are piling up in your home. If the standard of living is facing such a precipitous decline that you are potentially planning an escape, why would you casually throw away useful items, and continue to spend money on new items when you don't actual need to? What would you think of a person that leaves their car idling at all times and complains that they are oppressed by an increase in gas prices?

I think that is possible. My mother has had the same cotton canvas grocery bags for ~40 years. They are faded from washing, but are still strong, and she still uses them.

The other advantage is that cotton bags do not shed as many microplastics (the thread is almost always synthetic).

Many of the "re-usable" woven plastic bags I've acquired in recent years are of extremely poor quality. I have had to re-stitch many of them, and some had to be discarded after a very short service life.

Some companies offer compact reusable bags that can be stored in a coat pocket. For example:

https://seatosummit.com/products/ultra-sil-day-pack - I've had a few different versions of this bag for years. There are also cheaper/bigger/different versions of the same sort of thing you can find online for "packable daypack".

https://nanobag.com/products/nanobag - I have heard good things about these, but I prefer a backpack because it allows me to be hands-free, or to use my hands to hold more items.

However, I would start by carrying a lightweight "single-use" plastic bag, and simply re-use it. Plastic bags are not as strong as these premium bags, but they hold up well enough to be useful in most scenarios.

It's quite typical. You `docker run`, and specify the options to mount the work tree of the project into the container.

This seems like the sort of thing one would read about in https://lowtechmagazine.com/

They mentioned hooded chairs and bed canopies: https://solar.lowtechmagazine.com/2015/02/restoring-the-old-...

Git is a tool for collaboration, but is sometimes a poor fit for the reality of centralised, corporate software development. I'd like to see a product that fills these gaps, and I sense that this is part of what Diversion is about. For example, large file support in git depends on clunky hacks (that I respect) like LFS, but Diversion aims to make it actually work seamlessly. Companies awkwardly split their projects across many repos just to allow for access control, but Diversion aims to makes it easy by letting you just set access for directory. Those are great, "no-brainer" advances. There are a lot of other places where clunky hacks appear in popular git usage. A lot of those are also areas where big tech has introduced their own internal solutions. Maybe Diversion can cover some of these? Some examples:

- git has a very useful hooks mechanism, but each user has to manage their installed hooks in their own clone. This should be made more team-compatible. Make hooks a part of the history that can be patched by anyone, and then others can update their hooks simply by pulling. A less-clunky, built-in version of https://pre-commit.com/ , basically.

- Keeping with use cases for hooks, it should be possible to apply code formatting transparently. Nobody should have to think about code formatting, ever. It's a common practice to ensure code conforms to the company's standard format. However, why can't a developer also work in their preferred format? It should be possible for the system to handle this. I work in my preferred format, but all of the committed code is actually in the company's standard format. A bidirectional transformation.

- Break down the barrier between repo and other channels of company communication. Often companies have a wiki, a document drive, a chat app, a ticket system. With the ability to include real-time collaboration in the repo, it makes it possible to unify all of these things, ideally while keeping a full history. I basically want to version control my entire company, including what all of the non-devs are producing. Fossil has some of this capability, but it hasn't captured the mainstream: https://fossil-scm.org/home/doc/trunk/www/whyallinone.md

- Make repos composable. It should be possible to include a repo in another repo in a way that isn't clunky. Submodules, subtrees and subrepos are clunky. A use case for this would be including a third party library as source. It should also be possible to take one piece of a repo, and distribute that "view" while allowing bidirectional contribution. An example use case for this would be for maintaining a public open source project simultaneously in the company monorepo and on a public forge. There are (very nice) hacks for this like https://github.com/google/copybara and https://josh-project.github.io/josh/ , but these have considerable clunk-factor. When repos can be sliced and glued like this, a lot of the monorepo vs polyrepo debate becomes unnecessary; we can have both.

- Make it easy for everyone to use a patch stacking / "branchless" workflow with Diversion. There are numerous projects to enable stacking in git, and it's ubiquitous in big tech, yet it hasn't gone mainstream. It's only a matter of time until some company brings this to the masses.

- Allow history to be viewed and maintained at varying granularity. As I'm sure you know, a common debate you will see unfolding online is between keeping a clean, manicured history, and keeping a full history of what you actually did. You see git forges try to split the difference by offering squash merges. You see people recommending --first-parent for viewing the logs without noise. To me, this all points to a pointless limitation of the tooling. Why can't I take the raw, messy, actual commit log of what I did, and then bundle those up into a non-destructive "summary" commit that appears in the log. That way, people can see the clean, summarised version of my change, but can also dive deeper and see all of the twists and turns I took while producing that change.

There is so much room to improve version control. Much like build systems, I feel like the industry standard falls short of what we know is possible. I am happy to see new developements in this space.

Eventually these stores will fix the user experience issues (and I don't just mean the interface), and it will be much better. I tried a newer self-checkout kiosk at a store recently, and it was an improvement over the old system, but there were still a number of very obvious usability issues, unclear aspects, and annoyances that should have been fixed before the release. I expect they are planning to correct them in a software update.

This article is not really about debugging, but I would like to add something about debugging, and how the author relates it to programming:

I recall one time I helped a relative diagnose and fix a problem with the plumbing at his cottage. My relative was so elated afterward because he enjoyed the evidence gathering, proposing a hypothesis, going down one path of investigation, crossing that off, going down another path, trying experiments, etc. That was all a new experience for him. I didn't want to ruin his excitement by saying what I was thinking: that it was exactly the same debugging I have done all day at work nearly every day for years, and so I did not share his excitement, although I always enjoy a good debugging session.

This is all to say that I don't think debugging should be seen as exclusively a programming skill. It's a general skill that can be applied to certain types of problem solving. I probably learned it initially by playing with toys like train sets and wooden blocks. Later, I would use it when repairing things around the home. The schools I attended never attempted to teach debugging. My parents never knew how to debug. I think it is a useful skill for any person to know, but maybe I am biased. If we wanted to, we could teach children how to do it with physical mechanisms, and it would probably be intuitive, and maybe even fun.

Layers are a mechanism for de-duplicated storage, as well as incremental distribution, builds, scanning, and more. This is related to OCI being a full ecosystem of integrated solutions. Layers provide value across several concerns in OCI. In contrast, systemd-nspawn does not attempt address any of these aspects, and does not even have the same concept of a container image (just a disk image). systemd-nspawn is a single tool that does one thing well, which is not a bad thing, but also means it requires many other pieces to provide the same functionality as one would get with a typical set of OCI-compatible tools.

I will add that layers are an imperfect solution, but they are, IMO, simple and practical, and have provided value in a way that is relatively unobtrustive. In other words, many people have gained value from layers without having to think much about them.

>There were these myths or legends in the business, which I didn’t, personally, experience, but I knew about them and I could tell you 50 stories like that.

I wish I could hear more of them. Someone should write them all down.

I recommend using https://github.com/newren/git-filter-repo instead of filter-branch.

Isn't the "state" parameter often used for including the return url? Similar to RelayState in SAML2?

This article might provide some insight:

https://earthly.dev/blog/bazel-build/

My thoughts, as someone who has done a lot of build engineering, but that has only a small amount of experience with bazel:

If you are working with languages that are well supported by existing, maintained bazel rules, maybe. Otherwise, the answer is likely "no". You do not want to take on the burden of maintaining significant rules, or figuring out how to mate your ecosystem of choice to an opinionated build system that nobody else in your ecosystem uses.

If you can manage with something easier to setup, it probably makes sense to do that instead. My general experience in startups is that you have to "pick your battles" constantly. You don't have the luxury of infinite time and resources. Work on the build system has a high opportunity cost.

Most developers and other people who aren't build nerds care about the answer to two questions in regard to builds:

1. Is the build fast enough?

2. Is the build working?

That's it. This is frustrating when they don't understand the other important aspects of build system quality, but it is also, admittedly, somewhat of a pragmatic perspective.

There is much leeway inherent in the speed question. If the build is slow, people can wait. Do they have any other choice? There is plenty of other work to do while they wait.

If the build doesn't work, you, THE build guy, are going to feel the pressure to get it working again quickly. This often turns to bodging, and eventually to something resembling life support. However, nobody will care how much of a brittle, knotted mess the build code is if it still manages to mostly work.

To put it bluntly: A startup company can probably survive with a shit build system. And that might even be the right answer depending on the context.

I would personally be perfectly happy to get paid to set up a beautiful, apex example of a build system for a startup, whether it makes business sense or not. My professional integrity just won't allow me to recommend that path unless I think it's justified.

I might recommend to start with a script, or a makefile, or a ninja generator, and see how that works out first. After all, that is how Google did it for a long time before they decided to create Blaze.

No, you can use https://github.com/bazelbuild/rules_jvm_external

If you haven't discovered recursive path expansion with `**` yet, which is supported by a number of popular shells, including bash, it is about to improve your shell life.

There is a YouTube channel largely focused on this topic:

https://www.youtube.com/@the_aesthetic_city

There are even more fundamental mistakes in the concept of page styling. For example, that a webmaster should attempt to choose a readable font size and font colour on behalf of their users without knowing anything about the users' needs in that regard.

I am not familiar with a project that does that specifically. However, you can easily perform that type of operation with git-filter-repo and its --commit-callback flag , which lets you modify commit objects with a custom Python snippet.

https://github.com/newren/git-filter-repo

Make-like build system. This would expose students to a few useful concepts, and can be a 'jumping-off point' into various more advanced concepts.

- topological sorting the build graph - what is a graph - running child processes - what a process is - process api - interaction with the filesystem - r/w files - mtime comparisons - how computers store time - what is incremental execution

I would suggest to skip parsing, and use a Python literal to hold the 'Makefile'-equivalent dependency graph data structure.

You let students come up with their own fun build graphs, like making sushi:

tuna_maki -> nori, cooked_rice, tuna_fillet, chef, sushi_roller

cooked_rice -> uncooked_rice, rice_cooker, water, rice_seasoning

tuna_fillet -> tuna_slab, knife

tuna_slab -> fishmonger, money

nori -> algae, dehydrator

And then, when executed, it would print the steps, or say that a target was already made.

On a related note, I dislike when time zones are omitted from displayed datetimes. I have to guess: Is it my client's tz, the server's tz, UTC, or something else?

I am surprised that cardboard (corrugated fibreboard) furniture is not more common. It is an impressively durable and strong material despite its low cost. We could all have the option of cheap, lightweight, easy-to-move, utilitarian, eco-friendly furniture. There are only a few companies, like https://www.chairigami.com/ , that produce such furniture.

I cannot see myself subscribing until they make the search API generally available.

>NOTE: The Search API is currently only available to customers of the Kagi Teams plan. Please reach out to vlad@kagi.com for invite.

https://help.kagi.com/kagi/api/search.html

It sounds like an excellent product, but I don't want to be forced to use their client/interface; I want to be able to make my own.

The OCI runtime spec includes vm-related config, so you can create a runtime bundle that specifies that the container should boot with a specific kernel, for example.

https://github.com/opencontainers/runtime-spec/blob/main/con...

Based on my reading, Permazen does insulate the user from the data organisation.

https://github.com/permazen/permazen/wiki/FAQ#architecture

It provides a Java view of the data, and handles translating operations in that later into operations on the underlying stores.

>For the record, I'm not interested in reading whether someone selected a 'yellow dress' or 'purpley pink flowers' or who picked someone up when. I'd be more interested in reading about actual intersex issues.

That is all relevant. The immense gravity of her decision to become openly, publicly intersex, and the hours of apprehension and coaching required to go through with it, is a significant aspect.

One of the chief benefits of Earthly is builds that are always clean and predictable. This is especially important on a shared build server.

Earthly makes use of BuildKit, which essentially executes the build steps in containers. It provides more isolation from the CI runner / dev workstation. Instead of having developers manage their own build tools, Earthly makes it easy to have the build definition manage them.