3 ms·

Most of the problems are valid, but some of them are... very much not, and haven't been for years (and others are "problems" but absolutely not "major" by any s

Most of the problems are valid, but some of them are... very much not, and haven't been for years (and others are "problems" but absolutely not "major" by any stretch). > NVIDIA Optimus technology which is used in most laptops often doesn't work well in Linux. Then stop buying them. My laptop (Intel + AMD) works fine w/ Mesa, regardless of which GPU I'm using (Intel iGPU by default, and AMD if I set DRI_PRIME=1 for a given application, e.g. in a game's launch options in Steam). NVIDIA's terrible. This whole section of the article seems to only describe issues with NVIDIA. If you buy hardware that's not shit, then lo and behold, you'll have a better experience. > Open source drivers have certain, sometimes very serious problems If "sometimes" means "basically never", then sure. I've "basically never" have had issues with Mesa on Intel or AMD hardware (I'm indeed running AMD hardware w/ Mesa on the very desktop on which I'm typing this comment, and it's been absolutely painless out-of-the-box). > PulseAudio is unsuitable for multiuser mode sudo killall pulseaudio Wow, so hard. Plus, the hyperlink for "multiuser mode" describes exactly how to launch PulseAudio system-wide to address this very concern (even if they do nonsensically advise against it, because of course they do). PulseAudio's shitty, but this ain't a reason. > There are still many printers which are not supported at all or only barely supported And there are many more which work just about perfectly out-of-the-box, namely almost everything by HP or Brother. > Resume after suspend in Linux is unstable and oftentimes doesn't work. On a wide variety of old and new laptops on which I've installed Linux this has simply not been an issue for years. > I have personally reported two serious audio playback regressions, which have been consequently resolved, however most users don't know how to file bugs, how to bisect regressions, how to identify faulty components. Most users will report bugs to their distros' maintainers, who hopefully know how to file these bugs against the kernel. > X.org allows applications to exclusively grab keyboard and mouse input. If such applications misbehave you are left with a system you cannot manage, you cannot even switch to text terminals. Alt+SysRq+R, then Ctrl+Alt+F1 Wow, so hard. Like, this works for even the absolute worst lockups (it's the first step of the "REISUB" maneuver to cleanly reboot a locked-up Linux system). > X.org has no means of providing a tear-free experience, it's only available if you're running a compositing window manager in the OpenGL mode with vsync-to-blank enabled. Sounds like a "means of providing a tear-free experience" to me. And, like, does this really warrant the double-exclamation-marks? God forbid you see a graphical artifact every once in awhile. > Applications (or GUI toolkits) must implement their own font antialiasing Applications might have different anti-aliasing needs. I see no problem with this. And again, this absolutely does not warrant double-exclamation-marks. > Wayland doesn't allow XWayland applications to change display resolution Good. > Wayland doesn't allow applications to exclusively grab mouse/keyboard which is required for games and applications like VMs. Were you not just complaining about X11 allowing this in the previous section? > Traditional Linux/Unix (ext4/ reiser/ xfs/ jfs/ btrfs/etc.) filesystems can be problematic when being used on mass media storage. Okay, so don't use them. JFFS2 has been in the kernel since 2001. F2FS has been in the kernel since 2013. Both are commonly used for flash media. You're also free to use FAT like you would on Windows; that's been in the kernel since forever. Not that this seems like a real issue anyway, given that I've used ext2/3/4 and XFS on thumb drives with no problems at all. ext2 is particularly useful if you're concerned about journaling shortening the drive's lifespan. > For the same reason you cannot modify your partitions table and resize/move the root partition on the fly. I've resized my root partition on-the-fly multiple times with zero issues whatsoever. The fact that I use LVM on all my desktops/laptops might help with that. > No unified installer/package manager/universal packaging format/dependency tracking across all distros The whole point of a Linux distro is to be able to differentiate on things like package management or system configuration. No package manager is perfect for all use cases. And besides, AppImage works on pretty much every distro that uses a reasonably-modern glibc, and literally doesn't care about the distro itself. If your concern is "well I don't want to have to build packages for each and every packaging system out there", then AppImage is your tool, so use it. > It should be possible to install any software by downloading a package and double clicking it Which is totally possible, thanks to things like AppImage (well, you download it somewhere and mark it executable, but wow, so hard). Hell, most distros support this even for .deb and/or .rpm packages. openSUSE also has 1-click installers, but it seems like they've fallen out of fashion (which is a shame, since they address this issue pretty dang elegantly). > Applications development is a major PITA. Compared to Windows? Linux (and Unix in general) is a breath of fresh air in comparison. A PyQt5 app (for example) takes me a few hours (total) to design and develop in Linux... and then days of nitpicky troubleshooting to get it working on Windows in a way that's reasonable for end-user distribution. > Packaging all dependent libraries is not a solution, because in this case your application may depend on older versions of libraries which contain serious remotely exploitable vulnerabilities. And yet this is exactly what Windows and macOS encourage, specifically to avoid the need for users to manage libraries. Like, you can't have your cake and eat it too; either you're gonna be dealing with dependency hell or you're gonna need to package libraries with applications. ---- Continued below...

yellowapple 6y ago
Continuing from above: ---- > No plug-and-play support for a lot of input devices like joysticks and steering wheels. Many require editing of cryptic configuration files. My Logitech F310 and my Saitek X52 both work out-of-the-box without any such "editing of cryptic configuration files". At most, I might need to set bindings in the game itself. This applies even with Wine/Proton (I'm able to play Ace Combat 7 with a controller - like God intended - with exactly zero configuration on my part). > Many anti-cheat protections fail to work under Linux. Tell that to Valve Anti-Cheat. > There's no concept of drivers in Linux aside from proprietary drivers for NVIDIA/AMD GPUs which are separate packages: almost all drivers are already either in the kernel or various complementary packages (like foomatic/sane/etc). Good. Like, how is this a bad thing? It's the very reason (well, one of many) why I prefer Linux over Windows for my desktops and laptops. > There's no guarantee whatsoever that your system will (re)boot successfully after GRUB (bootloader) or kernel updates That's much less of an issue with UEFI (where you're not mucking with boot sectors and such). And kernel updates haven't been an issue for me for years. > Samba is not native How is it not native? Just because it's "reverse-engineered" doesn't mean it doesn't ship with most/all modern distros and can be used for filesharing. > Steep learning curve (even today you oftentimes need to use a CLI to complete some trivial or non-trivial tasks, e.g. when installing third [party software]). The link is to a question that specifically asks how to do it through the command-line. The user didn't have to do it that way (Google has provided .deb and .rpm packages on chrome.google.com for as long as I can remember, and nearly all distros using either package format are able to graphically install such packages with a double-click). > Most well written GUI applications for Windows 95 will work in Windows 10 (24 years of binary level compatibility) And most "well written" GUI applications for Linux 1.2 (which is when Linux switched from a.out to ELF) will work in Linux 5.4.31 (24 years of binary level compatibility). The problem is that applications are rarely "well written"; there are plenty of poorly-written Windows applications that don't run on more modern versions, and Linux is no different. If your (statically linked) Linux 1.2 compiled application doesn't run on the latest-and-greatest Linux, then that's a bug of the "Linus will verbally abuse someone on the LKML" variety. > No standard way of software deployment (pushing software via SSH is indeed an option, but it's in no way standard, easy to use or obvious - you can use a sledgehammer to crack nuts the same way). So? There are plenty of options here, ranging from "pushing software via SSH" to widely-used and industry-standard tools like Puppet and Chef. > No CIFS/AD level replacement/ equivalent (SAMBA doesn't count for many reasons) Why doesn't SAMBA count? I've literally used SAMBA 4 as an AD domain controller in production (with Windows, macOS, and Linux domain members). Works fine. There's also FreeIPA, but I don't have as much experience with it (besides trying it out when it was first announced, during which point it was pretty buggy, though Fedora was probably just as much to blame). > No filesystems at all to support per-file encryption gpg --encrypt --sign --armor -r my@email.address wow-so-hard.txt openssl enc -in wow-so-hard.txt -out wow-so-hard.txt.enc -e -aes256 -pbkdf2 -pass 'pass:WOW SO HARD' Like yeah, I guess it's cool if the FS itself supports encryption, but this seems like it's best left to the application (and obviously end-users shouldn't be expected to run these commands themselves, but applications can certainly do so or - better yet - use the actual underlying libraries).

yellowapple 6y ago

Continuing from above: ---- > No plug-and-play support for a lot of input devices like joysticks and steering wheels. Many require editing of cryptic configuration files. My Logitech F310 and my Saitek X52 both work out-of-the-box without any such "editing of cryptic configuration files". At most, I might need to set bindings in the game itself. This applies even with Wine/Proton (I'm able to play Ace Combat 7 with a controller - like God intended - with exactly zero configuration on my part). > Many anti-cheat protections fail to work under Linux. Tell that to Valve Anti-Cheat. > There's no concept of drivers in Linux aside from proprietary drivers for NVIDIA/AMD GPUs which are separate packages: almost all drivers are already either in the kernel or various complementary packages (like foomatic/sane/etc). Good. Like, how is this a bad thing? It's the very reason (well, one of many) why I prefer Linux over Windows for my desktops and laptops. > There's no guarantee whatsoever that your system will (re)boot successfully after GRUB (bootloader) or kernel updates That's much less of an issue with UEFI (where you're not mucking with boot sectors and such). And kernel updates haven't been an issue for me for years. > Samba is not native How is it not native? Just because it's "reverse-engineered" doesn't mean it doesn't ship with most/all modern distros and can be used for filesharing. > Steep learning curve (even today you oftentimes need to use a CLI to complete some trivial or non-trivial tasks, e.g. when installing third [party software]). The link is to a question that specifically asks how to do it through the command-line. The user didn't have to do it that way (Google has provided .deb and .rpm packages on chrome.google.com for as long as I can remember, and nearly all distros using either package format are able to graphically install such packages with a double-click). > Most well written GUI applications for Windows 95 will work in Windows 10 (24 years of binary level compatibility) And most "well written" GUI applications for Linux 1.2 (which is when Linux switched from a.out to ELF) will work in Linux 5.4.31 (24 years of binary level compatibility). The problem is that applications are rarely "well written"; there are plenty of poorly-written Windows applications that don't run on more modern versions, and Linux is no different. If your (statically linked) Linux 1.2 compiled application doesn't run on the latest-and-greatest Linux, then that's a bug of the "Linus will verbally abuse someone on the LKML" variety. > No standard way of software deployment (pushing software via SSH is indeed an option, but it's in no way standard, easy to use or obvious - you can use a sledgehammer to crack nuts the same way). So? There are plenty of options here, ranging from "pushing software via SSH" to widely-used and industry-standard tools like Puppet and Chef. > No CIFS/AD level replacement/ equivalent (SAMBA doesn't count for many reasons) Why doesn't SAMBA count? I've literally used SAMBA 4 as an AD domain controller in production (with Windows, macOS, and Linux domain members). Works fine. There's also FreeIPA, but I don't have as much experience with it (besides trying it out when it was first announced, during which point it was pretty buggy, though Fedora was probably just as much to blame). > No filesystems at all to support per-file encryption gpg --encrypt --sign --armor -r my@email.address wow-so-hard.txt openssl enc -in wow-so-hard.txt -out wow-so-hard.txt.enc -e -aes256 -pbkdf2 -pass 'pass:WOW SO HARD' Like yeah, I guess it's cool if the FS itself supports encryption, but this seems like it's best left to the application (and obviously end-users shouldn't be expected to run these commands themselves, but applications can certainly do so or - better yet - use the actual underlying libraries).