Anyone know if it fairs better on Android TV these days?

https://www.youtube.com/watch?v=6n3pFFPSlW4

Non-engineering positions

Big tech pays large amounts of money. This is why people choose to work there.

Indeed, wild statement if I ever heard one

Ed is the standard text editor

It’s mostly a skill issue for services that go down when USE-1 has issues in AWS - if you actually know your shit, then you don’t get these kinds of issues.

Case in point: Netflix runs on AWS and experienced no issues during this thing.

And yes, it’s scary that so many high-profile companies are this bad at the thing they spend all day doing

You enable it using git config, after that it will apply to whatever frontend you’re using.

Depending on how structured your commits have been, it can either be very difficult to get a rebase through or a complete breeze. There are some features to make it easier - rerere being the main one I’m thinking about.

What’s your mental model for a Git commit, and a Git branch?

Once I properly learned those two concepts, understanding rebases became a lot easier.

I’ll try to explain it to the best of my abilities.

• Think of a commit being a patch - a description of how to take a particular file from one state to another
• A branch is a list of patches to be applied in order, from the point where the branch was created until the last commit on the branch

When you rebase a particular branch, what you’re essentially doing is taking all of the commits that are currently on your branch, checking out the other branch, and then applying each of the patches in order on that new branch.

A rebase can be cleanly applied if the premise for each commit has not changed when applied, but if the premise has changed, you get a conflict to be resolved before being able to continue the rebase.

I mentally model a rebase a bit as a fast version of how it would look like to build the branch I was on, but on top of the branch I’m rebasing on.

ps aux | xargs kill -9

I’m guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.

I agree that these changes should be made in separate commits, for the benefit of the reviewer.

There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.

Force pushing is necessary when using rebases, and rebases are an essential tool, so you should not be afraid to force push under normal circumstances.

Don’t be afraid of rebases, they are an essential tool in Git.

This particular fear can only be addressed by understanding.

It’s mostly for undoing a rebase or merge you’re not happy with.

You’re missing some of the code in that snippet, because the author’s markdown rendering isn’t working properly.

Specifically, it’s missing #incluir <iostream>, where the <iostream>-part got treated as an HTML-tag.

Everyone who plays the lottery might be a millionaire too

Yeah, you can use the Epsilon garbage collector in Java for a no-op garbage collection strategy.

For short-lived programs that do not risk hitting any memory constraints, it makes a lot of sense - zero time wasted on cleanup during execution, then you just do it all at the end when killing the program, which you can do in constant time since you don’t need to reason about what should remain or not.

Largely accurate apart from special-purpose tools usually being employed instead of ChatGPT

Unironically true actually, ffmpeg is everywhere in the video space