nrclark

A quick note on this for non-editing folks: in context, a "proxy" here is a low-res version of your actual footage. It's common to use them while editing a cut together, and then to replace them with the full-res versions at the very end.

Agreed - I hate captouch buttons, and would rather have physical controls every time. But in case you're curious why they're so common:

  1. They're cheaper than mechanical buttons.
  2. They're more space-efficient inside of the product.
  3. They are easy to waterproof.
  4. They have no wear-out mechanism.

Can you elaborate a bit on the dependency-handling topic? I've always thought that Bitbake's dependency handling worked pretty well. It only has package-level granularity, but is quite good within that context.

To be honest, that kind of sounds like a dystopian hell: chatGPT writing memos because we can't be arsed, and the reading the same memos because neither can the recipient. Why even bother with it?

I don't disagree, but wanted to note- if you're ever stuck trying to trace a value, you can see everything that went into its calculation by using "bitbake -e".

I've had mixed results with this approach. What happens when I try it is:

   1. I communicate DATE and CONFIDENCE_INTERVAL
   2. My manager hears DATE and CONFIDENCE_INTERVAL.
   3. My manager tells project-manager "probably somewhere around DATE"
   4. Project-manager hears "DATE"
   5. DATE becomes what people thought I said.

I believe it.

My wife is boycotting Tesla, specifically because of Elon Musk's role in the destruction of our government. We're actively shopping for an electric car, and Teslas are off the table for us. I would guess that there are others who think the same way.

Given that TSLA is a personality-driven meme stock, it's very vulnerable to public opinion. Musk is alienating a lot of people, and that is likely to reflect in Tesla's valuation and sales.

> I didn’t know English had a diminutive suffix (-kin). Is it used still in common English?

No, at least not in the US. In American English, you'd use a modifier instead of a suffix. We have some pre-diminutized words like "oopsie", but no general-purpose suffix that you can attach to anything.

There are some _prefixes_ that you can use though. You could prepend just about anything with "micro", and people will know you mean "a small version of X".

> Also, is there an augmentative suffix as well that I don’t know about?

Also no (at least not that I can think of). Modifiers are also more common. You can also use prefixes like "Mega" as an augmentative. Depending on the word, this can be used for comic effect.

It's always interesting to see different tools in this space. I'm glad that people are trying to innovate on CI/CD workflows. @pandiculation, have you checked out Dagger? How does EG compare with it?

Totally agreed on this general pattern, even you're not using Bazel or Buck2.

In my experience working in large organizations - if a developer can't easily reproduce what the CI/CD pipeline is doing, then many won't try. That leads to a lot of "push-and-pray" magical thinking, minimal local testing, and a lack of understanding about what the pipeline does and doesn't do. Across a large organization, this can also get expensive if you're using cloud-hosted build runners.

Instead of putting a bunch of build logic in your pipeline, try to put it in a local script instead. Or better yet, wrap your actual build steps with a top-level Makefile (which can then call bazel, or cmake, or whatever). Design your pipeline to run this target, and keep the pipeline logic to an absolute minimum.

Your pipelines will become small, and easy to reason about. Your CI/CD setup will be more portable between different products (Jenkins, Azure Pipelines, Buildkite, etc). And your developers will be able to use the same workflow as the pipeline, leading to fewer "but it works on my machine!"-type problems.

There is some benefit to Makefile processing speed, if that's a metric that affects your build.

With one or two $(shell) calls, it won't matter at all. If you start to approach dozens or hundreds of calls, the extra overhead of all those shells can to be noticeable. Especially if your Makefile is automatically triggered on file changes or something.

100% agree. With the current API, there's no real advantage to using Guile over a C extension (other than the choice of language). If the Guile interface could hook into Make's dependency graph, it would be huge game-changer. But as it is, the Guile interface is basically a fancy macro processor.

The Guile interface can expand Makefile expressions into values, and can process/evaluate Makefile statements. But there's no way (that I've found) to do something like "remove this dependency from target X", ask "what dependencies does X currently have?", or ask "do you think X is currently up-to-date?".

Could be. But people need a sense of purpose. I'd rather have 20k people with a make-work job than 20k people collecting unemployment. Running too lean is also bad for resiliency, which is a lesson that every manufacturing company learned during the pandemic.

There's nothing stopping you from specifying an explicit shell in your Makefile (see: https://www.gnu.org/software/make/manual/make.html#Choosing-...).

You could set it to Ash, Bash, Perl, Python, execline, Docker exec, or whatever you want really. You can also set that variable on a per-recipe basis, if you have one recipe that needs a custom shell.

(note to any GNU Make maintainers who might see this: it would be really helpful to be able to set .ONESHELL on a per-recipe basis as well!)

So that's another 20k people who are now unemployed. Kind of hard to really count that as a victory.

Doesn't that seem ultimately futile though?

Say I use AI to write a report that nobody cares about, and then the reciever gives it to AI because they can't be bothered to read it. Who is benefiting here other than OpenAI?

"You have discovered ENGINEERING"

Yes, I bounced back.

Getting soft-fired really shook me, and it was a hit to my self-confidence. I did learn some valuable life-lessons from it though, and including that nobody should ignore office politics.

Afterwards, I found a job that was a much better fit. That next job changed the direction of my career, and I'm very happy with where I am now.

I was never really concerned about the ethics, but was more worried that I'd be personally liable for it. I kept thinking about the VW emissions scandal, where the engineer that implemented it was given prison time.

In hindsight, it was probably a stupid thing for me to worry about. I also never should have expected that I'd be able to change the director's mind by refusing to do what he said.

I was laid off once. The reason on paper was budgetary, times are tough, etc. But the real reason was that I was a bad fit for the role - for a variety of reasons.

I got pipped, and foolish me tried hard to work on the items in the pip (to no effect). The layoff came right on schedule.

A few years later, I was chatting with an old coworker and I came to find out that the director of engineering had demanded it. It was in direct response to me refusing to participate in building a knowingly DMCA-violating product.

The pip was theater. The "times are tough" bit was theater. The reality is that the director wanted me gone, and that is how they did it for legal coverage reasons.

I don't really blame the company - I was a bad fit, and I can see that clearly in hindsight. But it did teach me never to accept budgetary layoffs at face value.

FWIW, I like that a lot in my text editors.

`Just` is also popular in this space, but tbh I think Make is a better choice.

Make is included in most Linux distros, including the ones available for WSL. It's also included with Apple's developer tools. It's been used for decades by millions of people, and is very mature.

If you use it in a simple way, Make is almost identical to `Just`. And when/if you want Make's powerful features, they're there and ready for you. Make's documentation is also exceptional.

I've used a bunch of these kinds of tools over the years, and I've never found one that I like more than Make.

(not the parent)

Make is - at its core - a tool for expressing and running short shell-scripts ("recipes", in Make parlance) with optional dependency relationships between each other.

Why would I want to spread out my build logic across a bunch of shell scripts that I have to stitch together, when Make is a nicely integrated solution to this exact problem?

A small correction here: 90%+ of audio I/O ports aren't general-purpose. This is because there are almost always DC-blocker circuits on each output, commonly a series capacitor. With very few exceptions, you can't use your soundcard to provide an accurate DC output such as a control voltage.

From my perspective, Just would be more useful if it had some ability to skip steps where the input hasn't changed.

Like maybe a Justfile's recipe could produce a "<task>.complete" kind of file, and could decide whether to re-run the task based on whether the task's inputs (or its dependencies' inputs).

Also if that sounds like a useful feature, consider using Make.

Just a quick note for interested readers: you don't need to explicitly mark things as .PHONY in make, unless your Makefile lives next to files/folders with the same name as your targets. So unless you had some file called "install" in the same folder, you wouldn't need to have something like ".PHONY: install".

I have mixed feelings about this.

For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make.

If that developer causes enough problems over time, that is absolutely something that their manager can and should address.

Is there a specific package manager that you're thinking of? I'm always open for recommendations.

Submodules are great for projects where your code depends on upstream Git repos that you don't control and don't want to vendor yourself.

I recently did an embedded Linux design that depended on 5 external repositories: one from Yocto, three from OpenEmbedded, and one from a CPU vendor. My own code just sat on the top of this set of repos.

Submodules made that design very simple. One repo with all of my code in it, and submodules for all external repos. All dependent repos were pinned before of how submodules work. Pins were easy to update when desired, and never move on their own.

@JohnAtQNX can you remove the "everybody needs an account" restriction from your website downloads, and also remove the license mechanism from qcc? That would go a long way towards encouraging hobbyists to try it out.

Your money comes from high-volume licensing deals, where you presumably get a per-unit license fee. That revenue stream is jeopardized by pissing off the CI/CD teams that have to support QNX product lines.