8,809 karma · joined August 13, 2009
Usually things which are "no longer developed" do not have (at least) three implementations in development.
For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.
Of course from a user's perspective all these most likely do not make much of a difference.
For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.
One example would be Free Pascal and Lazarus, while there is some commercial support, the overwhelming majority of the development is community-driven and ironically both have a much better history of preserving backwards compatibility than most open source projects backed by larger companies.
Of course exceptions exist for both situations, but as a general rule i find if some project makes a big deal about the company behind them (or even worse, there is a company with the same name as the project) then i tend to look for more community-driven alternatives.
X11 is backwards compatible, you do not have to "keep up" with its changes.
wlroots seemingly isn't. This is a significant issue when it comes to relying on most 3rd party libraries.
You can avoid this complexity in the base widget class by placing those elsewhere, e.g. FLTK's base widget class[0] is much smaller at around 500 lines of code (+ documentation comments).
[0] https://github.com/fltk/fltk/blob/master/src/Fl_Widget.cxx
Sounds like for many programmers AI is the new Visual Basic 6 :-P
> start bullying everyone else to change their language
Either words matter or they do not. If words matter, then trying to dilute the term is a bad thing because it tries to weaken something that matters. If words do not matter, then the people who "bully everyone" can be easily ignored. You cannot have these two things at the same time.
I do not mind having a license like that, my gripe is with using the terms "permissive" and "open source" like that because such use dilutes them. I cannot think of any reason to do that aside from trying to dilute the term (especially when some laws, like the EU AI Act, are less restrictive when it comes to open source AIs specifically).
Uh, the "Modified MIT license" here[0] for Devstral 2 doesn't look particularly permissively licensed (or open-source):
> 2. You are not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company (or that of your employer) exceeds $20 million (or its equivalent in another currency) for the preceding month. This restriction in (b) applies to the Model and any derivatives, modifications, or combined works based on it, whether provided by Mistral AI or by a third party. You may contact Mistral AI (sales@mistral.ai) to request a commercial license, which Mistral AI may grant you at its sole discretion, or choose to use the Model on Mistral AI's hosted services available at https://mistral.ai/.
[0] https://huggingface.co/mistralai/Devstral-2-123B-Instruct-25...
You can also run a Forgejo instance (the software that powers Codeberg) locally - it is just a single binary that takes a minute to setup - and setup a local mirror of your Codeberg repo with code, issues, etc so you have access to your issues, wiki, etc until Codeberg is up and Forgejo (though you'll have to update them manually later).
Hell, those that did leave Twitter did it to move to Bluesky which is basically Twitter under a different banner.
Even if people move away from specific instances of some form of technology (like Twitter, Bluesky, Mastodon or whatever) they are not necessarily moving away from the idea/tech iself (like microblogging in this example).
Same with other social media: notice how after "Reddit gone shit" the people who felt like that and did move away didn't move back to forums or whatever, they went to Reddit-like boards like Lemmy.
The part i found neat was that i used a local LLM (some quantized version of QwQ from around December or so i think) that had a thinking mode so i was able to follow the thought process. Since it was running locally (and it wasn't a MoE model) it was slow enough for me to follow it in realtime and i found fun watching the LLM trying to understand the language.
One other interesting part is the language description had a mistake but the LLM managed to figure things out anyway.
Here is the transcript, including a simple C interpreter for the language and a test for it at the end with the code the LLM produced:
https://app.filen.io/#/d/28cb8e0d-627a-405f-b836-489e4682822...
It even had the original XUL-based DownThemAll version, got disabled after XUL addons were disabled and some time one or two years later it got re-enabled again after the dev released a webextensions compatible version (sadly with several limitations, but still useful for bulk downloads).
Amusingly, there are a couple Windows absolute paths in there even though this profile has been on Linux for a few years now :-P
It isn't like this is the original WinXP during the era where computers connected directly to the open internet and caught viruses just by existing, making computers groan and being very visible that something was wrong. Pretty much everyone is connected via a firewall and on top of that Windows has improved its security considerably over the years. And there are still security updates for browsers (the main vector for malware by far) that support Win8.x (e.g. Firefox ESR will be supporting Win8.x until next year and people have made Win7 and Win8 compatible builds for modern Chromium).
So it isn't surprising that for all intents and purposes it isn't broken, especially when the alternative is having to change to something that feels like downgrade in terms of UX. From a user's perspective it is a choice between the unlikely potential of something invisible perhaps happening (getting compromised) versus the absolute certainty of something very visible happening (having to get used to a worse UX). Considering Windows still tie security updates with everything else, it isn't surprising that people judge based on what they perceive the most.
Of course the best solution would be to switch to an OS where such choices are not necessary in the first place. I've been using Window Maker since early 2000s and the UI has remained the same since 1997 when WM was first made, aside from the occasional theme change (which is done only whenever i personally feel like it, i.e. is not forced on me) while at the same time i'm using the latest Linux kernel, C library, drivers, etc with all security fixes. I do not have any choice between having security fixes or using a GUI that i am comfortable with - i get to have both.
Remember that Blender was opensourced was because it failed commercially. Its commercial background is completely irrelevant to its success - which took years to achieve and most 3D artists for more than a decade saw it as a toy (undeservedly IMO because even by 2.44-or-so it became very capable, but the UI despite its massive improvements was still very undiscoverable and alien for most users).
You can download "Blender Publisher 2.25" from blender's own site which was the last commercial release to check it..
I use both on Linux via Firefox (their tabs are pinned side by side). I prefer Teams because:
a) Slack constantly forgets my credentials and i need to go through a whole dance of logging in, proving i'm human by clicking bicycles, having it email some code. Pretty much every day.
b) Slack, for some reason i cannot fathom, randomly switches me to "do not disturb" mode (or something like that) even though i'm right there. Not even away: it switches to a mode where i do not receive notifications when someone messages me. Fortunately it still does the beepy sound and i do keep the tabs visible on my screen all the time so i actually do notice messages, but i had at least a couple of questions from others why i am in that mode.
c) Slack does not support audio calls. Not sure why, but it doesn't work in Firefox. Teams does work just fine. Fortunately all work meetings are done via Teams and all people on Stack are also on Teams so if someone wants an audio call we use Teams, but still, a negative for Slack.
The only issue i had with Teams is that its text input can get confused when typing `backticks` and it seems to dislike using emojis at any place except the end of the text. Also Slack has some (old) meme emojis, though if that is a good thing or not depends on your taste :-P.
I put in the URL for a project of mine in Codeberg and didn't seem to be able to do anything - i expected that it'd go clone the repository, parse the code and attempt to tell stuff about it, but all i got was an error :-P.
However 99% of the times i use this isn't because i need an accurate summary but because i come across some overly long article that i do not even know if i'm interested in reading, so i have Mistral Small generate a summary to give me a ballpark of what the article is even about and then judge if i want to spend the time reading the full thing or not.
For that use case i do not care if the summary is correct, just if it is in the ballpark of what the article is all about (from the few articles i did ended up reading, the summary was in the ballpark well enough to make me think it does a good enough work). However even if it is incorrect, the worst that can happen is that i end up not reading some article i might find interesting - but that'd be what i'd do without the summary anyway since because i need to run my Tcl/Tk script, select the appropriate prompt (i have a few saved ones), copy/paste the text and then wait for the thing to run and finish, i only use it for articles i'm in already biased against reading.
To play games i use UMU Launcher which is basically Proton minus Steam (or Wine plus DXVK, etc, depending on how you look it at). I use the "raw" UMU Launcher with its own command-line utility, though it can be used as part of Lutris for a GUI-based experience.
Honestly, my SD has seen more use as a stationary PC than a handheld :-P
What i described was about Wayland, GNOME and Gtk specifically, not the entire "Wayland world". Wayland has been a mess that could have been completely avoided if people just tried to fix any issues with Xorg instead of falsely claiming that Xorg cannot be fixed and we'd had proper support for HiDPI, HDR, mixed refresh rate configurations with compositing and all sorts of other nice things at least a decade ago instead of creating a pointless schism in the already tiny Linux desktop ecosystem but ultimately you cannot control what other people spend their time on.
1) Window Maker does not provide anything to any application, if applications need such information they have to use the extension APIs themselves. IF there was an agreed upon protocol for window managers notifying applications to scale themselves, then Window Maker could implement it. But such a protocol does not exist.
2) Window managers do not provide any information there at all since there is no such support. And yes, all Wayland compositors do need to implement that stuff, but because it started from a clean slate and Wayland compositors had to be written from scratch anyway, it was easier to convince developers to do that because they self-selected to go through the effort of making a Wayland compositor in the first place. As i wrote in my original post, the issue here isn't if something would be written or not, but convincing the people who work on the projects. It is mainly a social issue, not a technical one.
3) Yes, without any other support in place, GUI toolkits and other applications can use the information exposed RandR to implement scaling themselves but, as i already wrote, this is a fallback solution because the rest of what i describe is not there. This is far from having robust support, ignores things like custom scaling options, handling moving windows between desktops and support for applications that do not do scaling themselves (which is many of them), among other things.
All of the above are things i already addressed in my original message BTW and again, the issue is not technical but social/political. It is about convincing people to cooperate, not if something is technically possible (and let's be honest, it isn't like Xorg's code is written in stone, if something is currently impossible, the code could be extended to make it possible).
Assuming they know what they're talking about and not just parroting whatever they read others mention, usually when someone says that "Wayland does $THING that X11/Xorg doesn't do", this is really a shortcut for "X11/Xorg could technically do $THING, if enough developers and projects cared about it, but that would be a massive undertaking and it is easier to convince developers do $THING if we can control most of the stack to only do $THING in one particular way we want by working from a clean slate".
Since you mentioned environment variables, not sure what SDDM exactly is doing, but in the case of HiDPI scaling under Xorg the only method for HiDPI i'm aware of that uses environment variables is Qt's `QT_SCREEN_SCALE_FACTORS` which is a semicolon-separated list of per-screen scaling factors that Qt applications can use to automatically scale themselves depending on the screen the window/application is in. Considering SDDM is written in Qt, i'll guess that this is what it set.
But the thing is, this is far from enough if you want "robust" support under X11/Xorg. The reason is that a typical X application under a typical X desktop has multiple components: an X server (which i'm going to assume it is Xorg for now - other X servers are basically Xorg forks and sync with its features), a window manager, an optional desktop compositor and a widget toolkit on the application's side (not strictly needed as an app can use its own adhoc code for that but let's assume it uses one since this doesn't really matter in this case).
The behavior you need for robust HiDPI support is for the application to use the proper scaling for each of its toplevel windows depending on the connected output the window is in (note: this may or may not actually be relevant to DPI - someone may have bad eyesight and want their 27" 1440p monitor to be 150% scaled) and have that be done automatically - ideally, transparently from the user's perspective - as they move windows between outputs and/or add/remove outputs (e.g. connecting/disconnecting or turning on/off a graphics tablet with an embedded monitor would add/remove an output).
Now, technically, Xorg does provide the necessary core functionality to implement the above, however the issues begin when you start considering who is going to implement it and what part of the stack is responsible for which aspect of supporting window scaling.
Ideally, what you'd want is for applications should be able to scale each of their toplevel windows arbitrarily based on notifications from the underlying system as the user interacts with the application windows (note: this is not necessarily limited to just the user moving windows between outputs - a user could, for example, select an option from their window manager to scale a window at 200% or 300% - this could be useful when doing video streaming or recording videos for example).
So, in an ideal world, the following should happen under X11/Xorg:
1. Widget toolkits can scale their widgets arbitrarily (ideally not just at fractional level but also sub-100% level too - useful when using secondary screens with a low resolution).
2. Window managers can receive RandR events for output DPI changes and use that information to maintain a scaling factor for each output (the user could also specify custom per-output scaling too).
3. As the user interacts with the windows, the window manager sends notifications to the windows/applications whenever a window needs its scale changed. The widget toolkits use these notifications to scale their windows' contents.
Ignoring a few details, the above is basically what Wayland does since it started from a clean slate where they could dictate everything from scratch.
However X11/Xorg already has a lot of software already written for it and there are a few snags in the way:
1. Pretty much no toolkit supported arbitrary scaling, so they had to be extended for it. Since Wayland needed that, toolkits that need to support it added the functionality anyway (e.g. Qt and Gtk) though not without issues along the way (AFAIK Gtk didn't support fractional scaling for a long time). Though not all toolkits have support for this.
2. Window managers must be extended to monitor outputs via RandR and send appropriate notifications whenever windows move across outputs to those windows. This would also need some new notification protocol (most likely a new version of EWMH). However...
3. ...toolkits must also be extended to support these notifications - supporting scaling isn't enough if they do not know when to scale. This introduces a problem because...
4. ...window managers will have to deal with toolkits not supporting the notifications. One way would be to just ignore them, but another way is to do the scaling themselves. However, there is another issue here.
5. When using (and having enabled) a desktop compositor scaling can be easy (especially when dealing with edge cases like a window lying across the edge between two monitors :-P), but without one, the window manager needs to scale the window itself (there was a Xorg branch by Keith Packard that introduced server-side window scaling but AFAIK it was never merged) without affecting the rest of the desktop - and of course do the appropriate coordinate transformations for various events (e.g. mouse motion). Moreover since a desktop compositor can be a separate program than a window manager (many -if not most- X11 window managers are not desktop compositors), they both need to somehow coordinate with each other.
6. Since this requires all window managers (and desktop compositors) to be updated, the inevitable result is that there will be a lot of them that will not be updated for quite some time, so applications (or realistically, widget toolkits) will need to also handle HiDPI scaling themselves by doing the RandR queries and automatically sizing their own windows based on output. This is a subpar option because the application does not know the window manager's own state and you can end up with the two "fighting" with each other. Also the window manager cannot do desktop-wide configurations (it is actually blind to them).
7. Obviously whatever protocols in place (as i wrote above, probably a new EWMH version) are used, they'll also need to let the components (window manager, widget toolkit) provide information for when any of the above are in place so the proper action is taken (e.g. a toolkit should not try to do the output tracking itself if the window manager supports it and a window manager should not try to do scaling itself if the widget toolkit supports it - but both need to inform the other about this).
As you can hopefully imagine, the above require the developers of all window managers, all desktop compositors, all widget toolkits and applications not only to coordinate with each other but also handle various cases in case the user used something in the stack that did not support things.
With Wayland since everything was done from scratch, there were less people that needed to be convinced to cooperate - and in practice since Wayland originated from RedHat and the GNOME ecosystem, convincing the appropriate GNOME and Gtk developers to cooperate was probably a coffee break away :-P. Meanwhile Qt would already need to add (or already had, not sure when it was added) support for scaling/HiDPI anyway for Windows and macOS, so the infrastructure was there.
The current situation is that Qt, currently, supports the #6 i mentioned above since it can be implemented without needing support from window managers, desktop compositors or specifying new protocols (something that seems to be much harder than it should be - e.g. AFAIK Cinnamon implemented a very trivial X attribute for displaying a percentage for windows in a taskbar/icon overlay -think of download percentage- but despite the developers' attempt to have others adopt it, i do not think it saw much adoption). But this is really the "fallback solution" when everything else is just not there, it is not the ideal one.
That said, from a technical perspective there is nothing theoretically stopping Xorg desktop environments having top-notch robust HiDPI support. What blocks everything is convincing the developers of the various components of the desktop stack to cooperate, implement and support it.
For example i think the first issue any new user will face is with many codecs not being available in the official repository distros, making various sites (and video plays) unusable. The solution to that one is simple, add packman, which is a community repository that contains all codecs - but IIRC packman is not mentioned anywhere during the install, it is something you need to search for (it is in the wiki). However, packman very often conflicts with the official repos when it comes to updates, making all GUI-based ones (that do not seem to handle cross-repo conflicts like zypper) pretty much unusable as they always give up in the presence of a conflict. And unfortunately some comments i've seen (mainly on Reddit) from people working on the distro seem to indicate at least a minor hostility towards using packman, so i do not see this being solved any time soon.
For an experienced Linux user this is a trivial issue, something that i doubt most (long time) openSUSE Tumbleweed users would even think about, but for someone new to Linux it can be a larger issue they wont find in distros like Debian (though they may find other issues :-P).
There have been other issues i had with openSUSE Tumbleweed, like -e.g- at some point after an update every 3D game had some significant input lag regardless of vsync state. I never solved that one, i just rolled back updates (snapper is great for that, but again an advanced Linux user feature) until at some point -months later- the problem stopped happening. Though now i have another issue where the X server randomly starts not updating the screen for random numbers of milliseconds - essentially it feels as if the entire thing is stuttering - but weirdly enough there are no CPU or GPU usage spikes and it doesn't seem to be relevant to CPU/GPU usage at all. If anything, it does not happen at all if there is some OpenGL or Vulkan program running in a window (so it doesn't affect games at all, just regular desktop use) and sometimes i just end up running vkcube in another virtual desktop (it doesn't matter if the output is visible or not) to avoid it. My guess is that there is some sort of scheduling bug in the modesetting driver as i never had that issue with the amdgpu driver (my guess is the modesetting driver doesn't get as much testing as the amdgpu driver on AMD GPUs), but the amdgpu driver causes the X server to hang after i suspend and resume my desktop since i got a RX 7900 XTX (it did not happen with my RX 5700 XT, which was rock solid), so it is choice between the lesser evil.