#nobridge

  • 1 Post
  • 20 Comments
Joined 1 year ago
Cake day: June 13th, 2023
  • anamethatisnt@lemmy.worldtoLinux@lemmy.ml•Microsoft donates the Mono Project to the Wine team
    896·
    1 month ago

    As in
    “We’ve finished taking all we need from the Mono project and implemented it into our proprietary .NET implementation for Linux, Android and iOS. Instead of getting flack for killing off Mono (which is open source and would’ve been forked anyways) we graciously give this old husk to the Wine project. We recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET. kthnxbye!”

    Good thing that it went to Wine I guess, as they do lots of work to get old Windows programs up and running in Linux and that often involves Mono.

  • anamethatisnt@lemmy.worldtoAsklemmy@lemmy.ml•Need help picking out a heating solution for the winter.
    10·
    2 months ago

    Info that could help others help you:
    House or flat?
    Renting or owning?
    How large an area do you need to heat?
    How many rooms?

    Temperature and savings:
    Where I live they say that a house with people living in it should be at least 16°C (~60°F) to handle the moisture we generate.
    Humans should have at least 18°C (64°F), preferably 20°C (68°F).
    That means that you could close doors and let unoccupied rooms have lower temperature than the rooms you use.
    If you’re stuck with space heaters then you’ll save quite a lot that way.

  • anamethatisnt@lemmy.worldtoLinux@lemmy.ml•Updates from the GNOME (Foundation) board
    9·
    5 months ago

    For details follow the link. This is nothing more than the headlines.

    Finances
    The GNOME Foundation reserves policy says that the buffer is too low to run at a deficit any longer, which it has done for three years. This years budget is a break-even budget.

    Strategy & Fundraising
    A five year strategic plan has been prepared and a draft approved by the board. A variety of fundraising activies will be launched over the coming months.

    Board Development
    More directors are being added to reduce workload on individual board members. Non-voting officer seats will be added for the same reason.

    Elections
    Annual board elections is coming up, 6 seats are being elected.

  • anamethatisnt@lemmy.worldtoLinux@lemmy.ml•I dislike wayland
    11·
    7 months ago

    So the blog has these points listed:

    • Wayland’s client API is gimped. Understandably, any piece of software has limits on its scope. I’m not criticizing that, but the limit on the scope of the Wayland ecosystem is way too small.

    • Wayland’s lack of feature parity with Xorg cripples it. This brief section is now outdated and much to my surprise, the tearing protocol was actually merged thanks to Valve pushing hard for it. The text is left here for historical reasons.

    • Wayland’s render loop design is ridiculous. If you build a client from ground up specifically with Wayland in mind, sure this is easy. But many applications are cross platform and internally driven.
      There’s nothing wrong with an application managing how it should render internally. It’s a natural choice for any program that operates in a cross-platform manner.

    • Wayland’s Mesa implementations are leagues behind Xorg’s. Both the EGL and Vulkan Mesa implementations are, quite frankly, bugged and lacking when compared to their Xorg DRI3 counterparts.
      In EGL’s case, the spec isn’t violated, but swap intervals greater than 1 are completely broken.
      Vulkan is more dire. The indefinite blocking behavior outright violates the Vulkan spec. Giving a timeout in AcquireImage does nothing in practice because the blocking is done in PresentQueue. Only two presentation modes on Wayland actually work: fifo (well this works by breaking the spec) and mailbox.

    • Wayland itself has bad core decisions. The big and obvious mistake to point out is fractional scaling. Update: The fractional scale protocol has been merged, and it’s definitely a step forward.

    • Was it really worth it? We were told all along that Xorg is so bad and terrible that it needed to be started from scratch but at this point people need to be looking in the mirror and asking questions. If that 14 years of effort was instead focused onto solely improving Xorg, what would the result be? Surely, much more tangible results would have been gained at the end of the day.

      I’m not qualified to discuss render loop design or mesa implementations, but it seems 2/5 points has been rendered obsolete in the last 18 months. Progress! :)