interesting, I've had a much easier time pairing (and felt benefits like you describe) over Zoom. Pairing by actually having 2 people at a desk never felt very comfortable, but screen-sharing with each person on their own monitor etc. works great, IME. I'm curious what you've tried / why it hasn't worked...
> This is a pure panic run on the bank though, irrational and counter-productive. The bank was not insolvent and could have been fine if everyone didn't withdraw all at once.
This is incorrect. SVB converted deposits to risky paper that lost value. They were insolvent.
The fact that the risky paper would return its promised 1%/yr, if everyone just waited 10 years, is a canard. SVB's depositors could get 4% elsewhere, today. Asking them to sit tight at 1% is the same haircut as liquidating that paper at a loss today (which is what happened).
4% inflation per year (the most common estimate I see in the US) means 3x over 30 years doesn't even break even (1.04**30 ≈ 3.24).
I often wonder how much people obsessed with home prices rising (in the US at least) take this into account. How much housing mania is fueled by people getting excited about gains that aren't as real as they think?
The 10MB estimated size came from [100 bytes per row] * [100k rows].
50 of the bytes per row were "description", which should compress well (2-3x, I'd guess).
40 bytes per row were the IPFS ID/hash, IIUC. I assumed this is like a Git hash, 40 hex chars, which is really just 20 bytes of entropy.
He also estimated 14 bytes for the size (stored as a string representation of a decimal integer, up to 1e15 - 1, or 1PB?). That's about 50 bits or 6-7 bytes, as a binary integer. Sizes wouldn't be uniformly distributed though so it would compress to even fewer bytes.
So if SQLite was smart (or one gzips the whole db file, like you did), it makes sense that a factor of 2 or so is reclaimable.
if you are "cutting and pasting from the notebook into a .py file" you should look at `jupyter nbconvert` on the CLI.
I think there's ways to feed it a template that basically metaprograms what you want the output .py file to look like (e.g. render markdown cells as comments, vs. just removing them), but I've never quite figured that out.
1. healthy decentralized services often have <1% of users who do "want to run a server," and the whole thing works as a result
2. immutability / inability to change quickly is good for protocols
3. crypto community does need to decide whether it cares about money or decentralization
Took a while getting to the good part of 1. Should have skipped "'no one wants to run a server' is factually incorrect!"
I loved the Moxie piece but it was strange bc Moxie is a legendary cryptopunk who presumably believes decentralization is good (though hard to attain/maintain)... right? Moxie made excellent points but left me wondering what he actually thinks, or thinks should happen.
I also liked the pushback here about email being an example of failed decentralization, because Gmail is big or something? Email seems like the last major decentralized communication protocol still standing, despite incredible centralization/"balkanization" of the messaging space.
semi-OT but Twitter seems to have recently started putting "mobile.twitter.com" in my URL bar (on mobile), as well as adding a UUID in a "t" query param when you use their "copy link" flow, which is all annoying cruft to have to delete when sharing links.
They used to just put "?s=19" through "?s=22" or so, which enumerated clients (desktop, mobile, Android, etc), which was better than the junk most other services stuff in (like utm_source and friends...)
"Better bike infrastructure" and "a bit of pedal assist" are both good things that we need more of.
Even in the best possible future, I believe cycling in US cities will involve some amount of mixing with cars for the rest of my natural life (unfortunately!), so I'm not sure "completely bogus if…" is fair.
And anyway, a little extra speed is still useful because it's transportation.
Here's a fun thought experiment: define "places I can go" as "the locus of points within 1hr bike ride of a train station." If e-bikes let me go 50% faster (say, avg 15mph instead of 10mph), that multiplies the accessible area around each train station by 2.25x! I can go more than twice as many places now!
Maybe I need to caveat it more, but I'm really focused on the range from, say, ≈5mph (uphill on a "leg-bike", or starting from a stop at a light or stop sign) to ≈25mph (roughly my top speed on a leg-bike or e-bike).
In that range, and in mixed traffic (which is unfortunately most urban riding in the US), a 5mph difference can be a step change in terms of whether drivers even feel the need to pass me at all. 15mph is only 50% faster than 10mph, but can totally flip the "who's passing who" dynamic from "cars passing me frequently+aggressively" to "cars hesitate, back off, and then I get ahead / pass the next cars in line at the next light."
I'm comparing new cars to new e-bikes and, sure, in both cases you can get something "pretty good" for ≈half the average new {e-bike,car} price. Some people will get something "very good" for 2x the average!
From what I can tell the research supporting the $40k average (or, alternatively, $800/mo) seems reasonable:
Hi, I'm the site creator, just saw this posted! Happy to field questions.
The site is due for an update, I've been compiling a lot more resources and bolstering some of the arguments with more data, but lately I've been spending a lot of time on these cyclist PoV videos https://twitter.com/CarsDontFitJC
To briefly touch on a few common q's I see cropping up here:
- Yes, cycling infrastructure is really bad everywhere in the US (some places worse than others). That's orthogonal to most of the things that are great about e-bikes though. Better infra, and more e-bikes, are both part of fixing the US's horribly broken urban transportation landscapes.
- "Rain and snow": it's just not that hard to make biking reasonable in all but the most inclement weather, and anyway, solving {traffic, parking, traffic violence, air pollution, noise pollution, emissions} on the other ≈95% of the days would be extremely good for everyone (including drivers). Making everyone wear a "$40k internal combustion parka" everywhere is not a good solution either!
I really appreciate the thoughtful feedback and discussion I have some related projects with cool software angles I am hoping to post here as well, soon™
rebase : centralized repo :: merge : decentralized repo
rebase : linked-list :: merge : DAG
If the work/repo is truly distributed and there isn't a single permanently-authoritative repo,
a "clean, linear" history is nonsensical to even try to reason about.
In all cases it is a crutch: useful (and nice, and sufficient!) in simple settings, but restricting/misleading in more complex ones (to the point of causing many developers to not see the negative space).
You can get very far thinking of a project as a linked list, but there is a lot to be gained from being able to work effectively with DAGs when a more complex model would better fit the reality being modeled.
It's harder to grok the DAG world because the tooling is less mature, the abstractions are more complex (and powerful!), and almost all the time and money up to now has explored the hub-and-spoke model.
In many areas of technology, however, better tooling and socialization around moving from linked-lists (and even trees) to DAGs is going to unlock more advanced capabilities.
Final point: rebasing is just glorified cherry-picking. Cherry-picking definitely also has a role in a merge-focused/less-centralized world, but merges add something totally new on top of cherry-picking, which rebase does not.
A problem with rebase workflows that I don't see addressed (here or in the replies) is: if I have, say, 20 local commits and am rebasing them on top of some upstream, I have to fix conflicts up to 20 times; in general I will have to stop to fix conflicts at least as many times as I would have to while merging (namely 0 or 1 times).
Moreover, resolution work during a rebase creates a fake history that does not reflect how the work was actually done, which is antithetical to the spirit of version control, in a sense.
A result of this is the loss of any ability to distinguish between bugs introduced in the original code (pre-rebase) vs. bugs introduced while resolving conflicts (which are arguably more likely in the rebase case since the total amount of conflict-resolving can be greater).
It comes down to Resolution Work is Real Work: your code is different before and after
resolution (possibly in ways you didn't intend!), and rebasing to keep the illusion of a total ordering of commits is a bit of an outdated/misuse of abstractions we now have available that can understand projects' evolution in a more sophisticated way.
I was a dedicated rebaser for many years but have since decided that merging is superior, though we're still at the early stages of having sufficient tooling and awareness to properly leverage the more powerful "merge" abstraction, imho.
afaict they just released 78.0.2 with a revert of the offending bits