Uh, they originally weren’t paid. They were paid for.

Huh, TIL, I thought these were the same characters.

It just occurred to me a reason TF3 can’t happen in a satisfying way.

You couldn’t make TF3 with a different cast of “heroes”, right? It would just be unsettling and disrespectful. TF’s DNA is their lovable characters.

Not a single TF playable character is a woman. That was on-par for the 2000s, but definitely not acceptable in the 2020s when your competitors are OW and Valorant which both have a diverse cast with (AFAIK) gender parity. Keeping the cast but adding 9 women and 2 enbies would feel extremely performative and like the new PCs are inferior “tack-on” characters.

TF3 would either be problematic or desacralized. IMO making new IP is the right call.

There are quite a few mature projects in 0.x that would cause a LOT of pain if they actually applied semver.

I am generally of the opinion that version numbers do not matter at all until the author/distributor has GUARANTEED that they do. Until then they’re worthless, including in places where semver is supposedly enforced like NPM. If I had a penny for every NPM package that broke my project after removing the package-lock.json, I could retire.

You mean npm duplicates even if the the two dependency versions are compatible?

By default yes, unless you explicity use the “peer dependency” system which isn’t the default. The “default” naive implementation is for every package in your node_modules to have a node_modules of its own, all the way down recursively. There are tricks nowdays to deduplicate packages with the exact same version, but not to automatically detect “compatible” versions and use those instead (in my experience nothing would work if that was the case, deleting package-lock.json causes way too many issues due to the… uh, let’s call it “brave” approach of JS devs to stability).

That couldn’t be, right? Otherwise, if you installed two packages that rely on different incompatible versions of another package, one of the two would break

Correct. This is intended behavior which is solved in several ways:

1. Correctly declaring your dependencies. If newer versions of a dependency break your package, disallow them, but that is not normally needed for minor version changes.
2. Focus on quality. Semver exists for a reason, and 1.2.3 should not break something built against 1.1.2. JS and NPM’s cascade of stupid implementations bred a culture of “move fast and break things”, but that’s not the norm in any other commonly used ecosystem
3. Linux distros almost exclusively use curated repositories, so they are (mostly) internally consistent and incompatibilities are rare and quickly fixed. A good package manager will resolve dependencies and automatically detect incompatibilities, proposing several fixes (typically abort the upgrade or uninstall one of the problematic packages)
4. Not breaking down packages into a constellation of smaller packages. glibc6 is glibc6, not glibc_string (1.2.3) + glibc_memory (2.6.5) + glibc_fs (1.5.3) + glibc_stdio (1.9.2) + glibc_threads (6.1.0) + …
   Internally glibc6 is a bunch of modules, but they get bundled into one package specifically to simplify dependency management.

Not being able to install two versions of the same package sounds restrictive, but it’s a HUGE security benefit: glibc6 (1.2.3) is vulnerable to CVE-2024-1, then updating to glibc6 (1.2.4) secures your entire system at once. With NPM though, you have to either wait for every. single. dependency on that vulnerable package down your tree to recursively update, or patch those versions yourself (at your own risk because again, small version changes often break things since developers think that NPM’s dependency model means they don’t have to actually provide stability guarantees).

It’s saner, not perfect. With virtualenvs it does basically what you describe except that it re-downloads everything for every virtualenv, but that does not typically matter much since it’s not downloading a billion dependencies.

With NPM there’s no choice but to have hundreds of duplicates installed for every project, that’s not just inefficient but it is a security, maintainability, and auditability nightmare.

npm downloads every dependency recursively. If a depends on d (= 1.2.3) and b depends on d (= 1.2.4), then both versions of d get downloaded into a and b’s respective node_modules.

All other package managers I’m aware of resolve dependencies into a flat list then download, and you can only have one version of the same package on your system.

1. Like Python, have a large and featureful standard library such that > 80% of NPM packages are redundant. Other languages allow you to make very large projects with only a few tens of dependencies. JavaScript requires THOUSANDS.
2. With this in place, stop with the recursive dependencies, immediately and forever. Every other package manager under the sun installs the dependencies next to each other.

I’d say pip is saner, though not by much as its support for private registries is very bad and seems designed to facilitate supply-chain attacks. I’ve heard a lot of good things about cargo but haven’t used it enough myself to have a strong opinion.

Skyrim’s true power is that it’s excellent for single-player roleplay. The game is very immersive, the universe feels extremely vast, and the gameplay allows for extremely varied play styles.

The end result is that the game is very replayable if your thing is building a consistent and unique (head)cannon for your character. If you don’t focus the main quest, you can put in hundreds of hours across multiple characters before things get stale. Even the quests that you follow multiple times, you might approach from very different angles.

It’s already a thing with near-zero delay. MS Teams does it (dunno about the translation) and the QSMP Minecraft server has a bunch of livestreamers from different countries who use it for realtime translation.

[EDIT: Live demo from today. Shit’s impressive.]

What actually happens is that the current sentence gets “corrected” several times as you keep speaking. It’s a bit jittery and if the word order differs significantly then the translated sentence might be a bit wonky for a few seconds, and there are a few misses but overall it works really well; at least well enough that people who don’t speak each others’ language can have a conversation in their native tongues with essentially no more delay than reading speed. I can easily follow a livestream in a foreign language with the live subtitles (which was not the case a mere 6 months ago for any language other than English).

US-defaultism has a catch: it sometimes accidentally extends to the Commonwealth. You won’t run into most of the internationalization quirks if all you’re comparing is “British English vs American English”.
[Sidebar: I notice this also when English speakers online assume that their audience at least has a vague idea of what Imperial units are, but while that is true of most native English speakers in the northern hemisphere who use feet and miles colloquially, for ESL audiences it’s almost always incorrect]

I switched from AZERTY to US QWERTY permanently specifically to avoid all the issues of badly internationalized software. Bad default bindings (e.g. common vim operations like { requiring the use of AltGr), but also things like games not working at all or only partially (e.g. the number row being either unbindable, or key hints naively showing as “&” and “é” instead of “1” and “2”). Surprisingly few devs understand the difference between key codes and characters, and lots of indie games straight up don’t even internationalize and require switching layouts (good luck if there is an in-game chat).
After getting into mechanical keyboards, the ANSI US keyboard layout has been useful as well because these are quite common. ISO mechanical keyboards are rarer, and Belgian AZERTY keycaps are borderline nonexistent.

Also in practice I use the qwerty-fr layout which is the US layout with a French layer on AltGr. The kicker? It’s better at writing French than the French AZERTY which is missing a lot of letters (Ç, æ, œ, À, …). AZERTY is a terrible layout but that’s a separate discussion.

Of course the Americans should develop properly internationalized software, but I personally know several fellow Belgians who switched to QWERTY for (some of) the reasons outlined above.

The title of the post is literally “I love my Gitea”.

The content of them meme does conflate “git” with its various frontends (like gitea), but it’s an incredibly common misnomer so who cares?

The person I responded to then went on a weird rant about how “git by itself is distributed” which is completely irrelevant to the point since OP’s Gitea provides a whole lot more.

You’re completely missing the point. Even Gitea (much simpler than GitHub, nevermind GitLab) is much more than a git backend. It’s viewable in a browser, renders markdown, has integrated CI functionality, and so on.

Even for my meager self-host use-case, being able to view markdown docs in the browser is useful from time to time, even on my phone.

As for the things I use (a self-hosted) GitLab instance at work for… that doesn’t even scratch the surface.

Immich saves pictures on the filesystem, where they are easily picked up by all my backup solutions. My pictures also get uploaded on NextCloud before being moved to Immich’s auto-upload folder.

… Where exactly is the risk for my precious memories? The bloody thing could rm -rf /* for all I care.

I seldom care to manually interact with it, but by god do I hate when it’s so narrow, low-contrast, and auto-hiding as to be virtually invisible (and I’m not even visually impaired!).

I want to know where I am, and how long the document is. Why are modern GUIs trying so hard to hide this information from me while pretending they aren’t, like a child stubbornly avoiding eye contact when the teacher asks a question?

I’m sure that there are tools to automate some of the work, but my understanding is that in most cases modelling artists want some kind of control over the generated LODs to ensure they don’t look like shit. Removing vertices on a 3d textured object is not nearly as simple as scaling a 2d picture as far as I understand it. You need to avoid mismapped textures, clipping vertices, the wrong missing details causing obvious pop-in, etc. A triangle in one place can be redundant but another triangle elsewhere may be a critical detail whose removal will be obviously missing from a distance (for example if you model the white house, you really want to keep the small flagpole up top at ALL levels of detail, but automated systems might remove it).

TBF part of the problem is that modern graphics cards mostly can shrug off insane amounts of geometry and badly optimized models, so management must have heard “high prio but not strictly blocking for release” and said “put it in the backlog” (aka “lmao whatever nerd I don’t care then, please focus on Marketing’s feature list happy please and thank you”).

BMW’s is alright IMO. Unorthodox in its layout but it actually works well with the center console knob thingy and has historically been low-latency even back when every other manufacturer had a 2 second delay for every action on their awful touch screens.

Of course even BMW’s system is still going to end up being an overly expensive Android Auto/Apple CarPlay launcher because what people want is Waze & Spotify, not random traffic updates from last week & DAB.

Game dev is not my wheelhouse but from what I gather in the article it is supposed to do some things better but the engine features (HDRP, DOTS, etc.) are still missing important features that led to a low of low-level re-implementations by Paradox…

However AFAIK game engines will not create LODs for you (and certainly won’t prevent you from using overly detailed models) so that part is squarely on Paradox.

At the end of the day a game engine is like any framework, it can make things a lot faster and easier but will not prevent you from shooting yourself in the foot if you don’t know what it is doing.

You don't own songs on spotify, you merely license the temporary right to listen to them. Therefore the proper comparison is not album sales, it's radio plays.

Now I don't know the average rate for radio licensing, but I'm willing to bet big money that it's absolutely nowhere near $200 for 20 people listening.

Maybe radio is not as cheap as spotify, maybe not, but famously spotify is not profitable so the labels are still to blame regardless.

The ads are really annoying if you streamhop frequently, because almost every time you switch stream you have to wait 30s-1m.

I pay for Turbo now so that's fine, but the way it's implemented seems really stupid to me, if you are looking for a stream to watch you sometimes get ad after ad after ad which can't possibly be good for viewer retention.