Quoting: GuestIndie devs: port their games to every platform possible, flawless native linux ports.
AAA studios with billions of dollards profit: wE cAn't aFfOrD LiNUx sUpPoRt uwu :cry::cry::cry:

just admit that game industry is full of incompetent useless people managed by greedy billioners. even though you buy all games, you don't support developers. you support upper management's annual paychecks so they buy another yacht size of aircraft carrier

While true on a level we also have to remember that indie devs owns their own games and can make their own decisions. When it comes to AAA studios the devs are not allowed to make any decision like this on their own. And the finance guys that runs the show in AAA studios sees the Linux market as far to little to be worth the effort (compare with say the movie industry where the financiers require that the movie makes 3-4 times the money or they consider it as a flop while a indie movie maker would see anything above production costs as a huge win).

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: F.Ultra

Quoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.

I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.

The same is also true of snaps, Mir, and Unity. Snaps predate flatpaks and have features that flatpaks still lack. Wayland wasn't (and still isn't) a good choice for phones since it's for the desktop. There (still) isn't a convergent desktop environment that will work across phones, netbooks, tablets and the desktop, which was the aim of Unity.

Canonical's problem is that they want to push things forward but don't have Red Hat (IBM now) money.

And they did plan to use Wayland, and if I don't remember wrong they where about to be the first distro to use it (just like they where the first to use Pulse) but then they discovered that it wasn't fully functional yet so they moved that back and started to work on bringing Mir to the desktop instead.

People also tend to forget the sorry state of Gnome 3.0 when it was released that made every distro out there either keep using the old Gnome 2.0, switch to something else or create something new like MATE or Unity.

And now again people are up in arms because some variant of Ubuntu will not default install flatpack, while it will remain in repos so any one that wants it can install it. Sometimes our community is worse than The People's Front of Judea.

View this comment - View article - View full comments

Quoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.

I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.

View this comment - View article - View full comments

Any one knows how this all works with games like Callisto Protocol where Steam downloads shader caches only for the game to then upon launch to rebuild the shaders anyway, sounds like the two systems are fighting each other and that perhaps the steam shader cache should be disabled for games like this, or does it still help in some way that I don't understand?

View this comment - View article - View full comments

For Ubuntu fixed packages for this was released on 2023-01-16, more info: https://ubuntu.com/security/CVE-2023-22809 [External Link]

Red Hat released patched versions on 2023-01-23, https://access.redhat.com/security/cve/CVE-2023-22809 [External Link]

Debian released patched versions on 2023-01-23, https://security-tracker.debian.org/tracker/CVE-2023-22809 [External Link]

I could not find any info for Arch on https://security.archlinux.org/ [External Link] but it looks from their package database that they released patched versions around 2023-02-10, 2023-02-15

Most others probably follow the releases above as they usually are based on Debian or Ubuntu.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: F.UltraThe problem space here is that both cores are high performance, just in different ways. I mean trying to determine if your thread/application would benefit from a higher clock or a larger cache is something that takes endless long benchmarks in numerous runs for application developers today (to determine which cpu to recommend to the enterprise to run the system on).

I wonder if AI can help with scheduler for that. It feels like prediction problem based on some moving sample input.

AMD are now adding AI chips to some of their APUs, so may be this can even be hardware accelerated in the future.

Possibly

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: F.UltraHow? I cannot think of how a scheduler can know which thread needs larger L3 vs higher clock frequency.

That's my thought too, but I think this so called "big little" issue exists for a while (started with ARM?) and may be there was some work for Linux on that front before in regards to asymmetric cache?

I also wonder what will happen if the scheduler will be unaware of any of that and scheduling will be random. I.e. what will perform better, 7950X or 7950X3D? Some thorough benchmarks comparing them will be for sure needed.

ARM big.LITTLE is a easy problem in this complex problem space. There the scheduler have the "simple" choice of "should this thread run on a high performing CPU or on a low performing CPU", it does this by doing some metrics (which still after all these years are far from perfect). Alder Lake have very similar design but there they added metric collection in the hardware (Intel Thread Director) buf AFAIK this is still far from perfect even in Windows 11 where compile jobs sometimes gets scheduled to the e-cores and thus takes 55min to complete instead of 17.

The problem space here is that both cores are high performance, just in different ways. I mean trying to determine if your thread/application would benefit from a higher clock or a larger cache is something that takes endless long benchmarks in numerous runs for application developers today (to determine which cpu to recommend to the enterprise to run the system on).

My guess is that MS (at this point in time AMD have only talked to Microsoft AFAIK) will simply (if they will do anything at all) try to detect if the application is a game or not and if so run it on the larger cache cores while running everything else on the higher boost cores.

To really benefit here the app/game developers would have to bench this individually and set the thread affinity but the number of combinations in combination with this probably going to be a niche cpu I have a hard time seeing this been done.

I think the most telling of all is that neither AMD nor Intel have any plans what so ever to implement either of these strategies on the server market.

View this comment - View article - View full comments

Quoting: MayeulCI'm surprised, I thought rsync already used rolling hashes.

There's also casync in that space: https://github.com/systemd/casync/ [External Link] (the blog post is quite nice IIRC).

If it's similar but better than rsync, I feel like these improvements should be folded into rsync.

Perhaps semantics but rsync uses a rolling checksum (a variant of adler-32) combined with a strong hash. Casync looks really promising but unfortunately it needs a prepare stage that is probably why it so far haven't seen wide adoption and implementing that in rsync would require a total rewrite so that will probably never happen either (plus I don't think the rsync devs wants that need to prepare the files for transfer), the CDC improvements however should be a great contender for a new version of the rsync protocol/algorithm, just unfortunate that google decided to go NIH instead of proposing this change upstream to rsync.

Anyone interested should contact Wayne at [email protected]

View this comment - View article - View full comments

Quoting: dpanter

Quoting: F.Ultrathere will now be a scheduler problem that is worse than on Alder Lake

Well, a potential problem at least. If it even is a problem at launch I expect it to be addressed quickly, much like Alder Lake was.

How? I cannot think of how a scheduler can know which thread needs larger L3 vs higher clock frequency.

View this comment - View article - View full comments

One huge problem is that on the 7900x3d and the 7950x3d the extra L3 3d-cache is only connected to one of the CCD:s so there will now be a scheduler problem that is worse than on Alder Lake in that it have to decide which thread to give extra L3 to and which thread to give extra potential cpu boost frequency to, which of course is not something the scheduler can do (a thread could very much switch between the two needs as well).

View this comment - View article - View full comments