I’m violently in favor of Big Light™. Really wakes you up that flashbang when you turn it on. 🙃

Yeah, I might block a contributor on sight, if they post something like that.

In case, you’re not aware, you can also email the dev. You can code up your commits as normal and then use e.g. git format-patch -3 to put the last 3 commits patch files. You can then attach those files to an e-mail and the dev can apply those patches with git am.

It takes a bit of playing around, but it’s actually really easy.
The Linux kernel, one of the most complex projects on the planet, develops like this.

I think, you could open the same file multiple times and then just skip ahead by some number of bytes before you start reading.

But yeah, no idea if this would actually be efficient. The bottleneck is likely still the hard drive and trying to fit multiple sections of the file into RAM might end up being worse than reading linearly…

Yeah, there are still indie titles with infamous creators. It’s just that the limelight is now taken by big corporations with big marketing budget.

Yeah, feels like the correct move here would be to hold off with the next generation, if you can’t get enough of a performance jump without increasing prices. Otherwise you’re just offering a premium edition.

Yeah, I always plead for as much as possible to be automated offline. Ideally, I’d like the CI/CD job to trigger just one command, which is what you’d trigger offline as well.

In practice, that doesn’t always work out. Because the runners aren’t insanely beefy, you need to split up your tasks into multiple jobs, so that they can be put onto multiple runners.
And that means you need to trigger multiple partial commands and need additional logic in the CI/CD to download any previous artifacts and upload the results.
It also means you can restart intermediate jobs.

But yeah, I do often wonder whether that’s really worth the added complexity…

I always thought openSUSE’s package manager zypper has quite a few neat ideas:

• It offers two-letter shorthands for subcommands, so zypper install→ zypper in, update → up, remove → rm.
• When it lists what packages it will install or remove, it will list them with the first letter highlighted in a different color, kind of like so: fish git texlive
  This makes it really easy to visually scan the package list, and since it’s sorted alphabetically, it also makes it easier to find a particular package you might be looking for.
  And while there’s separate lists for packages to be added vs. updated vs. removed, they also color those letters in green vs. yellow vs. red, so you can immediately see what’s what.
• When it lists items (other than packages), it prints an ID number, too.
  So, zypper repos gives you a list of your repositories, numberered 1, 2, 3 etc., and then if you want to remove a repo, you can run zypper removerepo 3.
• When you run a zypper search, it prints the results in a nicely formatted table.

Documentation: https://doc.opensuse.org/documentation/tumbleweed/zypper/

Hmm, I don’t know about Pacman, but for example openSUSE’s zypper remove has a --clean-deps flag, which doesn’t exist on the other subcommands. So, it wouldn’t make sense to have it be zypper --remove --clean-deps…

Yeah, this is one of those issues that I feel separates the seniors from the, uh, less experienced seniors. (Let’s be real, as a junior, you know jackshit about this.)

Knowing when to use an ORM, when to use SQL vs. NoSQL, all of that is stuff you basically only learn through experience. And experience means building multiple larger applications with different database technologies, bringing them into production and seeing them evolve over time.

It takes multiple years to do that for one application, so you need a decade or more experience to be able to have somewhat of an opinion.
And of course, it is all too easy to never explore outside of your pond, to always have similar problems to solve, where an SQL database does the job well enough, so a decade of experience is not a guarantee of anything either…

Don’t think the original LISP is used much anymore, but there’s various dialects like Scheme, Racket and Clojure.

Some examples where it’s used, off the top of my head:

• Lilypond for when you need your sheet music to be turing-complete. Uses Scheme.
• Emacs, for configuring the whole editor. (Has an own dialect, Elisp.)
• GNU Guix, which uses Scheme for configuring the entire operating system.

Obviously, you can also use them for general software development. A few years ago, I read of some project that used Clojure for a larger backend service, with the author gushing all over the place.
Some folks are really passionate about the LISPs, but yeah, not terribly popular in the corporate world…

Dungeon Lawl Stone Soup 🙃

I think, the problem is that Nvidia has two customer groups. Those that buy their products and those that buy their stock options. Nvidia can produce garbage that completely misses the point of real-world usage, so long as they can convince investors that other investors will join the pyramid scheme. And for that, it just has to look like impressive tech, not actually good or artistically meaningful.

Will it smooth out a wall that is supposed to look like it can be destroyed?

Yeah, at the very least, it will throw a whole bunch of details into the general area, which will make it harder to tell what’s interactable.

We’ve had photorealistic games before, by taking literal photographs and using those as point-and-click levels. You practically don’t see that anymore these days, because not being able to tell what’s interactable was a major weakness.

Doesn’t mean that DLSS 5 or the like will strictly have the same problem, but it certainly feels like these companies are trying to throw in photorealism again, with no regards for the cost.

I mean, yeah, but you’re kind of saying what the others here were saying, too, in that when something fits the anywhere close to the “old hag” category, that the probabilities will shove it entirely towards “old hag”.

That it’s somewhat fitting for this character, I would expect to be coincidence. Like, maybe they did actually give the image generator somewhat of a system prompt for this demo, that it should make her look extra wrinkly.
But yeah, shoving all depictions of women either towards young model or old hag is quite emblematic of these image generators, so personally, I don’t think, it was even necessary…

Don’t think the playable characters are supposed to be creepy, but yeah, a yassified zombie would probably fit right in. 😅

Never cared for realism in games to begin with, so don’t particularly care to comment on how it looks, but I’ve been thinking that I genuinely find it creepy.

Not just Uncanny Valley material, but also having these faces stare at you, always fully lit, it just gives me the creeps, kind of like a panopticon situation.
I don’t fucking know, if that’s my own trauma playing into that, where for the longest time, people looking at me generally meant they’re about to bully me.

But either way, I’m about to head to bed and genuinely feel like there’s a 20% chance I’ll have a mild nightmare from that shit.
This whole AI craze has been a wild ride of all kinds of nightmare fuel, from depictions with missing/additional limbs to the weirdest warping of objects+limbs in those fucking generated videos. And the worst part is that some folks seem to just not see it or not want to see it, so they keep using the nightmare generators.

Everything I implement at work is open source because I don’t want to wait for a purchase approval.

Just to say, though, I feel like 99% of the software we deploy is open-source for that exact reason. Projects generally start out small, where you try to evaluate some concept. You’re not gonna spend months to go through the purchase process of some proprietary tool, if you can help it…

Yeah, there’s a bias in these image generator AIs, because model photographs are:

• easy to get in bulk and in relatively high resolution etc.,
• relatively uniform (even lighting, facial symmetry etc.), meaning they reinforce existing patterns in the training data, and
• relatively easy to generate good-looking results with them, for obvious reasons, so more likely to be optimized towards by anyone involved in the training.

I think, why people perceive that right image as older is because the wrinkles carve much deeper. Yeah, same number of wrinkles, but it looks like they got chiseled down by 20 additional years…