programmer's definition of "breaking change" for semver purposes: "whatever is breaking my personal use case"

@whitequark *thinks*

Is there a more apt definition?

@mcc you could write down an interface specification before you write the program, and then check adherence to this interface specification

most programmers don't bother doing that! but even those who do, don't get very far, because without machine-checkable interface specifications it's trivially easy to ship a semver-breaking change without noticing. this isn't a great thing!

@mcc also without strong encapsulation, good luck enforcing that your clients actually stick to the interface specification you wrote

@whitequark @mcc do you have thoughts on https://github.com/obi1kenobi/cargo-semver-checks/ ? it tries to do the machine-checking part

@whitequark @mcc See systemd wantonly copy-pasting bits of glibc headers into their tree "because compile times"...

"If it's in /usr/include it's fair game" is apparently the attitude of at least one of the maintainers...

@becomethewaifu @mcc that's cursed. why not use precompiled headers?

@simon @mcc cargo-semver is the closest i've seen anybody come to making semver a technically useful concept rather than just a ritualistic one, but i haven't used it and it also seems _very_ incomplete (no detection of breaking type changes? that is ... usefulness-limited)

@whitequark @mcc preach

@whitequark @mcc yeah i got the impression that the set of rule is a work-in-progress (though it’s been a while since i looked)

@whitequark @mcc this is reminding me that i should probably learn the ATS language someday

@whitequark see also hyrum's law

@glyph @mcc brb, becoming a type of weirdo who puts the entire python module into a big function body and finishes each file with

__dict__.update(f()); del f

@tef yeah

@whitequark @simon @mcc there are very few public tools that do so in any useful manner. restrictive interface definition (languages/DSLs) are the only way this happens for network APIs in practice. *cough grpc*

@whitequark @mcc beat you to it https://pypi.org/project/publication/

@whitequark @mcc (this is not really the best approach and I want to revisit it in light of type checking and several other advancements in the field and the language, but you can see it’s been bothering me for a while)

@whitequark @becomethewaifu @mcc Because there's not actually a performance issue they're trying to solve. It's just ideological about not respecting interface contract boundaries. They did the header flattening for *their own* internal headers, and thereby they should also be allowed to do it for system header ones.

Because see, they're called "system" headers and that means they belong to systemd. 🙃

Obviously.

@dalias @whitequark @becomethewaifu To me if systemd were a good and useful system for whatever it is it does, then it would be nice if I could build systemd for platforms other than linux. by the way, does hardcoding glibc headers imply that building systemd with clang is not possible?

@mcc @whitequark @becomethewaifu I think you're mixing up glibc with gcc.

@dalias @whitequark @becomethewaifu yes, i do that a lot. but same question, does it imply you can't build systemd with musl libc? (it might be the case there is no good reason to do this.)

@glyph @mcc oh this is excellent

i'm probably going to use it for amaranth

@whitequark @mcc I mean if they don't, I consider it someone else's problem. 🤷 🙃

@dalias @mcc this works right up until it doesn't

@whitequark @mcc perhaps you can motivate me to do the stubgen integration and whatnot (remember to like & subscribe)

@glyph @mcc https://github.com/amaranth-lang/amaranth/issues/1614

amaranth doesn't ship type stubs (and mostly doesn't use types) though, so it's probably fine as-is

does it break sphinx?

@mcc @whitequark @becomethewaifu Indeed you can't, without some patching out of lots of gratuitous glibcisms. Some of the systemd devs are helpful and cooperative with the folks who've done that work trying to get it upstream. 👍 Others block & try to reverse it. 🤡

@dalias @whitequark @becomethewaifu you know, i really want to defend systemd from the various extreme attacks on it because i don't think the init.d system it replaced was particularly good and i think some of VFS-y things it does sound useful. but systemd makes this continually hard.

@whitequark @mcc Occasionally I think about trying to make it so that a project's existing tests cannot be changed without bumping the major version number

...though all the projects I currently work on are stuck in version 0.x so I haven't bothered to put too much effort into it

#programming

@diazona @whitequark i would do this, but also if i instituted this rule, and then i found an honest to goodness typo in the tests that would be obvious as both a typo to both me and a user, i would just fix the typo. and then i would break someone's usecase, and they would get angry at me, and they would be right to do so

@mcc @dalias @whitequark @becomethewaifu As with X11 vs Wayland, the old system was terrible but that doesn't mean the replacement isn't also awful in its own way.

@whitequark https://imgs.xkcd.com/comics/workflow.png

@whitequark @simon @mcc java & kotlin both have abi compatibility checkers. It looks like kotlin is bringing it in as a language feature, that'll be interesting.

@azonenberg @mcc @dalias @whitequark @becomethewaifu It's not even that it's awful in itself, so much as systemd developers seem to assume that they're entitled to decide the future of Linux themselves.

For instance, there's that passive-aggressive 'Tainted: unmerged-bin' that 'systemctl status' produces on Debian systems.

@foolishowl @mcc @dalias @whitequark @becomethewaifu Awful project culture is part of "the replacement being awful".

@azonenberg @mcc @whitequark @becomethewaifu This is what always happens when you decide you get to replace contracts other ppl depend on rather than replacing bad implementations while maintaining contracts and offering new optional functionality on top.

@dalias @mcc @whitequark @becomethewaifu yeah personally i would much prefer a from scratch rust x server stack with rarely used legacy functionality removed or replaced by a compatibility layer.

But keeping the same feature set.

@azonenberg @dalias @mcc @becomethewaifu i would absolutely not want to maintain either the awful x11 stack, or the awful init.d stack. the contracts fucking suck. they should be replaced. it's just that they should be replaced by someone who cares more

@whitequark @dalias @mcc @becomethewaifu Fair.

But yes. Providing at least the features people rely on is kinda important.

@azonenberg @dalias @mcc @becomethewaifu tbf this is much less of a problem with wayland because at least you are free, as a DE vendor (KDE for example) to work around all the egregious missing parts

yes, it still sucks for everyone involved, but at least you don't have to do things like "try to patch or emulate a moving target" that nobody seems to be able to do over long timescales

@whitequark @dalias @mcc @becomethewaifu yeah the problem instead comes from app developer perspective where you have to special case all kinds of features that nay or may not be available on a given compositor that might be critical to your system functionality

@azonenberg @dalias @mcc @becomethewaifu as if x11 doesn't already have that problem

@whitequark @dalias @mcc @becomethewaifu i don't think I've ever written code that depended on specific x drivers or window manager features.

But with wayland it seems like a lot of core things like xdg-toplevel-drag are optional features that a compositor can just decide to not support

@azonenberg @dalias @mcc @becomethewaifu an x11 window manager can decide to not support things like "min/max window size", "fullscreen windows", and so on

in fact, my current window manager i3 does that! it does a bunch of stuff that applications which expect gnome or kde don't expect. it causes exactly the type of random breakage you'd expect

@azonenberg @whitequark @dalias @mcc @becomethewaifu i kn ow it sucks.... but tbh this makes it SO MUCH EASIER to do compositors like mine that are in differing form factors!

@whitequark @azonenberg @mcc @becomethewaifu The X protocol is not a burden to maintain. It's basically write once and you're done. A giant volume of software depends on it. There's no compelling reason to replace it.

The init.d contract is only used by systems integrators and distros. Yes it's awful. You can keep a compat layer for it independently if needed but priority is much lower..

@dalias @azonenberg @mcc @becomethewaifu there are plenty of compelling reasons to replace X11 but i'm not really interested in arguing this with you, because you, of all people, ought to know better

@whitequark @glyph @mcc interesting.

I have written my own thoughts on the subject here: https://mkdocstrings.github.io/griffe/guide/users/recommendations/public-apis/. Worth noting: Griffe also let's you find breaking changes from one version of tour code to another, see https://mkdocstrings.github.io/griffe/guide/users/checking/.

I believe `publication` would not be supported by default by Griffe (and therefore mkdocstrings), and would require a Griffe extension.

@technobaboo @azonenberg @dalias @mcc @becomethewaifu yeah, i want to write a proxy that lets you share a window with someone remotely so that both of you have input, and features like clipboard just work

wayland makes this very easy, wl_seat's enable it on the protocol level

x11 does not

@whitequark @mcc nuttx rtos just changed the defconfig options to setup the generic watchdog timeout driver. Old config option disappeared, new default otions result in 10ms timeout. With a 100hz default tick. No doc. No notes. Nothing. Not a breaking change. Board does not boot, of course.

@whitequark @azonenberg @mcc @becomethewaifu But it's stuff some users use, want, and expect to keep working!

@dalias @azonenberg @mcc @becomethewaifu sure. my point is that nobody is in the wrong here: these features never made it into x11 proper (and don't get me started on ewmh), so i3 isn't wrong, but equally the applications can reasonably want to use some standard desktop features, so they aren't wrong either

@whitequark @azonenberg @mcc @becomethewaifu However the important contracts systemd broke weren't that. It was breakdown of where policy is set, and all the other non-init stuff they decided it was entitled to take over, like user account management, homedirs (and rm -rf'ing them), logging, cgroup policy, etc. that previously belonged to user or integrator to setup as they wish.

@dalias @whitequark @azonenberg @becomethewaifu When I look at the difficulties with Wayland deployment, I see the normal kind of consortium difficulty where a group of people made decisions about finite resources by the spec authors and implementors, and the thing holding features back is the least productive implementor (GNOME). I might dislike it, but I have *some* sympathy for the spec authors, and I also see I can implement my own Wayland if I get *really* annoyed about the limitations.

@dalias @azonenberg @mcc @becomethewaifu if you think x11 doesn't need replacing try making a window fullscreen. i dare you

@whitequark @dalias @mcc @becomethewaifu defining a standard set of features that a desktop oriented vs say vr oriented compositor is expected to support, and having many applications only support one of these profiles might be a good start.

(And having the desktop profile include support for things like absolute window layout)

@dalias @whitequark @azonenberg @becomethewaifu With Systemd, the sense I get— every time I look at a decision being made00 is that IBM is implementing arbitrary features in order to drive IBM's product needs. I don't see thought being assigned to use cases originating outside IBM, and often if I step slightly outside IBM's (undocumented, internal) use case the Systemd feature stops working. Moreover, I can't easily reimplement my own Systemd, as it is totalizing by design.

This feels worse.

@whitequark @dalias @mcc @becomethewaifu try launching a file browser from a fullscreen window if you want hell

@azonenberg @dalias @mcc @becomethewaifu i do have sympathy for not having absolute window coordinates in the core protocol because the concept of "window coordinates" isn't well-defined in the first place in presence of multiple monitors with possibly different DPI, and the main use case for getting them (saving window positioning) is _much_ better served in the compositor itself

@mcc @dalias @whitequark @becomethewaifu as an app dev rather than an end user i have to target every popular compositor which is why the fragmentation is so infuriating

@whitequark @azonenberg @dalias @becomethewaifu in certain types of VR, window coordinates may be non-cartesian

😈

@whitequark @dalias @mcc @becomethewaifu the correct solution imo is floating point coordinates in post dpi scaled space that are mapped to pixels by the compositor. The app only cares about visible rectangles on an infinite abstract plane

@mcc @whitequark @dalias @becomethewaifu which is why i said this should be a standard extension for the desktop profile where it's reasonable to assume one or more 2d rectangular displays

@whitequark @azonenberg @dalias @mcc @becomethewaifu wait what how?? i had a bug in gtk where it couldn't handle any combo of seats other than the first seat that must be present at the time of binding the global or input wouldn't work? does that work for you? if so i can overhaul my input code to make it work

@mcc @whitequark @dalias @becomethewaifu and apps that care about absolute window coordinates are free to disable some features or not work at all in vr

@azonenberg yes i understand sorry, it was intended as a "yes, and" comment

@azonenberg @dalias @mcc @becomethewaifu i don't see why ngscopeclient would care about absolute window positioning anyway

@technobaboo @azonenberg @dalias @mcc @becomethewaifu "easy" as in on the protocol level, there are definitely still implementation bugs

@azonenberg @dalias @mcc @becomethewaifu like, right now on my x11 session ngscopeclient cannot, by design, position windows wherever it wants. what breaks?

@whitequark @dalias @mcc @becomethewaifu the main problem is that it means imgui can't implement docking and dragging of or between windows without adding a lot of wayland specific code for xdg-toplevel-drag and adding fallback ux for compositors that don't support it.

Rather than simply assuming the entire display is a rectangle of pixels like every other platform (macos, windows, x11) where you can get global mouse and window coordinates and determine if a window has been dragged into another etc in a platform independent algorithm you write once.

@whitequark @azonenberg @dalias @mcc @becomethewaifu dear imgui's docking breaks.

@whitequark @dalias @mcc @becomethewaifu it's not setting positioning (except when restoring saved sessions) it's knowing relative positions when dragging and docking a dialog or plot in or out of a parent window

@azonenberg @dalias @mcc @becomethewaifu ok tbh this seems fine to me

@azonenberg @dalias @mcc @becomethewaifu that (except) is actually pretty important, plenty of applications break if your monitor configuration changes. as an end user this sucks and making you go through slightly more work to avoid that is probably justified

@whitequark @dalias @mcc @becomethewaifu see for example https://github.com/ocornut/imgui/issues/8587

As an app dev basically it means wayland renders core parts of our application ux nonfunctional in a way i can't easily fix or work around

@whitequark @dalias @mcc @becomethewaifu yeah but in general if I can't restore saved windows it's a very minor impact compared to dragging between top level windows or tearing off a dock becoming impossible.

It basically means you cannot effectively use ngscopeclient on a multi monitor wayland system with different sets of windows on each monitor etc

@whitequark @azonenberg @dalias @mcc @becomethewaifu yeah i think most people can agree that having the desktop actually restore your windows is a good feature, at least those who notice / care. but it's not really in conflict with application control of window positioning (in the multi-window docking / ui sense), it's just complicated by it.

@pawamoy @whitequark @mcc this is the first I have heard of griffe, it does look interesting. I had been idly hoping to add something like this to pydoctor for years, but perhaps we could use this as-is

@azonenberg @dalias @mcc @becomethewaifu yeah so this problem will go away for gnome/kde users when someone implements xdg-toplevel-drag protocol for imgui, at which point you're at the exact same place as with x11, where sway doesn't support it just like i3 doesn't support it

this is an annoyance for you, sure, but neither an architecture nor a governance problem

@dotstdy @azonenberg @dalias @mcc @becomethewaifu mostly i don't trust applications to be able to do it properly: it requires a lot of knowledge about the state of the desktop that the application might not even have, and it's incredibly difficult to do correctly (saying from experience of doing that)

so to me, trying to avoid this issue structurally makes sense

@erincandescent @dalias @mcc @whitequark @becomethewaifu I'm talking about dragging *windows*.

As in, you have a toolbar or something that's within an application, not a WM-managed-window, and you want to drag it out and make it a free floating window, or drag it into another window and make it part of the app window again.

This involves knowing relative positions of all of your app windows, the dragged window, the cursor, etc.

@whitequark @azonenberg @dalias @mcc @becomethewaifu I wouldn't disagree in theory, but given how much pain and suffering it took to get here (and the decade or so of time) I'm not sure I'd really call it a win. Also some users still want programmatic control, which I don't think is unreasonable.

@dotstdy @azonenberg @dalias @mcc @becomethewaifu I think this is basically reasonable yeah

@erincandescent @dalias @mcc @whitequark @becomethewaifu yes, you just need to completely rewrite all of your window management code in a way that is different from how every other OS implements it. Which is a huge headache.

More fundamentally though... wayland released without xdg-toplevel-drag, this is a fairly recent addition.

My biggest problem is that it's being rolled out prematurely, there's still things it can't do that X11 can, and distros should not have been making it default until much further in the future when things were stable and generally at feature parity.

@azonenberg @erincandescent @dalias @mcc @becomethewaifu on one hand, i agree

on the other, making something the default is ... _a_ way of ensuring it achieves feature parity in a reasonable timespan

@whitequark @azonenberg @erincandescent @mcc @becomethewaifu Making users your guinea pigs so you can get your thing made faster is user-hostile behaviour.

@dalias @whitequark @erincandescent @mcc @becomethewaifu yeah that's big-tech-company "move fast and break things" mentality

@azonenberg @dalias @whitequark @erincandescent @becomethewaifu A thing I'd ask is whether Linux distros, in general, have the resources to maintain both X11 and Wayland at a high level of quality. There was probably *some* point where they would have to make an unpleasant decision like this.

However, if this had to happen, I do wish they'd bent over backward to ensure screen reader users weren't in the "oh, it just won't work for you for a while" group. It doesn't sound like they really did.

@mcc @dalias @whitequark @erincandescent @becomethewaifu Yeeeah.

On that note, I would love better screen reader support in imgui since I like the library and would like to use it in other applications.

For ngscopeclient in particular it's a low priority since it's inherently a hyper-graphical application that would be extremely challenging to make useful for people with limited or no vision.

But I can easily see wanting to use imgui for other tools that are more broadly useful, and those might well benefit from better a11y.

But that's orthogonal to the wayland issues.

@dalias @azonenberg @erincandescent @mcc @becomethewaifu so, question.

leaving aside whether it is or isn't (people can definitely opt into being experimented on, and also shipping any software where you listen to feedback is experimenting on your users, so it's not as clear-cut) is this not literally what the entire Linux ecosystem, starting with Linux itself, was founded on?

@dalias @azonenberg @erincandescent @mcc @becomethewaifu the ethos of Linux is "we build shitty software and publish it so that other people who get annoyed at how bad it is spend their time making it less bad". that's how we got where we are, i think. which makes it clearer why we're in this particular situation right now

@whitequark @dalias @azonenberg @erincandescent @becomethewaifu by the way on that note does BSD support wayland at all

@mcc @dalias @azonenberg @erincandescent @becomethewaifu for a while yes https://docs.freebsd.org/en/books/handbook/wayland/

@whitequark @azonenberg @erincandescent @mcc @becomethewaifu No. Nobody was forced to use Linux (despite fedi reply guys trying to do that). Linux has always had "don't break userspace" policy for its existing users, too.

@dalias @azonenberg @erincandescent @mcc @becomethewaifu nobody is _forced_ to use Wayland either. I am not using it right now despite being on the latest Plasma version that ships!

@whitequark @dotstdy @azonenberg @dalias @mcc @becomethewaifu some applications absolutely require this functionality (accessibility inspectors, RPA, HUD applications, games) and wayland does not actually remove the functionality, they just make you implement it 5 different times in terms of 5 different window managers, which means that for these sorts of apps the correct solution is “just make a Windows version and hope Wine works it out”

@glyph @dotstdy @azonenberg @dalias @mcc @becomethewaifu "Wine is broken*" is like the #1 reason i don't switch to Wayland

* except for fullscreen games

@whitequark @azonenberg @dalias @mcc @becomethewaifu

I was at Sun (but not in the Windows group) during the first Windows wars, NeWS was Sun's attempt to 'start from scratch'. When Canonical jumped on the Wayland bandwagon I had hoped we could see a better outcome but too many of its developers looked up to the Win32 API. A small minority of programmers today understand *why* X11 is the way it is. I believe that contributes to them breaking things when they try to reinvent it.

@whitequark @azonenberg @erincandescent @mcc @becomethewaifu If existing software we depend on stops supporting X, or distros we use stop maintaining security updates for existing releases and force Wayland in new version, then yes we are effectively forced to use it. And this especially hurts users for whom it breaks accessibility.

@dalias @whitequark @azonenberg @erincandescent @becomethewaifu Bookworm LTS and Ubuntu 2024 LTS will be supported until 2029. If Trixie+1 and Ubuntu 2026 drop Xorg support, will there be adequate time *by 2029* to resolve all blocker issues affecting discrete communities (e.g., gamers, sight-disabled users)? It seems hard for me to imagine the answer is no.

@glyph @whitequark @dotstdy @azonenberg @dalias @becomethewaifu Speaking as a GNOME user, it seems to me inevitable that an increasing number of apps might just have to say "use the KDE compositor or gtfo", and maybe that's the correct product decision

@ChuckMcManis Yeah, I definitely see "oh, you fools…" decisions of the type you describe in Wayland, but it seems too late to usefully address those foundational issues :(

I am hoping the pit fight around the Wayland extensions ("protocols?") ends with good results.

@feld @dalias @azonenberg @mcc @becomethewaifu ah, "simply do not write code that crashes", from the school of code that gave us "simply do not write memory management bugs". this is hard to take seriously

@mcc @whitequark @dotstdy @azonenberg @dalias @becomethewaifu I am generally a GNOME user for cultural reasons but as a software developer I may switch to KDE and do exactly this, for exactly the reasons you are gesturing at

@mcc @glyph @whitequark @dotstdy @azonenberg @becomethewaifu My correct solution is "use the compositor that just translates to X11 protocol and pretends to be the KDE compositor".

@dalias @mcc @whitequark @dotstdy @azonenberg @becomethewaifu is this a real thing?

@mcc Agreed on the lateness. I sometimes have these philosophical debates about whether truly foundational software infrastructure can be developed without architecture. I started an essay once "There are no Cathedrals to visit at the Bazaar." (because I like puns). But the observation is that the more foundational something is, the more it benefits from a focused gaze.

@feld @dalias @azonenberg @mcc @becomethewaifu it does if you set OnFailure=

@glyph @whitequark @mcc There really is a #Python package for everything lol

@whitequark i hate it when people complain about a patch release breaking things that aren't even following semver and aren't even libraries

@glyph @mcc @whitequark @dotstdy @azonenberg @becomethewaifu Kinda already. There are rootful Wayland compositors that display on X, but I don't think there are rootless ones that seamlessly integrate with X window management yet. It definitely can be done and probably will.

@dalias @mcc @whitequark @dotstdy @azonenberg @becomethewaifu oh, you are talking about continuing to run X. that’s a non-starter for me because I am running exclusively in VMs to address a linux *audience*, not to serve my own computing needs. But if I were using it personally, I would need to see a (non-fascist) committed group of maintainers for Xorg going forward first

@whitequark @azonenberg @dalias @mcc @becomethewaifu yeah but if the apps don't impl it properly you can't do it in practice

@glyph @mcc @whitequark @dotstdy @azonenberg @becomethewaifu You don't need Xorg maintained. Wayback project (WIP by Ariadne who probably doesn't want to be @'d in this monster thread) gives you an X server with an unmanaged Wayland compositor as the graphics and input backend.

@glyph @mcc @whitequark @dotstdy @azonenberg @becomethewaifu https://gitlab.freedesktop.org/wayback/wayback

@dalias @mcc @whitequark @dotstdy @azonenberg @becomethewaifu ah, thanks for the clarification. still not really viable for my use-case but more long-term feasible for a workaround.

@diazona @glyph @whitequark @mcc oh I wanted to share this one too: modul, from Frost Ming, PDM author :)

https://pypi.org/project/modul/

@dalias @whitequark @azonenberg @mcc @becomethewaifu I never had much issue with SysV Init. Back then the shell was a common language, so it made sense to just keep a bunch of shell scripts. It did tend to accumulate hacks over time, but you could generally hack on it yourself. Not really comfortable trying that with systemd, at least beyond writing a few simple unit definitions.

It even had a primitive process supervisor built in, although that capability was hardly ever used for anything beyond spawning tty's.

I really wish that the community in general had decided to go with one of the awesome descendants of daemontools. I've used both s6 and runit and find both really comfortable and easy. My home server runs Void, and administering it is trivial. What I love most is that runit has a clearly defined scope, so it doesn't really change over time. I've never had to tweak things after an update like used to happen regularly with systemd. There's never a moment where I have to re-learn because, ok, we took over something else today and now you do it this way.

@jeang3nie @dalias @whitequark @azonenberg @becomethewaifu Okay, well I don't want to use SysV init. (Not that it matters anymore, but I think what I *really* like is Upstart.)

@mcc @dalias @whitequark @becomethewaifu

Changing compiler is not the problem. But changing the standard library becomes one. systemd gained problems with #musl because of this.

#systemd

https://tty0.social/@JdeBP/114646325165347305

@mcc @dalias @whitequark @becomethewaifu

It didn't replace van Smoorenberg init+rc. It replaced Upstart. The existence of Upstart is the part of history that many people forget or gloss over.

van Smoorenberg init+rc always was a straw man. The Debian committee included it, but everyone acknowledged at the time that the main contenders were systemd, Upstart, and OpenRC.

#systemd #Upstart

@foolishowl @azonenberg @mcc @dalias @whitequark @becomethewaifu the future of Linux is systemd, Wayland, and gnome. Nothing outside these boundaries will be tolerated by the owners of Linux, red hat

@kyle_pegasus @foolishowl @azonenberg @mcc @whitequark @becomethewaifu Huh? Lots of us consider them completely irrelevant. They aren't the owners of anything and their decisions have little impact on us.

@dalias @kyle_pegasus @foolishowl Also, as I've already commented in this thread somewhere, as a GNOME user it's fairly obvious that KDE will be the only full-featured option in the future, in part due to KDE seriously supporting Wayland and GNOME not

@mcc @dalias @kyle_pegasus @foolishowl Wait, isn't GNOME more into Wayland than KDE?

@tris @dalias @kyle_pegasus @foolishowl I can't speak to their mindset. I just know they're not very good at it and I am frequently finding important features that are present in GNOME X11, absent in GNOME Wayland, and present in KDE Wayland.

@mcc @dalias @kyle_pegasus @foolishowl Huh, interesting, I find the opposite true, features like gestures are simply not present in GNOME X11

@tris @dalias @kyle_pegasus @foolishowl I come not to praise GNOME but to bury them

@bob @tris @dalias @kyle_pegasus @foolishowl I don't want to use X11! X11 is terrible! I want to use Wayland and I want for Wayland to actually be fit for purpose

@mcc @bob @tris @dalias @kyle_pegasus I tried using KDE with Wayland a few weeks ago, and my system seemed to drop to a frame every few seconds. I was guessing it was software rendering. Maybe it was the combination of an old Nvidia card with proprietary drivers?

I'm staying with XFCE for now but I'm worried about being stuck on unsupported software.

@mcc @tris @dalias @kyle_pegasus @foolishowl I use xfce because it's GTK based but it will also likely continue to support X11 forever

@bob @mcc @tris @kyle_pegasus @foolishowl Same. I don't want a "desktop environment". I don't want 75% of my resources spent on trying to make everything look the same like it's some corporate branding campaign. I just want to use the individual applications I need without being bothered by that shit. And XFCE delivers.

@dalias @bob @mcc @tris @kyle_pegasus @foolishowl yep. I left GNOME as soon as 3.x came out and it stopped letting me easily do the classic "win2k style taskbar and start menu at the bottom of the screen" UI.

@azonenberg FTR there is a plugin I use that gives you that back… it breaks at every gnome update and seems to be basically impossible to use on ubuntu due to distro-specific bugs there

@mcc yeah, or i could just use xfce.

What i'm more mad about is the GTK people getting infected by this, since so many non-GNOME apps are being forced to use GTK3/4 and e.g. the file browser dialog no longer supports typeahead. There were patches to restore it, but the diffs gradually grew more and more painful and I don't think there are any seriously maintained forks at this point.

If you wanna add search as an option do so, but keep the existing (perfectly functional) behavior as a preference.

@azonenberg that is an option. i can't use xfce because the margins Look Wrong and as a mac user from 1992 this is intolerable to me.

i agree that the replacement of typeahead with search in gnome/gtk is fucking intolerable.

@mcc (and more generally, "search as primary UI interaction mechanism" becoming horribly prevalent instead of "let me organize my data and find it the way i want")

@azonenberg @mcc "Can you send it to me again? I don't have it in the Recents anymore"

@azonenberg @dalias @bob @mcc @tris @kyle_pegasus @foolishowl oh man I loved gnome 3 from the second I first saw it. I was coming off windows 8, where it was entirely fucking unusable until you knew you could win+d, and the first time I hit the meta key and the hud display came up I was fucking thrilled. Bind a hotkey for the terminal, different desktops for different content groups with easy scrolling between... I loved it, and I still love it, and although I get the hate I will defend it.

@silasmariner @azonenberg i am using current gnome with the dash-to-panel extension. i love how everything looks and other than problems with fractional dpi, almost my only complaints are things GNOME made bad on purpose (for example, the "typing a word in the open dialog searches within subfolders" behavoir

@mcc @silasmariner yes "bad on purpose" is my main complaint. Bad design not bad implementation

@mcc @azonenberg there are certainly a couple of usecases I stopped using the UI for and started doing in the terminal, but once I had the aliases for that I never really missed any capabilities... But, like, there are so many ways you can use a computer, and not being able to trivially fix a behaviour that grates with you is certainly frustrating. I've had my share of that, but have been happy with my current setup for quite a few years now. I guess one can forget overcome frustrations.

@foolishowl @azonenberg @mcc @dalias @whitequark @becomethewaifu

Declared a "wontfix" bug in #Debian back in 2024.

I wonder whether it did get carried over to a policy bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370#21

#systemd

@foolishowl @azonenberg @mcc @dalias @whitequark @becomethewaifu

Heh! It was, it turns out, and the only response stated to send it back to being a #systemd bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086055

#Debian policy ping-pong. (-:

@JdeBP @foolishowl @azonenberg @mcc @whitequark @becomethewaifu I think it was a mistake of Debian not to patch this out of their systemd build.

If a piece of software is trying to impose policy contrary to distro policy via a message it emits to your distro's users, that's a policy-alignment bug. And part of the distro's role is fixing ways packages violate distro policy (like putting files in the wrong locations, containing spyware, etc.).