Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Problems on the Desktop (2018)

itvision.altervista.org

Post reply on HN
Print view View original

151–160 of 402 posts

Re: Linux Problems on the Desktop (2018)

#151

Post by JonathonW »

coryrc wrote: post #57
jrockway wrote: post #27

I feel like a lot of the usability quirks that Linux has are trying to shoehorn a multi-user system into a single-user context. For example, there is so much work done (and even complaining in favor of doing that work in this article) to make it possible for multiple people to sit at the same computer. Nobody does that! Most people have more than one computer! Why do people spend their free time on that use case? Thi…

You got downvoted, but I mostly agree. I think mandatory strict selinux rules, containerize all user programs, or similar approaches are now more important for the threat vectors we face today on the desktop. I just discovered Apple's feature of requiring you to press a couple keys to authenticate a new keyboard. Doing that on GNU/Linux would be very hard.

That dialog (the "your keyboard cannot be identified" dialog) is about layout detection, not "authentication". IIRC, it's also skippable (but I haven't seen it in a long time; I've mostly switched over to Apple keyboards and they don't trigger that dialog).

Re: Linux Problems on the Desktop (2018)

#152

Post by Mister_Snuggles »

meditate wrote: post #123
Mister_Snuggles wrote: post #90

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…

>someone to make a decision about the one true way to do things. Things don't really work this way in free and open source development. There is no one person to make decisions, consensus is reached when the quality of something raises "above the bar" and actually improves things for all involved parties. If someone wants there to be an über-library that serves everyone's use case then it's up to them to go and do th…

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 CreateFileA).

There would need to be replacements for the libc file functions. These could be a shim in front of libc, or baked right into libc. Note, there's a LOT more needed than "just" new file functions - any functions that do anything with paths need to be looked at. Shells would likely need some changes to work properly, though it's not like the Windows shell can truly do much with UNC paths - copying files to/from works, but you can't cd into them.

How does it ask for credentials? If it's via DBus, a desktop environment provide the authentication prompts, but what about a pure-commandline system? Maybe the transport is just SSH and relies on the existing public key authentication? But what if you're just doing a one-off thing and don't want to set that up? Using SSH is probably a decent idea since it's got authentication, security, and a file transfer protocol, already built in.

On top of all of this, when you open //server/share/file.txt for writing, what does that actually mean? Is there a file descriptor? How does that work with the kernel? Does libc now manage all file descriptors with only a subset corresponding to kernel file descriptors? Could a pure user-space solution fake this well enough to actually work? Would this need to be a FUSE filesystem along with some daemon to automatically unmount the remote servers when the mount is no longer needed? Would it be something like the automounter, just a lot better? Does a kernel need changes for any of this to work?

This is one of those things that touches so many layers and potentially interacts with so many parts of the system, potentially all the way down to the kernel.

My guess, and I don't actually think this will happen, is that Apple will do something like this on Mac OS X and have a reasonable mapping to the BSD world underneath, then someone in the Linux community will come along and do something similar in a way that's better suited for Linux. As a parallel, Apple came out with launchd in 2005 to replace init scripts, systemd made an appearance in 2010 - both do very similar jobs, with launchd tailored to the needs of MacOS and systemd tailored to the needs of Linux. Maybe something similar could happen with UNC-like file sharing.

Re: Linux Problems on the Desktop (2018)

#153

Post by hartator »

yjftsjthsd-h wrote: post #138
hartator wrote: post #68

Earlier quoted context omitted.

If you need the last version of Wireshark, it’s getting complicated. And when you have a setup with Wireshark that works why update it? I am dubious that Wireshark can be an attack vector so security updates won’t be useful. Installing last versions is very straight forward when you are on Osx or Windows. You just go to the website and download it. Plus you get the original binaries not a doctored version to fit what…

> And when you have a setup with Wireshark that works why update it? I am dubious that Wireshark can be an attack vector so security updates won’t be useful. Ignoring feature enhancements and bug fixes for a moment, do you really think it improbable that there are security issues in a piece of software whose entire job is to sit on the network and record everything that it sees and then translate and interpret it?

If an evil app is already communicating on the web and is already on your computer, what can it gain more?

Re: Linux Problems on the Desktop (2018)

#154

Post by p2t2p »

jrockway wrote: post #27

I feel like a lot of the usability quirks that Linux has are trying to shoehorn a multi-user system into a single-user context. For example, there is so much work done (and even complaining in favor of doing that work in this article) to make it possible for multiple people to sit at the same computer. Nobody does that! Most people have more than one computer! Why do people spend their free time on that use case? Thi…

I dunno, I would like to be able to have a restricted account to give it to my daughter. Same for mobile device - she's too young to have her own but I would like to give her my iPad to run YT Kids for example and only that so some kind of multiuser-ness is needed but a different one. I'd say SE linux tries to achieve that but it is far from being usable.

Re: Linux Problems on the Desktop (2018)

#155

Post by eitland »

diffeomorphism wrote: post #150
pnutjam wrote: post #71

Earlier quoted context omitted.

Try OpenSuse, it has the best hardware support by far.

Why would it? Hardware support boils down to new kernels, mesa stacks etc and how many non-free drivers the distro wants to include. Opensuse (Leap) is not particularly cutting edge and is more restricted concerning non-free components than many other distros (e.g. why does it need pacman?). So, no. It does not have "the best" hardware support and no distro has "by far" more hardware support than all other distros.

> Why would it? Hardware support boils down to new kernels, mesa stacks etc and how many non-free drivers the distro wants to include.

Disagree. At least traditionally package choice and configuration by distro maintainers made a huge difference, as proven by the fact that problems could be solved by just fixing a config file or adding a package from the standard repo.

Re: Linux Problems on the Desktop (2018)

#156

Post by AnIdiotOnTheNet »

JonathonW wrote: post #146
AnIdiotOnTheNet wrote: post #111

Earlier quoted context omitted.

Right? The only reason user accounts exist at all in Desktop OSs is that all of them today were originally server OSs. Placing restrictions on user accounts is only useful for protecting the system from users, which is a valid concern on a network with shared resources but worse than useless on a personal desktop. Mobile OSs got this right: on a personal device, the permissions model should be applied to the applicat…

> Placing restrictions on user accounts is only useful for protecting the system from users, which is a valid concern on a network with shared resources but worse than useless on a personal desktop. True for home users; not necessarily true for corporate users-- where computers are IT-managed (i.e. "don't let end users fuck them up") and may be shared (which is highly situational-- the degree to which computers are s…

A few things, since I work in IT: we don't give a damn about your workstation. It's a fungible resource. Reimaging is easy and relatively quick. We even let you have local admin because who cares. Users are not prone to playing around with settings they don't understand, in my experience. If someone was constantly needing their workstation reimaged we'd probably just fire them for being incompetent. Ideally, the OS would be completely separate from the applications and configuration and be immutable, and that would go a long way towards eliminating those kinds of problems.

We managed to share home desktop computers in the 90s without significant problems, even though the OSs we used didn't support multiple user accounts at all. And there's no reason you need user accounts to accomplish what you're describing. You can still have profiles (preferences, application configs, etc), and you can encrypt them with a passphrase if you have any reason not to trust others using the same device.

> Heck, it's not even unheard of to end up with multiple "simultaneous" users on a single-seat desktop machine

A vanishingly small use case inside an already vanishingly small use case.

Re: Linux Problems on the Desktop (2018)

#157

Post by smallbigfish »

Mister_Snuggles wrote: post #90

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.

Re: Linux Problems on the Desktop (2018)

#158

Post by vertex-four »

copperx wrote: post #147
darkpuma wrote: post #136

Earlier quoted context omitted.

It's an Nvidia problem. Nvidia's proprietary drivers suck and they're nasty to anybody who tries to develop open source drivers for their cards. AMD and Intel GPUs have been flawless plug-and-play for years now. AMD plays nice with linux developers and you should give them, not Nvidia, your money.

The TFA mentions video issues as Nvidia/AMD's fault. To a reader, it might seem they are equally bad.

While it says that, it doesn’t actually link to anything about the modern amdgpu driver - developed officially by AMD and now part of the vanilla kernel - and the majority of the complaints are regarding nvidia.

Re: Linux Problems on the Desktop (2018)

#159

Post by eitland »

cheerlessbog wrote: post #13
smlacy wrote: 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.

I'm guessing you're relatively tech savvy and enjoy troubleshooting (within reason). Most people aren't, of course.

I've said for years that Linux works for grandmothers, and for me (and a bunch of others).

It doesn't work for people who:

- need a locally installed copy of MS Office or other Windows only software

- IT admins that stopped learning a long time ago

- etc

As others point out, for som of us using Windows or Mac is a hassle. They're slow (30% longer compile cycles, don't even get me started on git), missing important customizability,m no built in universal package management etc.

Re: Linux Problems on the Desktop (2018)

#160

Post by AnIdiotOnTheNet »

ilovecaching wrote: post #144
ThrowawayR2 wrote: post #143

Earlier quoted context omitted.

> Linux is literally the most used operating system on phone... So what happens if/when Google switches to Fuchsia on their phones?

At this stage, I’d say I’ll believe it when I see it. I don’t doubt that Google has the capacity, but replacing a kernel that works is fraught with peril, and it could very well be that Fuschia remains yet another Google research project.

I think the point is just that the Linux kernel is irrelevant to the Android operating environment. It could run on anything Google wants it to and may do so in the future.
Post reply on HN