HN user

epr

831 karma
Posts0
Comments183
View on HN
No posts found.

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

Building a Shell 4 months ago

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

Dwl: Dwm for Wayland 12 months ago

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.

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.

We studied 198 randomly sampled, real world fail- ures reported on five popular distributed data-analytic and storage systems, including HDFS, a distributed file system [27]; Hadoop MapReduce, a distributed data- analytic framework [28]; HBase and Cassandra, two NoSQL distributed databases [2, 3]; and Redis, an in- memory key-value store supporting master/slave replica- tion [54]

So, analyzing databases, we picked Java, Java, Java, Java, and one in C. This does not seem very random. I suppose this may provide insight into failure modes in Java codebases in particular, but I'm not sure I'd be in a hurry to generalize.

The best answer to your question is some variant of "write more assembly".

When someone indicates to me they want to learn programming for example, I ask them how many programs they've written. The answer is usually zero, and in fact I've never even heard greater than 10. No one will answer a larger number because that selects out people who would even ask the question. If you write 1000 programs that solve real problems, you'll be at least okay. 10k and you'll be pretty damn good. 100k and you might be better than the guy who wrote the assembly manual.

For a fun answer, this is a $20 nand2tetris-esque game that holds your hand through creating multiple cpu architectures from scratch with verification (similarly to prolog/vhdl), plus your own assembly language. I admittedly always end up writing an assembler outside of the game that copies to my clipboard, but I'm pretty fussy about ux and prefer my normal tools.

https://store.steampowered.com/app/1444480/Turing_Complete/

For what's written in assembly, lack of portability is a given. The only exceptions would presumably be high level entry points called to from C, etc. If you wanted to support multiple targets, you have completely separate assembly modules for each architecture at least. You'd even need to bifurcate further for each simd generation (within x64 for example).

If someone doesn't understand "container", I'm supposed to expect them to understand all the namespaces and their uses, cgroups, and the nitty gritty of the wimpy security isolation? You are proving my point that it's tough to summarize by using a bunch more terms that are difficult to summarize.

Once you recursively expand all the concepts, you will have multiple dense paragraphs, which don't "summarize" anything, but instead provide full explanations.

Having multiple processes under one user in an operating system is more akin to having multiple threads in one process than you think.

Not than I think. I'm well aware of how "tasks" work in Linux specifically, and am pretty comfortable working directly with clone.

Your explanation is great, but I intentionally went out of my way to not explain it and instead give a simple analogy. The entire point was that it's difficult to summarize.

No, they are not. I'm not sure who started this whole container is just a process thing, but it's not a good analogy. Quite a lot of things you spin up containers for have multiple processes (databases, web servers, etc).

Containers are inherently difficult to sum up in a sentence. Perhaps the most reasonable comparison is to liken them to a "lightweight" vm, but the reasons people use them are so drastically different than vms at this point. The most common usecase for containers is having a decent toolchain for simple, somewhat reproducible software environments. Containers are mostly a hack to get around the mess we've made in software.

Do you really believe what you're saying, or are you just trying to "win" the argument? The nukes functioned as intended...

I disagree. The reason humans anthropomorphize "AI" is because we apply our own meta-models of intelligence to llms, etc., where they simply don't apply. The model can spit out something that seems extremely intelligent and well thought out that would truly be shocking if a monkey said it for example due to our meta-model of intelligence, and that may be valid in that case if we determined it wasn't simply memorized. His argument can certainly be more fleshed out, but the point he's making is correct, which is that we can't treat the output of a machine designed to replicate human input as though it contains the requisite intelligence/"feeling"/etc to produce that output on it's own.

As someone who's been following this since the beginning, the most striking difference is the assumption that Ross was in fact the DPR ordering hits, which he repeatedly denied. Obviously, he could be lying, but that's the main question for me. Since people now assume he was the one and only DPR (I wonder if people didn't get the concept from The Princess Bride), they assume DPR chat logs where murder-for-hire occurred must have been him as well.

The big problem is that NEAT can't leverage a GPU effectively at scale (arbitrary topologies vs bipartite graphs)

Is that true? These graphs can be transformed into a regular tensor shape with zero weights on unused connections. If you were worried about too much time/space used by these zero weights, you could introduce parsimony pressure related to the dimensions of transformed tensors rather than on the bipartite graph.