Quoting: GuestOuch, just 2 native games out of 20 :/

Gee, you're really a glass half empty kind of guy, aren't you?

View this comment - View article - View full comments

Quoting: scaineHuh, I'm getting "Confirm your age to watch this video". Almost as if Google don't know that I'm a 50 year old man who's been using their products, including Google Pay, for decades. Despite being signed in to multiple Google products when I visit Youtube, where I'm also signed in. Jesus christ.

Priorities, priorities. They have to concentrate on important things, like knowing if you've recently bought a pair of slippers so they can try to get you to buy a bunch more, even though obviously you don't need them now since you already have a pair.

View this comment - View article - View full comments

Quoting: EduardoMedina

Quoting: Purple Library GuyThat video says "Flatpak is the future". Well, I'm willing to believe Flatpak is (the future of proprietary software on Linux). I don't think it would be such a good idea for every damn application and utility, the open source ones, the main Linux software ecosystem, to be using Flatpak instead of normal package management.

Why not Open Source apps? I use Kdenlive Flatpak and it's very much better than the RPM package I could get (when I was using Fedora Workstation) from RPMFusion, and Kdenlive Flatpak is an official compilation, so if it fails I can report directly to Kdenlive developers.

Many Linux users don't want solutions, they want patches that mitigates things but don't solve anything, because if you don't use Linux typing one thousand of commands per day because of mediocre software available for Linux, you aren't a true Linux user.

I use Mint. I never touch a command line, I can't remember a package ever breaking. Flatpak solves a problem I don't have, by introducing a bunch of bloat. For as long as open source stuff is being maintained, and depends on libraries that are fairly current, normal packaging should be fine.

Closed stuff, on the other hand, typically doesn't get maintained for nearly as long as it may be used. A solution that bundles the libraries it needs with it is going to come in handy. If my old Loki copy of Alpha Centauri had been done as a Flatpak, maybe I could still play it today without masses of workarounds.

View this comment - View article - View full comments

Quoting: ShabbyX

Quoting: Eike

unified save names for PC - MAC/Linux

Yes please!

I mostly play on my Linux box, but sometimes also on my wife's Windows :sad: PC and my father-in-law's gaming box, so that's very handy.

Finally, the cool future has come when someone can play on their *father in-law's* gaming box!

Oh, that's it! Now I have to get my grandson or granddaughter to play a game on my computer.

View this comment - View article - View full comments

Quoting: Guest

Quoting: Peak

Quoting: Guest

Quoting: Guest

Quoting: Guest

Quoting: PeakHopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.

Not sure what one has to do with the other?

Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.

A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.

I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.

Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.

Halo Infinite specifically uses DX12's dynamic rendering, which there is currently a draft to implement in dxvk

I think that refers to dynamic resolution rendering, which is not the same as Vulkan's dynamic rendering extension.

And this is why people should think about names a bit more. I mean, how much stuff is there in any graphics thingie that has something to do with "rendering"? Stacks and stacks. And, how much is there relating to graphics that, you know, move, that's "dynamic"? More like, what isn't dynamic? So like, how many dozen things could you call "dynamic rendering" for what seemed like a good reason at the time?

View this comment - View article - View full comments

Quoting: sudoer

Quoting: SamsaiI highly doubt

well you can highly doubt anything, but the fundamental reason for Arch being a simpler, faster and less dependency-hell-prone distribution are those 2 simple facts, as stated here

In Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.

This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete [External Link]. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019) [External Link].

https://bbs.archlinux.org/viewtopic.php?pid=1956215#p1956215 [External Link]
, the rest like the package manager, the simpler packaging, take advantage of those principles, leading to more efficient code with much less needs and to a faster, cleaner system.
You can find more material with details on the internet.

Quoting: sudoerIMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

Quoting: SamsaiI have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.

regular computer users -you mean Windows users...- will break their systems no matter how many flatpaks they will use, and will continue to feel helpless when they will try to access their file system to find their file from another drive, while the flatpak will be showing them its own cut filesystem.

It's better to tell them 2 simple things to do to maintain their systems than having a holy cluster-mess of ignorant helpless users left in complete darkness and a handful of holy-grail universal packages just adding to the already available ones.

You know, the strange thing here is that you're advocating for Arch and telling me it's the future, but the more I read of what you're saying, the more significantly my impression of Arch is getting worse.

Before your first post my opinion was that Arch was not for me since I'm more a simple user type, but that it was nonetheless pretty cool. As this conversation goes on, I've started to think maybe Arch is actually kind of a stupid idea, and its popularity an artifact of the failure of Linux to make desktop inroads while it continues to dominate various other spaces, so that far too many Linux users are actually computer developers, tinkerers etc. who happen to use some desktop functions. Talking to you, I'm starting to think that if mindsets associated with Arch take hold more broadly, it will actively hinder both wider adoption of desktop or gaming-oriented Linux and the development on the Linux desktop of what most people would consider "usability".

View this comment - View article - View full comments

Quoting: sudoer

Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here [External Link]

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

Waitaminute. So as far as I can tell, that link says Arch always uses just the latest versions of all libraries, and then deals with the problem of applications that might need different versions of a library by just dumping applications that can't keep up.
Well, sure, that's one way to avoid dependency issues, but it's not much use if I want to use that application. And it has nothing to do with either being a rolling release or pacman managing things better. It's just a very ruthless approach to running a distro.

View this comment - View article - View full comments

Quoting: sudoerFlatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.

I don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

So if it was genuinely the case that some particular "rolling release" distro did not suffer dependency hell, it would have to be because of a superior package management system or people doing packaging for the distro just being really good at it. To call things what they are, since there's only one really significant rolling release distro (well, technically Debian but nobody thinks of it that way, particularly not people evangelizing about rolling release distros), it would have to mean either the Arch maintainers just happen to be wiz, or pacman was significantly superior to debs at avoiding dependency issues.

If it's the latter, maybe everyone should just be switching to pacman. But is it really even true that Arch is better at avoiding dependency problems? And are those even much of a deal any more?

View this comment - View article - View full comments

Quoting: ridgeGuess it's time to stop...

To protect your privacy, external media requires approval to load.

Source: bohatala.com

View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

It really is. I've seen a performance of that . . . it is such a downer.

View this comment - View article - View full comments

Quoting: Beamboom

Quoting: GuestDoomsaying that ports are forever destined to be inferior is silly. If it's all about that last bit of performance and not caring about the tech, then why not just use Windows for games and get the 100% experience?

My point was rather that I *only* care about the tech, and not the principles. The perspective is that *technically* it doesn't matter, because in essence the two approaches have more in common than what separates them.

That said, nowhere do I indicate that I think that ports (and I now talk about what I would call REAL ports - porting of the code rather than wrapping it) are forever destined to be inferior. That would indeed be silly. But as long as the market share is as it is today, it makes no business sense to put the resources into full ports. Especially when we add a continued support to the math:

That is one major advantage of using Proton. We are guaranteed to receive the future patches and updates because we are using the main branch. Look at the Rocket League story. At one point it makes no business sense to keep creating patches for a special version of the game for a platform that might at that point only have a good handful of active gamers. We are a tiny segment and must relate to that.

And just to be clear: I speak from a pure technical point of view. Emotionally it would be fantastic to receive the love of a real version built for our platform. But as long as the alternative is as good as it is - and it indeed is good now - I think that the primary driver for semi-optimal ports are more of emotional than rational reasons.

Of course, better, and probably less work technically than a wrapper let alone a port if it's done right, is to write the game to be cross-platform from the start. I guess that's still more work than trusting to Proton, though.

View this comment - View article - View full comments