Live data from Hacker News

I'm tired of this anti-Wayland horseshit

drewdevault.com

881–890 of 892 posts

Re: I'm tired of this anti-Wayland horseshit

#881

Earlier quoted context omitted.

Gentoo still has their own init, some distributions still use sysvinit, and both can run GNOME. Upstart is a dead project AFAIK, and the developer dropped it and said it was strictly inferior to systemd. ALSA is just the kernel layer, there is a limit to what you can put there, so some of it has gone into another layer in userspace, that's by design in the kernel. I won't comment on the display system, everything tha…

ALSA is just the kernel layer Just one point about ALSA; most of it actually lives in userspace. The ~/.asoundrc file can specify complex routing and mixing, including the use of LADSPA filters. What's done is done, and pulseaudio is reasonably usable now, but IMO we'd be much better off if the work that went into Pulseaudio and jackd instead went into the ALSA userland.

I don't understand what you're suggesting. To put the work into the ALSA userland, you would make an additional daemon on top of it and put features there, which is exactly what Pulseaudio and jackd are.

Re: I'm tired of this anti-Wayland horseshit

#882
post #879
post #843

Earlier quoted context omitted.

Well, there is a solution: either buy another video card for graphics, or use iGPU. And leave the nvidia one for CUDA only.

This is in a work issued computer, so no, this is not a valid solution.

Then add an RX480 4GB as secondary GPU for desktop usage, and only use the nvidia card for CUDA?

Or rather, complain to your IT to do so.

Re: I'm tired of this anti-Wayland horseshit

#883

Earlier quoted context omitted.

ALSA is just the kernel layer Just one point about ALSA; most of it actually lives in userspace. The ~/.asoundrc file can specify complex routing and mixing, including the use of LADSPA filters. What's done is done, and pulseaudio is reasonably usable now, but IMO we'd be much better off if the work that went into Pulseaudio and jackd instead went into the ALSA userland.

I don't understand what you're suggesting. To put the work into the ALSA userland, you would make an additional daemon on top of it and put features there, which is exactly what Pulseaudio and jackd are.

ALSA already comes (or at least did in the past) with an optional daemon for dmix and dsnoop. Putting as much of what jack and pulse do as possible into libasound (which already handles a lot IIRC), with the minimal amount necessary into a shared daemon, could have allowed all existing ALSA applications to work with the dynamic switching that is now handled by PulseAudio, or the low latency that is now handled by Jackd. ALSA already had a signal graph that could have been evolved into the independent signal graphs that PulseAudio and Jackd can now build.

Re: I'm tired of this anti-Wayland horseshit

#884

Earlier quoted context omitted.

On this particular issue I find it hard to fault them for using a (perhaps overly) safe default. Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data. If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.

If your software corrupts data when it's killed, it's honestly not very good software. I kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P

I don't disagree, necessarily, but ACID[0] is/was quite expensive for (usually) marginal gain. These days, I'm sure it could be done a lot more efficiently (with SSDs and such), but the fact is that there's no real way to do it using just POSIX syscalls. Applications literally cannot 'signal' transaction boundaries wrt. file system writes as it is. The APIs simply aren't there.

[0] Well, not exactly, but you get the idea.

Re: I'm tired of this anti-Wayland horseshit

#885
post #874

Earlier quoted context omitted.

Only if you care deeply about always having the latest data, rather than just consistent data. I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.

Current generation file systems, including ext4, already have journaling to prevent this.

True, and you can even turn data journaling on. The problem is... what is an "atomic write" from the perspective of an application? There is no POSIX interface for that. Of course making a single 'write()' syscall atomic, and so forth is a good thing, but... that's not an application level 'transaction' necessarily. Libc has buffering between fwrite and write... that's pretty arbitrary (fflush notwithstanding). Also: Dirty read (A) -> Writes that are committed, but the data read (A) doesn't get committed. Uh, oh!

The problem is a thorough lack of semantics on file systems. It's the wild west.

ACID was a good start for databses, but even that is pretty vendor specific in the specifis... and nobody truly understands the basics of it anyway.

It's a difficult problem.

Re: I'm tired of this anti-Wayland horseshit

#886

Earlier quoted context omitted.

> there's no discipline in the Linux community [...] look at projects like glibc or GNOME So not the Linux community then. Outside it. Do all the new GitHub-driven programmers who exclusively use MacBooks and constantly rev things with the same frequency not exist? Why is this still being presented as a freedesktop-related problem and not a general problem with creators' fickle and fleeting attention, when we have ev…

> So not the Linux community then. Outside it. Sadly, that ship has passed... long ago. When you encounter a random person about "Linux", they will think of the Linux ecosystem , not just the kernel . In other words, your and GP's definition of "Linux" is different, and they are both correct depending on how would you read it . (And before you go almighty on definitions, the majority of linguists agree to just monito…

I'm aware of the equivocation, but there's absurdity in the statement "there's no discipline in the Linux community" demanding a definition that excludes Linux proper. Descriptivists and prescriptivists should agree that no matter where you lie on the spectrum, this is bonkers.

Re: I'm tired of this anti-Wayland horseshit

#887
post #562
post #518

Earlier quoted context omitted.

Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places). What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.

Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus. The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something si…

Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling"

edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1

[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

Re: I'm tired of this anti-Wayland horseshit

#888

Earlier quoted context omitted.

NVidia is broken, not Wayland. They refuse to implement the same APIs as everyone other driver does. Wayland is 10 years old, and extremely stable. If it isn't working properly it's either your driver vendor or your desktop environment that is to blame.

> NVidia is broken, not Wayland. They refuse to implement the same APIs as everyone other driver does. I'm extremely sympathetic to this argument, and I actually agree with ddevault's decision not to support NVidia in Sway. I think as an Open Source maintainer you don't have an obligation to burn yourself out solving a problem that is NVidia's fault, and we need real pressure on NVidia to stop being completely awful.…

I think its worth pointing out that Wayland does support NVIDIA's hardware, that the two most widely used Wayland compositors (GNOME and KDE) do support NVIDIA's hardware, and that NVIDIA pays people to work full-time on Wayland, and these compositors, opensourcing their work.

The issue here is that sway, one wayland compositor, does not want to support NVIDIA hardware because they lack manpower. They are also not able to attract anyone willing to implement this support, like other compositors have done.

If you wonder why this is the case, just read this blog post again, and wonder if you'd like to spend your free time working with maintainers that write like this. Go ahead, read any of the other blogpost, or skim through the closed issues in the sway repository.

Trying to spin sway's failure to support NVIDIA's hardware as "NVIDIA hates wayland" is ridiculous in 2021.

FYI I use sway as my main DE, and I'm indeed grateful to its creators and maintainers (ddevault is not a maintainer anymore). But when I read this:

> "We’ve sacrificed our spare time to build this for you for free."

they sound to be entitled to my gratefulness. This is just such a toxic way to go through this world.

Re: I'm tired of this anti-Wayland horseshit

#889

Ok, here is my use case that wayland doesn't work for. I have an AMD graphics card (5700xt) and two 4k screens. I want to run firefox, chrome, emacs, and a terminal. Using KDE or Sway, if I set my desktop scaling to 2x, all programs that run through XWayland have extremely blurry display (they've been rendered at 1x and then crudely scaled up). This includes firefox, chrome, and emacs. The browsers have ongoing work…

A pgtk build of emacs is what I have been using for quite some time without any significant problems (native Wayland build)

https://github.com/masm11/emacs

Pretty sure there are builds for the browsers you mentioned that run natively on wayland

Re: I'm tired of this anti-Wayland horseshit

#890

Ok, here is my use case that wayland doesn't work for. I have an AMD graphics card (5700xt) and two 4k screens. I want to run firefox, chrome, emacs, and a terminal. Using KDE or Sway, if I set my desktop scaling to 2x, all programs that run through XWayland have extremely blurry display (they've been rendered at 1x and then crudely scaled up). This includes firefox, chrome, and emacs. The browsers have ongoing work…

A pgtk build of emacs is what I have been using for quite some time without any significant problems (native Wayland build) https://github.com/masm11/emacs Pretty sure there are builds for the browsers you mentioned that run natively on wayland

Yeah, here's where I think things tend to go off the rails in the wayland discussions with people having different personal experiences. I've tried to run both firefox and chrome in the native wayland mode and neither works properly _for me_. I forget what the chrome issue was, but in firefox on KWIN if I enlarge a window the portion of the window that was added doesn't render properly --- it's a flashing white rectangle --- and then if I resize it down it either crashes or garbles the whole window. I'm sure this doesn't happen to everyone.
Post reply on HN