all 27 comments

sorted by: hot top controversial new old
[–] 17 points 6 months ago (1 child)

Once Linux becomes the premiere platform for gaming, the kernel will be expanded to make gaming faster. I see no problem with this.

  • source
  • hideshow 1 child comment
  • [–] 25 points 6 months ago (24 children)

    there's a disgusting implication that Linux is stealing code from Windows to implement APIs from this title

    I can't wait to get rage baited about it from my windows using friends

    "Linux is only doing good now because they're copying windows APIs into the kernel!"

  • source
  • hideshow 24 child comments
  • [–] 14 points 6 months ago (23 children)

    I mean...the code isn't copied but the design is and it honestly frustrates me. Like yes Linux performance is improving...but I personally don't like adding kernel functionality specifically for the benefit of wine

  • source
  • parent
  • hideshow 23 child comments
  • [–] 24 points 6 months ago* (2 children)

    The game supply is built against those APIs. If games are to be played on Linux it is necessary to adapt to the games until Linux is big enough that games change for us.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 6 months ago (6 children)

    I honestly welcome it. It brings up a lot more than just games in the future like MCAD and maybe even more creative apps.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 2 points 6 months ago (5 children)
  • [–] 3 points 6 months ago (4 children)

    CAD software for Mechanical design (mechanical engineers use it to design motors and transmissions and other machinery).

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 6 months ago* (3 children)

    interesting, worked in cad/cam and arch viz but never ran into it called mcad. always specific applications like catia or autocad, onshape etc.. assumed it was an application name

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 6 months ago (10 children)

    Why? Lots of people are using wine.

    That's like saying we shouldn't be including modules for reverse engineered hardware that only benefits that company

  • source
  • parent
  • hideshow 10 child comments
  • [–] 1 point 6 months ago (7 children)

    No, that's not quite the same thing, I fundamentally don't think it should be Linux's goal to be a good windows emulator. It's fine if wine exists and people use wine for that, but I don't think that should be a goal for the kernel, this starts pushing into that territory. Hardware support very much is the Kernel's job and modules which benefit it should be there if it's meaningful

  • source
  • parent
  • hideshow 7 child comments
  • [–] 2 points 6 months ago (6 children)

    Except this is a scheduler issue from my understanding.

    You can make the argument to put everything into user space, but it's a performance issue.

    One of the growing huge applications of linux these days is gaming, which depends hugely on performance, and almost every gamer out there is likely using wine (generally, without even realising it).

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 6 months ago* (5 children)

    It's not a scheduler issue, it's a windows apps do thread synchronization differently to linux apps. Additionally fsync in the vast majority of use cases works just fine, the article notes most performance comparisons are against vanilla wine synchronization, i.e. without fsync or even esync. Regardless I still don't think the kernel should be emulating windows scheduling behavior.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 6 months ago* (4 children)

    Don't compile it in then...

    It's literally that simple.. but yeah, it is sync, you are correct

    We could debate the advantage and disadvantages of a lot of things in the main kernel. There's so much stuff in there that only benefits certain limited applications, and we could make the argument for userspace for almost everything, including a lot of filesystem drivers

    Like it or not, wine and gaming is probably the biggest avenue where Linux is winning on the desktop at the moment (especially thanks to steam). We shouldn't ignore it

    I've been using Linux for at least 20+ years now. And seen a lot of stuff come and go.

    A lot of distros are shipping with ntsync anyway, and, it's something that will definitely get maintained

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 6 months ago

    Also, I grew up trying games like Unreal tournament on Linux.

    At the time, I thought wine was stupid and would never catch up.

    However we're at the point that a lot of games already run better on Linux than windows even via wine.. There are even more opportunities here in the future

  • source
  • parent
  • [–] 1 point 6 months ago (2 children)

    I already don't compile it in...I'm just stating my opinion. I don't think that should be something in the kernel. I complain, but I also do something about it.

  • source
  • parent
  • hideshow 2 child comments
  • 36 comments in c/pcgaming@lemmy.ca view that post
    [–] 147 points 6 months ago (21 children)

    how shit of a software company do you have to be where your own os's software running through a translation layer on another operating system is threatening to run faster than natively on your os. somethings gotta snap.

  • source
  • hideshow 21 child comments
  • [–] 30 points 6 months ago (4 children)

    It's less of a translation layer and more of a reimplementation. But yes, it does demonstrate how shitty Microsoft is that other people can implement its APIs better than it can.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 21 points 6 months ago (2 children)

    a reimplementation built from reverse engineering and documentation that lies, meanwhile microsoft are the ones who should know how it all works, but apparently not.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 36 points 6 months ago (3 children)

    it's not just the software that runs better, in many cases it's the hardware too.

    Take laptop batteries for example. users will state over and over how their batteries last a lot longer when their system is running linux as opposed to windows.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 6 months ago

    It was then that microsoft found out that constant monitoring and stealing every little bit of information while flooding the users with ads and unwanted and unneeded AI is bad for batterylife. Who knew, except everybody?

  • source
  • parent
  • [–] 17 points 6 months ago (7 children)

    Threatening to? When was the last time you used Windows? Maybe you've forgotten just how much of a slug it is for gaming. Hell, just opening Steam can be a five minute ordeal depending on what Microsoft wants you to do first.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 11 points 6 months ago (4 children)

    Sounds like you're not running 32 ssd's in raid 0 😏

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 6 months ago (2 children)
  • [–] 4 points 6 months ago

    yeah switching to Linux is likely a lot less work if you factor in the price of the hardware you need to run games windows 11 smoothly at your current pay per hour(or salary/hours worked)...

    Unless you "need" to play a game that uses "kernel level anti cheat"... then you're SoL... 😞

  • source
  • parent
  • [–] 6 points 6 months ago

    If you count all the aggressive pop ups and prompts and notifications and other bullshit that you can't turn off any time you try to just use your own fucking computer... 10 minutes from power button to game launch. Linux? Less than 2.

  • source
  • parent
  • [–] 5 points 6 months ago

    To be honest, Microsoft's software is running against an API that uses a translation layer to talk to an older API. Multiple layers of this happen before you get to hardware, mostly for compatibility with legacy software that uses the older APIs.

    Not to mention MS have rewritten their frontends for their apps several times and keep them each time.

  • source
  • parent
  • [–] 37 points 6 months ago (1 child)

    Screw Windows! I'm going to make my own Windows, with blackjack, and hookers!

  • source
  • hideshow 1 child comment
  • [–] 28 points 6 months ago (1 child)

    I wonder how they like being on the other side of Embarce, Extend, Extinguish

  • source
  • hideshow 1 child comment
  • [–] 12 points 6 months ago* (3 children)

    Unlike in Windows, in Linux the graphics UI concerns are outside the kernel, so graphics layers sit pretty close to the hardware, so even just from that higher performance was already expected as the adaptor layers such as Wine/Proton improved because the kernel itself is faster and gets less in the way.

    Then, of course, the Linux kernel tends to be developed by people with lots of experience, overseen by people genuinelly at the Software Architecture level of experience and given its architecture benefits from know-how both from the server-side and the front-end sides of software development.

    My point being that the Linux architecture is not only far more mature and controlled by far more experienced people than the Windows one, but it also gets way less in the way of graphics applications trying to squeeze as much performance as possible from the system hence in Linux improving such graphics applications or the adapter layers for them can go further in delivering better performance than in Windows were the kernel becomes a performance bottleneck sooner.

    What we're seeing now is those two effects delivering, especially once the Wine/Proton adaptor layers matured and entered a stage of more performance and stability improvements than feature implementations.

  • source
  • hideshow 3 child comments
  • [–] 5 points 6 months ago (1 child)

    Unlike in Windows, in Linux the graphics UI concerns are outside the kernel

    That's not exactly correct. In Linux kernel talks to hardware and user space driver talks to kernel.

    There absolutely is a kernel driver for AMD and Intel cards. It's just there's very clean separation between userspace driver that exposes APIs to the applications and kernel driver (which is part of the kernel, literally) that talks to hardware.

    This allows inplementing all sorts of APIs without modifying the kernel driver. In principle you could make Playstation or Nintendo switch graphic API driver in userspace and it could work with existing AMD/Intel chips

  • source
  • parent
  • hideshow 1 child comment
  • [–] 6 points 6 months ago*

    Unlike in Windows, in Linux the graphics UI concerns are outside the kernel

    is in the sense that the Linux Kernel isn't in any way form or shape optimized for any kind of graphics features, unlike in Windows. The software design concerns about graphical interfaces are in user space and, as you say, the "kernel talks to hardware and user space driver talks to kernel".

    I don't see how what I wrote is inconsistent with what you wrote: the kernel only delivers access to the graphics and leaves to user space the details of what's done with it, most notably (by comparison with Windows) all the software design concerns from having a graphical user interface - I just described in high-level Software Architecture terms the "why" for the "how" that you described in Software Design terms.

    Granted, with GPUs the complexity is so much more than with traditional systems (such as networking or data stores) that a lot of the performance improvement happens is in the graphics drivers, which is not quite kernel but kernel-adjacent, so it's a little less perfectly split between kernel-space and user-space than what I wrote made it seem.

  • source
  • parent
  • [–] 20 points 6 months ago

    Windows is pretty bad. Microsoft should be split up. If I had the magic powers, its leadership would be stripped of wealth, barred from holding similar positions for life, and have their faces on some sort of wall of shame. Everyone is allowed to throw trash at them, and they have to pick it up.

  • source
  • [–] 10 points 6 months ago* (3 children)

    I always thought it would have been cool if some rogue and disgruntled programmer with the skills to do so, built DirectX and other Windows proprietary stuff natively into a Linux distro illegally.

  • source
  • hideshow 3 child comments
  • [–] 8 points 6 months ago (2 children)

    That actually happened and it wasn't illegal. There was gallium9 project that literally implemented DirectX9 natively in the open source graphics stack.

    But the translation layer was so much easier to maintain and develop that gallium9 was discontinued

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 6 months ago (1 child)

    If it wasn't illegal, it couldn't have been that cool. 🤷‍♂️

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 6 months ago

    Well Wine devs said they won't support that due to amount of code to maintain. At the time that was weird decision since it required passthrugh to driver, not full translation (similar to what now wine does with Vulkan games) but I think in the long term they were correct

  • source
  • parent
  • 13 comments in c/linux@lemmy.ml view that post
    [–] 50 points 6 months ago* (9 children)

    oh wow the third xda post of the year about ntsync. it's been on since November 2025 btw

  • source
  • hideshow 9 child comments
  • [–] 39 points 6 months ago (8 children)

    n'tsync is gonna make everyone say Bye Bye Bye to Windows

  • source
  • parent
  • hideshow 8 child comments
  • [–] 23 points 6 months ago (5 children)

    I thought n'tsync was delayed because when I asked about the release, the devs said it's gonna be May.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 6 months ago (1 child)

    Devs of which project? I thought it was in Kernel 6.14 and wine 11?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 6 points 6 months ago

    The joke:

      oooOOOOOOOOOOO"
     o   ____          :::::::::::::::::: :::::::::::::::::: __|-----|__
     Y_,_|[]| --++++++ |[][][][][][][][]| |[][][][][][][][]| |  [] []  |
    {|_|_|__|;|______|;|________________|;|________________|;|_________|;
     /oo--OO   oo  oo   oo oo      oo oo   oo oo      oo oo   oo     oo
    

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • source
  • parent
  • [–] 20 points 6 months ago

    And its getting better more modern implementations. Not code from the mid 2000s that has been run though dozens of code translations and compatibility layers.

  • source
  • [–] 15 points 6 months ago (1 child)

    I knew the article was going to mention NTSYNC, but is that really it?

    I get that we don't want the argument for compatibility to effectively allow windows to define what the linux kernel has to looks like, but afaik this is one instance. The headline makes it sound like a systemic issue.

  • source
  • hideshow 1 child comment
  • [–] 3 points 6 months ago

    I remember several decades ago when I dug into wine things asynch io was a thing there was a lot of discussion over. Apparently windows actually has a very robust asyncio interface that's emulated with a bunch of epoll and other logic.

    I believe a lot of games did tricks with this and the hacks sometimes had performance costs.

    A quick Google says that's still a thing being worked on and there's a newish io_uring but apparently that has problems. So maybe that's a place we can see improvements in the future.

  • source
  • parent