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

Major Linux Problems on the Desktop, 2016 Edition

linuxfonts.narod.ru

Post reply on HN
Print view View original

261–270 of 384 posts

Re: Major Linux Problems on the Desktop, 2016 Edition

#261

Post by TazeTSchnitzel »

Sanddancer wrote: post #242
incarnated wrote: post #74

Earlier quoted context omitted.

Tell me how one can update a Windows system (incl. all installed applications) in a straightforward manner. Windows comes with no package manager, as far as I know.

Yes, Windows doesn't come with a walled app repository. That's one of the benefits -- I don't have to ask Ubuntu and Debian and RedHat and god knows who else, "mother may I" before I write a program. I just do it. Though I do know people who now do get most of their apps from Microsoft's package manager these days.

You could have a system-wide update mechanism without a common repository. Linux distros have that: you can use as many different repositories from different vendors as you like, but there's still only one update command.

Re: Major Linux Problems on the Desktop, 2016 Edition

#262

Post by serge2k »

vezzy-fnord wrote: post #191
serge2k wrote: post #188

Earlier quoted context omitted.

I'm not, does he not like kernel debuggers or something?

"No" would be an understatement: https://lwn.net/2000/0914/a/lt-debugger.php3

> And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing.

That's insane.

Re: Major Linux Problems on the Desktop, 2016 Edition

#263

Post by serge2k »

vezzy-fnord wrote: post #226
addicted wrote: post #223

Earlier quoted context omitted.

That's a really interesting post, and I'm glad I read it. I find myself agreeing with Linus quite a bit, and until now I did not realize that there is programming being done without step by step debugging. And I think Linus's claims that people would be more careful when first designing and writing code if they didn't have a debugger to help them going forward makes a lot of sense. Unfortunately I work with too many…

The point is his view about kernel debuggers is complete nonsense, and I'm baffled that you and so many others could ever take it seriously. Yes, people would be more careful without debuggers, the same way they'd be more careful with cooperative multitasking hanging the system when they forget to yield. That doesn't make it good.

Quite often I read posts by Linus and find myself unable to take him seriously. He's arrogant, abrasive, and some of his opinions (security, debuggers apparently) are ridiculous.

Re: Major Linux Problems on the Desktop, 2016 Edition

#264

Post by xjia »

albinofrenchy wrote: post #245
vezzy-fnord wrote: post #133

Earlier quoted context omitted.

Kernel debuggers exist. Of course, we're all aware of Linus' opinion on the matter.

Not all debug tools are single step debuggers. There are memory verifiers, formal proof techniques and self testing frameworks that Linux uses that are very, very useful

What are those tools?

Re: Major Linux Problems on the Desktop, 2016 Edition

#265

Post by xjia »

derefr wrote: post #246
Animats wrote: post #62

He's right. Many of the driver problems come from the fact that Linux finally worked on the desktop about the time desktop machines were replaced by laptops. Desktops with slots tended to have relatively well-defined hardware, and plugging in third party hardware was normal. This is much less true for laptops. OS development for laptops requires that laptop. It needs a Q/A organization which has one of everything you…

> Microsoft got drivers under control with the Static Driver Verifier, which uses automatic formal proofs of correctness to determine whether a driver can crash the kernel. ... Linux has no comparable technology. That's a pretty cool idea (also similar to the static verification in NaCl.) Is there a reason one couldn't implement a static verifier for Linux drivers? Would the problem be harder in any sense for Linux,…

AFAIK MSR sponsored lots of research in this area. Program verification is still not that easy.

[edit] http://research.microsoft.com/en-us/projects/slam/

Re: Major Linux Problems on the Desktop, 2016 Edition

#266

Post by reedlaw »

As a developer I feel neither Windows nor Mac OS are ready for the desktop. Windows is almost completely useless and you need to immediately resort to Cygwin or a VM to get anything useful done. Mac OS is much more useful out of the box but lacks up-to-date packages and a good package manager. I haven't used Mac OS recently enough to comment on Homebrew, but the last time I tried it was no where near as robust as many Linux package managers are. Arch Linux has a huge amount of user-submitted packages so that even relatively unknown projects tend to be easy to install.

Re: Major Linux Problems on the Desktop, 2016 Edition

#267

Post by digi_owl »

chx wrote: post #49

I have one more which this article doesn't mention: Bluetooth. It's an extremely fragile house of cards (as far as I can figure, there are a few kernel modules, dbus, a bluetooth daemon and pulseaudio involved) and every upgrade you roll is extremely risky. Currently my BT works but after a day or so uptime it will simply stop working and nothing short of reboot helps. (More https://bbs.archlinux.org/viewtopic.php?id…

The basic thing is that Bluetooth didn't start on a multi-user OS. It started on Ericsson mobile phones.

And there it was at first basically a way to do handsfree without a wire.

From that you have OBEX from IRDA added to handle various data transfers, and a concept of profiles that are half in hardware half in software.

In essence the very design jumps back and forth between kernel/hardware and user space.

Still, the place of failure i most often encounter is something getting stuck in dbus. Meaning that i can restart all the daemons, but unless i restart dbus shit all changes once a failure happens. But restarting dbus at best kills my desktop, at worst reboots the computer (hello systemd).

Re: Major Linux Problems on the Desktop, 2016 Edition

#268

Post by rythie »

I'll add:

NFS home directories don't seem to be tested by KDE developers, taking 30seconds or so to start fully everytime you move machine because they generate stuff in /tmp.

Most programs don't take quota into account when calculating free space, and fail in weird ways when it gets exceeded

Cups password authentication can't send a prompt to the user. Windows did this in XP (OSX has this problem too)

Re: Major Linux Problems on the Desktop, 2016 Edition

#269

Post by Zigurd »

sunnyps wrote: post #114
Zigurd wrote: post #42

Earlier quoted context omitted.

Technically correct. But no Linux distro has so radically altered the userland as Android: One runtime and one UI stack for all apps. That might not be the only way to make Linux into a widely used consumer OS, but it is, by several orders of magnitude, the most successful approach so far.

There's another distro like that: ChromeOS :)

I was about to say that ChromeOS is a lot closer to being a conventional desktop Linux, with X11, blah blah blah... Good thing I checked that! I had not been paying much attention to ChromeOS and was surprised to learn of Freon.

Re: Major Linux Problems on the Desktop, 2016 Edition

#270

Post by FireBeyond »

awalton wrote: post #147
izacus wrote: post #28

Earlier quoted context omitted.

It's a single location summary of things that still have to be done / are lacking in the project. It's thus useful for contributors to see what needs work, since it's easy to get tunnel vision when working on a project. Don't you have such yearly reviews on your long-running projects?

It's mostly trolly though. I mean, read through some of his complaints: > No high level, stable, sane (truly forward and backward compatible) and standardized API for developing GUI applications Really? He's calling Win32 sane and stable ? The API where they're constantly having to introduce terrifying new hacks to stay bug compatible with themselves and still failing ? Most of it's the same trolls we hear every day.…

Yeah. Except he doesn't mention Win32 in this context. Does Win32 have to be sane/stable before Linux should have something adopted?
Post reply on HN