This is incorrect, apps installed through the macOS App Store have required sandboxing since 2012. Since 2018, Microsoft is also attempting to get developers to sandbox more apps, see more about that here: https://news.ycombinator.com/item?id=36059982
I'm pretty sure you're wrong. Looking over the part where you imply that the MacOS App Store is the standard way to install Applications on MacOS (opposed to dragging the application to the Applications folder), let's look at what the system you're referring to actually does:
Show me where it says a program installed from the MacOS appstore will be unable to read the user's files unless the user explicitly authorizes it. Here's how it actually works as far as I can determine: The application developer grants their app the entitlements to read user files. The user may see that entitlement before installing the application, but thinks nothing of it because of course the program operates on their files. This does not protect the user against a malicious program being shipped with those entitlements and a plausible pretext to justify it. Example: The user downloads a program to read some kind of unusual file for work, the program grants itself access to ~/Downloads because of course it needs that, then the program instead reads ~/Downloads/your-tax-documents
This system only protects the user if the application was legitimate, refrained from granting itself the relevant entitlements, then got compromised by an attacker.
That's the same limitation as XQuartz or any other rootless X server. And you have this exactly backwards. The majority of X clients that users care about are ordinary programs, not window managers or xdotool.
> The majority of X clients that users care about are ordinary programs
This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xrandr, xrdb, xsel, xset)
xbacklight, xcalib, xcape, xmodmap, xrandr, xset: These are utilities specific to configuring the X server. They're needed on non-X11 window systems.
xbel: I don't know what this is.
xdotool: Some commands will still work. Other commands that require interaction from the window manager might not work, but they won't work on some X11 window managers either.
xrdb, xsel, xkill: These still work, although for obvious reasons they won't affect native Quartz or Wayland applications.
By the way, none of those are ordinary X applications. Notice how none of them actually display any windows or having graphical interactions with the user? You know, that thing that X11 is designed to do? Put windows on the screen?
Which X clients are these? You didn't name any so let's just look at some of the popular and recent flathub apps: https://flathub.org/
I see a lot of games, chat apps, text editors, photo apps, office apps. These all will work fine in XWayland and XQuartz. But also, it's relatively easy to get them running on Wayland natively.
If this works for you, cool. But this is... not good in any way, and it's still not going to work for clients that use a different toolkit or text renderer than the ones you've configured. I hope you can see how it's unacceptable for an average user to have to mess around with this many random commands and environment variables just to get scaling working.
>X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon
Outside of a very small niche of obscure window manager developers, this isn't true. GNOME and KDE have been trying to get rid of it for decades. The glaring flaws in the API have been known for that long.
>38 years of backwards compatibility and still being able to deliver performance
No, the Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream. At the time some of those may have been the best way to deliver performance on specific hardware but, like anything, they didn't hold up and were thrown away. It wasn't because an IBM/Redhat or Collabora employee said so. See also https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
Both are are really bad desktop environments and part of the reason the FOSS desktop never took off. Also they are mostly developed by full time paid employees with zero community involvement. As such they are the small niche.
> The glaring flaws in the API have been known for that long.
X11 has flaws but I wouldn't call them "glaring". They are a nuisance at best. You don't pay for functionality you don't need. Wayland has glaring flaws because it does not provide and standardize functionality that people need. It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
> Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream.
Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
>Also they are mostly developed by full time paid employees with zero community involvement.
No. Both of them have a good mix of community contributors to do the fun stuff, and paid employees to do the annoying tasks no one wants to do for free. A good project needs both. Are you really suggesting that another desktop is somehow going to spring up and succeed with no paid employees and no business case? If what you're saying is true, wouldn't that have already happened and left GNOME and KDE in the dust long ago?
>You don't pay for functionality you don't need.
You actually do if you're maintaining the X server and protocol.
>Wayland has glaring flaws because it does not provide and standardize functionality that people need.
These can be fixed by extending the protocol, unlike in X11 where the flaws can't be fixed because they're built into the core.
>It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
This is actually a kernel/driver problem. It also happens in X11 if you use a driver with implicit sync.
>Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
No that's not what's happening either. Lots of current X11 extensions (such as Big Requests, XC Misc, XFixes, XSync) actually exist only to paper over old cruft in the core protocol that can never be removed. It's possible to remove other extensions from the core and still keep the core intact. When the core X11 protocol itself becomes unused and unpopular (which it is) then it's time to remove the whole thing.
Are you actually suggesting that most Linux desktop users only use the same 4 programs you do and will never use or install anything else? If that's the case then why bother with a display server or package managers? We can hardcode those 4 programs into the system, have them draw directly to the framebuffer and then we can remove the ability to install any other programs. Sound good to you?
No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.
X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.
No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.
This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym.
But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.
Yes, I know what it is. Here are some corrections.
1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB.
2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling.
3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor.
4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension.
5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.
Like everything else in XCB, those are just stubs autogenerated from the wire protocol definition. The client has to actually implement the protocol semantics including duplicating a lot of logic that's already present in Xlib. There's no performance benefit to this either. For that reason XRandR is probably one of the most useless and least beneficial things to use XCB for. Signed, someone who actually did try this at one point and ended up reverting back to Xlib.
>But, yes, software using Xcb does have to actually do it correctly for it to work,
There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.
> There isn't a way to do this correctly, it's a hack
Hacks are often the correct way to do things.
JFC this is annoying. I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
This doesn't work on Wayland. It does work on X11. You can stomp your feet until you're blue in the face but that won't change this basic fact.
If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
>I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
No it's actually the other way around. You keep gaslighting and insisting that it's a valid solution because it works for a small subset of clients that you've picked for yourself. I'm telling you this isn't a valid solution for any X11 maintainer to put in place. I've already showed you where an X11 maintainer actually said this, but for some reason you think you know better. Well I'm sorry, but it's not a solution. When you maintain something like that, you don't get to pick and choose the clients you support. You have to support all of them. And yes, it is impossible for X11 maintainers to go and find and fix bugs in every single client from the last 35 years or port them all to XCB and rewrite the drawing code or whatever it is you'd like them to do.
>This doesn't work on Wayland. It does work on X11.
No, it doesn't work on X11 either. Refer back to the merge request I posted earlier. This isn't something you can just hack in. Your solution will break down if you ever need to use a different type of client.
>If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
Where is this coming from? I've never said you should switch display servers. I'm only observing that you probably will once the limitations in your approach become apparent. You realistically don't get to even have preferences here, maintaining all of this is too much work for one person. Maybe you won't switch to Wayland, maybe it'll be something else entirely. Who knows? The point is, X11 doesn't do it.
And this is really my problem with talking about open source on HN. The well has been poisoned, I can't point out broken stuff without someone accusing me of having some kind of agenda. As if anyone who's developed for X11 for the last 36 years hasn't run into all these problems, repeatedly. Nothing is going to get fixed if everyone gets defensive and starts playing the blame game when bugs are pointed out. But that's all that happens here. If you ask me, it's yet another sign that the project is finished.
That article is horrible. What it describes is yet another hack where clients attempt to guess the DPI and then rescale themselves, and the server and compositor know nothing about DPI. That method only exacerbates the problems where clients that don't support scaling are going to be scaled wrong on every screen. Compare this to Wayland where the compositor itself knows the scale of every window and does all the scaling.
Which is a fair assessment, And I think I agree with you. however there is a bit of irony around the whole situation.
The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.
The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.
