sirclueless

I don't think it's absurd at all. I think it is a practical principle that shows up all the time in collective action problems. For example, suppose hypothetically there were a bunch of business owners who operated under an authoritarian government which they believed was bad for business, but felt obliged to publicly support it anyways because opposing it could lead to retaliation, thus increasing its ability to stay in power.

Like every other decision SBF would prefer you not examine: It fits because the ends justify the means.

It's important for the business that the insurance fund is safe. If you look closely you will find that it is unsafe. But if people believe it is safe you won't need the insurance fund, so do whatever you need to to inspire confidence in the insurance fund.

I don't really understand the analogy. Mechanical watches have created an industry of skilled practitioners trained to fix them because they often need diagnosis and repair. NASA has a room full of oncall personnel available for many hours any time they launch anything, and they launch things much less frequently than your average tech company.

Oncall rotations are part of defense-in-depth against bugs and unforeseen circumstances: Most of the companies that survive without a formal one only do so by outsourcing this for the most common cases; to Cloudflare, to Amazon, etc. -- if there's an opportunity cost to being down someone needs to be able to pick up the phone when there's an outage or critical issue.

It's especially hard because the stdlib changes quite a lot still. Examples go out of date so adding documentation like this is not just one-time work. I am working my way through learning the language and it's not uncommon to find blog posts or news snippets from 4 months ago introducing features, and they already don't compile.

E.g. if A patents X and some large company B wants to use X and A refuses, then B cannot use X even if they offer millions.

How does this situation improve in any way if X is a trade secret? Under what circumstance would company A be willing to accept payment to make X open, but not willing to license X as a protected patent?

It sounds like you'd be in exactly the same situation except that there would be a massive collective action problem trying to figure out how much the world should pay A to make the invention open and who should pay it, and also A and B would have multi-million-dollar incentives to engage in corporate espionage and counter-espionage that achieves no progress.

That may be true but people here aren't talking about firing the bottom 10% of ICs, they're talking about firing "50% of Google".

While that's true, I'd be very surprised if git delta-compressed the commit objects themselves. Changing a commit to point at a different tree wouldn't impact the delta-compressed packings of any file blobs, it would just change the actual file the commit points to.

For example, suppose you started with a commit graph that looked like this:

    C1 --- C2 --- C3
     \      \      \
      T1     T2     T3
       \      \      \
        F1 - - F2 - - F3

    C1 --- C2'--- C3
     \      \      \
      T1     T2'    T3
       \      \      \
        F1 - - \  - - F3
                \
                 F2'

I just follow a couple YouTubers who make videos about it. For example:

William Lin - https://www.youtube.com/channel/UCKuDLsO0Wwef53qdHPjbU2Q

Errichto - https://www.youtube.com/channel/UCBr_Fu6q9iHYQCh13jmpbrg

These things really aren't so far apart.

                    --> solve the problem
                  /
    see a problem
                  \
                    --> exploit the problem

As someone who occasionally watches competitive programming for fun (and competitive programming is basically competitive whiteboard interviewing) it gives me quite a bit of perverse pleasure that even in languages with great first-class class and object support the norm is to write functions that operate on global variables.

Granted, the file that the commit touches would need to be not touched in other commits.

That's not how git works. The commit contains the entire tree. You could prepare two separate repositories such that `git checkout deadbeef0001deadbeef` in one checks out the linux kernel and in the other checks out ILOVEYOU.exe.

Every commit references every file. If you change the content of an old commit you would only affect people who check out the old commit. So this is utterly pointless and not what someone would do.

Instead what you would do is attempt to make a file-object that has a certain SHA1 hash identifying it, and a colliding file-object that has the same SHA1 hash. Then you are free to give people who clone the repository different file contents depending on when/who/how someone requests it (if the file content is hosted on github, how to change the file object identified by a given SHA1 hash is an additional hurdle since it's assumed to be immutable and indefinitely cacheable; if you control the host yourself you can just change it whenever you like).

Commits aren't patches. They contain the whole tree. Retroactively changing a commit can't possibly introduce conflicts with other commits on top of it, the worst it can do is introduce big funny-looking diffs.

The point isn't to authenticate control of an account, it's to tie the account to some kind of expensive-to-replicate real-world cost, ideally one that most potential customers are already paying for.

Phone numbers are nice because the marginal cost to a customer is low (they probably already have one) while the marginal cost to a bad actor is high (it's expensive to acquire many of them or to change one once it's been identified as malicious).

The DMCA has a couple major parts. The part most people are familiar with deals with safe harbor provisions and "DMCA takedowns". The relevant part for this discussion makes it illegal to circumvent digital access-control technology. So you could argue that if you have reasonable measures in place to stop automated access of your content such as robots.txt then Facebook continuing to send automated requests would be a circumvention of your access controls.

Usually complaints like this have more to do with the social processes around coding than the actual task of storing and versioning source code (which as you say is portable and standard).

"I want to make a change to a shared library. Why can't I make a pull request?" "Wait, I have to use this unfamiliar interface to make comments on other people's changes and I can't leave comments on specific lines?" "You know, if you used Jenkins and Github then you could show the status of passing or failing tests right here on the code review screen..."

These social pressures are really quite strong. They affect a bunch of open source projects especially: people who want to make changes expect code to be on Github and might even mirror it there themselves (creating confusing situations for anyone trying to contribute). Even if the project does host its code on Github to allow for contributions from Github users, Github is (naturally) not very good about directing its users off of its platform to where the existing discussion and development is going on. "It's easier if you just do everything on Github" says Github, and their users by and large agree, and slowly more and more process (code review, merging patches, CI, documentation) gets sucked onto Github by the platform effect.

I haven't figured out whether the C I learned was poison. I often wish I could intuit Haskell without translating everything to imperative in my head, because of how cleanly many complex things can be expressed. On the other hand, pretty much everything I program has some rough kind of performance constraint in practice and I appreciate how directly I can read the performance characteristics of an imperative program from its control flow.

Authorization has a common English definition too. If, for example, an employee's credentials were compromised, anyone who wasn't that employee who accessed the database would be considered "without authorization". And checking the access logs for any use of that employee's credentials would give you some idea of what data was accessed. Enabling authorization on your mongodb is good, but it absolutely won't stop all forms of unauthorized access. They may gain access to your server itself, or gain some credentials to your MongoDB database some other way (for example, if someone carelessly ships them as part of your software, or includes them in a github commit, or something like that).

In the worst case, if someone notifies you of a configuration problem or some software bug that allows anonymous access to your database or the ability to remove logs, you may have to assume the entire database was compromised since the existence of that configuration issue or software bug.

Pretty incredible that it's survived decades and multiple iterations of the game, and you can still pick it up and buy your trusty AK or M4 and play essentially the same game from decades ago.

Yeah, for sure. The flood is one of my most vivid memories in gaming (and I didn't even play the game until years after it had come out, around Halo 3 days I think).

Many games since (including Destiny) have tried to recreate that feeling of an oppressive enemy that you can't defeat, only push back or cut a temporary swathe through. But no one comes close to Halo.

There's a related corollary to this question though, which is whether systems that require less human memory enable you to remember other things better.

For example, your phone can dial dozens or hundreds of your friend's phones without you remembering their numbers. This means you never need to use their phone numbers and hence don't remember them. A reasonable question you might ask is whether you are now free to spend that brainpower memorizing other, more useful things? Or are you actually less capable of memorizing other things because you are exercising your memory less?

There are other similar examples, for example password managers and even just general Google-able trivia. Is it a good thing or a bad thing for general intelligence that humans need spend less time memorizing these things?

I think people who say other languages "just don't get it right" are living in a fantasy world. At the end of the day, Smalltalk is a pretty extreme language. The insistence that, e.g., every integer value is an object that can be sent messages, or that every code block is an object, or that every code block can introspect its caller, all lead to a pretty extreme amount of flexibility but an inability to write efficient code or do much optimization.

At the end of the day, languages that were less extreme won the popularity contest. Ruby and Python, for example, are just more accessible and full-featured.

The basics are easy. A rudimentary normal mode with HJKL for movement is not hard. Block-select, sensible paragraph hops, copy/paste registers, repeatable macros, etc. is much harder to get right, and rough corners there can be a deal-breaker. Vim is a lot more than moving a cursor with your right hand.

Inadequate clothing is not a protected class under the Civil Rights Act. Hence there are major legal differences between refusing to serve a person because they are black, and refusing to serve a person because they are shirtless.

The reporter doesn't make any claims like that. The word "prove" or "proof" don't appear at all. Instead they say, "The findings do not support the learning styles concept," and "Student grade performance was not correlated in any meaningful way with their dominant learning style or with any learning style(s) they scored highly on."

If there's a complaint to be had here, it's that the HN poster changed the word "did" to "do" in the headline while posting here.

This is why your choice of threshold matters. Your strategy should be to choose a threshold randomly from any distribution that is non-zero everywhere (such as a normal distribution), then choose a hand uniformly at random.

Choosing zero as a threshold deterministically does not work for all choices that Alice can make because, as you say, for some choices such as (10,20) it gives you exactly 50% chance to win. But as long as there is always a non-zero chance that you chose a threshold between Alice's numbers, then there is a > 50% chance that you win the game.

You can do better than that. You can guarantee there is > 50% chance you win on the first guess.

You're exclusively borrowing res_a, res_b and res_c for the lifetime of the scheduler. Which works fine since res_a, res_b and res_c are hard-coded variables with separate lifetimes. What rust doesn't know how to do is borrow mutable references to elements of a container without borrowing the entire container.

https://play.rust-lang.org/?gist=1324a919ca5d0e2f16e445364a7...

The problem is that schedule() needs to mutate result asynchronously at some point in the future. It can't do this if result is a mutable reference, since it needs to return immediately so borrowing a reference doesn't work. It also can't take ownership of result, since it has no way to give it back (short of changing the API, for example by making wait() return a collection of results).

The right way to implement the API above is for schedule() to take Arc<Mutex<Result>>, and explicitly share mutable ownership over each individual result between some unspecified asynchronous execution mechanism and the caller of schedule(). This makes the calling code significantly more complicated as it needs to incur the overhead of atomic reference counting and a mutex per result, and must try to lock each result before using it, even if it knows there are no other owners of the result due to wait() returning.

I don't think this is just about being more or less verbose. It's about the awkward ways it contorts the ways you write programs. For example, in C++ you might write an asynchronous job scheduler with an API like the following:

void Scheduler::schedule(const Job& job, Result* result);

void Scheduler::wait();

The consumer of this API in C++ has an easy job. They can create an array of results and iteratively call schedule(jobs[i], &results[i]) for each job, and then call wait(). A similar API in Rust would be a giant pain in the neck to use, because there's no simple way to collect the results. You'd likely want to scrap this API entirely and have Scheduler expose some kind of queue or something.

My point is that these extra constraints are not just extra typing locally to specify how you're using lifetimes. You'll likely have to rethink the way you write APIs and whole programs in Rust because of the ways it restricts mutability. Which is OK, it's a trade-off, all I'm saying is the safety doesn't come for free.