For anyone who is confused: This is exploiting an old soundness bug in the Rust compiler that is still present. The GitHub issue page has this comment from maintainers:

we already had a crate published on crates.io before which used this bug to transmute in safe code, see #25860 (comment).

this issue is a priority to fix for the types team and has been so for years now. there is a reason for why it is not yet fixed. fixing it relies on where-bounds on binders which are blocked on the next-generation trait solver. we are actively working on this and cannot fix the unsoundness before it's done.

To be honest, you can say the same about any large cloud provider. What happens if AWS, or Azure, or Google Cloud go down, or become terrible?

You might look into displaying images in the terminal as well; many modern terminals support showing actual images natively

Yep; sometimes I will be able to do a search and then when I try to click on a result it has me restart.

For anyone who is still confused about what causes this: Firefox launches copies of itself when creating new website instances (usually when loading a website that has not already been loaded). Because of this, if it is updated in the background (through any means; I usually see this after a manual system update), Firefox has to restart when you try and load a new site because it cannot create any compatible copies of itself, since the old version is the one that is still running and the copies would use the new (updated) version.

The solution is to only update when Firefox is closed, or restart it when it asks.

I believe you are correct; if the unsafe code can cause undefined behavior if input data is not following a specific contract, then the entire function should be labeled unsafe so the caller knows that.

The other option is to check to make sure the contract is valid, and return an error or panic if it is not. That function would be sound, as no inputs cause undefined behavior.

Check out Ollama and its extensions for VSCode; might save you some money paying for other services if your computer can run models locally.

My computer was taking too long to start up, which I interpreted as failing to boot, but in hindsight was probably just my hard drive being slow. So, I booted into recovery mode, and ran an update. At one point, apt said "there are unnecessary packages" and would I like to remove them? I figured that apt knew better than I did (after all, maybe a package dropped a dependency), so I said yes.

It was after I noticed the very large number of packages that I suspected I messed up. Turns out, apt uninstalled the entire desktop environment, and network manager, so I had to boot into a USB drive with Network Manager installed, chroot into my main drive, and reinstall plasma. As a bonus, I think I missed the main group for the plasma desktop and only installed only most of it, so some of my extensions just didn't work anymore.

Not all ad blockers remove elements from web pages, and if they acted that predictably you could detect the ad blocker by detecting whether an expected element is hidden.

I have not looked through an ad blocker's code, but I don't believe it is that simple.

This already exists - @soatok@furry.engineer's blog already has a popup about not having an adblocker, although it is easy to dismiss. It's probably a bad idea to block content based on not having one, as detecting ad blockers is a losing battle (as YouTube is learning).

Definitely seems like an AI generated article. I can't imagine a human actually writing "the sound of legends being printed."

To be fair, I have seen many people confused by git (in fact, there is a relevant xkcd). So for you and anyone else that could use some help:

Git is just a version tracker. It is basically like naming a files "project_1", "project_2", "project_final", etc. It just does the hard work of remembering history for you, and only shows you the current version.

The commands are somewhat oddly named, but are fairly intuitive:

git add - adds some of the current changes to the tracker ("stages" them).

git commit - commits (i.e. saves) the currently staged changes to a new point in your history (a 'commit')

git checkout - check out, as in take a look at, another branch

And you shouldn't think about pushing and pulling as a tree; think about it as an action you take. You either pull changes in from the server or you push them up to the server.

For more complex situations, you will need to use more complex functionality. Git is built to help manage changes when working on a team, so it has the concept of creating new branches of history - like an alternate timeline - so that each individual can work on their code as if they were working alone. When they are ready to send their changes to the main (or master) version, they can merge the changes in. In the event that you want to change history, there is git amend and git rebase.

The normal work flow goes like this:

• git checkout -b new-feature: check out a new brach, based on the one you are on now
• make some changes
• git add file.txt (or -A for all): add your changes to tracking
• git commit: save the changes to a new commit (a new point in history). This will try to open an editor so you can write a short message explaining the changes; you can use -m "message" to specify a message from the command line if you prefer.
• repeat until you are done working
• git push: send your changes to the remote server (add --set-upstream origin new-feature if this is the first time for this branch)
• open a pull request or something similar so someone else on the team can review and approve your code
• merge the pull request in

If your changes fall behind the main branch, you will need to update your branch before merging it in. First, checkout the main branch and pull the new changes. Then, checkout your branch and add the changes from main. There are two ways of doing this:

git merge main - merge the changes you are missing from main, creating a new point in history for the combined changes

git rebase main - change history so that it is as if your changes started from where main is now - change the base of your branch to be the current state of main.

If there are conflicts, stay calm and take a look at your files. You should see something like this (from here:

here is some content not affected by the conflict
<<<<<<< main
this is conflicted text from main
=======
this is conflicted text from feature branch
>>>>>>> feature branch

You need to edit the file to decide which of main's code and which of your branch's code to use. Once you are done, run:

git commit: if you are doing the merge method

git rebase --continue: if you are rebasing. A rebase resolves conflicts one commit at a time, so you might be editing code from previous commits, and you might need to repeat this process for the rest of your commits until you get back up to now.

Another tip: if git complains about uncommited changes, or if you just want to save all of your changes somewhere and go back to a clean slate, you can use git stash. This will create a local stash of your current changes, and allow you to get them back later with git stash apply or git stash pop.

And you aren't expected to remember it all. That's what man git, Google, and websites like git.wtf are for. Or, you can call that one friend who understands it, and ask them for help ;)