831 karma · joined April 9, 2018
> 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.
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
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.
I used it in a previous job to automate configuring thousands of network devices
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.
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
#!/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 secondSo, 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.
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.
Once you recursively expand all the concepts, you will have multiple dense paragraphs, which don't "summarize" anything, but instead provide full explanations.
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.
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.
1. Smart person makes lots of money
2. Smart person has children
3. Smart person's children are likely to be smarter, and guaranteed to have more money
Sounds about right to me
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.