Earlier quoted context omitted.
I think just the opposite - most of my software runs on Linux, but hardware is the main obstacle. I've installed Linux many times on desktops and laptops, and I have yet to simply install a graphics driver and have it work first try. My laptop locks up the cursor after two minutes of use, doesn't support two-finger touchpad scrolling, and exhibits constant graphical artifacts, all under multiple driver and kernel com…
That used to be a problem, but I don't think it is any more. Linux "just works" on both my laptop (including sound, multitouch touchpad, wifi, and graphics, also when I'm not using it, I only ever put it to sleep by closing the lid, and I've never had a problem) and my desktop, which has an AMD graphics card (Radeon HD 7950) and an external USB audio interface (Focusrite Scarlett 2i2).
Major Linux Problems on the Desktop, 2016 Edition
271–280 of 384 posts
Re: Major Linux Problems on the Desktop, 2016 Edition
#272Earlier quoted context omitted.
Technically vim exposes the x11 clipboards (plural) as registers - I never use registers, but I think "+p [Ed: for those not familiar with vim: " can be thought of as 'with/from/into register named:', + is the register and p is paste. Similarily "+yw is 'yank/copy current word into register named +' ] should be paste x11 selection. I don't normally use gvim/vim as an x11 application, but looks like * (star) is typica…
why does it work on osx then ? is there something special happening at the OS level there ?
Re: Major Linux Problems on the Desktop, 2016 Edition
#273He'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…
That makes no sense. Most of that are drivers and platforms you won't ever use. And some forms of symbolic checkers exists for Linux (maybe not that advanced as for the Windows kernelspace, though, I don't know -- although even simple local heuristic checks are quite useful to check automatically in their ability to find real bugs -- sometimes even more than very complex solvers)
Re: Major Linux Problems on the Desktop, 2016 Edition
#274Linux users often take the idea of 'self-examination' way too far and it turns into 'self-disparagement'. The fact is, if you vet your hardware and use a major distro (Ubuntu, OpenSUSE, Fedora) you'll wind up with a perfectly functioning Linux desktop or laptop. You think about it, OSX only runs on a few laptops. Linux runs perfectly on more laptops than exist for OSX. Windows run on many laptops, more often than not…
Exactly, I've always used whatever hardware I wanted, and Linux mostly just worked. The occasional hiccups are proprietary Nvidia drivers, and some wifi chips being too recent and needing an open source driver readily available. I use Ubuntu on a dual boot, I hardly ever boot Windows. And I'm a gamer! Steam + wine is enough for me.
Re: Major Linux Problems on the Desktop, 2016 Edition
#275Re: Major Linux Problems on the Desktop, 2016 Edition
#276I stopped using Linux as my primary desktop OS around 2012. Until then I was an Arch user with my own desktop environment built on StumpWM and a hodge-podge of hand-selected tools. There was no Gnome or KDE in my setup. I liked it quite a bit. I used Ubuntu on my laptops since I wanted to spend less time administering drivers and arcane configuration formats. This is a good list. I just got tired of the configuration…
I've considered doing this myself, especially with WINE taking eons to implement adequate DX11 support (most games released in the last 3 years won't work), but it's a plunge I haven't been able to make yet. I think I'm going to just set a Windows box right next to my Linux workstation and move the mouse, kb, and monitors over when I want to do something Windowsy.
The ideal would be getting hardware that supported raw GPU passthrough, getting a spare GPU, and doing all of the Windows stuff in a VM (this allows you to get 90-95% of your full GPU performance, and have the card controlled by the Windows system), which would really be the ideal solution IMO. However, I found that even the full technical manuals rarely mentioned if the hardware had the IOMMU, the require capability (both the processor and the motherboard must support), and that by far the vast majority of hardware doesn't.
I have a dual-boot partition now, but I use it probably about once every 9 months, and mostly just to poke around for a second and see if it has spontaneously combusted whilst unsupervised before rebooting back into my workstation OS. It's simply too much hassle to have my primary workstation offline for hours at a time while I game, because it hosts many services that my house relies on. I also have a Windows VM that I do most of my photo editing in.
Re: Major Linux Problems on the Desktop, 2016 Edition
#277He'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…
> 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. The Linux kernel is about 20MSLOC. The Windows kernel is about 50MSLOC. IIRC, OS X used to be ~80KSLOC. Problems with debugging are endemic to any monolithic kernel. Neither Windows nor OS X is easier to debug technologically , but Microsoft and Apple both have many employees and lots of money…
There are a lot of people who are paid to work on the kernel full time from Red Hat, Google, IBM and many others. If I had to guess I'd say there are probably more than the other two, it would be interesting to find out. But if you include people where it's not 100% of their job, but still an official part of their job, I'd say it's almost certainly more for Linux (not even counting unpaid contributions).
Linux is the most popular platform for servers and HPC because most of the time it's the better kernel. It's so dominant that Apple has basically left the server area and the handful of showcase supercomputers built on Apple gear have long since faded from view. Linux went from having one supercomputer in the top 500, a fraction of a percent, in 1998 to 98.8% of the top 500 currently.[0] The other six seem to be IBM machines running something else. OS X's first release was 2001 and it and Microsoft offerings are simply not present in that top section of the HPC space.
Linux is also the kernel on the most popular smartphone platform so it's not all computational either, when the hardware is tightly controlled it works fine. The problem isn't the number of developers on kernel or how hard it is to debug, it's that laptops and desktops aren't offered from a single company that can tie everything together.
Re: Major Linux Problems on the Desktop, 2016 Edition
#278Earlier quoted context omitted.
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.
But at least the beginning technical shortcomings could be explained because Linux kernel hackers of that time were unexperimented, and they actually several times silently learned from (some) NT designs and/or maybe big Unixes of that epoch (probably mainly Solaris) and adapted them not a too long time after trolling about why their previous simpler one was good enough (when it was clearly not). The security approach today coming from people having work that long in the industry is inexplicable. (maybe it is just to early and they will just silently convert to reasonable opinions in 2016? :p )
Re: Major Linux Problems on the Desktop, 2016 Edition
#279Too many layers of abstraction lead to the situation when the user cannot determine why his audio input/output doesn't work (ALSA kernel drivers1 -> ALSA library2 ( -> dmix3 ) -> PulseAudio server4 -> Alsa library5 + Pulse backend6 -> Application - in other words, six layers of audio redirection; or seven layers in case of KDE since they have their own audio subsystem called Phonon).
That's just not true. In the case of an application that directly supports PulseAudio, there are merely 3 levels:
ALSA kernel drivers -> ALSA library -> PulseAudio Server/library -> Application
In the case of an application that doesn't directly support PA (most that don't will support ALSA), it's one level little worse:
ALSA kernel drivers -> ALSA library -> PulseAudio server/library -> ALSA library (pulse plugin) -> Application
In that case, 4 levels of indirection.
If dmix is set up in the case where PA is being used, that's a bad system misconfiguration and the distro should be slapped.
So that's 3 levels of indirection for a "modern" app, and 4 if you need the compatibility layer. How are OSes like Windows and MacOSX designed? Unless they have a sound API that goes right to the kernel (and the kernel handles mixing if the hardware doesn't support it), I don't see how you can do much better than the current state of affairs, aside from having PulseAudio directly hit the ALSA kernel interfaces, which seems unnecessary.
(Note: for the purposes of debugging & figuring out why sound isn't working, I'm considering the PA server and library [or "backend" as the OP calls it] a single layer. It's true that there's an extra "hop" involved there, but in practice that's unrelated to any possible audio issue but latency, which isn't what the OP is talking about.)
Re: Major Linux Problems on the Desktop, 2016 Edition
#280Earlier quoted context omitted.
No, there's no consumer-level desktop hardware you can't use on either Windows or OS X or both. That's false. Hardware support is indeed a reason not to use Linux, but the question is who needs to pick up the slack. With other operating systems, manufacturers put (more or less) effort into writing device drivers that are functional. With Linux, they really do not. It's a large and moving target, and the market value…
> No, there's no consumer-level desktop hardware you can't use on either Windows or OS X or both. That's false. Oh, I can show you multitude of printers, scanners, tv tuners that do not work with Windows or OSX. Or they work with exactly one Windows version and that's it.
The reality is that when a new laptop is released, Windows will support everything it has from day one. If that's because of Microsoft's or the manufacturer's efforts, that doesn't matter for regular users.
On Linux, you buy the laptop and wait 1-2 years for bugs to be ironed out or even for things to barely work for the first time. Afterwards, Linux will continue to support that for a very long time while Windows may drop support after 2-3 versions because the manufacturer has no interest in upgrading drivers for the newest Windows releases. Specially for something that is not selling anymore.
Most people I know in the open source world barely use any fancy features like tv tuners, fingerprint scanners, touchscreens, or even printers. From reading some comments here, these are usually the people saying "everything is fine". I do think everything is fine for open source developers but no so much for regular users. And if the focus can be on the latter, then I guess everybody will benefit at the same time.
EDIT: typing this from Fedora 23 on a laptop with a NVIDIA card that is disabled because I got tired of bugs in nouveau and the constant hassle of updating the kernel and the GPU drivers stopping to work. I'm happy with the ingrated graphics though so my next laptop won't have a dGPU, probably.