𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 @ sxan @midwest.social

🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆.

---

Read more

Posts

26

Comments

3,682

Joined

3 yr. ago

Yeah. And literally "leftover". You share your bandwidth with everyone in your neighborhood. When you everything gets slow in the evenings and weekend, it's because everyone else is online, too.

Always pick fiber if it's available. Xfinity is shit. We've been stuck on them for the past 6 years because it was them or DSL, and DSL is only slightly worse.

The girl in the red dress was a Jew, right?

Or, did you mean the children actors, in general? I may have misunderstood.

What client are you using? I don't see that in Voyager, or on the Lemmy web interface

Edit: Oh. You're saying you can put emojis in replies? That's not the same thing. Think github reactions: they don't pollute the comment thread with noise; they just annotate a given comment with emoji reactions and counts.

I want to be able to give a comment a thumbs up, not reply to a comment and type a single-glyph response.

Safely changing history

How exactly does Mercurial manage to keep you from getting in trouble while changing history?

Mercurial actually keeps track of something called phases. Every time you push changesets to another repository, Mercurial analyses the phases for those changesets and adapts them if necessary.

There are three phases, each resulting in different behaviour:

• secret: This phase indicates that a changeset should not be shared with others. If someone else pulls from your repository, or you push to another repository, these changesets will not be pushed along.
• draft: This is the default phase for any new changeset you create. It indicates that the changeset has not yet been pushed to another repository. Pushing this changeset to another repository will change its phase to public.
• public: This phase indicates that a changeset was already shared with others. This means changing history should not be allowed if it includes this changeset.
• Mercurial uses this information to determine which changesets are allowed to be changed. It also determines how to select changes to rebase or histedit automatically. For example: using histedit without any arguments will only show draft and secret changesets for you to change.

You can not change history for any published changes - like I said, doing so makes your repository incompatible with any other clone.

Good resource, thanks

Read the thread. The Kernel maintainers use b4, which rewrites history.

Mercurial does not work like git, and history is immutable: there are no commands for changing history.

I'm American (US) but when I lived in Germany, by the end of two years there I thought in German. I remember it, but there are two anecdotes that underscore it:

1. When I returned to the States, I'd occasionally not be able to remember the English word for some things. I lost "trashcan" for a good half hour, once.
2. I occasionally talk in my sleep, and for a few years after I returned my wife would sometimes tell me that I was speaking German.

I didn't spend much time around English speakers when I lived there; I met my wife the year after I returned, and the person I was seeing when I lived in Germany had barely spoken English.

Sounds like OP might be at a point where they could use a little more information.

OP, what you could do is get yourself a small USB memory stick - 8 GB should be fine - and flash different distributions on it, boot into them without installing, and find one you like and install that one. There's a tool called Ventoy that will make it really easy: especially if you have a larger USB stick, you could put several different distributions on the stick and choose which one you boot into at boot time.

My only suggestion when you do the install is to partition the hard drive and put /home on its own partition. If you decide later you want to use a different distribution, you don't have to backup and restore your user data.

I liked your explanation; you said it better than I ever could have.

You know what Lemmy needs? Some sort of reward... something... we could call it "Lemmy Gold." Then monetize it.

Kidding about the second part, sincere about the first. I will, however, repeat: Lemmy Needs Comment Emoji Reactions.

Is it? Is random variance the source of all hallucinations? I think it's not; it's more the fact that they don't understand what they're generating, they're just looking for the most statistically probable next character.

This is the way.

I will say, Jellyfin's aggressive transcoding has brought even my relatively modern, 12-core AMD to its knees, but for everything else, more RAM has been more important than CPU or GPU specs for self-hosting. Before Jellyfin, I hosted the entire house on an ARM-based micro.

That said, the game changes if OP wants to do any LLM stuff. Memory is still important, but the GPU starts to play a bigger role.

If I could know only one stat for making a decision, though, it'd be RAM.

Naw, I didn't think you were mad; it was funny that you sounded so shocked that someone on the internet could be wrong.

Unless you go in with a byte editor, you can't change Mercurial's commit history. I didn't say "fabricate", I said "change".

You can, as you say, configure your user name and email to be "Linus Torvalds" and change your computer date and fabricate whatever history you want. You might also be able to go in with a byte editor and fiddle bits and change history that way; Mercurial provides no blockchain-like cryptographic guarantees. But, unlike git, rewriting history is not supported by Mercurial; history is immutable. Rebase doesn't change history; the commit index only ever increments. Squash and rebasing create new commits, and there history of what happened is always in the repo.

There's a distinct and clear difference between Mercurial's immutable history and git's de jour history rewriting, which can literally - with the git command - change published history to make a commit made 3 years ago look like it was committed by someone else. The git workflow used by the kernel team, and the b4 tool, use this history rewriting in the standard workflow.

If you wanted to do the same thing with Mercurial, you'd have to get a byte editor and start hacking the on-disk format, and it would have to be entirely outside of any Mercurial tooling. And there is some sequential hash verification you'd have to work around, even if it's not cryptographically auditable.

The point is, with Mercurial it would be hard and the result would be utterly incompatible with any other clone of the repo: there would be no way to propagate your changes to other clones. With git, this is a standard workflow.

I'll say here that one of the less discussed differences between git and Mercurial is that Mercurial does not allow commited history to be changed, and git does. Git users call this a "feature," and it leads to situations like this which are utterly impossible in Mercurial.

Git allows rewriting history by design. The kernel team uses it liberally. It is debatable whether this is a good thing, but it's one reason I stick with Mercurial.

I read through it by clicking the "next" link at the bottom. There isn't a single email explaining it; it's a story you have to read through to understand.

If you jump to the last message, it's someone saying they had the same issue.

But, TL;DR a tool kernel devs use has surprising behavior that's biting people, and can alter the commit history to be a pack of lies that looks suspiciously like malicious intent.

The thread doesn't mention how or if the tool has been changed. The tool is b4.

Naw, there are several good use cases for blockchain. Ask a blockchain hater how to implement an auditable change log, and they'll re-invent blockchain and claim it's not.

I'm only saying: you specifically mentioned Bitcoin, and then later said design goals included cryptocurrency integration. I'm not opposed to crypto, conceptually - I'm just giving a possible reason why you may be garnering downvotes.

Yeah. NFS and CIFS got mangled in my brain.

Well, I didn't say "NT" stood for "network", but you're right that I was wrong about it being a network filesystem.

holy shit.

I'm glad you're so passionate about people being wrong!

Wayland is super fast, free of tearing and can handle completely different monitors working together without issue

I had the opposite experience. Wayland was slower, and didn't handle my different DPI and monitor sizes correctly; I could set the exact same fonts (family, sizes) in two different applications and one would be normal and the other unreadably small. I haven't experienced tearing on X in decades; I haven't seen that on Wayland, either, but it hasn't been a issue for me.

I'll try it again here pretty soon. It's improving; my biggest issue was that people were pushing it while it was still clearly half-baked; maybe the issues I've seen are resolved. And, maybe it's caught up to X in speed, although the last benchmark I saw (Phorix?) it still lagged X for many things.