I didn't see the con explicitly in the comments. When someone adds a file, they'll have trouble figuring it out why it's not visible in git, or they may not realize an important file is missing if they are adding multiple.
Platonism - not even once. Green is the smell of my grandmother's lawn on a hot summer day. Just because things are similar to a lot of people doesn't mean their fundamentally the same.
Occasionally I put on multiple programs. Movies in one room, an audio book in another, music in another, etc. Your mind drifts to what is interesting. Lights strobing. Working on 5 different home projects in parallel. It's a vibe.
> So I said, imagine you had 10,000,000sub10 grains of sand. Then you could … well, uh … you could fill about 10,000,000sub10 copies of the observable universe with that sand.
I don't get this part. Is it really rounding away the volume of the observable universe divided by the average volume of a grain of sand? That is many more orders of magnitude than the amount of mass in the universe, which is a more usual comparison.
> The True Believers hypothesis rings false because that would be a frankly ridiculous belief to hold. Sometimes people profess ridiculous things, but very few of them put their money where their mouth is on prediction markets.
It sounds like the author is saying the belief is ridiculous in general. However, if Jesus returns, then the believers would ascend to heaven. So, they would not be able to cash out.
What if polymarket put in the money to drive people to vote on the no side? It could be quite a marketing stunt.
As someone who has never studied distributed computing seriously, yet a systems guy, three or four articles deep here: I feel like I've had my eyes open to a new corner of computing and therein the answers to my problems.
This is anticipated from work on constrained output from LLMs, and it's good to see it being developed. One nitpick though, this paper mentions the complexities of implementing type checking for program prefixes in languages that are not context free. It's true this is extremely difficult for languages which are context sensitive, especially because types may be defined after they are used. However, it does not mention that it is impossible to implement such a program for Turing complete languages such as C++. I would never miss such an opportunity to criticize C++ and highlight the need for better language design. I love you C++.
Nothing is demonstrably secure, only not demonstrably insecure. This is - hey our builds come with a bunch of resources you can use to try to prove they're insecure, but you probably can't - but it's an advertisement.
Oh man, my guys may be able to be replaced if you have enough time, but I'm fucking terrified they would leave. It would set us back 6mo or a year at least. The stack is too complicated, and yes, there is a lot of pressure to pick the right projects, not waste time.
Mugshots are pretty locked down now, but when I was younger, you could just scroll and scroll. Used to go through, check to see if I knew anybody. Got lucky a few times. Well, if you think you're safe, you're not, and if you think it's deleted, it knows everything about you. The difference between the marginal mugshot and the whole database is how prepared you are. Scrape that data every day, baby.
I tried to come up with an optimistic response, but when you consider all the ways data can be exfiltrated: if you can send a bit, you can send a file.
Here's the dangerous way I put it that I only tell senior people: understand why rules were made and make sure the people who made them would be happy.
I never went to class myself unless I was required, had an exam, or loved it. Sometimes I would skip my research advisor's class to do research in his lab. Even if I wasn't in class, I was there though. I'd get notes from someone.
This implies an API where the server has a single shared implementation. Imagine for instance that the server implements a shim for each version of the interface, then there isn't a need for the null in the API. Imagine another alternative, that the same API never adds a field, but you add a new method which takes the new type. Imagine yet again an API where you are able to version the clients in lockstep. So, it's a decision about how the API is used and evolves that recommends the API encoding or having a null default. However in a different environment or with different practices, you can avoid the null. Of course the reason to avoid the null is so that you can statically enforce this value is provided in new clients, though this also assumes your client language is typed. So in the end, protobuf teaches us, but it's not always the best in every situation.
This is the same as a null pointer, and the requirement is very deeply tied to protobuf as it is used on large distributed systems that always need to handle version mismatch, and this advice doesn't necessarily apply to API design in general.