ninkendo

I think you're basically proving my point? (My point being: politics isn't just "getting elected".)

In such political systems where you essentially must vote the party line, what makes an individual "effective" (ie. what constitutes being "good" at your role)? I'd say it comes down to all kinds of political soft skills, ie. forging the right alliances, convincing the right people to change course, understanding motivations of others, etc.

All of these are generally called "politics", and are things that happen very much after you're elected.

> Politics is about getting elected

There's a lot under the umbrella of "politics" that happens after you get elected. If you want to accomplish anything after you get elected (heck, even if it's just personal enrichment) you have to be somewhat skilled at getting others to work with you, one way or another. As a politician you can have flawless convictions and be right and well-informed about all your decisions, but at the end of the day you're just one vote (to use legislators as an example) and it does nothing if you can't convince or work with others.

No, it is always right to criticize Corporate Memphis. Keep up the fight.

I don't generally do anything "incriminating" that would need to stay out of my browser history, and even if I did, clearing your local browser history isn't going to mean much: If it's truly criminal stuff you're talking about, all the websites you use are likely subpoena-able anyway and they'll get your "history" one way or another.

For mildly "incriminating" stuff that isn't illegal, just use an Incognito window. :-)

Nah, my point is that having tons of tabs open literally clouds my mind, like being in a messy room. Closing the tabs feels like I'm tidying up. History exists so that I can still go back to a tab if I really need it, which makes it less "scary" to simply start from a clean slate.

Or a history item!

People forget about browser history. It’s super useful.

My technique: I open tabs just like anyone else, and when I feel like “that’s too many tabs”, I just close them all. Every one of them.

If I need them again? Open up the browser history. It’s searchable. It has everything. Use it!

> the most "counter-intuitive" aspects of QM (interference, the uncertainty principle, entanglement) make perfect sense in this framework

Scott Aaronson’s “Quantum Computing Since Democritus” makes a similar assertion about learning QM from a linear algebra perspective and completely sidestepping all the thorny interpretation questions. It’s mostly a book about complexity theory and what quantum computers actually buy you, but it gives a lot of insight into the mathematics of it.

If you think the AI problem on YouTube is getting bad you should see what kinda stuff they put on there for kids.

Every now and then I’d let my 3 and 5 year old pick what they want to watch (on my account, but I’m supervising them) and they’d find these Mario videos that are basically someone prompting “make as many YouTube channels with Mario videos as you can” and walked away from the computer. Each video is a bunch of 3 second clips smooshed together with no continuity, backgrounds constantly changing, suddenly there’s 100 Luigi’s in the background for no reason, etc. And my kids couldn’t get enough of it.

Suddenly our recommendations were all Mario videos, and banning the channels does nothing because they’re coming from hundreds of different channels.

I just locked the profile, deleted all its history, and never looked back. No more YouTube for them.

> Natural language programming, or natural language processing, as it was called

NLP has nothing to do with programming. The Wikipedia article you linked doesn’t even mention programming once. NLP is old-school AI like you get when you try and cram all language into an ontology and try to “parse” it in an unambiguous way. It’s how Siri worked from the beginning, and it’s a complete dead-end. (I have some background here, I was an engineer on Siri for over 10 years.)

The fact that a compiler using old-school NLP would need a complete understanding of the world and all relevant facts in order to make natural language “process-able” is the reason the whole thing was a failure and why LLM’s are needed to make the idea work. You can’t just go from “parsing language” to “make me a TODO list app” without having an arbitrarily intelligent system to understand all the relevant background that such a statement implies.

When people realized human-level intelligence is necessary to make natural language programming work, is basically when the idea died. And now we have LLM’s and (what many would define as) human level intelligence, and its ability to program is just one side effect of many of it being truly artificially intelligent.

> it really comes down to whether humans or AI is more likely to take 'shortcuts'?

That’s not the original claim though, the claim is that this “vulnpocalypse” is only temporary because AI will no longer produce the kind of code it’s finding issues with. If AI still takes shortcuts, but only marginally less than the humans it’s trained to imitate, we won’t get there.

You could speculate that a year from now the models will improve to always approach problems from multiple angles and bring in multiple sub-agents each tasked with red-teaming the resulting code, and that this will be done implicitly and automatically for all tasks… and maybe that will be what actually makes this prediction come true. But that’s speculation and not what we have now.

I never said you can’t do that, I’m merely pointing out that GP’s example isn’t an example of doing that.

My point is that the Dockerfile is not a particularly good build system. It doesn’t solve any of the hard parts (how to build the thing, what to build when) and only solves problems it created (how to avoid re-running something on every invocation) and does it poorly (it doesn’t track dependencies, just determines cached-not-cached on every line.) It leads to awful hacks like putting every build step on an enormous chain of `cmd && \` lines to make sure you don’t produce extraneous layers.

A reasonable build system tracks dependencies for what needs to be built and has a target it’s trying to get to. Docker just says “do your build imperatively and we’ll figure out caching” and it’s extremely easy to shoot yourself in the foot leading to overly large images.

An example: there’s no way to say “build container: do this build and put the product here, runtime container: take the product and store it here” without creating a temporary layer in the build container that is not used anywhere else. So if your artifact is 1GB, you will always require 2GB to do a build: one for the runtime container (where you want it) and one for the build container (where you only needed it temporarily.) You just have to do “docker builder prune” every now and then when your disk inevitably gets full, there’s no way to simply not produce the duplicate in the first place.

(My workaround is to keep the artifact in a type=cache mount, store its SHA sum in the build container, then in the runtime container, grab the artifact from the type=cache mount and compare the SHA sum to make sure it didn’t change. Cache mounts can be GC’d at any time so it’s not even guaranteed to work.)

When I used docker at scale back in the day, the thing that worked best was always: bind-mount an artifacts dir into the build container, run the build. Then package up the artifacts dir. Then at runtime, fetch the artifacts, bind mount them into the runtime container. Then you can use a real artifact store on a plain HTTP server instead of messing with docker layers (no more worrying about pushing 100 1KB layers because you didn’t put enough &&’s in your dockerfile) and it was so, so much faster than any docker registry was in practice.

Dockerfiles are great for simple stuff but, if I already have a great build system that produces single binaries, it’s so much more pleasant to just use that.

I’ve never seen it work except in first party apps. YouTube, plex don’t support it, maybe Jellyfin does but I don’t remember. I’m betting it comes down to whether you use the built-in frameworks for video playback or bring your own.

These two statements are distinct:

- You can program in natural language

- You can tell an AI what to do in natural language, and it can gather requirements, sketch up a design, write code, search the web for error messages, and iterate on the program until it works.

For certain things people care about, they’re equivalent (I tell the computer what I want and out pops a program) but for certain other things, they’re absolutely not (natural language doesn’t map deterministically into machine instructions.)

When people talked about natural language programming decades ago, they were talking about a system that compiles natural language into machine code. They weren’t talking about a system that autonomously gathers requirements, decides what frameworks to use, searches the web to look up error messages, iterates on ideas, etc… these things are so different from “natural language maps to machine code” that I don’t think we’re going to have a useful discussion if you think “I tell the computer what I want” is the only aspect of this worth looking at.

> You can absolutely build images with a bash script, here's an example

That script is just calling docker to build layers manually via `docker create`/`docker commit`/`docker run`/etc, using a Dockerfile as a rudimentary DSL over it. It's still building images "the way docker does", but in a more error-prone way.

What GP is trying to say with "I would've been happy with a Bash script, or handing it a tarball", is that it ought to support giving it a literal tarball, like you'd get via `make install DESTDIR=./out && tar -czf image.tgz -C ./out .`. Or just tar'ing up the build artifacts of any other existing, competent build systems. There's no need to treat building an image as some "containerized" thing where you have to run inside the bottom layer of the container to build the artifacts.

In fact nowadays with the best practice of split container builds, there's no benefit of saying "the container is guaranteed to have the dependencies because it's the container you built with", because in practice nobody wants to ship their runtime containers with an entire build environment in them. So they do one container to do the building, then pick out the artifacts they need and place them in the runtime container. At that point, what's the point of using containers to build again?