nrclark

By themselves, no. But FPGAs are widely used in mixed-signal systems with an ADC on one side and a DAC on the other.

It's true that most FPGAs have limited built-in analog capabilities. But good DACs and ADCs aren't too expensive, and an FPGA can control them with exceptional precision. Does your process have some kind of input / output that can't be handled that way?

Dedicated DACs/ADCs will almost always offer better performance than the ones you'd find on a microcontroller or even an ASIC.

I use Chatgpt for coding / API questions pretty frequently. It's bad at writing code with any kind of non-trivial design complexity.

There have been a bunch of times where I've asked it to write me a snippet of code, and it cheerfully gave me back something that doesn't work for one reason or another. Hallucinated methods are common. Then I ask it to check its code, and it'll find the error and give me back code with a different error. I'll repeat the process a few times before it eventually gets back to code that resembles its first attempt. Then I'll give up and write it myself.

As an example of a task that it failed to do: I asked it to write me an example Python function that runs a subprocess, prints its stdout transparently (so that I can use it for running interactive applications), but also records the process's stdout so that I can use it later. I wanted something that used non-blocking I/O methods, so that I didn't have to explicitly poll every N milliseconds or something.

In my experience taking both, Greyhounds are significantly faster and far less comfortable. Maybe it's different in other places in the country, but this was my experience in coastal California:

Greyhound buses run more-or-less on time. The routes are direct, they're predictable, and they will take you where you want to go. They also don't have a dining car, spacious bathrooms, room to walk around and stretch your legs, etc. If somebody has diarrhea, everybody on that bus is going to know it and smell it.

Amtrak is more comfortable in every way. It's also usually late, and subject to delays because of low rail priority. You can't really count on it for anything other than "it'll leave eventually" and "it'll get there eventually". While on the train, it's really quite pleasant - as long as you don't care about arriving when the schedule said you would.

Tangential, but does anybody else get real npm vibes from the rust ecosystem?

Something about the “every productive project depends on this one external package” situation really makes me uneasy. And there are language features like async that can’t even really be used without going to crates.io for a bunch of stuff that really ought to be in the stdlib.

That's true, but grandparent's advice is a good way to pick standardized parts. If there are 4 versions of a switch with identical footprint on digikey, you can be pretty sure that you'll also be able to source it from Taobao or LCSC or something.

It can already do that, afaik. When I last checked, BusyBox supported installations via 4 methods:

  - symlink
  - hardlink
  - shell script wrappers
  - executable binary wrappers around libbusybox

Across a large enough sample set, I definitely see occasional serial errors (although they're rare).

For me, I detect them by checking the exit-code on each command that I run, and also by looking for expected output in response to the commands.

Corrective action is usually a full-stage retry.

I use pexpect frequently for automating serial-port communications. It’s very useful for implementing test/flashing automation that needs some kind of a serial-port step (such as asking u-boot to run a few commands).

There's no reason to reinvent a tool that has literally decades of development behind it, is included in pretty much every Linux distro, and does what you need.

Dismissing it as being for olds is short-sighted.

Can you give me a specific example of what I said that's incorrect?

Make recipes are literally shell scripts.

Make is designed to take a bunch of little shell scripts, give each one an arbitrary name (which can be the output files if you want, but doesn't have to be), and run them. Dependencies are run first, if your script has any of them. Files can satisfy dependencies unless you tell Make that they don't.

It's really not different from a shell script with a bunch of functions that you can call by name, except that Make has already provided the scaffolding for you (including dependency-awareness, tree walking, parallel execution, etc)

As near as I can tell, the main benefit is "new and shiny", combined with "tabs???? yuck" and "I used Make in college and never really learned it, therefore it's bad"

Make can do all of those, easily, even eliminating TABs if you really care that much (I don't, my IDE handles them and it's really not a big deal). Have you ever taken the time to learn how to use it?

Make targets can be whatever you want, and don't have to produce files.

Make -n TARGET will list everything that Make thinks it needs to do to achieve TARGET, including anything that has to happen for any expressed dependencies (which can be tasks, and don't have to produce files).

Make recipes are arbitrary shell scripts that can do whatever you want, including changing directory. Make can also include other Makefiles, or call other Makefiles.

At its core, Make is a way to express "snippets of shell scripts, with a dependency graph between them". It can track files as dependency input and output -if you want-, but Make does not care if you don't. Call your targets whatever, and don't have them produce files. Boom, command runner. Make also has a powerful design, with a lot that you can do at parse-time.

And as it turns out, most tasks -do- have some amount of file dependencies. Maybe they need to consume a key file. Maybe they download a tarball. Maybe they produce a logfile that another task uploads. Being able to express as much (or as little) of that dependency graph as I want is a feature, not a bug.

unrelated but curious - what do you think of OSTree-based embedded distros? Any future in it?

Agreed, NXP does a good job with their yocto layer.

Globally, I would bet that there are more daily Android users than daily Windows users. There is no real competitor to Youtube.

You mean strnlen.

I like Tcl. It's still very common in the electronics design industry, and it's a fun language to write things in. Kind of feels halfway in-between LISP and Bash. Tcl is also found in Python (weirdly) as the implementation language of Tkinter.

It's not exactly a popular language these days, but it has its niches. It has a small runtime with an event loop and a nice GUI extension. It's stable, easy to embed into other programs, easy to write, supports networking and all kinds of OS operations, and has a large body of libraries and examples out there. Its performance is also pretty reasonable these days.

These days, I think that Lua and Python are more common as extension languages - and that's totally fine. But there will always be room in my toolbox for Tcl.

That chart has real Krazam Microservices vibes to it.

If you were trying to convince a german to abandon old/bad process, what would be a convincing / resonant counter-statement?

it's worth noting: meat production is only resource-intensive because of the amount that we produce. In smaller quantities, cows / sheep / goats can graze on land that isn't useful for anything else. Pigs and chickens can eat garbage.

Pigs especially were a significant urban technological advance, good at turning most kinds of organic matter into usable food. They played a big role in the rise of many civilizations.

If we ate less meat overall, we could absolutely produce it in ways that were environmentally friendly.

The nice thing about my approach is that pip-tools is only needed when modifying your requirements, and it also lives in a separate venv/requirements.txt from the dependencies you actually care about.

So yes: you need those dependencies in a development context, if you're actively modifying your Python requirements. But they don't make their way into your production requirements.txt, and don't need to be installed anywhere other than a short-lived venv.

I ship a lot of Python in a CI/CD or devops context, and also deploy it to embedded targets. I've never needed anything more than pip, a venv, and pip-tools (to provide pip-compile). Venvs are treated as disposable. The basic workflow I use is:

One-time (or as-needed for manual upgrades):

   1. Make a venv with setuptools, wheel, and pip-tools (to get pip-compile) installed.
   2. Use venv's pip-compile to generate a fully-pinned piptools-requirements.txt for the venv.
   3. Check piptools-requirements.txt into my repo. This is used to get a stable, versioned `pip-compile` for use on my payload requirements.

During normal development:

    1. Add high-level dependencies to a `requirements.in` file. Usually unversioned, unless there's a good reason to specify something more exact.
    2. On changes to `requirements.in`, make a venv from `piptools-requirements.txt` and its `pip-compile` to solve `requirements.in` into a fully-pinned `requirements.txt`.
    3. Check requirements.in and requirements.txt into the repo. 
    4. Install packages from requirements.txt when making the venv that I need for production.

This approach is very easy to automate, CI/CD friendly, and completely repeatable. It doesn't require any nonstandard tools to deploy (and only needs pip-compile when recompiling requirements.txt). It also makes a clear distinction between "what packages do the developers actually want?" and "what is the fully-versioned set of all dependencies".

It's worked great for me over the years, and I'd highly recommend it as a reliable way to use the standard Python package tooling.

Is there any good way to make some Bazel targets hermetic, and some non-hermetic? I'd love to be able to set my build up with something kind of like:

    1. Non-isolated Bazel target that produces a container image.
    2. All other targets are isolated, and build inside of a container created from the new image.

One other hidden Bazel trap that I've seen is for companies to migrate a large codebase to Bazel, but then to rely on OS-provided tools and libraries. Commonly, this gets paired with a glib answer like "it's fine, we build from inside of a Docker container". But I've never seen that Docker image linked into Bazel's dependency resolver, or the compose scripts used to launch the container.

This has the following effects:

    1. There are unexpressed package/tool dependencies.
    2. Across a large organization, Bazel's reproducibility guarantees go out the window.
    3. Developers can't just clone the repo and start using Bazel. Instead, they have to pull down some pinned Docker image, or build it themselves and lose reproducibility.
    4. This effectively poisons the cache whenever the Docker image is updated or rebuilt. If using a shared remote cache, it can be a major issue.

If an organization isn't big enough to vendor every single tool dependency, shared library, etc (which basically requires building out an OS distribution in Bazel), what's the right way to approach this problem?

Can you point me at some more detailed rules that support your assertion? Not trying to argue - I’m actually interested to read more details on that.

QNX really needs to modernize if they want to survive. Their tooling ecosystem is stuck in 2008, and their kernel's performance is pretty low. IIRC, the kernel itself is also single-threaded, and can't take advantage of multiple CPUs (even if tasks can be SMP scheduled).

Their moat is supposedly their ASIL certification, but I see that value shrinking more and more over time for the following reasons:

1. If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.

2. I'm not convinced that the QNX kernel is less buggy than the Linux kernel. Also, most failures don't tend to be kernel related.

For the curious - it looks like this uses the Allwinner F1C100S, which is a 533MHz single-core ARMv7 with 32MB of onboard DRAM.

What other parts are out there that are similar to this? It would be fun to play with one that has a little more RAM, and maybe a faster clock rate.

Iterm2’s remote tmux integration is a killer feature for me. Gives you a native, normal “windows and tabs” kind of feel, but for a remote connection. You can also disconnect/reconnect without losing your windows and tabs.

You don’t need to know any tmux to use it either (except for how to launch the right mode, which is easy to script).

If you spend a lot of time SSHed to other computers, I would highly recommend trying it out.