Why not?
356 karma · joined May 17, 2020
Reproducible can sometimes be a goal, but repeatable is always important.
I do think for this case specifically (base images for a specific distro), they should be reproducible.
If you don't want to use Alpine for whatever reason, you can just write your own javascript, you can use hyperscript, you can use some other inline scripting library.
Mr. HTMX touches on it in one of the essays: https://htmx.org/essays/hypermedia-friendly-scripting/
> when I need to work with json - since I don't control all backend and json isn't really a first class citizen of htmx
yeah, if you can't make the backend return HTML, you're in a worse off place if you want to use htmx.
There's extensions [1][2] for receiving and rendering JSON responses with htmx (though I haven't used them), but I totally understand it starting to feel like a worse fit.
1 - https://github.com/bigskysoftware/htmx-extensions/blob/main/...
Grain of salt too, I'm typically a "DevOps engineer", and I generally lean towards backend development. What I mean to say is that I don't know react and I don't want to.
My understanding of it is that HTMX is a library, whereas React is a framework. With a library, you need to figure out the structure yourself, and that sometimes makes things more difficult since it's another responsibility. This is likely where things fail for the large enterprise apps _not_ using a framework, since structuring the codebase for an enterprise application (and convincing your colleagues to like it) is genuinely difficult and there's no way around that.
> as some people have suggested - perhaps cynically - a simple lightweight replacement of jQuery?
I don't even see this as cynical, I think it's a relatively fair assessment. A key difference is that jQuery has it's own language to learn, whereas htmx is pretty much a few extra html tag attributes.
I'd recommend you just try HTMX out when you have an opportunity to write something small and full stack, you might like it a lot.
In common lisp, you don't need a build system at all; you can `(load "file.lisp")` everything and it should generally just work. But of course, build systems are useful tools, so nonetheless ASDF exists and it's nice enough to the degree that nobody has built a better and more widespread common lisp build system.
Some good trivial examples are in the lisp cookbook:
```suggestion
my_change
```
if there's someone on your team prone to style nitpicks like this, this can often sate them, and it's convenient for you to merge into your branch
Ok, you're obviously trolling here. This is clearly bait. But for anyone else reading this:
NASA's budget for 2023 was roughly $25 billion [0]
For the same year, NASA generated (again, roughly) $76 billion in economic output [1].
Every dollar of funding goes back into the economy three-fold. Doesn't really seem like a waste to me.
Also, NASA's operations in 2023 created/supported over 300,000 jobs to Americans[2]. Again, doesn't seem like a waste to me.
[0] - https://www.nasa.gov/wp-content/uploads/2023/03/fiscal-year-...
[1] - https://www.nasa.gov/wp-content/uploads/2024/10/final-fy23-n...
[2] - https://www.nasa.gov/wp-content/uploads/2024/10/nasa-fy23-ec...
Docker compose also has a "watch" command that can do lots of the the things devcontainers does, and I use it for more simple setups.
The cosmetic items from loot boxes (as well as those attained from normal play) can then be sold in online markets (such as scrap.tf or marketplace.tf) for real-world currency.
This is probably what the primary goal of the bots is. Ironically, the source of TF2's profit for Valve (microtransactions for cosmetics) is also a partial cause for the bot crisis.
It's literally bots/non-human players that stare at the sky and beeline to either the objective or a predefined path. They usually spam music over in-game chat and there is simply zero plausible deniability that this player in the game is a bot. They usually come into a game, and then invite other instances of the bot to the same game, to prevent them from getting kicked (which requires 6 "yes" responses from the same team) and to kick other players from the game. These are the vast majority of bots/cheaters that you see in the game, and they are the primary reason that "casual" matchmaking is sometimes unplayable.
"real" players that are cheating in the game with some kind of aim assist, but it's still a human behind the wheel, are relatively easy to detect and spectate if you're on their team. They typically get noticed and kicked
This is pretty significant, since the 2 different apps are relatively large JVM apps, each requiring ~16GiB of memory
A whole bunch of state such as this is stored in the MySQL database rather than the client/client files, so it's definitely theoretically possible to spawn an NPC of Thrall on the throne in stormwind.
yeah, it's possible to create a new client. It'd be a lot of work, though.
Some people make their own patches for the standard client if they have something they want to integrate. I don't really know much about that, though
There's a lot of people involved, and a lot of various PR's and issues in github. As with most projects, this is where it's a situation that the game is so large and there are only so many people maintaining the project and so many people testing or confirming issues.
The project is a fork of a fork of a fork, for the most part. Much of the code comes from either SunwellCore (parent), or more likely TrinityCore (grand-parent), and over the past few years since the SC fork has been maintenance and bugfixes. I don't think any of the "current" contributors wrote the code that manages the actual game world, for example. My biggest complaint, I would say, is that at times there's a lot of "well this is how we've done it in the past" as opposition to a new feature or pull request
I think I would consider AzerothCore to be as complex as a medium-large monolithic service, I'd say. That's basically what it is, since the client is "off-the-shelf". There's a lot going on in the source code, but it's generally not difficult to figure out where an issue is.
I hope that helped answer your question.
Testing PR's and confirming that the behavior is correct is actually one of the best things people can do to help - that's something we're always short on.
For most of the code, as long as you can justify the change, it makes sense, and it's in line with the style standard, it'll probably not be an issue
The primary differences that come to mind between CMaNGOS and AC are AC's larger and more active community, AC's module system, and CMaNGOS has a relatively good bot (as in, non-human players) system [0].
As an aside, AC does have a playerbots module [1], but my understanding is that it doesn't have the same polish as CMaNGOS's. It's also distributed as a patch to the upstream AC repo instead of a standard AC module, so that can be a pain for some as well.
[0] - https://github.com/celguar/mangosbot-bots [1] - https://github.com/liyunfan1223/mod-playerbots
The largest issue I can think of that actually impacts overall gameplay is the thread system [0]. It definitely works, but currently threat at times isn't given or reduced in the correct amounts. The most common way this manifests is Growl from Hunter pets not properly taking aggression away
[0] - https://github.com/azerothcore/azerothcore-wotlk/issues/5985
A sibling commenter quipped about which quests are bugged and which aren't, but the reality of it is that the vast majority of quests work perfectly fine, including the quests that are heavily scripted (such as the Battle for the Undercity)
AzerothCore's "killer feature" is that it has a module system, where the game server can use C++ code to hook onto events. It's pretty slick and works quite nicely.
One of the things I've been interested in working on is setting up dynamic linking for the modules so it's easier to just download the compiled module and run it with the server instead of compiling the server with the module. The biggest problem I've run into with my implementation for that is the .so for each module ends up being on the scale of hundreds of megabytes, which seems incorrect.
> I should be working out the dependency story and compiling some driver from Github myself.
no, nvidia _should_ make it easier for people using the 3rd most popular desktop OS to use their hardware. It would make them more competitive against AMD and Intel, which both support hardware video decoding.
That's probably not going to happen, so the next best option is to install a package from the package manager [0]. There might be some kind of compilation needed, but in my experience that's rarely an issue (aside from time), especially if it's coming out of the package manager for a popular distribution.
> It's just not a real option for maybe 99% of PC users.
well, 99% of PC users with Nvidia hardware. It's an important distinction since this problem is specific to Nvidia. If the solution is to installing a package from the package manager, it's only as difficult as installing the browser in the first place.
I do agree there's some extra questions that may make things difficult, or unfamiliar for the vast majority of people, though. Like how is someone supposed to know they need the nvidia-vaapi-driver package anyway?
[0] - https://github.com/elFarto/nvidia-vaapi-driver#package-manag...
there's also so many weird quirks to the projects, it's basically what keeps me coming back.
I contribute to AzerothCore[0] pretty regularly. There's a lot of improvements that could be made, but it's overall fun and the majority of people who frequent their Discord are friendly enough.
I realize the answer is that people use Windows because the software they use requires Windows, but it just irks me that this is the solution to not wanting a "bloated" OS.
In practice, it's pretty normal to use OIDC to authenticate Github Actions to AWS:
https://docs.github.com/en/actions/deployment/security-harde...