I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
I remember Wayland scared me off of Linux when I tried to switch to Ubuntu a few years ago. I couldn’t watch a movie without jiggling my mouse every few minutes. At the time I feel like it was like “yeah that feature doesn’t exist yet” or something. So I switched back to Windows. It looks like there’s workarounds now but I’ve mostly switch to my fantastic M1 MacBook Air at this point.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X
wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.
Xorg is still being under development, there is another fork in development too (XLibre) and you're in the comment thread for a project about a brand new X server written from scratch.
Usually things which are "no longer developed" do not have (at least) three implementations in development.
(i worked a _little bit_ on dwl) each wlroots upgrade is a pretty small diff on the dwl source. the annoying part is, as dwl is configured with patches, every patch author has to update their patch to the new 0.x, as dwl is quite minimal, and thus has no stable api. that being said, obviously, dwm doesn't have this problem :)
also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)
Nearly every Wayland compositor is built on wlroots. Somehow they manage. But yeah, of course it's going to change more than X11, which is older than I am and more or less abandoned...
And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.
And it's C. And it'd mean I would lose my session if I want to make changes and restart it.
What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.
Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).
What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.
I know how to get the audio stream names, the problem is the window titles. With X it's easy, just call xdotool. I'm sure it's probably easy enough on Windows and MacOS too. Wayland is the weird one for making focused window titles privileged information.
Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.
This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.
Wayland is approximately correct in this case and Windows and Mac are behind the security curve for bincompat reasons; window titles certainly leak PII. There should be a way to do it, but it is sensitive information.
Sure, but again there's no interest in actually making a standard way to do it. I can understand it being something that arbitrary applications probably shouldn't be able to access, but that somehow turns into no way to do it, or complete fragmentation where every DE does it with arbitrary differences (or, more realistically, some DEs support it and others don't).
Okay; is there a way to do it? Can I, the user, decide that I do actually want a program to see titles? Or is it still impossible because 17 years isn't enough to implement utterly trivial APIs that people want?
> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.
There are in fact multiple implementations of X and xdotool works with all of them. Typical Wayland advocate, doesn't know what the fuck he's talking about while telling people to just ignore the problems they have with Wayland, probaby because you don't even understand the problem in the first place. Why did you even respond to me? To insult me? To waste my time?
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.
This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.
"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.
You could fork it. X11 hasn't shipped a major release since 2005, the likelihood of a complete overhaul making it upstream was slim to none even in 2009. X11 developers were better-off focusing on stability, and the Wayland devs moved on. There was no conspiracy to kill either project.
So what is it, in one comment you say there were plenty of x11 devs who objected to wayland (please name and show the posts) and on the other hand you say there were not enough to keep an xorg fork going?
People are arguing that fixing the issues in X11 would have been much easier and less work than making wayland. So why could those half of x11 developers who left make wayland while the other half that was left over could not even make one release?
Valve ships a Wayland compositor that just runs XWayland for apps and doesn't even expose the Wayland socket by default. I'm really not sure how we're supposed to count that.
For one of my first jobs I negotiated a better offer because "strings" on the document revealed the previous offer they'd sent out, and made me confident I could ask for more.
Though, makes me wonder if someone has intentionally sent out offers like that with lower numbers to make people think they're outsmarting them.
Your comment explains why we want a travel router. I have a wire guard setup for my servers.
I'm entirely comfortable with setting that up.
But I value my time enough that I don't want the hassle of that for the various devices my family uses when I can just preconfigure and plug in a tiny device and not have them depend on me being in the same location all the time.
UK is not included, but most UK mobile networks have chosen to pretend the UK hasn't to their customers, and offer similar amounts of voice and data in the EEA, so it still mostly works "one way".
The issue with that in terms of the simulation argument, is that the simulation argument doesn't require a complete simulation in either space or time.
It also doesn't require a super-universe with identical properties and constraints.
There's no guarantee their logic is the same as our logic. It needs to be able to simulate our logic, but that doesn't mean it's defined or bound by it.
It's an article that tries to be literature rather than just the information it conveys, and some people don't like that whether it is successful or not.
I'm Norwegian, and the Norwegian stereotype of Finnish people used to be that they are dour and introvert. And we're by and large culturally a lot less outwardly cheerful to people we don't know than the Danes.
Sometimes Norwegian TV would show Finnish dramas while I was growing up in the '80s, and the standing joke was that the typical Finnish drama had two guys hiking through the forest, one of them saying something, and then half an hour more of hiking before the other would reply. I don't remember whether that was accurate (it's not as if I'd have kept watching), but I suspect not.
Really, this. You still need to check its work, but it is also pretty good at checking its work if told to look at specific things.
Make it stop. Tell it to review whether the code is cohesive. Tell it to review it for security issues. Tell it to review it for common problems you've seen in just your codebase.
Tell it to write a todo list for everything it finds, and tell it fix it.
And only review the code once it's worked through a checklist of its own reviews.
We wouldn't waste time reviewing a first draft from another developer if they hadn't bothered looking over it and test it properly, so why would we do that for an AI agent that is far cheaper.
I wouldn't mind see a collection of objectives and the emitted output. My experience with LLM output is that they are very often over-engineered for no good reason, which is taxing on me to review.
I want to see this code written to some objective, to compare with what I would have written to the same objective. What I've seen so far are specs so detailed that very little is left to the discretion of the LLM.
What I want to see are those where the LLM is asked for something, and provided it because I am curious to compare it to my proposed solution.
(This sounds like a great idea for a site that shows users the user-submitted task, and only after they submit their attempt does it show them the LLM's attempt. Someone please vibe code this up, TIA)
It absolutely can, I'm building things to do this for me. Claude Code has hooks that are supposed to trigger upon certain states and so far they don't trigger reliably enough to be useful. What we need are the primitives to build code based development cycles where each step is executed by a model but the flow is dictated by code. Everything today relies too heavily on prompt engineering and with long context windows instruction following goes lax. I ask my model "What did you do wrong?" and it comes back clearly with "I didn't follow instructions" and then gives clear and detailed correct reasons about how it didn't follow instructions... but that's not supremely helpful because it still doesn't follow instructions afterwards.
It increasingly is. E.g. if you use Claude Code, you'll notice it "likes" to produce todo lists that rendered specially via the TodoWrite tool that's built in.
But it's also a balance of avoiding being over-prescriptive in tools that needs to support very different workflows, and it's easy to add more specific checks via plugins.
We're bound to see more packaged up workflows over time, but the tooling here is still in very early stages.
Tell it to grade its work in various categories and that you'll only accept B+ or greater work. Focusing on how good it's doing is an important distinction.
Oh I'm not at all joking. It's better at evaluating quality than producing it blindly. Tell it to grade it's work and it can tell you most of the stuff it did wrong. Tell it to grade it's work again. Keep going through the cycle and you'll get significantly better code.
The thinking should probably include this kind of introspection (give me a million dollars for training and I'll write a paper) but if it doesn't you can just prompt it to.
Think of it as a "you should - and is allowed to - spend more time on this" command, because that is pretty much what it is. The model only gets so much "thinking time" to produce the initial output. By asking it to iterate you're giving it more time to think and iterate.
reply