I wonder how "permissive seeders" would be protected from folks pushing large binary files.
Also, wouldn't storing everything about the repo make it very large? Even when cloning large git projects, it is from time to time necessary to make a "shallow clone" to avoid downloading hundreds of megabytes per repo. I imagine with all discussions it would be worse.
I rerun vimtutor from time to time, because I still don't remember every trick from it. I've recently tried to read the whole embedded "introductory documentation" on a train, learned a lot, but probably need to do it again. Setting every option in the .vimrc seems a nice exercise, will need to do it some time! I like to nuke my config from time to time anyway. (My experience with Vim is about 14 years I think.)
This nerd-sniped me. I think we should separate "chess board" and "chess game state" as two different problems. For "chess board", we don't consider any castling, en-passant or similar. We might store a bit for "who goes next". This is useful for chess puzzles where state shenanigans are rare (I think).
But if we store castling state, I think we are already trying to store the whole game state, and this is representable only by full history because of move repeating rules.
So, I think storing board state as a sequence of moves is more interesting. I would estimate that a number of possible actions on average is closer to 8 than to 16, so it would give as 3 bits for half-move and 6 bits for full move. 24-move game could be represented with 18 bytes, which is considerably lower than 26 bytes!
You can get close to average bit per move, if you reuse "spare" places for the next move. So, for instance, first move have 20 possibilities, which is representable by 5 bits, but you can reuse "spare" 32-20=12 possibilities as a bit for the next move.
This is a representation assuming you use only "move validator" thing that returns a list of possible moves. I think that if you use a chess engine that would output you a probability distribution of possible moves, you can compress noticeably better on average, but decoding would be slow.
Huh, and that works? Sounds a bit… old-fashioned? I’d think people are looking for these services online or in some gig work app. Interesting. Sounds unpleasant both for workers that have to hang around on the street, and customers that are approached (at least that’s how I imagine it) by people offering services even when they don’t need it. (Or do customers approach workers themselves?) From the outside, sounds weird. I wonder what in the US caused it.
I am confused about the situation. Can someone with more context please explain? Is HomeDepot forcing their own workers off the parking lot? Or are there some other workers there? What do they do on a parking lot? Are they in cars or on foot? Why do they stay on the parking lot the whole day, if they are not HomeDepot employees?
I worked at largest European tech companies and YC startups. I have ML education from a top uni. I have 8+ years of ML experience.
Working in large companies, I've trained large language models myself, which helps me to understand what makes an LLM tick. I worked on a web-scale RAG system at a major search engine company before this term was popular.
I am a generalist, proficient with Python, but also capable with Rust, C++, Javascript. I can serve as a fractional CTO, capable both as a leader and as a highly efficient individual contributor.
But you see, intuitively we think that the number of upvotes in that model is a “dollar payout” for this post. But actually it isn’t! In a meme community, a post with 1000 upvotes would bring its author 1000 * (1/1000) = 1 dollar, but in a hardcore geek community it would be something like 1000 * 1 = 1000 dollars.
It makes me think, what if the upvote counter was the same, i.e. you have only one upvote per month, and it gets split between all upvoted posts. And maybe it would be nice if you could accumulate your upvotes over several months...