I think FTE is mostly used as a 'unit'. E.g. if two people work on something 50% of the time, you get one "FTE-equivalent", as there is roughly one full-time employee of effort put in.
Though in this context it just seems to be the number of people working on the code on a consistent basis.
* “Full Time Employee” (which can itself mean “not a part-timer” in a place that employs both, or “not a temp/contractor” [in which case the “full-time” really means “regular/permanent”]) or
* “Full Time Equivalent” (a budgeting unit equal to either a full time worker or a combination of part time workers with the same aggregate [usually weekly] hours as constitute the standard for full-time in the system being used.)
Anecdotally, I strongly doubt this is true, although my environment is probably quite biased. I know a ton of people who use Gnome, some who use KDE, and I think roughly all of these people use them with Wayland. The standalone-WM users I know are also mostly on Sway or other Wayland ones. The only real X11 holdouts seem to be people using X11-only DE's, such as Xfce or Cinnamon.
> I think roughly all of these people use them with Wayland.
While we're making unfounded statements based on our own anecdotal experiences: can't speak for Gnome users (very few in my circle), but for KDE and tiling window manager users, it's a lot of X11. Hard to say exactly, but would put it at ≥50% X11.
Xfce is working on Wayland session support. It is working now with some limitations (limitations on what you can embed in the panel are all that's left, I think).
Pretty much possible to use gnome and x11 (until now).
Personally I have given up with wayland as in years ago. There will always be something I should not have wanted to do in the first place while using wayland. I would rather use x11 and have much better control.
Rumors of Gnome's demise seem greatly exaggerated to me. It's still the default DE in nearly all major distributions, and it doesn't seem to have incurred major mindshare or marketshare hits recently. I feel like most of the 'complainers' already abandoned the Gnome ship with the release of GNOME 3.
Really the only high-profile 'switch' in recent times I can think of is that Fedora promoted KDE to be first-class ('edition') alongside Gnome, instead of delegated to a more second-class spin. And while KDE is a bit more conservative in this regard, I believe that in the long term KDE also wants to go Wayland-only at some point.
Personally I did switch from Gnome to KDE some time after Gnome 40, since I quite liked 3.x but the UI overhaul 40 did wasn't really my thing. It also helps that KDE got a lot better in recent years.
KDE got better some ways, but I would really like to be able to write an applet without learning QML and everything that goes with it. The learning curve feels higher than when I wrote my first Android app.
Where is this Wayland black box then? If anything, Wayland made this situation significantly better: the X11 server was exactly this 'single point of failure black box' you are describing. Wayland replaces this with a much simpler protocol with multiple independent implementations (notably Mutter/gnome-shell, KWin, wlroots-based ones such as sway, and Smithay-based ones such as niri).
I don't think it's true that anything is architecturally or fundamentally broken in Wayland (though if you disagree, I'm very curious what you think is so deeply broken).
Most of the issues and slow adoption were because the core protocol was deliberately kept extremely minimal, and agreeing on all the needed extensions took a long time. Don't take it from me, but rather from KDE developer Nate Graham: https://pointieststick.com/2023/09/17/so-lets-talk-about-thi...
As such, anyone who tried it early probably had to deal with a pretty large amount of non-working stuff, but by now the platform is capable of most features people require and the biggest remaining bottleneck is that software needs to use these new APIs.
Window positioning is one that on its own is sufficient to make me ignore Wayland, as it means that without my own compositor with my own extension, I can't get a file manager that will behave how I want it.
Most people won't care, but for a number of us Wayland is stubbornly refusing to support functionality we see as dealbreakers.
That's fair! I believe that window positioning also works on XWayland, though, so running your file manager that way should still work with the rest of the system being Wayland (and Gnome has no plans to drop XWayland afaik).
I believe the main holdup is a desire for Wayland to be usable with e.g. VR interfaces where there is no simple 2d grid.
Out of curiosity, how do you want the file manager to behave? And did you write your own or are you using an existing one that works that way?
It's managing the desktop too, so I'm not sure that'd work unless running Xwayland in "rootful" mode, in which case I might just as well run X.
The VR stuff is a poor excuse - just fail on that scenario. Nobody that cares about window positioning will have an issue with that.
My file manager defaults to re-opening a window for any directory to a previously snapshotted location, like the Amiga Workbench did. And, yes, I wrote my own. It's a few hundred lines of of a quick and dirty Ruby hack talking directly to a pure Ruby X11 binding, which is anothe reason I stick with X - I can throw things together quickly for X. The amount of ceremony, or big additional dependencies, needed for Wayland is ridiculous.
The only file managers that run on Wayland are the weird "flat" kind with "is" that prevent you from doing anything that didn't match their poorly conceived use cases
Do you have more specifics? I just tried it on my machine (Fedora 42, Plasma 6.5.1 Wayland, Konsole 25.08.2, Radeon 780M) and it seems fine for me. Does it only occur occasionally/under specific circumstances for example?
What is broken for you? At this point, starting from roughly KDE 6, Wayland has been pretty much flawless for me. KDE 5.27 was pretty much fine already as well.
Just installed fresh and logged in to Wayland. Sudo password stopped working. After fixing that it kept opening some window and refused to close. Even without those bugs none of the accessibility tools work.
Fractional scaling is awful on Wayland if the application relies on XWayland to work. Drives me up the wall having to find the various flags to force Wayland mode.
Not sure if ditching infinity cache/L3 for a bigger L2 would make sense. It seems at least plausible to me that growing the L2 cache that much would make its latency worse, thus losing most of what has been gained. In the image you linked, Nvidia's L2 latency is like twice as high as AMD's!
Keep in mind that the 'big' desktop chips have bigger caches too. The L2 on a 5080 and 'L3' on a 9070 XT are both 64 MB. Additionally, AMD has already been growing the L2, going to 8 MB on the 9070 XT vs. 4 MB on the 7800 XT and 6800 XT.
To clarify, the idea that AMD is ditching IC is not mine, I find it puzzling too.
Their marketing materials to OEMs have been leaked, and they no longer mention IC at all, instead proudly displaying (much higher) L2 amounts per GPU. This of course doesn't necessarily mean that they are definitely removing it, but it certainly hints at that.
Well, sure, but from what I know, humans are way better at following 'implicit' instructions than LLMs. A human programmer can 'infer' most of the important basic rules from looking at the existing code, whereas all this agents.md/claude.md/whatever stuff seems necessary to even get basic performance in this regard.
Also, the agents.md website seems to mostly list README.md-style 'how do I run this instructions' in its example, not stylistic guidelines.
Furthermore, it would be nice if these agents add it themselves. With a human, you tell them "this is wrong, do it that way" and they would remember it. (Although this functionality seems to be worked on?)
Out of curiosity, how much of the 138K LUTs (as well as other resources like BRAM) are in use here? I wonder if there's much room to add fancy peripherals, or perhaps "growing" the CPU to achieve better IPC.
It currently uses 44% of the LUTs and 59% of the BRAMs (out of 340 × 2 KB blocks). The chip itself is fairly large and inexpensive, though performance leans toward the lower side.
Though in this context it just seems to be the number of people working on the code on a consistent basis.
reply