We have to investigate if Windows and or Apple had their fingers init.
At hindsight it seems such a stupid decision to fragment a small comminity by designing such a small protocol instead of revamping the existing X protocol to sane security stamdards
X11 was an unmaintainable pile of legacy mess, Wayland was its exhausted developers starting from a blank slate with tons of lessons learned the hard way. It's not a cabal or a conspiracy, just a sensible evolution.
It's a pattern that I have seen a few times before, "I know! We will do the exact opposite of the problems with the previous project!" - but that's not ideal neither.
I don't have a horse in this race, but I also can't blame the Wayland designers for not rushing to implement something like that. Encouraging application developers to manipulate windows themselves essentially means turning them into window-manager developers, but with a hand tied in their back and probably little interest in doing it thoroughly. I think the practical results speak for themselves: I cannot count a single application that does it extensively and that isn't broken in the typical multi-monitor cases you find in the wild.
Well, in Wayland, the same apps just don't work at all. The developer basically has to rewrite them and turn them into different apps to make them work in Wayland. Is that good or bad? Maybe if you hate a certain type of app it's good, but this is the open source world and if something doesn't hurt anyone then you should probably be allowed to do it. It's not the display server's job to rule by fiat. It might be the window manager's job, but only if the application-provided coordinates don't work, or you're using something strict like a tiling WM.
> The developer basically has to rewrite them and turn them into different apps to make them work in Wayland. Is that good or bad? Maybe if you hate a certain type of app it's good
Just to make the record straight, it's not about "hating" anybody or anything. And I really don't see the need to appeal to emotions here.
It is about acknowledging that this way of doing things might, in retrospect, have been a bad idea all along and represents a technical dead-end. Departing from it, given the chance, is for the benefit of all in the long run (tech doesn't like carrying old bags around forever, and I suspect that your laptop don't hold a CD-ROM drive for similar reasons).
> if something doesn't hurt anyone then you should probably be allowed to do it
It would cost the Wayland compositors developers extra effort to maintain this capability for decades to come, it's not free. Moreover, those apps would still be broken by design (not in a position to do as good a job at positioning their windows as the compositors would do), so the compositors developers would, as a second order of annoyance, probably see their issue trackers filling-up with user complaints that are outside of their scope/power to address.
> this is the open source world
And the great news here is that those entrenched apps who refuse to adopt more modern UX paradigms (for the detriment of their old and new users alike, if I might say) will still be able to run through XWayland virtually forever.
Yep, on Gnome we have both eog and GIMP that support webp completely, and have for many years. I don't think I've even tried with other apps but haven't needed to. I didn't even realize this was a problem for some platforms
Traces have a very specific data model, and corresponding limitations, which don't really accommodate log events/messages of arbitrary size. The access model for traces is also fundamentally different vs. that of logs.
There are practical limitations mostly with backend analysis tools. OTel does not define a limit on how large a span is. It’s quite common in LLM Observability to capture full prompts and LLM responses as attributes on spans, for example.
> There are practical limitations mostly with backend analysis tools
Not just end-of-line analysis tools, but also initiating SDKs, and system agents, and intermediate middle-boxes -- really anything that needs to parse OTel.
I know the spec says the default AttributeValueLengthLimit = infinity, but...
> It’s quite common in LLM Observability to capture full prompts and LLM responses as attributes on spans, for example.
...I'd love to learn about any OTel-compatible pipeline/system that supports attribute values of arbitrary size! because I've personally not seen anything that lets you get bigger than O(1MB).
Well yeah, there are practical limits imposed by the fact that these have to run on real systems. But in practice, you find that you're limited by your backend observability system because it was designed for a world of many events with narrow data, not fewer events with wider data (so-called "wide events").
OTel and the standard toolkit you get with it doesn't prevent you from doing wide events.
Logging in OTel is logging with your logging framework of choice. The SDK just requires you initialize the wrapper and it’ll then wrap your existing logging calls and correlate term with a trace/span in active context, if it exists. There is no separate logging API to learn. Logs are exported in a separate pipeline from traces and metrics.
Implementation for many languages are starting to mature, too.
No idea about stability on that scale, I don't do support. On my local machine both behaved about the same in the past.
KDE however is way ahead in fractional scaling, buffering etc. Not sure how to measure Wayland support. Do tell though.
>I'm so annoyed by the crowd recommending it.
Well, Gnome's fault. I've been on team Gnome until they've ruined it after Gnome 2 is ended. Can't really use it with more than one monitor these days too.
> If using Win10 or 11, you may find that even with a zeroed floppy or HDD partition when you power off, the partition will be silently formatted just as Windows last remembers it when you reboot, transparently without notice.
I have a USB floppy drive with a known good disk in it. Not sure if a regular 34-pin floppy would be any different. But blanked it, connected to Win 11, and rebooted. The drive seeked on startup, but otherwise it's still blank:
dd if=/dev/rsd1c | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
2880+0 records in
2880+0 records out
At hindsight it seems such a stupid decision to fragment a small comminity by designing such a small protocol instead of revamping the existing X protocol to sane security stamdards
reply