Live data from Hacker News

Linux Problems on the Desktop (2018)

itvision.altervista.org

261–270 of 402 posts

Re: Linux Problems on the Desktop (2018)

#261
post #256

I use Linux for gaming almost everyday with Steam/Proton. It works flawlessly 90% of the time. I find no issues with my linux desktop whatsoever. It is stable, I rarely restart it, updates so far didn't break a thing.

To be viable as a general desktop environment for non-technical users, that has to be true not just for some users like yourself, but for all but about a few in a thousand users across a very wide cross section of available hardware.

> across a very wide cross section of available hardware

This is a sticking point I just cannot get behind. When you're purchasing a computer running Windows, it is optimized for Windows. When you're purchasing a Mac, it is optimized to run macOS.

So it should logically follow that if you want hardware optimized to run Linux, you should purchase that specifically. Expecting Linux to work flawlessly on any random junk is a feat you're not expecting of any other OS.

Therefore by that logic, for Linux to be good enough on the desktop, it has to ascend to places no other OS does.

Re: Linux Problems on the Desktop (2018)

#262

PS4 is basically a modified Free BSD. So, "fixing" Linux desktop is probably doable, but extremely difficult to profitably do. Valve seemed interested when Windows introduced the App store and seemed to be going App store / Play store way, but now that Microsoft is losing interest in Windows, they don't have as much incentive to pursue Linux.

PS4 is not really comparable. (Nor is macOS, for that matter.) It's one thing to get some *nix flavor to work on standardized hardware. It's another to make it work on the wide variety of computing devices where you could install Windows.

Re: Linux Problems on the Desktop (2018)

#263
post #9

How about a list of all the things that really work great? I've been using Linux on the desktop for nearly 20 years and I'll have to say it's fantastic, despite the occasional headache, which seems to be at a far less frequency than other major desktop operating systems.

Note that the same author also lists all the problems for Windows 10 (http://itvision.altervista.org/why-windows-10-sucks.html), so at least he's holding equal ground. Think carefully about the pros and cons, and then choose one (Or maybe both, if you are willing to dual-boot or use a VM)

Re: Linux Problems on the Desktop (2018)

#264

> Android is not Linux I really, _really_ hate this statement. Android meets the only definition of 'linux' that matters IMO: it runs on a linux kernel. That's linux, full stop. That said, I do find myself agreeing with most of the points listed there. I just not sure I'd call them 'linux on the desktop' issues per se. They're wayland/xorg issues, deb/rpm/flatpack/snap issues, pulseaudio/alsa issues, gtk/qt issues, e…

> Android meets the only definition of 'linux' that matters IMO: it runs on a linux kernel. That's linux, full stop.

So what do you think of WSL ? It has all the things of an Ubuntu, but it does not run a Linux kernel.

Re: Linux Problems on the Desktop (2018)

#266
post #256

Earlier quoted context omitted.

To be viable as a general desktop environment for non-technical users, that has to be true not just for some users like yourself, but for all but about a few in a thousand users across a very wide cross section of available hardware.

> across a very wide cross section of available hardware This is a sticking point I just cannot get behind. When you're purchasing a computer running Windows, it is optimized for Windows. When you're purchasing a Mac, it is optimized to run macOS. So it should logically follow that if you want hardware optimized to run Linux, you should purchase that specifically. Expecting Linux to work flawlessly on any random junk…

If the point is that this is a problem for vendors to solve, not the Linux desktop community, then that's fine. I can live with that.

Re: Linux Problems on the Desktop (2018)

#267
post #118

"Linux has a 255 bytes limitation for file names (this translates to just 63 four-byte characters in UTF-8) - not a great deal but copying or using files or directories with long names from your Windows PC can become a serious challenge." Not sure what he is speaking about.

File and folder names can't be longer than 255 UTF-8 code units in Linux, which means they can contain 255 US-ASCII characters, but only 127 Cyrillic characters, 85 Chinese characters, or 63 emoji. In Windows it's different, because file names can contain up to 255 UTF-16 code units. This is 255 characters in almost every language (but only 127 emoji.) So, if you create a file name with 100 Chinese characters in Windows, you can't transfer it to Linux (or upload it to a Linux web server, for example.)

Windows, on the other hand, has problems when the full path to the file (eg. C:\folder\file) is more than 259 UTF-16 code units, but it's getting better at this, and newer Windows apps normally handle longer paths just fine.

Re: Linux Problems on the Desktop (2018)

#268

I wish that there would be one unified API for creating desktop programs on Linux. Right now it's somewhat coalesced on GTK/GNOME and Qt/KDE, though there are a number of others out there. I use Linux in a VM for very hobbyist level embedded development (think Arduino and the like). Driver problems are non-existent, all of the technical problems are non-issues in this environment. The problems that I see are all to d…

"On Windows, you can basically use a UNC path" How about NFS in Linux? It's a lot more transparent than SMB will ever be in Windows. SMB is and will remain a Windows feature.

These aren't the same thing.

In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive).

Re: Linux Problems on the Desktop (2018)

#269

Earlier quoted context omitted.

You're absolutely right. I wonder if something like DBus and PulseAudio could happen with my UNC pain point. With the assumption that the goal is for "vi //server/share/file.txt" to work the same as "notepad.exe \\server\share\file.txt" does on Windows, here are my thoughts. First off, notepad.exe doesn't really care about the fact that it's a UNC path. It just opens the file with CreateFile (either CreateFileW or Cr…

All that has been doable for quite some time, you could mount SMB shares like that with smbfs since early releases of Samba, and later with the CIFS fs driver. You do need root to mount things that way, so it isn't ideal. For the more complicated stuff it can be done but not everything is available via a simple GUI. GNOME and KDE have their own virtual filesystem layers in userspace, GVfs and KIO, I don't know what K…

These aren't the same thing though. The GNOME and KDE VFS layers only apply for applications written for those APIs. It's not a universal thing.

Being able to mount a CIFS filesystem is fine, but it's not the same thing. In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive).

What I'm really looking for is the user experience, not the underlying protocol. On Windows, I can just go "notepad.exe \\server\share\file.txt" and edit the file, on Linux I need to either use a KDE application or go through the ceremony of mounting the remote filesystem. It's the fact that the feature is silo'd into GNOME and KDE (and the fact that it doesn't even exist on Mac OS, but that's another issue) that bugs me.

Re: Linux Problems on the Desktop (2018)

#270

I wish that there would be one unified API for creating desktop programs on Linux. Right now it's somewhat coalesced on GTK/GNOME and Qt/KDE, though there are a number of others out there. I use Linux in a VM for very hobbyist level embedded development (think Arduino and the like). Driver problems are non-existent, all of the technical problems are non-issues in this environment. The problems that I see are all to d…

Windows doesn't have that kind of unique standard either. Both KDE and GNOME have user interface guidelines. If Software doesn't follow it, well...

In recent years, Windows has become a mess in the UI space. Mac OS X has fared a little better, but it's also becoming a mess.

It makes me sad. Years ago programs written for either operating system tended to follow the UI standards pretty well, with the main exception being games. Microsoft started to try new things with Office, so if you wanted to see where the standard was going you just had to look at where Office was.

Post reply on HN