I’m not trying to pick a fight or anything, just doing my part to prevent the spread of disinformation and ignorance on the internet. The second paragraph in your comment shows you don’t understand these technologies at all, and I feel compelled to point it out for the benefit of people reading it, so they don’t come away misinformed.

There are no abstractions here. Containers use kernel features called “namespaces” and “cgroups” to isolate system resources and implement sand boxing. There’s no abstraction layer in the software engineering sense. You might be confused because containers look like virtual machines (which is by design), but they’re not that at all, they’re regular native system processes that just aren’t allowed to see each other. There’s nothing about this that is precluded by “cobbled together e-waste”, except maybe if you can’t install a modern-ish Linux kernel for some reason.

For some perspective, the exact same containerization technology is deployed in production on millions of Linux servers around the world every day. Every wasted second in those environment costs money, and they wouldn’t be used if they were “wasteful” or inefficient.

There’s a lot of misinfo online about Flatpaks and their disk usage. Yes, they include all their dependencies, but so do a lot of other devs who ship software on Linux (and some don’t even bother to statically link them) outside of a system package manager. The name for that is “vendored” libraries. Flatpaks however implement deduplication.

For anyone on the fence who is reading this, some important perspective to have is that, like many old communities, Linux has people who are stubborn/resistant to change. Sometimes that’s a good polocy, sometimes it’s not. In this case, it certainly is not. Look at the growing success of immutable distros (like Steam OS) for proof of that. Android and iOS have successfully deployed a similar model since day one. Linux can’t offer a stable API like win32 for various reasons, but it can do Flatpaks, which comes with the added benefit of secure sandboxing (which win32 lacks). It makes life easier for users, and makes it easier for devs to port their software to Linux.

It is the future.

Don’t knock it till you’ve tried it. History has shown that a system package manager is a very poor solution for distributing software. Anyone who disagrees has never been involved in shipping and/or supporting software on Linux. Nix tries to solve this one way, immutable distros solve it another (IMO much simpler) way.

You can still install software using a traditional package manager via podman or docker. Toolbox and Distrobox streamline this for the common shell use-case by automatically doing things like mounting your home directory, using host networking, etc so it looks/acts like a regular shell. Anything you install in the container works exactly as it would on the host, except you can completely wreck it without breaking your host (just don’t rm -rf your home directory, or anything shared)

Immutability is the future of the Linux desktop.

lmao this is a targeted campaign to fuck with you. Look at people in your circle of family/friends/acquaintances/enemies and you’ll find your suspect. Real viruses don’t do anything as remotely entertaining as this, they just steal your passwords/crypto/etc, ransomware your files, or turn your PC into a botnet for internet spam or mining.

Download a fresh install of debian, flash it onto a usb, and do a reinstall. Use different root/user passwords that you’re certain nobody knows, and ensure you lock the computer whenever you step away. Also, obviously, be careful with what software you’re installing.

Lol imagine getting filtered this hard, and publicly posting it. Some people have a humiliation fetish I guess.

MSVC redistributable dependencies are also a problem on Windows. If you try to run an app built with a version of the MSVC runtime that’s not installed on Windows, you’ll get an error telling you to install it. Microsoft doesn’t ship all possible versions of that with Windows, so users are on the hook to install it themselves (if it’s a big publisher though, they’ll typically include it as part of a installation wizard, and Steam handles it automatically behind the scenes).

make sure it’s compatible with other software you have

Not sure what you mean by this, as wine software is contained within a wine prefix. If you have dependency conflicts within a wine prefix, you can just create a separate one. Apps like Lutris make this easy to do via a GUI, and they even have community sourced installer scripts for well-known software that automates installing dependencies (like MSVC, fonts, or other bullshit you’d normally have to get through something like wine-tricks).

Another reason to use Linux is to spare yourself the Windows CMD prompt syntax

Rug pulling a blog service? Seriously? Any first year student can make something like this. The name/brand is probably the only part that’s remotely valuable, and a rug pull is a good way to fuck that up.

With old hardware, beggars can’t be choosers. I get the appeal of the nouveau driver, but if your goal is to save a machine from the landfill, it’s probably the better compromise to use the proprietary driver and keep it actually competitive for as long as possible. Those 900/1000 series cards are still plenty powerful today, even if they can’t quite do AAA gaming anymore.

Bazzite. Every other recommendation is wrong.

Bazzite is “immutable”. What that basically means is that you won’t be able to break it even if you try. And if it does break somehow (for example, because of a bad update), you can fix it by doing a rollback, which is literally a one-line command: sudo rpm-ostree rollback

Sure, there are other immutable distros out there, but Bazzite is probably the most popular right now, and it ships with Nvidia drivers so it’s ready to go for 99% of people with no changes necessary.

being inserted automatically.

Aka the entire point of RAII

This non-sarcastically. The operating system is better at cleaning up memory than you, and it’s completely pointless to free all your allocations if you’re about to exit the program. For certain workloads, it can lead to cleaner, less buggy code to not free anything.

It’s important to know the difference between a “memory leak” and unfreed memory. A leak refers to memory that cannot be freed because you lost track of the address to it. Leaks are only really a problem if the amount of leaked memory is unbounded or huge. Every scenario is different.

Of course, that’s not an excuse to be sloppy with memory management. You should only ever fail to free memory intentionally.

Software. It’s a phone that can’t make phone calls, with a camera that can’t take pictures. It doesn’t matter if some coding genius manages to port Crysis to it, if the phone can’t phone, it’s DOA.

I haven’t used it that much (never even done a jam with it). The weird licensing of the editor rubs me the wrong way, and IIRC it even has some telemetry enabled by default. That’s kind of a red flag when you consider the engine came from King, a mobile game developer. I don’t think I want to trust them, but other people might not care.

But I do like the design of the engine. Message passing is actually a great pattern in general, and it’s used by other engines like O3DE to great effect. It does take some getting used to though, and I personally never was a fan of Lua. If you’ve ever done any Objective C or Swift, it’ll be familiar. It provides a way to build decoupled systems effortlessly, and long-term keeps your codebase flexible and maintainable, which is exactly what you want for a game that needs to constantly evolve its design throughout development.

based on my anecdotal experience your comment sounds rather biased.

That’s called an opinion. Usually, you can identify those when someone writes something like “I don’t like it”

Godot’s easy to use, that’s its strength. Past that, it is riddled with issues. A lot of APIs are either poorly designed, half-implemented, or outright broken. The engine has terrible extensibility support due to a shitty build system, which is why you need to download a separate build of the engine if you want C# support. Third party native plugins like Spine also require a custom build of the engine to deal with this (want to use multiple third party “plugins”? Start learning C++ and scons so you can glue them together yourself). The internal organization of the code is sloppy, and while understandable due to it initially being a one-man project, the situation has not improved despite the massive increase in volunteers and money it has had over the years. There’s a lot of bike shedding that goes on, and leadership doesn’t seem to have a clear vision of where to take the engine.

GDScript sucks. The events system sucks. The hierarchical entity design sucks (although the nestable scenes helps smooth that over). Godot physics sucks. Jolt physics is better, but the integration sucks (Try making joints. The only reliable one is the 6DOF joint, but that requires you to fiddle with dozens of parameters to try and achieve what you want). A lot of the rendering features suck and/or are broken, even basic things like static lighting and shadowmaps fall apart with basic geometry. Everything is buggy as hell, and that’s something you just need to accept if you’re going to make games with it.

I don’t hate Godot, and I do use it because of its main strength: ease of use. It’s my go-to for game jams and prototyping, and I have used it a lot. But if I’m going to invest serious time/effort into a project, I’m not going to disadvantage myself right out the gate by choosing Godot.

• HaxeFlixel is a popular choice for 2D stuff. You can use it with Tiled or LDTK for level editing. This sounds more like what you’re looking for

• Defold might interest you as it has a full editor built in, though I’ve barely used it so don’t ask if it’s good

• Gamemaker is a classic, but idk what pricing is like nowadays

• Godot will work, but I don’t like it. Once you get past the highly polished editor, everything else kinda sucks