It’s got your number.

Read through the Readme and it’s definitely a good tool to know about. It doesn’t fit the needs of my current problem, but I’m certain I’ll use it in the future for context sensitive searching, since grep/awk/sed/tr have definitely fallen flat for me in the past. I might also be able to study how they utilized tree-sitter CLI when I explore my own implementation.

For my purposes, I want to take a group of similar-yet-different YAML file sets (though file type should be arbitrary), and feed them through a tool that will spit out a YAML template containing everything that is shared between multiple sets.

Then, I want it to create a file for each YAML which defines which parts to pull from the template file and a list of variables to be inserted into holes in the templates. Basically creating a madlib that can recreate any file in the original group given the right list of variables to insert.

For example, if I have a hundred YAML files that are mostly similar but contain different project names, have different server types provisioned, and are pulling different product versions, I would want this script to parse all hundred files and spit out a template that could be used as the basis to build any of the hundred files. The template would be combined with a hundred variable trees that would insert each unique part of each file into the right place.

In effect, I could have a small variables file that gives only the unique portions of the equivalent YAML - in this case, it would contain only the project name, the server type, the product version. Then, these small files could be combined with the universal template to recreate the original hundred YAML files. But unlike using a simple override mechanism, I would be able to change elements of the template YAML including broad structural changes, and after some processing, the change would affect all one hundred output YAMLs.

One could track things like environment variables that are specific to a certain project version and require that whenever a project version has a particular value to insert a particular environment variable into the output YAML. Or a centralized file could be made specifying which product versions correspond to which projects, allowing the engineer to change all product versions for a given set of projects in one go. Or one could create a universal template of IaC code that’s applicable to a broad swath of use cases and quickly build out a full set of YAML manifests and Terraform files using a small file that specifies what components will be needed and where to authenticate to the server.

I’m not aware of any tool that does this, but I think tree-sitter gets me much of the way there. If I can use it to parse any given file into a context aware tree, I would then need to make a script that combines the shared features of many context trees and splits the unique features out into small variable files. Then a script to merge them back together as needed. And something to manage file system structure, such as whether to parse every file individually or to strategically merge some sets so you have one variable file that produces multiple output YAML.

Sorry I’m brainstorming at you, just trying to figure out if the tool I’m envisioning is even feasible. Seems like it is, but I’ll have to figure out how to use tree-sitter CLI before I begin.

Pirate keys for sure. Not using one is just asking for a stranger to grab your booty.

It is time to fill your role in the family business, Wishbone.

United States, United Kingdom, Norway, Australia, Canada

I might not remember what I was supposed to do this afternoon, but I know the surface temperature of the sun. I mean, I know there is one.

This is super cool. Watched the talks from Max Brunsfeld, surprised this has been around since 2018 and I haven’t heard of it.

I actually tried some complex parsing myself lately. I had a bunch of YAML I needed to maintain for various deployments in a CI/CD system. I really wanted to have one YAML template to generate the files, plus a file for each project with unique elements to be injected into that project’s generated YAML.

Probably was more of an indication that we needed to clean up the overrides we were putting on top of our Helm charts, but I wanted a way to generate our lengthy override files without having to manually keep track of where the differences were between projects. And maybe even stage changes to deployment files for when new product versions are released.

This is exciting. I’m going to look into Tree Sitter more and maybe try to contact the dev. It seems like it does everything I’m looking for, just for an entirely different use case.

I used to work for a company that did various kinds of biometric recognition. I unfortunately was paraded past these cameras many times for testing purposes, so my face was compromised many moons ago.

We had two kinds of products we installed in airports. When looking at large crowds most airports wanted cameras that would monitor the flow of traffic, determining if there were any bottlenecks causing people to arrive at their gate (or baggage claim) after their luggage.

The other product was facial recognition for identification purposes. These are the machines you have to stand right next to. There are various legal reasons airports did not want to use any crowd-level cameras for identification. They hadn’t obtained consent, but also, the low resolution per face would lead to many more false positives. It was also too costly.

But we did have high def cameras installed in strategic locations at large music halls. These private companies were less concerned with privacy and more concerned with keeping banned individuals out of their property. In those cases, we registered faces of people who were kicked out for various reasons and ignored all other faces.

My point I guess is twofold: first, you might not be facially tracked in as many places as you think you are. Second, eventually you will be and there’s not a whole lot we can do to stop it. For many years, Target has identified people with their payment card, used facial recognition to detect when they return to the store, and used crowd tracking to see where in the store you go (and sometimes they have even changed ad displays based on the demographics of people standing nearby).

Mostly, you will be identified and tracked when there is financial incentive to do so.

Makes sense. Thanks for the info!

I finally got fed up with my Windows machine and upon seeing symptoms of motherboard failure, I’ve ordered all the parts for a new rig and intend on installing Linux as my primary OS.

Haven’t decided on a distro yet. I’m a DevOps engineer with a few passion projects, so I plan on setting up a couple of kubernetes clusters where I can play. I do all the usual things (word processing, gaming, web browsing, multimedia, etc), plus some AI stuff (stable diffusion, local LLMs, OpenCV). Ideally don’t want to have to fuss with drivers too much, but I don’t mind getting my hands dirty every now and then.

Is Chimera the kind of distro I should be looking at, or should I pick something else for my first go at full-time Linux?

Respectfully, I disagree. We’ve entered an AI boom, and right now, the star of the show is in a bit of a gangly awkward teenage phase. But already, these large data models are eating up mountains of energy. We’ll certainly make the technology more energy efficient, but we’re also going to rely on it more and more as it gets better. Any efficiency gains will be eaten up by AI models many times more complex and numerous than what we have now.

As climate change warms the globe, we’re all going to be running our air conditioning more, and nowhere will that be more true than the server centers where we centralize AI. To combat climate change, we may figure out ways of stripping carbon from the air and this will require energy too.

Solar is good. It’s meeting much of our need. Wind and hydroelectric fill gaps when solar isn’t enough. We have some battery infrastructure for night time and we’ll get better at that too. But there will come a point where we reach saturation of available land space.

If we can supplement our energy supply with a technology that requires a relatively small footprint (when it comes to powering a Metropolitan area), can theoretically produce a ton of power, requires resources that are plentiful on Earth like deuterium, and doesn’t produce a toxic byproduct, I think we should do everything in our power to make this technology feasible. But I can certainly agree that we should try to get our needs completely met with other renewables in the meantime.

Oh whale…

Everything is a meme.

Entomologist

Yeah. Been trying to find a non-boring way to visualize the start of the universe for a long time. Most of the time I reach for binary which in retrospect is way less fun than trains 🚂

A lot of people describe the first moment of the big bang as infinitely small, dense, and hot. These descriptions may approximate that first moment of existence, but they slightly miss the mark because in the very first moment of existence, size, density, and temperature didn’t exist. There was nothing to compare anything else against.

Instead, let’s visualize that moment as infinitely same. Erase all thoughts of violent explosions happening very quickly and instead just imagine a single point of light. Not big, because size requires multiple things. Not small because it encompasses everything. Just one infinite same.

Now, since it’s hard for us to visualize change in an infinite void that is simultaneously nothing and everything, imagine that point of light as a magical tank engine at the front of a never-ending train. And our job as conductors of that train is to get to the caboose at the end.

The train cars could theoretically go in any order, but because we conductors are beings of time who need them to arrive on a schedule, we must visit each car in a precise order. And before we can access a car, we must make it unique by showing it something that has never been seen before.

For the first car, this is easy. We simply show it the tank engine at the front of the train. So, the inside of the first car transforms its interior into a copy of the tank engine it’s attached to.

But when we arrive at the second car, things are more complicated. The cars have already seen the tank engine. So, instead, we show the second car the first car. And the second car transforms into a copy of the first car and the tank engine attached to that. And inside the copy of the first car is another copy of the tank engine.

As you can imagine, the further down we get on this train, the more this starts to get out of hand. Copies of copies of copies abound. The magic train is powerful, but as mortal conductors of time, we worry our own powers may have limits. So, to reduce the burden on ourselves, we take some shortcuts. Instead of trying to visualize increasingly long nested copies of trains inside each new car we visit, we start to conceptualize these copies as amounts, or amplitudes. When we open the door to a new car, all of the amplitudes inside resonate and interact, becoming maybe more abstract than they are in reality. They form spatial dimensions and physical properties, as mediated by fundamental forces.

These aren’t set in stone, but determined by the lens through which we view them. And when we look through specific lenses, we see these forces causing certain repeated amplitudes to intermingle and stabilize to the point that even though all of the train copies are further nested when we step into the next car, we can recognize and identify some of the same structures, just shifted slightly in their spatial relationships since we last witnessed them in the previous car. We call these persistent formations matter. And as their shared spatial relationships cause them to cluster and coalesce, we refer to that as gravity.

While in the early cars, this continuum of space and matter is not impossible to conceptualize, the more cars we travel through, the more apparent it becomes that these increasingly complex objects are becoming more and more isolated from each other. At every scale of amplitude, each nested car is attached to its own tank engine. While these engines can interact with each other virtually, at the end of the day, they are all just virtual copies of the train we are on. It is entirely impossible for any one of these tank engines to travel so far that it reaches the edge of its bounding box. Because that bounding box is just a lens through which we imagine overlapping traits of increasingly many very similar objects. And the more of them we imagine, the more space is required to provide the virtual framework of this lens.

So, when we feel like we are experiencing random events in our small subsection of the universe, those events are not truly random, but instead the result of our precise position in the the universal train we’ve been virtually sliding through for over 13 billion years. The universe has become so large that it contains every possible event that could have happened in this span of time. The events are not random but calculated, and duplicated every moment so that every time we enter a new train car, two copies of our observable universe exist at a distance so far apart it’s impossible to comprehend.

And when we observe celestial objects apparently propelled away from each other at increasing speed, they are not really being pushed or pulled anywhere. It is simply an artifact of trying to keep track of the “same” object in rapidly advancing train cars, while each car doubles in size to contain everything the previous car had, as well as everything new that might emerge from the duplication event. The celestial objects year by year, and indeed ourselves from moment to moment, are never the same thing twice. It’s an illusion brought forth by our brains being born into a cosmic flipbook.

Even something as simple as seeing multicolored pixels on this screen is not real, but the result of virtual “tank engines” moving into the same spatial zones occupied by our retinas, which are themselves constructed of virtual trains of varying size. The reason photons move at a set maximum speed which makes them exempt from experiencing time is because they are all just virtual copies of the real locomotive which is driving the whole train. Every photon in our universe is just a make-believe copy of the very first moment of the big bang. A specter of infinite sameness.

So, objects in our universe aren’t moving apart as much as the space between them is increasing to account for the overhead of a universe with constantly growing entropy and uniqueness. The extra space represents a boundary which limits how far light can travel and affect matter in its realm of influence. If you’re still reading this, somewhere out there, in a part of our universe so far away that light from our known universe will never even remotely reach, there is an opposite you made of antimatter reading the exact same thing as written by an opposite me. But we are only made of matter because of a virtual compression of sameness, so that antiverse may be the exact place where the curvature of the entire universe loops back around and is overlaid upon itself. And the uncertainty of photons may arise from the fact that there are two identical universes overlapped and constantly exchanging probabilities. And this may be the compressive property which allows the fundamental forces to exist in the first place. So, say hi to yourself. You’re the reason you’re here.

deleted by creator

I’d call it a success, in that as I was scrolling, before I saw the title, I thought, “Is that meant to be Danny Pudi?”

I understand how this one is loss. I’m just saying that in general, all undecipherable memes lead to loss.

This is my reaction to any meme I don’t understand. I know it’s loss. I just need to figure out how it’s loss.