Live data from Hacker News

Major Linux Problems on the Desktop, 2016 Edition

linuxfonts.narod.ru

61–70 of 384 posts

Re: Major Linux Problems on the Desktop, 2016 Edition

#61
I don't understand - I never see a mention of the biggest annoyance to developers on linux : consistent copy paste. It is a cognitive exercise to copy from the terminal or paste to the browser...or (the horror) copy from the terminal and paste on vim.

It does not help that this works beautifully on the Mac.

Is this not an annoyance to anyone else...and more importantly, considering all distros are now using libinput,can I compile my own libinput that will universally copy paste using win+c ?

Re: Major Linux Problems on the Desktop, 2016 Edition

#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 support. Linux lacks that.

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. (The driver may not control the device correctly, but at least it won't blither over kernel memory or make a kernel API call with bogus parameters. So driver bugs just mean a device doesn't work, and you know which device and driver.) All signed Windows drivers since Windows 7 have passed that. This has eliminated most system crashes caused by drivers. Before that, more than half of Windows crashes were driver related. Linux has no comparable technology.

The monolithic Linux kernel is just too big. What is it now, 20,000,000 lines? There's no hope of debugging that. It shows.

Re: Major Linux Problems on the Desktop, 2016 Edition

#63
When you think Gnome, you probably think Fedora. Fedora and Gnome are buddy-buddy, and being basically the upstream of RHEL makes it the place to be if you are big on Gnome. KDE has Kubuntu, kind of, since its sponsored by Blue Systems, but there is a huge issue with how KDE is presented to users in that the Ubuntu release cycle has no correlation to the KDE one, and since Plasma 5 has started shipping in Kubuntu that problem has become a catastrophic deal breaker. The KDE community made a great move by breaking up the release cycles of frameworks / plasma / applications, but Ubuntu itself does not care - which lead to releases like 15.04, where 5.2 was shipped despite 5.3 coming out the same week and being significantly more stable, but Kubuntu users would never see that release until 6 months later. Now, 5.5 is out a few months after 15.10, and again a much more stable release won't see Kubuntu until April of next year.

I'm pretty high on the KDE koolaid, and contribute a lot to the project, and it is the most painful experience to know there is no actual answer to the question of what distro I should be recommending to people for a KDE experience. A sane KDE distro should be shipping these new updates after a testing period - all at once, preferably, I use Arch mainly but its release model also conflicts with KDEs since - for example - 5.5 came out developed against upstream Frameworks which eventually released weeks later as 5.17 (frameworks are released monthly), but 5.5 with 5.16 was broken as hell. Applications 15.12 came out weeks later after that, and were a seamless upgrade because they were also developed against the same Frameworks version, but they were already available and thus everything went swimmingly.

Fundamentally my point is that I imagine despite Fedora and Gnomes friendliness, the problem happens there too. It doesn't hurt that software availability on Fedora is awful and it is not presented at all as a consumer desktop since its more of a test bed for RHEL. Distros today are shipping around either fixed releases - that because of the fragmentation of the ecosystem nobody is targeting upstream - or around arbitrary goals, which can be years of waiting (cough, Suse, Fedora). But on the flipside an average user almost certainly does not want a fully rolling release like Arch, because breakage in Arch often doesn't stop a package from being pushed to release (and often those bugs are missed because Arch doesn't have enough users of testing to catch everything) and the constant churn means your system only works precariously in its current configuration - trying to roll back anything on Arch is insanely hard, because everything is built against the latest and greatest of everything else. Thus, there remains significant value in releasing updates at once.

What I really wish we had was Kubuntu, sponsored by Blue Systems, just with updated userspace software on a regular basis (feel free to freeze the LTS, or even have two repos at install - frozen or not) This problem is mentioned in the OP, but it can be soul crushing for a developer in this purgatory because your fixes and improvements may not see the light of day for almost a year or more.

Personally I'd love to see an Arch derivative (since it has IMO the least age rot and bloat of modern distros, cough Suse /etc/init.d after having systemd for years) that just did frozen monthly releases. You release, you wait two weeks, you freeze, you test, you release again all at once. Users get latest and greatest but you can also hold back anything broken until its unbroken. But that kind of commitment requires work, the kind of work you cannot just throw on hobbyists and hope gets done, the kind that needs salaries and business. I still wonder why there isn't any commercial presence of full stack computer vendors of Gnome / KDE - boutique vendors that ship distros running non-Ubuntu that then use their revenue to develop it.

That was a lot of typing, but just some anecdotal remarks:

Linux grsec is the greatest security project ever, and nobody supports it. Selinux / Apparmor / Tomoyo are all trash by comparison, and Arch's stock kernel doesn't even have MAC at all. It is also probably the greatest notch in Linux's belt over Windows that it can be objectively secure, when you actually care about security cough Wayland. There is a distro I see in my dreams that has secure packages, user repositories, and PAX enforcement to prevent malware from accessing anything but its own personal .config file and .share directory. Users can install their own packages rather than having to install them systemwide, but the package manager is smart enough to promote software installed by multiple users to a shared hierarchy rather than duplicating space usage. And the filesystem layout makes sense (/usr...).

xdg-app is supposed to be this pancea that saves the desktop from application fragmentation. It should give us sandboxing, appstream metadata dependencies so we don't need insane duplication of all the system libraries like in click packages, and a puppy. Lets see if that ever happens.

Audio will never get better. Just use pulseaudio and fix it where you can. I'm working on improving plasma-pa for KDE right now to make it more like the old Veromix widget (which was great). It already does its job of catching ALSA applications that would try to steal the soundcard, and rather than try to throw away all the work that went into it we just need to make it suck less.

Re: Major Linux Problems on the Desktop, 2016 Edition

#64

Earlier quoted context omitted.

I've got a windows 10 machine with a pretty fast NVMe SSD. It takes 10 seconds to get to the login screen, and another three minutes to load up all of the services that are set to run on login. I'm convinced that the NTFS driver must be a nightmare of blocking I/O.

That's definitely not the norm. On both my Windows 10 machines the desktop becomes usable within seconds after login. Might be worth having a look at what's taking so long on your machine... As far as I remember there is even a Microsoft tool that highlights startup jobs that are slow to run, isn't there?

Autoruns: https://technet.microsoft.com/en-us/sysinternals/bb963902.as...

Re: Major Linux Problems on the Desktop, 2016 Edition

#65
post #18

I've been using Linux on the desktop daily since about 1998. It may look a little prettier today, but I find it crashes and freezes a whole lot more these days.

In my experience the kernel and drivers are better than ever, but the desktops are awful and have grown worse. When KDE 4 came out I went to simple window managers like i3 and fvwm. These are extremely stable but things as simple as looking at photos in file manager are painful, and forgetting how to change the clock when I fly to a new timezone is frustrating.

Re: Major Linux Problems on the Desktop, 2016 Edition

#66
post #53

Earlier quoted context omitted.

What would consider entry level? I use a Mac mini from 2012 (i7 with 8GB) every day and I'm not seeing any beach balls unless Flash crashes some web page.

http://www.apple.com/shop/buy-mac/mac-mini?product=MGEM2LL/A... Dont add any extras... its simply not usable on the net Hardware 1.4GHz Dual-Core Intel Core i5 (Turbo Boost up to 2.7GHz) 4GB 1600MHz LPDDR3 SDRAM 500GB Serial ATA Drive @ 5400 rpm Intel HD Graphics 5000 User's Guide (English) Accessory Kit

Maybe you have a faulty unit or are driving a very high resolution display. Otherwise at first glance that seems powerful enough to browse the net.

Re: Major Linux Problems on the Desktop, 2016 Edition

#67
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…

Is Tanenbaum going to have the last laugh?

Re: Major Linux Problems on the Desktop, 2016 Edition

#68
So is there anything that a normal developer could do to help fix these issues? After all, isn't one of the points of OSS that we should be able to mess with it and change it to our liking?

Or, am I correct in assuming that Linux has gotten so big and complex it'd be unreasonable to expect your average developer to be able to make a meaningful contribution?

I really enjoy using Linux, but I'll admit I still barely understand anything about it after using it for several years and it isn't from a lack of interest or trying.

Re: Major Linux Problems on the Desktop, 2016 Edition

#69
post #33

#25 is wrong: > There are no antiviruses or similar software for Linux. Say, you want to install new software which is not included by your distro - currently there's no way to check if it's malicious or not. http://www.eset.com/int/home/products/antivirus-linux/

Considering that most Windows AV products appear to be remotely exploitable and to actively install malware-like things, I think the lack of Linux support for these tools is a good thing.

Re: Major Linux Problems on the Desktop, 2016 Edition

#70
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…

Bluetooth is a complete mess. Every new bluez version breaks backwards compatibility (all applications depending on it break!) and removes features.
Post reply on HN