4 ms·

I haven't used RedHat since they started to charge for it. Fedora 27 was ok. I think Linux generally works on the desktop. It's true that GNOME 3 is still bugg

by qplex 8y ago

I haven't used RedHat since they started to charge for it. Fedora 27 was ok. I think Linux generally works on the desktop. It's true that GNOME 3 is still buggy. I've had Nautilus crash on me while copying files and other horrible things. Wayland hardly has any apps with native support, it crashes a lot and the hardware support sucks too. Also (afaik) applications such as Wine can never be ported to Wayland. However GNOME and Wayland are just one bleeding edge. If you run X with some stable WM or DE, things work so well it's almost boring.

jchw 8y ago
Sure. If you run at 96 DPI, with a static monitor configuration, with a single GPU, no expansion cards, with English language only. However: - with multiple GPU configurations, all bets are off. - Thunderbolt docks and even the Thinkpad dock can be buggy and cause crashes. I've had a few instances of Xorg crashing on dock. - HiDPI sucks. Linux took the wrong approach from the get go. Now each Xorg client has to be DPI aware, but if it isn't, there is no graceful fallback. There's also no easy way to determine what the DPI should be, and any hopes that you can have monitors with differing DPIs is right out. Wayland tries to fix this, but in my experience so far things look blurry and horrible. - IME sucks really badly. It almost was good for a bit, with IBus. But now I don't even know what the standard is or how to configure it. How do I even get Japanese IME in KDE? I can get it working in GNOME but good luck getting that to work with apps that don't use GTK. - Sleep is still complicated. There are multiple DBus APIs for power management, and they're not compatible. GNOME does OK here. KDE does worse, and I find myself needing custom code to inhibit sleep in some circumstances. Not user friendly, though workable for me. - Resume is more complicated. - It feels like boot splashes have only gotten worse since the old days. Entering in LUKS keys is still weirdly unfriendly, especially if your boot splash misbehaves. - X11 has security issues. No shock there, but it makes application isolation like Snap and Flatpak pointless. - Audio can be tricky. I was a PulseAudio early adopter and like it better than raw ALSA since it covers more use cases like Bluetooth and provides some extra features. That being said I've found it can be problematic on a lot of hardware, sometimes I lose audio until I kill pulse and it's hard to debug. Worse, lately some apps are having difficulty selecting their own input/output devices, making conference calls a nightmare. This is really just the beginning. Windows sucks too, don't get me wrong, but Linux is definitely not "so stable it hurts"
- asveikau 8y ago
  > I was a PulseAudio early adopter and like it better than raw ALSA since it covers more use cases like Bluetooth and provides some extra features. The last time I had Bluetooth audio actually work, it was before it needed to be routed through pulse. Alsa applications played Bluetooth audio just fine. Then at some dist-upgrade it pulled in a new bluez and that no longer worked, and I literally could not get it working through pulse. I actually have this experience 100% of the time with pulse: introduce pulse and everything breaks. When things talk to lower level pieces it works fine. By the way, alsa itself is a little bit of a case study in confusion between api and implementation... My freebsd machines are using the oss audio API with none of the problems that plagued oss on Linux in the 90s.
  - jchw 8y ago
    I am aware that there was a bluez-alsa adapter. I am sure it worked, but with pure ALSA there was a lot of issues that made hotpluggable audio devices tricky. I often had to mess with asound.conf and alsamixer to get things working correctly - and that sometimes also meant that I had to restart all my audio-using applications if I wanted to switch. And all of those problems occurred WITHOUT Bluetooth being thrown into the mix. I had multiple audio devices, including Intel HD Audio, an Audigy LS of some kind, and a USB microphone that presented it's own audio device to the system. (This was a while ago, I have no setups that look like this anymore.) I'd often have the devices come in a different order, and when this happened my mixer levels would be all messed up, and often times if I booted with the microphone plugged in... it'd be the default output device. With PulseAudio, I have less trouble - things do generally get setup how I expect it, and when they don't I can switch everything at runtime to be correct. It's worth noting that the trouble I have had with stability is heavily tied to hardware. Of course that doesn't mean it's not a PulseAudio issue, but I think a lot of people have trouble that they may not realize is not actually the normal PulseAudio experience. Even latency varies per hardware, in what I can only assume has something to do with how the audio hardware handles timings.
- qplex 8y ago
  I'll admit I'm happy with a basic desktop setup. Probably it's part of the reason why I don't have much trouble or complaints either. Linux has worked on x86 workstations _very_ well for well over 10 years, but it has always required some extra effort to configure etc. And yeah laptops... they work sometimes.

by qplex 8y ago

jchw 8y ago

Sure. If you run at 96 DPI, with a static monitor configuration, with a single GPU, no expansion cards, with English language only. However: - with multiple GPU configurations, all bets are off. - Thunderbolt docks and even the Thinkpad dock can be buggy and cause crashes. I've had a few instances of Xorg crashing on dock. - HiDPI sucks. Linux took the wrong approach from the get go. Now each Xorg client has to be DPI aware, but if it isn't, there is no graceful fallback. There's also no easy way to determine what the DPI should be, and any hopes that you can have monitors with differing DPIs is right out. Wayland tries to fix this, but in my experience so far things look blurry and horrible. - IME sucks really badly. It almost was good for a bit, with IBus. But now I don't even know what the standard is or how to configure it. How do I even get Japanese IME in KDE? I can get it working in GNOME but good luck getting that to work with apps that don't use GTK. - Sleep is still complicated. There are multiple DBus APIs for power management, and they're not compatible. GNOME does OK here. KDE does worse, and I find myself needing custom code to inhibit sleep in some circumstances. Not user friendly, though workable for me. - Resume is more complicated. - It feels like boot splashes have only gotten worse since the old days. Entering in LUKS keys is still weirdly unfriendly, especially if your boot splash misbehaves. - X11 has security issues. No shock there, but it makes application isolation like Snap and Flatpak pointless. - Audio can be tricky. I was a PulseAudio early adopter and like it better than raw ALSA since it covers more use cases like Bluetooth and provides some extra features. That being said I've found it can be problematic on a lot of hardware, sometimes I lose audio until I kill pulse and it's hard to debug. Worse, lately some apps are having difficulty selecting their own input/output devices, making conference calls a nightmare. This is really just the beginning. Windows sucks too, don't get me wrong, but Linux is definitely not "so stable it hurts"

asveikau 8y ago
> I was a PulseAudio early adopter and like it better than raw ALSA since it covers more use cases like Bluetooth and provides some extra features. The last time I had Bluetooth audio actually work, it was before it needed to be routed through pulse. Alsa applications played Bluetooth audio just fine. Then at some dist-upgrade it pulled in a new bluez and that no longer worked, and I literally could not get it working through pulse. I actually have this experience 100% of the time with pulse: introduce pulse and everything breaks. When things talk to lower level pieces it works fine. By the way, alsa itself is a little bit of a case study in confusion between api and implementation... My freebsd machines are using the oss audio API with none of the problems that plagued oss on Linux in the 90s.
- jchw 8y ago
  I am aware that there was a bluez-alsa adapter. I am sure it worked, but with pure ALSA there was a lot of issues that made hotpluggable audio devices tricky. I often had to mess with asound.conf and alsamixer to get things working correctly - and that sometimes also meant that I had to restart all my audio-using applications if I wanted to switch. And all of those problems occurred WITHOUT Bluetooth being thrown into the mix. I had multiple audio devices, including Intel HD Audio, an Audigy LS of some kind, and a USB microphone that presented it's own audio device to the system. (This was a while ago, I have no setups that look like this anymore.) I'd often have the devices come in a different order, and when this happened my mixer levels would be all messed up, and often times if I booted with the microphone plugged in... it'd be the default output device. With PulseAudio, I have less trouble - things do generally get setup how I expect it, and when they don't I can switch everything at runtime to be correct. It's worth noting that the trouble I have had with stability is heavily tied to hardware. Of course that doesn't mean it's not a PulseAudio issue, but I think a lot of people have trouble that they may not realize is not actually the normal PulseAudio experience. Even latency varies per hardware, in what I can only assume has something to do with how the audio hardware handles timings.
qplex 8y ago
I'll admit I'm happy with a basic desktop setup. Probably it's part of the reason why I don't have much trouble or complaints either. Linux has worked on x86 workstations _very_ well for well over 10 years, but it has always required some extra effort to configure etc. And yeah laptops... they work sometimes.