https://www.youtube.com/playlist?list=PL16yfJJxAM6g-4YxKGI-1...

I'd recommend some combination of the Bethesda open world games and the JRPG genre today. They're not the same, nothing really quite fills the Ultima gap that I know of, but between those two I'd call it close enough.

It's like you say, not exactly the same, but for CRPGs it's hard to go wrong with Baldur's Gate 3. It's similar enough to later Ultima in some ways that it might scratch the itch.

I do not have the same complaint about them as I do Ultima VII. A good remake could still be an interesting experience today, with little more than a graphical overhaul and modern controls. Both of them have a mixture of exploration, combat, and conversation that keeps them engaging over time.

Ultima VII's problem is that it's just... one big fetch quest. The combat is a non-entity (in the original game, I gather some of the remakes have tried to address this but they're starting way, way behind the eight ball), and there just isn't much else there.

Ultimas prior to VII don't have that problem because combat is functional, so the essentially multi-genre nature of an RPG where each subgenre keeps the other from becoming painfully tedious is there, but by modern standards, probably still fairly unplayable. Neat ideas, you can see how later games picked up the ball and ran with it in various directions, but very hard to play by modern standards. For instance, Ultima 4 combat has modern TRPG combat in it to some extent... except no even remotely modern TRPG game makes "moving one space" an entire action on par with "make one attack", and for good reason.

His other videos on other games are great as well!

- ai therapist for your ai agents

- genetic ai agent container orchestration; only the best results survive so they have to fight for their virtual lives

- prompt engineering as a service

- social media post generator so you can post "what if ai fundamentally changes everything about how people interact with software" think pieces even faster

- vector db but actually json for some reason

(Edit: formatting)

AI Agent Orchestration Battle Bots. Old school VMs are the brute tanks just slowly ramming everybody off the field. A swarm of erratically behaving lightweight K8s Pods madly slicing and dicing everything coming on their way. Winner takes control of the host capacity.

I might need this in my life.

Losing family is hard, but losing them suddenly makes it harder. Losing them suddenly because of poor advice or (in)action of people who are supposed to help is yet more difficult. I know from experience.

It does get easier to deal with, in time.

What’s next, sick days and parental leave for the software? Give me a break. This is performative.

Being able to use sane scripting to solve problems, ZFS snapshots to undo bad mod installs, using the same system for development, and so on is no longer something I'm willing to give up. I've also started amassing a small collection of Cloud Init configs that set up game servers inside LXD containers. Some of these have native Linux binaries but a few only have Windows servers. They run perfectly well through Wine.

Anyone here even vaguely interested, I encourage you to just try it. I use Ubuntu and it works great on both AMD and Nvidia cards for me. What have you got to lose?

It allows my wife to play Stardew Valley on the TV via game streaming, while not disturbing my work at all on the PC. When she launches the game, I don't even notice it on my PC, meanwhile other solutions like Sunshine or Apollo do not let you use your computer while a gaming session is active on a client. Sadly, Duo is Windows only for now, which sucks.

Does anybody know a alternative for Linux that would work this way?

1. https://github.com/DuoStream/Duo

Shit just works. When it doesn't, changing the proton version usually fixes it.

Way better than Windows.

I realize by posting that here on HN I'm tempting people to send me the ProtonDB garbage tier list, but it's true for the types of games I play.

My stack is so vanilla (nvidia, python, R) I can’t think what the issue is. Maybe hardware.

The graphical environment is neither here nor there for me, I just want to do an update and cuda libraries/nvidia drivers not break and for my OS to boot!

26.04 will be a huge upgrade if you stay

As for interactivity - I use a REPL daily with Clojure and it works just as you'd expect from a CL REPL. The only time you need to reload is if you add a new JAR to the classpath or occasionally when state gets really weird. There are reload facilities baked in to nREPL too.

For reference, I've used Clojure professionally for about a decade.

I'd suggest trying it out with Calva in VS Code.

Google’s version Jules has one.

I bought a small press book with a collection of this art and it was a fun little trip down memory lane, as I’ve owned some of the hardware (boxes) depicted in it.

For anyone else interested: https://lockbooks.net/pages/overclocked-launch

To me, this is a continuum with the box art of early games, where because the graphics themselves were pretty limited the box art had to be fabulous. Get someone like Roger Dean to paint a picture for the imagination. https://www.rogerdean.com/

The peak of this was the Maplin electronics catalogue: https://70s-sci-fi-art.ghost.io/1980s-maplin-catalogues/ ; the Radio Shack of UK electronics hobbyists, now gone entirely. Did they need to have cool art on the catalogue? No. Was it awesome? Yes.

https://spillhistorie.no/2025/10/03/legends-of-the-games-ind...

Turns out that the Psygnosis developers in the 1980s used him as a kind of single-shot concept artist. They would commission the box art first, then use that as inspiration for designing the actual game to go inside the box.

https://row.rarevinyl.com/products/anderson-bruford-wakeman-...

Weird shop; they never really got rid of any stock that was even theoretically useable, so it was at least partially a museum of outdated gadgets.

Today, a layman couldnt chronologically sort CoD games from past 10 years from looks/play/feel, new Fifa and similar is _the_ same game but with new teams added to it, and virtually every game made is a "copycat with their own twist" with almost 0 technical invention.

Feels similar to how painting hasn’t had any revolution in new paints available.

I think he meant the software side (game-systems wise), not hardware innovation

I mostly play indie/retro/slightly-old games these days, so I mostly hear of the negatives for modern AAA, admittedly. I'm also tempted to complain about live service, microtransactions, gacha, season passes, and so on in recent big releases, but maybe that would be getting off-topic.

Just like Crysis did 18 years ago?

>it's no longer really feasible to keep most of your games installed all the time and ready to play.

Crysis was around 5% of common HDD back then. Now, it'd be equivalent of around 80 GiB now. That would be just about what Elden Ring with the DLC takes.

So I will probably install Linux (probably Debian) and move on and forget about those particular games... (~30 years since I first installed Linux on a PC!).

I built its successor in 2020, using a GPU from 2017. The longevity of the PS4 has given that thing serious legs, and I haven't seen the need to upgrade yet. It still runs what I want to run. It's also the first post-DOS x86/64 machine I've owned that has never had Windows installed.

The only reason I'd upgrade is to improve performance for AI stuff.

The AM5 platform is quite lacking when it comes to PCIe lanes - especially once you take USB4 into account. I'm hoping my current setup from 2019 survives until AM6 - but it seems AMD wants to keep AM5 for another generation or two...

You'd be better off complaining about how Threadripper CPUs and motherboards are priced out of the enthusiast consumer market, than asking for the mainstream CPU platform to be made more expensive with the addition of IO that the vast majority of mainstream customers don't want to pay for.

x16 GPU + x4 NVMe + x4 USB = 24 direct CPU lanes covers 99% of the market, with add-ons behind the shared chipset bandwidth. The other 1% of the market are pushed to buy Threadripper/Epyc.

Now it's a node in my proxmox cluster running transcodes for jellyfin. The circle of life

I genuinely don't believe this to be true for AMD. I bought a 6600xt on Release Day and by the time I was able to build my complete PC, it had upstream linux kernel support. You can say what you will about AMD but any company that respects my freedoms enough to build a product with great linux support and without requiring any privacy invading proprietary software to use is a-ok in my book.

Fuck NVidia though.

And it looks like Linux-Libre also opposes CPU microcode updates[1], as if bugged factory microcode with known security vulnerabilities is any less non-free than fixed microcode. Recommending an alternative architecture that uses non-proprietary microcode I can understand; this I cannot.

[1] https://www.phoronix.com/news/GNU-Linux-Libre-4.16-Released

I remember when running linux on your computer at all was hit or miss, these days i can go to lenovo and buy a thinkpad with ubuntu preinstalled and know that it will just work.

That was 2021 though when AMD was still a relative underdog trying to claw market share from Nvidia from consumers. AMD of today has adjusted their prices and attitude to consumers to match their status as a CPU and GPU duopoly in the AI/datacenter space.

It's cool that it exists, and it's impressive that it is built on top of git itself. If you (like the author) want to use it, then more power to you. But I have yet to be convinced by any of these articles that it is worth my time to try it since nearly all of them start from a point of "if you hate Git like me, then try this thing".

If anyone has a link to an article written from the point of view of "I love or at least tolerate git and have no real issues with it, here's why I like JJ," then I'd be glad to read it.

And when you rebase, the commits lose their identity since commit hashes are content-addressed, despite having an identity in people's minds - a new revision of a commit under review is usually logically the same unit of change, but git doesn't have a way of expressing this.

jj, as I understand it, addresses these pains directly.

There's a semi-recent addition that makes it a single command, the --update-refs flag to rebase (along with the --rebase-merges flag, formerly called --preserve-merges).

Would be nice, if it would also have a flag to choose that behaviour.

Since when does rerere not work with rebase anymore?

>> Git records merge resolutions

isn't true either.

There's nothing wrong with taking the time to learn how to use a bad UI, especially if there's no other option. But don't mistake your personal mastery of git for evidence that it's better than jj.

In all likelihood, the git proposal you allude to would not extend further than adding a bit of persistent metadata that follows commits after "destructive" changes. And even then, it'd be imperatively backing into the change-as-commit-graph data model rather than coming by it honestly.

> If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO

This is like saying if people take the time to learn curl, there's really no reason to learn Firefox.

And it doesn't suggest to me that you're all that familiar with jj!

- automatic rebasing! goodbye to N+1 rebases forever

- first-class conflict resolution that doesn't force you to stop the world and fix

- the revset/template languages: incredibly expressive; nothing like it in git

- undo literally any jj action; restore the repo to any previous state. try that with the reflog...

No amount of learning git nets you any of these things.

I always introduce jj as a better git ui.

Where jj shines is advanced workflows that aren’t practical with git. If you aren’t interested in those then it doesn’t give you as many benefits over git.

If you are breaking down your features into small PRs, stacking them, etc…, then jj is super helpful.

It turns out there were a lot of things that I was not doing with git because with git it would have been painful.

Now my PRs are split into human-sized commits that each contain a set of changes that make sense together, and I keep moving changes around during development to keep the history tidy, until it's time to send the pull request. If a commit introduces a typo, the typo fix should go into that commit so the typo never happened in the first place and you don't get reviews like "please fix this" and then "oh wait I see you fixed it in a later commit".

And sure, with git you could checkout the faulty commit, amend it, then amend -a and hope no one was looking, and rebase your dev branch onto the amended commit and it will often even work. Or rebase -i, sure -- have fun with it if the typo was 12 commits ago.

So I just never did that because augh.

With jj it's trivial. You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it.

No more rebase hell. No more deleting the checkout and pulling it clean because things went sideways in a way that would be hell to fix manually -- jj takes snapshots after every mutation and rolling back is easy. No more squashing on merge to sweep the messy commit history under the carpet. No more juggling index and staged files and stashed files and all that messy business. Everything is just suspiciously straightforward. To think this could have been our lives all along!

And I'm not looking back.

It's not that I dislike git. It's just that I love jj.

That's my workflow in Git. It is sometimes painful, but only because other people don't do that.

It is less work, if you use git --fixup=old-commit-hash and then use git rebase --autosquash. The --fixup step can even by automated, by using git-absorb, but this needs to be installed separately.

> You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it.

That sounds the same in Git?

> No more deleting the checkout and pulling it clean because things went sideways in a way that would be hell to fix manually

When do you need to do that? The only case in which I messed up my repo, was when I had a harddrive crash and recovered commits manually from git objects, because the other files were corrupted.

> rolling back is easy.

Yes, that seams a bit easier, but reflog still exists.

> No more squashing on merge to sweep the messy commit history under the carpet.

This is just as well a stupid idea in Git and I hate that. This seams to be cultural and is not suggested by the tool itself.

> No more juggling index and staged files and stashed files

I find these useful, but you can also use Git without them. Just always use commit -a and commit instead of stashing.

> That sounds the same in Git?

I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago.

In JJ I'd do this:

    vim file/with/typo.txt
    jj squash -into abcd1234 file/with/typo.txt

    jj edit abcd1234
    vim file/with/typo.txt
    jj edit <<my latest commit ID>>

    vim file/with/typo.txt
    git add file/with/typo.txt
    git commit --fixup=abcd1234
    git rebase --autosquash -i

The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234 was the last time you modified these lines.

The second approach is this:

    git rebase -i abcd1234~
    # do 's/pick abcd1234/edit abcd1234/' in your editor
    vim file/with/typo.txt
    git rebase --continue

So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

As for effect on the workflow, you can just continue to work and commit and then call autosquash in two weeks, when your about to merge. This also has the benefit, that Git (by default) only alters commits nobody has used yet.

The second approach has the exact same amount of commands. The first has 2 more. The add is necessary, because Git separates committing into two steps, which has other benefits. If you would want the JJ behaviour you can call commit -a. The autosquash is necessary, because you don't need to use fixup with autosquash, you can also do it alone, which is recommended if this fixes something, that is already in an older release.

As for jj, JJ and Git are much more close than C and Rust. JJ tends to have slightly less commands, but only because what are flags in JJ are separate commands in Git. The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered.

Also I prefer refining stuff we already have instead of throwing it all in the bin and stating it's obsolete.

I don't think it would have been doable. I hear this question/comment sometimes. I sent https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.

> The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.

This doesn't support what you said?

> I don't think it would have been doable.

This only states that JJ has a different user model, with a different structure of commands and flags, not that it magically does things that are impossible in Git.

Btw., you could just link to the commit diff instead. And are you quoting yourself?

-----------

Oops, now I see the issue, you misunderstood me.

> but they just never bothered.

"They" referred to the authors of blog posts. I didn't want to claim, that it would be a good fit to merge the JJ user model with the Git user model. My claim was that the approaches people learn with the JJ user model aren't exactly difficult in the Git model either. People just reconsider their approaches when they touch a new tool with the experience they gained since starting to use Git. They just never considered that approaches with a tool they have been using for years.

My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.

I'm not sure if I would like it, because I care about reproducibility of commits so I want commit hashes to stay the same after a rebase. Does it support --committer-date-is-author-date ?

I'm also somewhat wary of additional layers on top of something.

That flag seems a bit weird, though. Wouldn't you want to keep whatever the committer date already was? Why would you want to reset it to the author date? Of course, after you have passed the flag once, any subsequent uses will have the same effect as keeping the committer date, so maybe that's why it's good enough. Maybe it works the way it does for historical reasons (I happened to see that it used to be passed to `git am` back when `git rebase` was based on that).

> Wouldn't you want to keep whatever the committer date already was?

Note, that when you create a new commit, the beginning committer and author date are always equal. So the original one is always the author date.

I find this flag useful, because it means that I can keep rebaseing and still reproduce the same commit hashes. This is really useful for asserting that nothing changed when the commit hash is equal or that really something changed when it is different. Otherwise the commit hash changes for all commits you touched in the rebase and you constantly need to verify if there was a change or not.

Or do you mean if jj updates the committer timestamp while leaving the author timestamp unchanged? Yes, that's also the same as what Git does.

I did not dig into the history of the code, so I can't say if it was an explicit design decision or just how it was implemented. Since there hasn't been a lot of demand to change anything here, I didn't see any active discussion about the choice.

EDIT: oh I see martin has said 'we just followed git' here: https://news.ycombinator.com/item?id=45599741

https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...

That having been said, I didn't hate Subversion either. It was fine.

Idk man, the first two paragraphs of the article very much make it sound like you hate git.

> Over the past few years, I’ve been seeing people rave about Jujutsu, and I always wanted to try it, but it never seemed worth the trouble, even though I hate git.

> I don't hate git

but

> I have my trusty alias, fuckgit

Someone who doesn't hate git would have named this alias quite differently...

But hey, it's not my alias. I'm just saying that the way I read it didn't suggest hate, just a little cleverness. I can't speak for what the author was thinking.

I think you linked to the same post as OP, though?

I used bzr after SVN, but my larger point is that it's all fine, the question was whether you want to go through some short-term learning for long-term gain, or if you want to keep using what you know. Either is fine, I'm still using vim as my editor, for example.

Was it better than CVS in some way? Sure.

But git is just better in so many ways. Back in the day I used git exclusively with git-svn at a place that was still stuck with SVN and I had a blast, while everyone else didn't. I just never had any of the problems they did.

I'm not entirely sure what pain people speak of with git. I found the transition very natural. And don't come talking to me about the "weird command syntax". Some of that was specifically to be compatible / "intuitive" / what they were used to for people coming from tools like SVN.

Sure you gotta learn about "the index", understand that everything is local and that you have an origin and local copy of all the labels (also sometimes called branches or tags) you can attach to commits. That's about it for the normal and regular use that someone would've had with SVN.

It can't be that SVN is bad and git is better but also that git is fine even though jj is better.

You start out the article with hate for git without explaining what you actually don't like, then here on HN say "I don't hate git". A command called `fuckgit`? Because you need to re-clone? What are the things you commonly do that require this? I've never encountered it. Maybe you're just too advanced a user for git and jj really is better for you. But for us lowly regular users I really do not see an issue.

Some of the benefits you tout, like "editing a commit and you don't need to commit it yourself"? I'm sorry but I want to be the one in control here. I am the one that says "I'm done here, yes this is the new version of the commit I'm comfortable with". I've specifically forbid Claude to add, commit, push etc. for example.

It also breaks your "you need to stash" argument. I don't stash. I just commit if I have something WIP that needs saving while I work on some other emergency. There's no reason not to just commit. In fact I do that all the time to checkpoint work and I amend commits all the time. It's my standard commit command actually `git commit -a --amend`.

Automatic "oplog" of everything Claude did, IDE style: sure, maybe. Though I've yet to see that need arise in practice. Just because I have Claude et. al. now, I don't believe changes should be any bigger than they used to. Nor should my "commit early, commit often, push later" practice change.

I start out the article saying I never understood git, and why does it matter what I don't like? That would only matter if I were trying to say that git is bad, but I'm not making a comparison. I just think jj is better-designed, and that you should try it.

> Some of the benefits you tout, like "editing a commit and you don't need to commit it yourself"?

I never said that's a benefit, I just said that's something jj does differently. I `jj commit` when I'm done with some work anyway.

> It also breaks your "you need to stash" argument. I don't stash. I just commit if I have something WIP that needs saving while I work on some other emergency.

In that case, you'll like jj, as it handles all that for you.

Your comment is coming off as a bit defensive, I didn't write my article to attack git. If you like git, keep using it, I prefer jj and I think other people will too. It's hard to get started with because its workflow is different from what we're used to, so I wrote the tutorial to help.

    Your comment is coming off as a bit defensive

    I didn't write my article to attack git [...] I wrote the tutorial to help.

Blue speech bubble with literally the text: "If you don't like Jujutsu, you're wrong". This is text. There's no "tongue in cheek" voice and body language here, even if potentially you meant it that way. But given how the article itself starts, I don't think there was any of that to transport :shrug:

    Needless to say, I just don’t get git

Except Git doesn't do it differently here. Git only provides an additional way to commit temporary changes, you still can commit them how you like. In fact a stash are just two commits.

I probably would have stuck with Sapling, but my company switched to git and the jj integration was cleaner -- especially being able to run in colocated mode: your project root directory has both .jj/ and .git/ subdirectories, and you can use both jj and git commands without much trouble. If someone gives me a git commit hash, I can just use it directly with jj.

Sapling is good. I'm still fond of it, and in fact still have a few repositories I haven't switched over yet. But being able to do everything with a single tool is useful, plus jj gives me some extra capabilities over sapling (or at least things that I don't know how to do as easily).

When I was an intern at GenericCorpo we had days we couldn't work because SVN was down. WTF was that?