doorman2

I was recently working with a bunch of pseudo-terminal stuff, so I was curious about how unbuffer works. One thing that stuck out to me in the manpages is this:

    Caveats
    
    unbuffer -p may appear to work incorrectly if a process feeding input to unbuffer exits. Consider:
    
    process1 | unbuffer -p process2 | process3
    
    If process1 exits, process2 may not yet have finished. It is impossible for unbuffer to know long 
    to wait for process2 and process2 may not ever finish, for example, if it is a filter. For expediency, 
    unbuffer simply exits when it encounters an EOF from either its input or process2. 

Why does unbuffer care whether or not process2 exits? Can't it receive the EOF from process1, send it to process2, and then wait for process2 to exit? If process2 doesn't exit after receiving an EOF from stdin, then what's the issue about simply letting the pipeline hang? Isn't that what would happen without unbuffer?

It's not like they're giving the lithium away for free?

What was it about the 20th century that produced such heartless people? Lead exposure? I understand that the 20th century is far from an aberration in terms of human cruelty, but there is an element of sadism that feels different than other centuries.

For instance, read the first sentence from Harlow's Wikipedia page:

> Harry Frederick Harlow (October 31, 1905 – December 6, 1981) was an American psychologist best known for his maternal-separation, dependency needs, and social isolation experiments on rhesus monkeys, which manifested the importance of caregiving and companionship to social and cognitive development.

Did we really need to torture these creatures for decades to understand the importance of care giving? The experiments seem like a flimsy pretext for torture.

You’ve jumped to conclusions. “If you work out like Mike Tyson, then you’ll definitely get into shape.” Ok I agree.

“If you act like Jeff Bezos, you’ll definitely become a millionaire.” How?

You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility...

As you can see it's quite complicated. The contents of go.work is literally

    mod1/
    mod2/

Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.

FTX being corrupt doesn't automatically mean banks are not corrupt. Just 14 years ago, the actions of banks brought most of the world to the precipice of financial collapse. FTX and Alameda depositors will lose their money. During the GFC, almost everyone lost their money.

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies.

E.g. if your workspace looks like this:

    workspace/
        mod1/
        mod2/

Then both mod1 and mod2 will pull their dependencies remotely.

But if you add a file to workspace/go.work, then local versions of mod1 and mod2 can be used without changing either mod1 or mod2.

Go workspaces are amazing. You create a go.work file, add a line with each module you're working on, and then the Go language server handles the rest. Solutions and projects seem way more complicated, but also not entirely congruent. A Go workspace is used when you have two modules that depend on each other and you want to work on both concurrently. The two modules are still independent and could be worked on individually by pulling in the latest release of the other module.

The modules in a workspace may have entirely different ownership. For instance, let's say you're using a WebRTC library to run a selective forwarding unit as part of your video conferencing app. Maybe you notice a bug in the WebRTC library. You can check out the code for the WebRTC library and add it to your workspace so you can test your application against your local WebRTC library changes.

I guess that makes sense given that the CEX can simply update values in their own (non-blockchain) database. This highlights that blockchain tech isn't really ready for prime-time use, yet. If the cost / tx could be brought down significantly, then there would be no need for a CEX.

I think you're missing a step (4). You have to prove your series of steps covers the entire domain of the problem.

I'm not too involved with the crypto space, but why have a centralized exchange at all? Like why can't the exchange setup a transaction directly between me and the counterparty that we both sign?

Inductive here meaning going from specific to general. I've never played the game, but it seems like you start with a specific example of the rule and try to generalize its definition. So in that sense, it's a little like pattern matching. "Proof by induction" is a proof technique where you prove that if something holds for n, then it also holds for n+1. That doesn't seem related to this game, but the game might help with your pattern matching abilities.

The Rx model works nicely. Rather than trying to model state transitions, you model "scopes of work." So if you have something like an event listener, you would tie it to the active unlock session. When that session ends, you dispose of that "scope of work" and all work associated with it would immediately stop.

The same thing could happen with crypto. A smart contract developer sells crypto to fund development of a smart contract. That smart contract can provide new utility and drive demand for the currency.

It has depegged before, like when LUNA crashed. During times of high uncertainty, it’s definitely worth 1-2% to get your money out. It remains to be seen if this current run will significantly impact Tether.

By that definition, which financial instruments aren't negative sum? E.g. stocks trade hands in a very similar way, and companies can always issue new shares.

Agreed. When you mock, you're essentially writing your implementation twice. Once for the real implementation, and again via the mock interactions. Sometimes, this type of test is helpful in the way that you can catch typos by writing the same piece of prose twice. However, these tests quickly become burdensome to maintain, e.g. changing an implementation in a way that produces identical results requires updating tests even though the behavior is unchanged.

While true in many places, bronze specifically corrodes over time when exposed to air.

Too bad FTX is crashing. I don't know where else I can buy (put) options on crypto.