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'm tired of this anti-Wayland horseshit
881–890 of 892 posts
Re: I'm tired of this anti-Wayland horseshit
#882Earlier 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.
Or rather, complain to your IT to do so.
Re: I'm tired of this anti-Wayland horseshit
#883Earlier 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.
Re: I'm tired of this anti-Wayland horseshit
#884Earlier 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
[0] Well, not exactly, but you get the idea.
Re: I'm tired of this anti-Wayland horseshit
#885Earlier 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.
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
#886Earlier 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…
Re: I'm tired of this anti-Wayland horseshit
#887Earlier 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…
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
#888Earlier 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.…
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
#889Ok, 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…
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
#890Ok, 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