Linux Problems on the Desktop (2018) • Hacker News Board

Re: Linux Problems on the Desktop (2018)

#351

Post by godelski » Mon, Feb 25, 2019, 8:01 PM UTC

rbanffy wrote: post #346

shrimp_emoji wrote: post #142

Earlier quoted context omitted.

I was surprised when I saw the newest Vega firmwares show up in my /lib/firmware/amdgpu/ with a kernel update only 6 days after the release of the last AMD GPU -- and on Manjaro, where updates are supposedly delayed a little. AMD touted "day one Linux support", which I don't know if they fulfilled, but they're certainly more committed to Linux than Nvidia. Unfortunately, Nvidia's so dominant (and rightly-so from a pr…

> price-per-performance unit standpoint You know... If the thing doesn't work, price doesn't matter that much. I prefer something more reliable that's not as fast (I've been using Intel GPUs for many years now)

So that being said, I may not be able to use the HDMI port, but CUDA works great.

Re: Linux Problems on the Desktop (2018)

#352

Post by AsyncAwait » Mon, Feb 25, 2019, 8:12 PM UTC

sametmax wrote: post #274

rbanffy wrote: post #249

Earlier quoted context omitted.

> The Linux community has been in denial about this for years. That's not right. We all know support for some hardware is spotty and we all have learned to avoid that. My laptops tend to use Intel GPUs, for instance, because I want to work on them, not fix them. I'm eyeing that new Lenovo thingie with an epaper keyboard, but I know it'll run Windows and probably never be upgraded because nobody will write the drivers…

> Nope. It's still moving forward and it's still quite reliable. All my workloads run on it (except my pets that run on FreeBSD and OpenIndiana because I get a kick out of managing different OSs). That's the denial there. I'm a Linux guy. I post this from a linux distrib. But realistically, we do have a huge amount of technical debt, and less and less incentive to work on them. Case in point: every time we touch some…

> Case in point: every time we touch something to improve it, we break things for one year or two. Pulse audio ? Took 4 years to be stable.

Honestly, it seems to me like what you're complaining about is the nature of FLOSS development i.e. we do it in the open and collect feedback from users rather than spending billions we don't have on focus groups.

Also, I remember early PA days and it certainly did not take 4 years to be usable, but it did took Ubuntu about that time to get it right. That's however a problem of holding Ubuntu as the Linux disto, which is honestly a whole separate rant I could get into.

As for systemd and 3 years, I am honestly not sure what you're talking about. I've been on it since 2012 and it has been mostly smooth sailing since the beginning.

Re: Linux Problems on the Desktop (2018)

#353

Post by AsyncAwait » Mon, Feb 25, 2019, 8:15 PM UTC

pjmlp wrote: post #339

bluedino wrote: post #280

Earlier quoted context omitted.

I really want to know how GNOME 3 even saw the light of day, and why distros like Fedora even went with it. Unusable.

Easy, Red-Hat used to pay the salaries for a big chunk of GTK/GNOME developers.

GNOME 3 is also far from universally deemed unusable, (I use it daily with great success), despite what the propaganda would have you believe.

Re: Linux Problems on the Desktop (2018)

#354

Post by pjmlp » Mon, Feb 25, 2019, 8:27 PM UTC

AsyncAwait wrote: post #353

pjmlp wrote: post #339

Earlier quoted context omitted.

Easy, Red-Hat used to pay the salaries for a big chunk of GTK/GNOME developers.

GNOME 3 is also far from universally deemed unusable, (I use it daily with great success), despite what the propaganda would have you believe.

I tried to use GNOME 3 after Ubuntu dropped Unity, and it never performed like Unity, hence I am now using XFCE.

The latest updates, show there is still work left to do in this area,

https://discourse.ubuntu.com/t/monday-25th-february-2019/995...

Re: Linux Problems on the Desktop (2018)

#355

Post by Animats » Mon, Feb 25, 2019, 8:32 PM UTC

rbanffy wrote: post #343

Animats wrote: post #191

Earlier quoted context omitted.

Desktop is a dying market. Actually, tablets are a dying market.[1] Laptops are a declining market. Fewer desktops are being sold, but they're lasting longer because there's no reason to replace them. [1] https://www.statista.com/statistics/272595/global-shipments-...

So, as we move forward, all these desktops will end up having stable and mature support. Drivers are often lacking for bleeding edge components, but stuff that was released 3 or 5 years ago tends to be very solid unless it's something obscure nobody has ever seen.

Microsoft doesn't want you to have stable and mature support. They want you using the latest everything and paying for it each month. Microsoft pushed hard to force users to upgrade to Windows 10.[1] Even today, many enterprise users refuse to convert. They don't want Microsoft's new rent, rather than own, software. They don't want Microsoft looking into their machines. They don't want to store corporate data in Microsoft's cloud. But they will convert, like good sheep.

[1] https://www.forbes.com/sites/tonybradley/2016/01/22/resistan...

Re: Linux Problems on the Desktop (2018)

#356

Post by kakwa_ » Mon, Feb 25, 2019, 8:36 PM UTC

The Linux Desktop has problems, yes, but that's Ok.

We just have to accept that Linux will never be a mainstream desktop environment.

A desktop environment needs a well polished experience. And this experience can only be created by centralized organizations with extensive resources, like developers, QA, designers, ergonomist, user's behavior studies and a common and consistent vision of what the experience should look.

In the Linux DE world, a project can consider itself lucky if it has enough developers.

Yet, these developpers are doing a wonderful job, specially given the lack of resources, with applications that are more than usable and can solve 90% of use cases.

Yes, Linux DEs are sometimes a little clunky, and the overall experience might encounter issues not solvable by the average user. But that's Ok, having a well polished experience would require an order of magnitude more resources, and an organization far more vertical than the existing array of communities.

Diverting so much resources for the DE goal would be a mistake. Even if by some miracle we manage to solve all the issues mentioned, we would be "X but different/better", and this business model doesn't generally do so well, it will not displace Windows/Mac OS.

Linux and the OSS ecosytem should remain what it is today: a powerful and rich toolbox to build things from giant web services or phones to Vacuum cleaners, cars or milking machines, and this toolbox should keep improving.

It doesn't mean we should not look around and see what is happening around us in the DE world, but it should not be the absolute priority. Building a Linux desktop should not jeopardize the use cases that made Linux a success.

Linux is a clunky Desktop Environment, yes, but this clunky environment has enabled me to build software reaching thousands of people.

Thank you to all the devs who have built this (mostly) working experience.

Re: Linux Problems on the Desktop (2018)

#357

Post by Mister_Snuggles » Mon, Feb 25, 2019, 9:40 PM UTC

meditate wrote: post #337

Mister_Snuggles wrote: post #269

Earlier quoted context omitted.

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 mappi…

There is currently no kernel interface that I know of to do that, and I don't think it would be too hard to hook into an open() on an invalid path and try to do something (mount a network fs, call out to GVfs or KIO, etc), but I can tell you you will meet resistance if you try to because things like "//stuff" and "smb://stuff" are already valid local file paths in Linux. So I leave it up to you to figure out how to d…

Yeah, this is definitely not an easy problem to solve given the design of Linux.

I don't know why I didn't remember this earlier, but I actually explored this a number of years ago and came up with two things that are close, but not quite there:

First was to use a systemd automount unit[0], but I didn't really get anywhere with it. From the looks of it you have to know all the possible things you could want to automount, it can't do wildcards. Being able to do some kind of pattern matching on the requested path and translate that into a mount command would go a long way to making this work.

I also explored the good old automounter[1][2], but it has a lot of the limitations that systemd's does. It does have the advantage of supporting host maps, which gets me a bit closer to what I'm looking for. The unfortunate thing that remains is that this is NFS instead of a modern protocol. If this were somehow backended on sshfs, I suspect it would be quite useful. Of course, sshfs is missing the concept of shares but that's not a showstopper by any means. Authentication becomes a problem since the automounter probably can't ask the user for a password, and may not even know which user is requesting the mount.

I have no idea how well either will work in practice. Modern Linux on the desktop is a very different environment than the one the automounter and NFS were built for. The systemd automounter looks like it serves a very specific purpose and can't currently do what I want.

Maybe all we really need is a modernized automounter and/or some extra features in systemd's automounter. These could lead to to "vi /net/server/share/file.txt" working as expected which, quite honestly, is basically the same as what I suggested earlier.

[0] https://www.freedesktop.org/software/systemd/man/systemd.aut...

[1] https://linux.die.net/man/8/automount

[2] https://linux.die.net/man/5/auto.master

Re: Linux Problems on the Desktop (2018)

#358

Post by ilovecaching » Mon, Feb 25, 2019, 10:57 PM UTC

pjmlp wrote: post #327

ilovecaching wrote: post #325

Earlier quoted context omitted.

> Amazon could rebuild AWS on top of hypervisors Um, what? > BSD or what have you and none of those users would notice FaaS and CaaS doesn't negate that there is a kernel API you're interfacing with. It absolutely makes a difference. Claiming that kernels are completely interchangeable is extremely naive, but then again, your first statement about hypervisors is so absolutely, confusingly incorrect that it's difficul…

If you prefer the full description, type I hypervisors with unikernels.

Of course, how could I have not inferred unikernel from hypervisor, how silly of me.

Re: Linux Problems on the Desktop (2018)

#359

Post by baroffoos » Mon, Feb 25, 2019, 11:25 PM UTC

Animats wrote: post #191

ilovecaching wrote: post #107

Earlier quoted context omitted.

Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX. But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts. The DE has gotten much better transitively from all the work that’s…

Desktop is a dying market. Actually, tablets are a dying market.[1] Laptops are a declining market. Fewer desktops are being sold, but they're lasting longer because there's no reason to replace them. [1] https://www.statista.com/statistics/272595/global-shipments-...

This seems right. Apart from store PoS systems I haven't seen a tablet in years and my desktop is 5 years old without any signs of needing replacement. I think it might last another 5 years.

Re: Linux Problems on the Desktop (2018)

#360

Post by Dahoon » Mon, Feb 25, 2019, 11:36 PM UTC

AnIdiotOnTheNet wrote: post #112

Dahoon wrote: post #16

> "most Windows 95 applications still run fine in Windows 10" Uhm, no. Not really. With hacks by the user (or OS) maybe, but if hacks are allowed then most of that list can be deleted.

Actually yeah, lots of software that was compiled for Windows 95 really does still run fine on Windows 10. Games are a big exception. What doesn't work is 16-bit Windows applications, at least not without DOSBox.

Yes lots of programs still work if you just do this little thing and maybe this little hack which is the same as not working unless you use hacks. Which brings us back to what I wrote.