Hacker News Reader

>> the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under

That one drives me insane.

>> general window positioning

I want my applications to come up where they were when I last closed them. This used to be up to the app under X, and I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position. But that means putting things where they were is the DE/compositors responsibility now, and I fear they're going to fight that idea forever. I hope I'm wrong though.

> I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position

Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack, and I don't have a good intuition for why it should be necessary.

With multiple monitors, and multiple multi-monito configurations, window position becomes a complicated concept, full of pitfalls and corner cases. It is reasonable (although admittedly not the only possibility solution) to centralize the window position management in the wm.

Your conclusion doesn't follow from your premise.

What does follow is that apps should have a library available which allows them to express their positioning desires while accounting for the complications and corner cases.

Even if positioning were centralized, apps should still have been able to tell the WM "This is what I want to happen w.r.t. positioning, try to accommodate me".

I should have explained myself better. The old way of specifying a position (pixel coords in a plane) does not work well for complicated setups. Among the possible alternatives there is:

1. Assign responsibility to the wm (Wayland’s way)

2. Create a new way to specify position preference in a complicated world. That’s what you propose, IIUC. It’s possible but complicated, and Wayland had a lot of other problems to worry about, therefore I understand why they didn’t choose this way.

3.Leave the simple protocol in place, but let the wm override the application’s choice when necessary. I guess a lot of apps would not work properly in such a system.

Given the choice between the window manager making all of the positioning/size decisions and allowing the app to do it, I'll gladly pick the WM. In the opposite world, sure, most apps will behave sensibly but then occasionally you're going to run into that application where the author says, "hey, my app is so great, you're definitely going to want it full-screen all the time!"

An exaggeration of course, but I have seen plenty of apps try to do "smart" things about window management on their own, and they always get it wrong. It's one of the reason's KDE WM allows you to to override and make permanent a surprising number of settings.

(I also believe that websites should not be able to just do whatever the hell they want on my computer, but that battle seems to have been lost.)

More simply, because I say where the application goes. It absolutely does not get a say in the matter. It's my computer.

>> Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack...

The security model in Wayland seems to keep the application largely isolated from its environment. No warping the mouse pointer, no reading pixels, no understanding of what the user might be doing outside the application window. I can agree with all of that in principle. It is not the applications place to move anything on the desktop including itself. Those are to be done by the user. Also for consistency this kind of thing has to be done by the DE.

It was also nonsensical to have have applications be responsible for remembering their own positions instead of the "window manager". Read that again "window manager" ;-)

> The security model in Wayland seems to keep the application largely isolated from its environment.

I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.

If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.

> any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit.

Not that I'm a fan of it or that knowledgeable about the subject, but isn't this sort of where Flatpak comes in where applications have to be given permission to access some of these?

I know that Fedora is very clearly moving toward the Silverblue (OSTree) endgame where the underlying system is immutable and Flatpak is the default for user applications on top.

> I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.

It doesn’t require changes as deep as you’re implying (although I would say moving away from the traditional UNIX permissions model would ultimately be a good thing). It can be beneficial with existing application confinement mechanisms like Flatpak. You can restrict a Flatpak app from accessing your $HOME, but if it’s given access to your X server it has a lot more access than it likely needs. My understanding is the situation is better with Wayland, provided you only give it access to the Wayland socket and not the X11 socket.

Why do Linux heads this needless containerization thing to themselves? There are zero new desktop apps coming; those in use are F/OSS and have been thoroughly reviewed for like 20 years. What's the threat? At best, it disturbs user file-based workflows and puts additional work onto developers who are few and far between anyway. Distros have worked well for a long time - much better than Win or Mac sw updates. If you want to compile your own app, it's well supported. We don't have a rush of new unstable must-have libs to compile against all of a sudden.

Just wait until systemd grows a ui toolkit :D

Will that come before or after the SystemD kernel? I assume the systemD web browser comes after the UI toolkit?

The problem is not trusting the application, but that application having to manage untrusted data. Let’s say you have a trusted open source pdf reader. It can easily be infected by a pdf that exploits a memory bug in it.

>> If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.

No, you're only screwed 4 or 5 ways. Applications can't screen capture, and they can't monitor the keyboard input to other applications.

Your points on other security issues are valid, but just because there are 6 different ways a program can dig into your system is no reason not to plug some of those holes. Wayland does that.

IMHO we need to restrict a bunch of system calls so they can only be used by the GUI toolkit. Then only files selected by the user could be accessed by an application. Of course CLI programs and other cases need permission too, so there is some complexity to work out. But this would allow a random application to use the system installed GUI toolkit and access only what the user specifically says through interactions.

Better security doesn't have to be hard, but it does require that changes be made.

Just because the existing situation on Linux is terrible from a security point of view, it doesn’t mean we shouldn’t start fixing it.

Not being able to install a keylog from an npm package is already a huge improvement.

With respect to the Wayland devs, as they've been fighting more than an uphill battle for a decade now, but that is so bone-headed.

If their design philosophy is like this in general, no wonder no one is adopting it. It's just a worse X.

It is the default used by every major distro now, so it is definitely adopted. Also, it has a very good design, solving real issues.

I got used to type slash(/) which opens file input field when ever I'm pasting file.

> I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB

Kubuntu was my first distro and posts like these reconfirm my decision to stick with KDE.

I wish it was mine too. I would have gone for Linux as my main OS lot earlier.

> - the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under

I deeply hate this one, it always gets me when I'm saving in a hurry.

And let's not forget about buttons on windows title bars. Someone please tell GTK developers that most of us aren't using tablets; computers with actual keyboards and mice are here to stay for a long time.

That one drives me absolutely fucking batty. Nobody uses GNOME on the touch screens that the UI was clearly designed for, and moving the default requestor buttons out of the bottom right where literally every single GUI of any note throughout history puts them is a particularly galling bit of NIH snowflakery.

Gnome is what you get when you combine the worst parts of Windows 8 with the worst parts of MacOS. Bad ideas + bad execution, but most major distros ship it by default for some inexplicable reason.

> I think I'm going back to Mac.

This is poor conclusion imo. KDE might better suite your needs. Plus, macOS comes with its own wtf's: https://medium.com/@parttimeben/mac-it-just-works-horribly-c...

Yes I'm aware Mac OS isn't a panacea either (used MacBooks/PowerBooks and Mac mini on and off alongside Linux since 2003). But I had such a craptastic experience with PC hardware lately: on my 3rd Dell Latitude/Precision with battery and other hw defects ootb sent by customers for work within 8 months, and my 2019 Thinkpad has a stuck trackpad - miniscule as it is - due to completely unused mechanical parts (buttons, think point, and whatnot). Meanwhile, M1/2 MacBooks leave x86 notebooks in the dust performance-wise, and have left PC notebooks behind in terms of screen resolution for a long time now, also wrt trackpad and keyboard, and value retention, it's not funny

I like to say that Apple providing a much better experience than the competition has less to do with Apple being amazing and more with the competition being shockingly bad.

Word.

Mine is that they kind of abandoned Vala and then started using their own JavaScript engine for everything beyond bare bones Gtk+.

The slowness and leaks of not having a V8 class implementation, has made me embrace XFCE for the surviving device I still run GNU/Linux natively on.

And to think 22 years ago I was arguing for GNOME, advocating for Gtkmm versus Qt.

"Their own JavaScript engine" is Mozilla SpiderMonkey 91.

https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md

It appears to be broadly competitive with V8.

https://www.anandtech.com/show/16078/the-2020-browser-battle...

Maybe it is competitive now, it hasn't always been like that.

https://gitlab.gnome.org/GNOME/gjs/-/issues/231

https://gitlab.gnome.org/GNOME/gjs/-/issues/361

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...

Just to give you a taste of the issues.

When I complain about something, usually it is based on experience and knowledge.

And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.

My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation".

> https://gitlab.gnome.org/GNOME/gjs/-/issues/361

Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether

> https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...

This fix is strictly specific to GObjects wrapped by GJS

From my point of view, the whole experience end to end counts as having a V8 class implementation, and not the bare bones runtime.

ChromeOS isn't only V8 without anything else.

> - general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf

I like this behavior. It only happens for apps that take too long to start. When an app takes too long to start, it is usual for me to continue doing other things while it starts, when it starts, I don't want it stealing my focus. I think this feature works exactly as intended.

You prefer a notification to steal your focus instead? :)

The notification does not steals my focus, it may call my attention, but it will not steal my focus. Focus stealing is when the app I'm using is switched to another without any action from me.

> general window positioning

This has worked as expected to me. It generally opens windows on top of the stack unless the app takes too long to start and you've interacted with the window on top. In that case I appreciate it doesn't change focus (I could be typing something for example).

I started with desktop linux with KDE2, and KDE3 was... seemingly perfect. I watched some colleagues move to KDE4 when it came out and it felt like a ... mess. I tried it myself for a few days and it was too foreign. Never cared for gnome as a main desktop, although I do recognize gnome foundation did provide a lot of useful software over the years, some of which I used.

Moved to mac for main desktop around 2008. I look back some times and KDE5/plasma/whatever might be worthwhile to check out again. Mac annoyances are piling up over the years, but I suspect it would be "the grass is greener" somewhere else, and I'd find a lot of the KDE annoyances which led to me leave may still be there.

Same here. GNOME 2 was just about perfect.* KDE 3 was even better. Rock solid and lots of excellent, well-integrated functionality. Everything after those two have been a showcase of failed UX experiments.

* (It's successor MATE has not aged gracefully, unfortunately.)

Modern KDE is pretty good. Most importantly, it still lets you configure things to your own liking, instead of one-size-fits-all approach that GNOME espouses.

If you're a KDE 3 fan, https://trinitydesktop.org/ is actively maintained.

> I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB

I'm curious, what do you expect won't work under KDE?

Nothing in particular; maybe third-party apps like MS Teams (ugh) I need for my customer projects (which also didn't work right on gnome for years, and had trouble when switching logins/customers), that kind of stuff. I considered kubuntu, but thought I was leaving Ubuntu mainstream for good anyway, so why not go to eg Slackware w/ KDE Plasma and say goodbye to systemd, snaps, and containerized browser behemoths that want to update themselves all the time anyway. Don't want that shit on my main machine period. I'll be keeping my old (Ubuntu 16.04 ESM and 20.04 LTS) notebooks around just in case, but customers keep sending me shite notebooks, and MacBooks are more than capable to run Docker crap anyway.

Getting rid of systemd is harder. But applications don't stop working because you switched a DE.

What do you so heavily dislike about systemd? It's pretty useful.

I ran into not being able to open Nautilus as an admin without having to install some packages through apt. Why is Linux the only OS that doesn't allow me to edit or view a system file out of the box?