For you and anyone else curious to find something similar to Foobar2k on Linux, there’s DeaDBeeF. I used to use it way back before I switched to ncmpcpp

That’s slightly more reassuring. The store page sure makes it seem that way. Glad they clarified.

I was going to give it a try, but there’s no way I’m making an Epic Games account just to play this game with friends. I’ll pass on this one.

It’s based on mpv. VLC isn’t.

Ultimately, the real comparison is here is just ffmpeg vs ffmpeg, but some people prefer mpv defaults over VLC. Search and you’ll find many many comparisons of the two.

Sure. Discourse is quite popular forum software and it’s written in ruby.

There’s only one day of the year when you can dupe me this well. Well done

“One male returned back into the house. The other male jumped two fences as he was fleeing. When officers located him on the other side of the fence, he appeared to have suffered an injury to his leg,” the police continued. “Officers rendered aid, and he was transported to Grady Hospital, where he was pronounced deceased.”

Just seems really sketchy. He injures his leg fleeing, the police rendered aid, but he still died presumably on the way to the hospital? Sure hope they release some actual details about this.

Strongly agreed. Frankly Blizzard got away with decades of discrimination and harassment to the point where an employee took her own life because of the shitty frat culture that festered in the company. And for all that they essentially got a slap on the wrist, a governor in-pocket, and a merger with Activision.

Nice. This used to be a Saturday-morning title for me. I’d buy it for the soundtrack alone

I don’t develop distributed applications, but Im not understanding how it simplifies dependency management. Isn’t it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

That’s correct. This simplifies the dependency management system because not every distribution ships with every version of every package, so when software requires a version of a package that the distro dosesn’t ship with or have in its repositories, the end user has to either build the package from source, or find some other way to run their software. Flatpaks developers will define the versions of dependencies that are required for an application to run and that exact version is pulled in when the flatpak is installed. This makes the issue of every distro not having every version of every package moot.

Don’t maintainers have to release new bundles if they contain dependencies with vulnerabilities?

They don’t have to, no. But they absolutely should.

Is it because developers are often using dependencies that are ahead of release versions?

Sometimes, yes. Or the software is using a dependency that is so old that it’s no longer included in a distro’s package repositories.

Also, how is it so much better than images for your applications on Docker Hub?

I would say they’re suited to different purposes.

Docker shines when availability is a concern and replication is desired. It’s fantastic for running a swarm of applications spread across multiple machines automatically managing their lifecycles based on load. In general though, I wouldn’t use Docker containers to run graphical applications. Most images are not suited for this by default, and would require you install a bunch of additional packages before you could consider running any graphical apps. Solutions to run graphical applications in Docker do exist (see x11docker), but it doesn’t really seem like a common practice.

Flatpaks are designed to integrate into an existing desktops that already have a graphical environment running. Some flatpaks include the packages required for hardware acceleration (Steam, OBS) which can eliminate the need for those packages to be available via your distro’s package manager.

What this means is that a distro like Alpine Linux that doesn’t have an nvidia package in its repos can still run Steam because the Steam flatpak includes the nvidia driver if you have an nvidia GPU installed.

Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it’s something I should adopt, or if I can continue to blissfully ignore.

¯_(ツ)_/¯ It’s a tool. Use it when it’s useful, or don’t.

They have individual people maintaining over a thousand flatpacks.

I don’t believe this to be the case with Flathub, only the Fedora repo. I’m asking about the wider flatpak ecosystem, not the fedora-specific repo or how it’s setup.

Additionally, if you go to install the real flatpack, Fedora pushes you to use their poorly-maintained unofficial one instead.

I’d agree that seems like a needless hoop at the very least, but my concern is more to do with the growing trend to shit on Flatpaks as an ecosystem, not just this particular instance of Fedora head-assery.

I think it’s decent software and has really solid use-cases, far from unreliable shit at least in my own anecdotal experience. But my experience is limited, which was why I asked the OP to elaborate on actual flaws they see with the Flatpak ecosystem.

cause they’re honestly pretty shit and known to be unreliable.

Can you elaborate here? I’ve had very few issues with Flatpaks and the documentation is pretty thorough. I’m curious what wider issues it has to make the whole ecosystem “pretty shit” and unreliable.

Most AI models need at least 24 but preferably 32.

Where are you getting this information from? Most models that are less than 16B params will run just fine with less than 24 GB of VRAM. This github discussion thread for open-webui (a frontend for Ollama) has a decent reference for VRAM requirements.

This may be an unpopular opinion, but I’ve been preaching to friends for years that FOSS versions of Starbound and/or Terraria would be a big hit.

Nah. When I’m using Zed it’s typically for Elixir/Erlang and I’m usually run debugging tools outside of Zed in a separate shell. When I’m using iex and/or observer I like to use a full screen terminal on a separate workspace/tab than the editor itself

Depends on what device I’m using. On my tower(s), I’m typically reaching for Rider, Pycharm, or Zed. On my laptop(s) it’s pretty much always Helix or Zed. On servers it’s vim 100% baby. I’ve gotten pretty comfortable working with theses tools, so I haven’t really needed to look into alternatives at all.

Sounds like the perfect use case for devenv. I use it in a handful of personal projects and it’s proved to be very useful when swapping projects especially when they require multiple services (eg. postgres, redis, nginx, etc.)

It can be setup as a flake that you can use with nix develop.

There’s options to start services and you can use scripts if you want some easy ways to tear down environments while in the devenv shell.

Hope this helps.

Technically stable, polished gameplay, great aesthetics; but there’s no heart. No passion. Everyone involved was just there for the paycheck. It’s routine.

This is an almost perfect description of modern cinema as well.

In my work organization, we don’t allow pushes from users that have not signed their commits. We also frequently make use of git blame along with git verify-commit. For this reason, we have most new developers at any level create a GPG key and add it to their GitHub profile shortly after they join or organization. We’re a medium-sized FinTech organization though, so it’s very important we keep track of who is touching what.

That said, I can’t see it being all that important to an individual unless they’re very security-focused. For me personally, I have multiple yubikeys and one is meant specifically for SSH authentication and GPG operations including signing commits. Since I use NixOS and home-manager, I use the programs.git module to setup automatic signing and key selection. I really haven’t touched it at all in years now. It was very “set it and forget it” for me.

First result of a search:

Gitorious was a free and open source web application for hosting collaborative free and open-source software development projects using Git revision control. Although it was freely available to be downloaded and installed, it was written primarily as the basis for the Gitorious shared web hosting service at gitorious.org, until it was acquired by GitLab in 2015.