Ok, so rpm-ostree was the reason. Was not aware suse Lacks this…

They have been a supporter / promoter of KDE for a long time, would seem logical to me that KDE would go with suse.

Wondering why this isn’t built on opensuse.

For what it’s worth, Kent said they plan to drop the experimental flag next year.

Isn’t it actually a privacy nightmare?

https://cybernews.com/security/google-pixel-9-phone-beams-data-and-awaits-commands/

The main reason is that Dbus is not available during early stages of boot. There are many others.

Varlink seems to be better or the same compared to dbus in all except two things:

• json doesn’t handle 64bit integers, it handles 52bit (or 54bit?) (size of mantissa for floats)
• you cannot (yet) list all things connected to the bus

Details here:

https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-

I think this number is overblown. Production useful doesn’t have to mean 1:1.

Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel…

If every OEM starts contributing their drivers in rust, this could move quickly…

Who was the guy that had a lot of pauses with mmmmmm when talking?

Why would they put effort into changing something which works for them with the risk of breaking things?

The sentiment is similar to climate change deniers. Why would we stop with fossil fuels when they work, people have jobs, etc. And why would we risk breaking the power grid?

And as long as that works for them, they won’t actively change anything.

Wayland on gnome and Ubuntu is already the default. It seems to me you have to actively change the default to x.

It would be interesting to see in which scenario x is better than wayland. The only reason I can think of is an (old) Nvidia card. With new Nvidia’s I guess the statement would otherwise be ‘i will not use it until they fix Wayland’

Depends on the timeline.

X crashed way more for me on kde than Wayland on gnome. ‘Never’ is quite the statement.

Right. And I’m interested if there are some legitimate needs for you to run x until it stops working.

Or is this just a revolt?

Why would someone stay with x even though it’s deprecated, architecturally broken and unmaintainable

Until I cannot run software on X11, I won’t switch over knowingly.

Please explain

Maybe check how long it is already going, so it can give you some confidence. Forgejo is a fork of gitea, which is a fork of gogs.

Also, codeberg, a nonprofit from Germany, is supporting development.

https://docs.codeberg.org/getting-started/what-is-codeberg/

The codebase history of Forgejo and its predecessors predates Codeberg. However, since 2022, Codeberg is backing the development of Forgejo as an umbrella organization.

Oh, so it basically displays a remote window manager in the browser? For a moment, I thought it was running the compositor directly inside the browser with extensions or something like that, hahaha.

I saw it basically months ago, so don’t remember 100%. To not say the wrong thing, you can read about the architecture here: https://greenfield.app/pages/design/

Also, here is a video. The dev demonstrated it’s fast enough for gaming https://fosdem.org/2024/schedule/event/fosdem-2024-3219-greenfield-wayland-in-the-browser-an-update/

I agree, all the apps I use run natively on Wayland, but I think there will always be some legacy X11 apps that won’t get ported. So, I think I’ll implement it, but it is definitely not a priority.

While I understand the need for legacy, I also think at some point legacy should be left alone. If it is really needed for some old app to run, VM should do fine. I don’t think missing xorg is ever going to be an issue in 2025+ (well, Electron apps maybe). Yet added and not used features (or seldom used features) is offset with future maintenance burden and/or security issues for no good reason.

This also applies to OpenGL comment. Every code path introduces a maintenance burden. While support of more devices is good, supported devices are super old in this case and the question is - is it worth it? Vulkan drivers should either way be in a better state.

Looks very interesting! I wonder how it works, so I definitely will check it out.

Is super cool, there is a presentation in one of the conferences about it. Architecture is explained somewhere in the docs. Anyway, if you do implement it - this would be a good alternative to https://guacamole.apache.org

Who knows, maybe it would be a money opportunity.

Why?

It’s not Microsoft, but actually an open source community running open source forge. Also, it’s way faster to use in browser.

If we are talking ideas, I would propose the following:

• focus on the future instead of the past
  • get rid of everything Xorg (including xwayland). Reasoning: recent app upgrades to gtk4 and qt6 support Wayland just fine. Gnome has it by default, I’m not sure where plasma stands. Few things that don’t work, people can probably live without (like chromium which has Firefox as a working alternative)
  • replace OpenGL with Vulkan (that means get rid of OpenGL completely if possible). Reasoning: things sold in the last 10 years support vulkan.
• not sure what is the state in smaller distros. Maybe it would be good to reach out to LinuxMint, lxqt and others to see what would it take for them to switch. If you could implement needed features easily…maybe they would switch.
• RDP?
• Html? E.g. https://greenfield.app/
• consider moving to codeberg?

I know dropping xwayland and opengl is unpopular, but this is where things are going. It’s on the gnome Todo sometime because as far as I read, there is development for mutter to be built totally without xorg support. Plus they recently switched gtk4 to use New vulkan rendered by default.

Another question came to my mind: how is video processing handled? There were some changes in Mutter and/or gtk4 so it would be efficient, any chance for louvre to have it?. E.g. https://www.phoronix.com/news/GNOME-46-Beta-Released

This looks awesome.

Looks like it could be a very good alternative to mutter and kwin.

Questions:

• what about Vulkan instead GL? Should be more performant and use less battery. Especially if it is meant to also work on mobile.
• is Louvre drawing those window decorations?
• there is some overlap with https://github.com/winft/theseus-ship - any idea for a collaboration there?
• there seems to be a company behind, while I didn’t investigate, are there plans for further development that you would publish, is there a way to influence those plans (suggestions, donations, some other way)
• any plans to make a shell around it?
• it is mentioned that this is a library, but obviously there is a working compositor. Regardless if this is a technology demonstrator, would it be possible to publish a compositor with decent theming and a few distinct layer modes (classic windows with taskbar, windows 8 like, Mac, gnome, ubuntu). I guess many smaller Linux DEs would consider it then…
• how does it compare to kwin/mutter?

It has SJ in the description

Mozilla, partners, and participants will explore threats AI poses to democracy and social justice https://foundation.mozilla.org/en/blog/togetherness-and-solidarity-explore-the-mozfest-house-amsterdam-program/

While somebody needs to do this, somebody also needs to do the browser development. And Mozilla has been neglecting and deliberately decimating firefox market share with stupid decisions. Funding Mozilla meant funding everything else except Firefox.

This way we may get the chance to fund exclusively Firefox and not other nonsense.

Let’s hope this enables direct donations to Firefox and not to some sjw activities or Baker’s salary/bonus