Distrohopping sounds exhausting. I don't know why people bother.

How people can just wake up one day and go, "Man, FUCK all my apps and settings, today I want to reinstall and reconfigure 70% of them and then find and learn alternatives to the 30% that aren't transferrable, and completely disrupt my workflow for several weeks" is utterly beyond me.

It's like a miniature version of people who get tired of living in a place and just... move. For no reason. All that effort, selling your home, finding a new one, finding a new job, just because you're... bored?? I am not knocking it, I just can't relate at all.

I started my Linux life in Ubuntu MATE, and then to Debian when I figured I no longer needed Ubuntu's handholding and I was tired of dealing with MATE's abysmal lack of community resources and documentation. Unless and until Debian either becomes antagonistic to me or their support for new software becomes severely crippling, I have no intentions to leave.

It just works. Leave it be. This is my home.

The other thing I try to do that I didn't think of in the other reply is not mixing mods together.

Most major tech mods are balanced for standalone play. They merely contain integrations with other mods as convenient curiosities. So when you mix overpowered machine from mod ABC that is regulated by some restriction, and combine it with machine from mod XYZ that trivializes that restriction, the progression collapses and it's boring.

Some people like that. I try to avoid it.

Some might wonder what the point is in playing with all the mods if I don't actually use all the mods. And my answer is I do, but all separately in parallel. I like being a botanist and a thaumaturge and a blood magician and an astral sorcerer and a pressure mechanic and a mekanism engineer all at the same time, but like... in shifts. When I get bored of one I put it down and advance another. I want to feel like I've mastered them all rather than cherry picked the best parts of each. I get all the variety but few of the problems.

All of this context switching means I waste a tremendous amount of time, but it does make the game last longer. But not too long.

Also, in coop, it pays well when players specialize. I do this magic, you do that tech, etc. Share one or two things in common, but also be different. You might end up wickedly out of power balance depending on which mods you picked to specialize in, but imo that's not really the mark of success.

Yeah, this is inevitable.

My limiter tends to be that anything I make has to do things not only efficiently, but fashionably. I like to be immersed in a factory that looks vaguely like a real factory, rather than laying down a bunch of minmaxxed spaghetti. So I spend a lot of time faffing about with where a thing should actually go and how do I hook it up in a novel way.

Casuals still can't keep up and tryhards pass me by. Stuck in the middle, lol.

I tend to burn a little slower than that, but yes. Post-scarcity is usually the goal and the game needn't overstay its welcome.

When you cram it full of tech mods it is.

If you don't have at minimum 4 GB of RAM to dedicate to the game alone, you are not going to be able to load the packs I want to play. And yet, this is apparently how much RAM a lot of people still have in their PCs total in the year of our lord 2024.

I also have a lot of friends using underpowered netbooks as daily drivers, which will quickly be CPU-bounded in a game like modded Minecraft.

Minecraft, especially modded Minecraft, is almost an anti-game. Unlike nearly every other big game, where it's a neat and tidy compiled package that stays in its lane memory-wise, loads relatively quickly, and only makes you ask questions about how many pretty settings your GPU can handle and what FPS you'll get doing it, Minecraft instead is a bloated, memory-hogging dumpster fire written crappily in Java (many of the mods are, anyway) that runs like a dream on integrated graphics but can bring nearly any processor you might have to its knees on single thread performance.

I have asked many a friend to play modded Minecraft with me.

Unfortunately, I am reminded time and time again that the Venn diagram of people I know who are interested in that and people with PCs who can run that is two circles.

If all characters are equally likely, it's a fine password. It's long and certainly immune to any dictionary attack.

But if the attacker knows it's generated with this method, then it is probably a poor one. Bottoms tend to spam only homerow keys, either in all lowecase or all uppercase. The restricted character set vastly reduces the search space.

It bumps the speed and officially supports Displayport and PCIe protocols being tunneled through.

Also, as a tiny nit for seemingly no other reason than to piss us all off, they have decided the "correct" way to write it is "USB4" (no space). This is in contrast to every previous version of USB such as "USB 3" (space).

My phone has this problem. It's RAM.

My phone is literally never not using the full 8 GB it has, and it's constantly juggling. Even when I have next to nothing open.

What's eating it all? Fuck if I know. My phone also has a system memory leak that has eaten up 90% of the onboard storage with modem crash dumps I can't delete without root, and this phone has no custom firmware to do that. Got what I paid for, I guess...

You don't. One of the core aspects of Git is that it fully expects conflicts to be inevitable, and it gives you tools to resolve them.

I will say that if you learn to aggressively rebase branches, you can at least occasionally reduce the complexity of conflicts.

If you are working on a long branch and three other branches that conflict with your changes land in the meantime, a simple merge will force you to reconcile all of those conflicts in one big stinky merge commit.

If you instead rebase after each individual branch lands, you resolve the same number of conflicts but in three smaller, focused steps instead of one big ugly one. You also don't get a merge commit full of redundant deltas that serve only to resync your branch to master; all the conflict resolution becomes baked in to your individual branch commits.

Spreading out the problem is not reducing the problem. But it can make fixing the problem less daunting, which has a similar effect.

I have no idea what you mean by DIY distros, what a peculiar adjective in this context. Linux itself is DIY. Life is DIY.

Pretty sure what they meant is no distros where you have to manually curate and possibly even build every sodding package, like Linux From Scratch, Gentoo, and maybe to an extent Arch. I presume they want a disto that flashes to a live USB, walks through a wizard, and boots up out of the box fully functional in minutes, no fuss required.

Yeah, the notion that "cut" and "delete" are the same operation was an interesting hurdle. It's quite elegant, honestly.

The only thing it disrupts is the situation where you want to copy something, delete a second thing, then paste the first thing. Oops! Too bad! It's gone now!

I'm aware we do have access to multiple registers in Vim, effectively giving us many clipboards to bypass this, but I don't know the commands to utilize them. Without that knowledge, this little quirk remains an occasional irritation. Just not irritating enough to motivate me enough to knuckle down and learn it.