Working for an organisation which systematically abuses and degrades disabled people is not a morally neural act. If you're life is difficult then that's sad, but not an excuse to exact that difficulty 100 fold on other people.
I'm almost certain this is from the UK, and here we have a government that is absolutely obsessed by the concept of benefits fraud. Every real analysis has shown that virtually none exists, but it is a good excuse to tighten up the government budget by trimming some fat (disabled people).
Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.
How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.
Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything.
This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.
Imagine you wrote an application that supports global, unfocused keybinds (OBS is one popular example).
Instead of implementing it one way that works forever with any WM/DE (X11), now you must rely on each individual wayland compositor to implement one or more optional extensions correctly, and constantly deal with bug reports of people that are using unsupported or broken compositors.
Or you could write portable software that doesn't rely on reading global input. OBS you give as an example, and it is a good one. They could simply register a D-Bus handler and provide a second binary that sends messages to the running instance. The software is more general in this way as it allows full programmatic control. A Sway user, for instance, could add
bindsym $mod+r exec obs-control toggle-recording
to their configuration. What's more, they can do this in response to other system events. A user might wish to change the recording configuration of OBS in response to an application opening, and it now becomes possible to write a script which opens the application and applies the change.
If your disdain for desktop isolation is so great, you needn't even use D-Bus. Registering a simple UNIX socket that accepts commands would work equally well in this case.
What's really desired here is a standard way for programs to expose user-facing commands to the system, which is clearly not within the scope of the specification for a display server. The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user, and so many apps have become reliant on this and developers have neglected the creation of portable ways to achieve these objectives. A new specification for display servers that excludes this harmful behaviour is a clear long-term positive.
I'm not sure how any of that sidesteps the point of my comment, which was having to rely on many different wayland compositors all implementing hotkeys properly.
I don't think it's always practical or desired to move the hotkey support completely out of the program itself. Most users (especially consumer/nontechnical people such as many OBS users) are not willing to setup hotkeys through a third-party program to manually get it to control OBS externally... so I think it needs to support hotkeys internally, whether there is also control possible via an external socket/dbus/etc. or not.
This is an excellent description of why this is an awful situation.
It's extremely user hostile.
> The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user
It's not "unrelated functionality". It's an entirely generic ability to listen to events that is available with Wayland as well, just with an added restriction.
So either every user needs to manually bind every command using their WM's bespoke global hotkey mechanism, or the developer needs to ship keybinds for every possible WM.
Sounds like a nightmare for everyone involved to me
I think you've got it backwards. Applications like OBS do not typically register default global keybindings to avoid clobbering, you have to do it manually in their settings menu. The only difference with a generic interface is that the dialogue opened from the setting menu would be from the WM instead of OBS.
The problem with Wayland in this respect is that there is no such generic interface that works everywhere - each compositor may choose not to support it at all, or support it in different ways.
If there was a single standard way, great. In the meantime I'll stick to X11, which isn't this incredibly user-hostile.
That is not a problem with Wayland because specifying this is not a within the purview of Wayland. People like you don't seem to understand that Wayland is specification, and not an implementation like X11.
Reminds me somewhat of Vulkan. I think the trend of making the actual specification of something lower level and less convenient is rather logical. Why burden implements with a load of convenience functions when that could be left up to libraries?
Because those libraries will not materialize in time, and more importantly the hobbyists who are supposed to write those libraries don't have the testing capabilities of large organizations (e.g. testing across hundreds of hardware configurations).
...or worse, the libraries do get written, but multiple times in mutually-incompatible forms that are tightly coupled to specific compositors / desktop environments. (Screengrabbing, anyone?)
Because the low level details tend to change over time and then it's too late and you're committed to supporting something that doesn't make sense anymore. like branch delay slots in some RISC cpus, or vulkan (https://www.sebastianaaltonen.com/blog/no-graphics-api)
import Mathlib
def Goldbach := ∀ x : ℕ, Even x → x > 2 → ∃ (y z: ℕ), Nat.Prime y ∧ Nat.Prime z ∧ x = y + z
A short specification for the proof of the Goldbach conjecture in Lean. Much harder to implement though. Implementation details are always hidden by the interface, which makes it easier to specify than produce. The Curry-Howard correspondence means that Joel's position here is that any question is as hard to ask as answer, and any statement as hard to formulate as it is to prove, which is really just saying that all describable statements are true.
This argument is based on the notion of proof irrelevance – if a theorem is true, any proof is as good as any other. This is not the case for computer programs – two programs that implement the same specification may be very different in terms of performance, size, UI/UX, code maintainability, etc.
Performance and size can easily be added to any specification, maintainability is not a problem if you never have to maintain it, UI/UX are design issues not code issues. If you specify a UI, it will have the UX you want. We can already do UI creation with visual editors.
These days people are fearful of their work ending up in LLM training datasets. A private, but static hosted website is on a lot of people's minds. Most social networks have privacy setting these days, which feels like a missing feature of standard, static blogs.
If you are interested in multi-byte access to GCed arrays, something similar can already be accomplished. You can hold the array data in Wasm linear memory, then have an object that wraps a pointer to it, and using JS code, associate a finalizer with that object that frees the related section of linear memory. It's essentially how FFI memory is handled in most native GCed languages.
I considered that, but it requires more pointer indirection and I'm supporting WASI as a first class target, so won't always have access to JS finalizers. I'm going with copying as simpler for now, praying that multi-byte access lands by the time my language is viable.
> This perception, for what it’s worth, runs counter to statistics: Between 2000 and 2022, the years for which data is available, only 0.5 percent of startup venture funding went to LGBTQ+ founders.
The article seems to admit that its central premise is entirely made up. If a conservative 3% of people are some flavour of gay, then they are 6-fold underrepresented, at least in this area.
reply