skysight-inc/HackerNews huggingface dataset:
That's just if you want to match the actual leg style. A round stick of wood with a hole in the right spot would technically work :-)

I don't have a lathe, but when I run across one, I'll give it a go, or ask a friend.
What providers offer 10 years of email (guessing many GB in size), plus allow using your own domain name for free?

All the one's I'm seeing are paid options, some of which get very expensive if you have more than just one or two users.
Seurat Technologies Raises $21M
I feel like you did most of the work :)
The Central Order
I should also say my explanation assumes we're in last betting position here. If we're first to act, the logic is somewhat more complicated than I can successfully conjure up here without going back into the books - it's been many years since I played seriously.
Hyperbolic Tree Browser – CHI 1995 – Ramana Rao and John Lamping
While you're technically correct, that's the worst kind. Surely you aren't arguing against their real point that the USPS is the most equipped federal agency for getting items to people, and for having the physical real estate proximity to people to be convenient?
Huh? Are you expecting others to take care of your needs while you do nothing?

At what time in history has this ever been an option. You would be dead in a ditch with this attitude for most of our history. Maybe you need to go out into the woods and survive without help to force an attitude change.

You have a skewed since of reality egged on by a society that's let you survive off of doing basically nothing and yet you still complain. The problem here is that you believe all of the stuff to keep you alive just magically appears without anyone doing any work.
I agree but the trend still seems to prefer one or the other and that's why it's so important to talk about the potential downsides instead of closing our eyes and saying everything is gonna be better if we do microservices.
Amazing, thanks! I did try looking up in my local city library (it didn’t have it) but using your link I found there’s a Uni library nearby that does have it!
If you doing a lot of small screws I would suggest getting a Wiha precision screwdriver set. The iFixit set has great cost/value ratio, but there are much better tools on the market.
That is contradicted by how this phenomenon isn't happening to any other mediums- books, movies, shows. Why should music be any different?
I think the 70s and 80s pop hits have had staying power because those songs were the pop music of the people with the power to choose the content of mass media as media became more massive in the 90s and 2000s (further television/radio station standardization and the internet).
I appreciate your clarifications.

And in eschewing brain teasers and leetcode, you're definitely on the right track.
Article is dated July 30, 2020.

I don't know how much things have changed since then, but...
The article starts by stating a rather obvious problem: if you revert a commit, you might break something because any commit following the reverted one could build on what was added in the reverted commit.

Then the article describes a very elaborate way of… not addressing the problem?

Reset-Cleanup is a decent idea and helps keep a tidy repo which is a good goal. But the revert reason seems contrived.

The problem is going to be later code (from other pull requests) being dependent on the code in my pull request.

If my pull request is reverted then any later change can break. If my PR consists of 5 well separated commits or 3 messsy ones doesn’t matter in that scenario.

If someone against all odds wants to revert one individual commit from a merged branch but not revert the whole PR by reverting the merge commit then not only can the feature in the PR stop working (if the feature/bug fix in the PR didn’t need that commit to work then why was it there in the first place!?), any later code can break just as it can when PR is reverted as a whole.

This is why I recommend squashing for almost all cases. For really complex features with dozens of commits you can always do a rebase + FF (but in that case all commits should build + pass tests, which is an unrealistic goal in all code bases where a build + test takes hours).
The reasons are complex—more than just the appeal of old tunes

Does the author explore the reasons at all? Should we just guess? One jumping out at me is the share, population and disposable income-wise of boomers, who might just be buying music that was popular when they were growing up. Are people rebuying their current collection of old tracks in new formats? Does the current lack of a mono-culture around music mean that new music can't get the same traction old music had enjoyed? Do fans of new music spend less time/money enjoying music compared to other things that fans of older music don't like, like twitch subs, games, whatever?
Just didn't find the time to do it :-) But you are right - I should do it!
Culture has already fractured, and it's mostly due to YouTube/Twitch/TikTok, and not so much about the siloing.

I'm not sure I agree that it's not a competitive marketplace though, just look at all the players! What I would agree with is that it's not consumer friendly, and I agree no one will pay $500/mo, but a lot of people have been paying $100-$150 for cable for decades, and for that budget you can still get a lot of good stuff without needing to get everything.

All that said though, the vertical integration is pretty interesting because this is how the movies studios were set up in the first half of the twentieth century. They owned the production (including actors as highly paid indentured servants) and the theaters. It was only in 1948 that anti-trust action was taken to force them to divest theaters. That's super interesting because it's hard to imagine that type of anti-trust action today.
Oh yeah occupancy is not great, but a rollback to plan A will make little difference. Most firms are still operating an optional return to office policy and very few changed that as a result of the switch to plan B.
I can’t be too mad because I’ve had 15 or 16 years of free service, but I’m now annoyed I have to investigate where I want to migrate, since I literally don’t use any of the other Google services.

And now I get to figure out what happens when a Google account is no longer tied to a paid Google account for stuff like calendar and document access.
It adds a salt. Otherwise entropy shouldn't really be a factor - your input password could be more entropic than your output hash, in terms of shannon entropy/ number of bits needed to represent the values.
>The number of hours played by working bands has never been lower in history.

Are you referring to a decline as a result of the pandemic, or a larger trend that was occurring even before ~spring 2020? If the latter, I would be curious to see any data you have to support that.
Not much trouble if you're used to it.

git rebase --interactive master
In Vim: ciw e ESC :x
git reset HEAD~
// Make your commits
git rebase --continue
Trying to understand where the danger is with git reset. To avoid a very harmless and easily reversible command, you complicated the process with another branch. The fact you feel it is dangerous tells me that you don't have a strong understanding of how git works. It's always kind of funny to me to see how strong of an opinion devs get over how to use git when it's clear they don't really understand the toolset. It took a while to get all the devs at my last company to understand how simple it is to rebase/reset, and write some publish worthy commits, but once they all understood the value it adds, they all became converts and did the evangelism job for me the next time we hired a dev. I recommend reading Pro Git by Scott Chacon. Git is pretty dang amazing.
Step 1: Defund and castrate the government. To hell with administrative state!

Step 2: Observe disaster.

Step 3: Bitch and moan about how the ineffectual government was not able to prevent this. Offer the solution of ... small government.

GOTO 1.
> E.g. if you merge two branches with the same patches but in different order, but the file contents are the same at the end, git will need to you to manually address the merges for each patch.

That's not really true - only in the case where the changes are ambiguous.

I've worked on very hairy Git repos and haven't really felt blocked, even when some crazy merge conflicts happened.