epr

So are kids not going to have access to llms? Seems trivial to get around this from a technical standpoint for frontier llms no matter how this is implemented.

Generally I think this is a legitemate issue, although:

> the training process doesn't introduce anything novel

This is not always the case. A compiler, linter, proof checker, tests, etc. can all lower entropy.

To fix this I recently made myself a tiny tool I called jtree that recursively walks json, spitting out one line per leaf. Each line is the jq selector and leaf value separated by "=".

No more fiddling around trying to figure out the damn selector by trying to track the indentation level across a huge file. Also easy to pipe into fzf, then split on "=", trim, then pass to jq

I think there's a good one if you search around for "xv6 sh.c". Hard to tell immediately from a google search just now since there are many implementations (people do it in school) and github's currently blocking requests from my phone.

Also helpful may be running strace on your shell, then reviewing the output line by line to make sure you understand each. This is a VERY instructive exercise to do in general.

These are all great. If you need to do something more involved, pexpect is also worth mentioning. It's a reimplementation of expect in python that's easy to be productive with quickly.

I used it in a previous job to automate configuring thousands of network devices

dwm and the community around it tend to use patches for absolutely everything, unlike most other projects. For most projects/codebases, maintaining patch sets is done for security, customizations, etc., but rarely are users expected to configure their window manager by modifying the source code. dwm is well known for being very minimalist, with many features people would expect from other window managers not being included out of the box. To get something more fully featured, users are meant to cobble together their own version of dwm with multiple patches. I'm not saying this workflow doesn't work for dwm and other suckless software projects, it's just that it's pretty out of the ordinary.

So, having some experience with the project and how different x and wayland are, when I saw this commenter had brought up the idea of making the switch from x to wayland a patch, it made me laugh out loud. The idea of leaning even further into the borderline degenerate amount of patching already done with suckless software to the point where you're practically rewriting the majority of it was very funny, and so I was confused about the downvotes.

I guess people downvoting this don't get the joke?

Everything is an object in Python as well

Human beings get by quite well with extremely oversimplified (low resolution) abstractions. There is no need whatsoever for something even approaching universal or perfect. Humans aren't thinking about fundamental particles or solving differential equations in their head when they're driving a car or playing sports.

Yes, but the main thing here is that ALL software development is now "profit" in the short term. In theory you've developed a capital good that benefits you over time, hence the amortization.

Simplified 2021 example before 174:

    100k Revenue
    100k Software Dev Costs
    No profit or tax

Simplified 2022 example after 174:

    100k Revenue
    100k Software Dev Costs
    90k "profit"
    18.9k taxes

Above example is year one of suddenly having these taxes, because if your software costs are the same or lower over time it gets easier. It's just extremely painful for smaller and especially fast growing companies like startups without a lot of cash, especially when interest rates are so high.

Accountants: If I am wrong about the above, please correct me

My bad on that typo. I write "$@" so often in shell scripts that I should know better. Also would've been caught by shellcheck. Outside the hn edit window though, so my mistake is permanent :(

I'm generally not a huge fan of inlining the command or cluttering up my local directory with little scripts to get around the fact that it must be a subprocess you can send a signal to. I use a wrapper like this, which exports a function containing whatever complex logic I want to time out. The funky quoting in the timeout bash -c argument is a generalized version of what aidenn0 mentioned in another comment here (passing in args safely to subproc).

    #!/usr/bin/env bash

    long_fn () { # this can contain anything, like OPs until curl loop
      sleep $1
    }

    # to TIMEOUT_DURATION BASH_FN_NAME BASH_FN_ARGS...
    to () {
      local duration="$1"; shift
      local fn_name="$1"; shift
      export -f "$fn_name"
      timeout "$duration" bash -c "$fn_name"'  "$@"' _ $@
    }

    time to 1s long_fn 5 # will report it ran 1 second

A bit confusing for sure, but I think (not sure) I get what they're saying. Training a nn (for visual tasks at least) consists of training a model with much more dimensions (params) than the input space (eg: controller inputs + atari pixels). This contrasts with a lot of what humans do, which is take higher dimensional information (tons of data per second combining visual, audio, touch/vibration, etc) and synthesizing much lower dimensional models / heuristics / rules of thumb, like the example they give of the 5 second per mile rule for thunder.

Actually no, it's not interesting at all. Vague dismissal of an outsider is a pretty standard response by insecure academic types. It could have been interesting and/or helpful to the conversation if they went into specifics or explained anything at all. Since none of that's provided, it's "OpenAI insider" vs John Carmack AND Richard Sutton. I know who I would bet on.