This isn't true in the broad sense you've used. It's true that most people don't have the hardware to run the bleeding-edge foundation models, but with a modest Macbook you can run very capable local models now (at least capable for coding, where my experience is).
Here I was talking of the AI vendors - they specifically provide inferior models for local usage while offering the "insanely" good models only online.
AI can be run locally but with the growth of agent factories, this is going to be less and less possible if you want to keep up with the Jones.
How "fat" are the packed machines? In other words, how much bloat is inevitable, or is that entirely controlled by the base image + the user's smolvm machine spec? How does smolvm's pack compare to something like dockerc [0] in terms of speed and size? Disclaimer: I just learned about dockerc!
I can't actually create and test a pack right now because of [1], but I love the idea of using this to distribute applications you might otherwise use a Docker image for.
He had in his path a script called `\#` that he used to comment out pipe elements like `mycmd1 | \# mycmd2 | mycmd3`. This was how the script was written:
```
#!/bin/sh
cat
```
Can you explain to me why either of these is useful?
I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.
Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.
Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.
As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
Wow I hate* that. I use bracket comments. They're cool cause they are bracket comments, so I use it in scripts to document pipelines. They are annoying cause they are bracket comments, in an interactive shell I have to type more and in TWO places. It's fun to reason-out how it works ;)
$ echo foo | tr fo FO | sed 's/FOO/BAR/'
BAR
$ echo foo | ${IFS# tr fo FO | } sed 's/FOO/BAR/'
foo
It's nice to have a way to both /* ... */ and // ...
in shell scripts though:
foo \
| bar ${IFS Do the bar. Do it. } \
| baz
* in the best possible way, like it's awful - I hate I didn't think of that
There's good and bad to both approaches. I like how I can use () and {} to bracket things and otherwise every line that end in \ is continued. I line-up on the left with the operator, you with indentation. When you use a # style comment, you have to look up and back and forward to see what the operator is you are continuing over to the next line:
aha! I see what you mean, it's indeed a nice option, yep.
Using brackets like this is something I never thought of, and it's probably why it's hard for me to process it, but I can see it provides nice annotation capabilities, and it's a more self-contained style.
Haha yeah, can't have nice things I guess. I'm currently working on automated moderation to catch that stuff faster. In the meantime, Report button exists if you stumble into anything awful.
I got this itch too when I came across tinyrenderer [1] and worked through the early lessons through shading, but didn't quite finish the texture mapping yet [2]. It was fun to work in pure C from first principles, even side-questing to write a simple TGA file reader and writer.
I'd be very interested to see your tutorial when it's done!
> Violin bowing, the researchers say, is a much more complicated interaction to model.
reply