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

221–230 of 384 posts

Re: Major Linux Problems on the Desktop, 2016 Edition

#221

Post by tadfisher »

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…

I solved it and all of my wireless-networking issues by installing Intel wireless cards in all of my computers. Broadcom and Atheros have always given me problems.

Re: Major Linux Problems on the Desktop, 2016 Edition

#222

Post by ris »

pjmlp wrote: post #159
ris wrote: post #136

Earlier quoted context omitted.

It's quite telling though that most microkernel proponents tend not to be kernel developers.

It is also quite telling that micro-kernel haters fail to acknowledge that they won in the embedded space and software systems for high integrity deployments.

I... never said anything about these spaces, which I suspect you would agree require significantly different kernel design from a "desktop system" which is what this topic is supposedly about.

Re: Major Linux Problems on the Desktop, 2016 Edition

#223

Post by addicted »

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

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 people whose approach to programming is "Read spec, code, debug why code isn't working to spec, fix that specific bug". Design, architecture, etc. are simply not part of the process. I can see how a lack of easy debugging may force some forethought into the development process.

That being said, how valid would this be in a development environment (like the kernel) where a lot of the work you are doing is making changes designed and created by someone else? Linus says the solution is to make sure you were careful at the start. But what if you weren't even there at the start, and had to step in later?

Re: Major Linux Problems on the Desktop, 2016 Edition

#224

Post by chx »

tadfisher wrote: post #221
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…

I solved it and all of my wireless-networking issues by installing Intel wireless cards in all of my computers. Broadcom and Atheros have always given me problems.

Does Intel make USB bluetooth sticks? If my laptop didn't come with a combo miniPCIe card I doubt the necessary antenna is there. In a desktop, I looked for mPCIe - PCIe x1 adapters with lots of antennas but I can't really find any in low profile. So... how did you do that?

Re: Major Linux Problems on the Desktop, 2016 Edition

#225

Post by TingPing »

geggam wrote: post #53
fauigerzigerk wrote: post #29

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

Own one, can confirm that OSX is unusable on a 5400rpm drive. Replacing it with any SSD makes it decent.

Re: Major Linux Problems on the Desktop, 2016 Edition

#226

Post by vezzy-fnord »

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

Earlier quoted context omitted.

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

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.

Re: Major Linux Problems on the Desktop, 2016 Edition

#227

Post by thyrsus »

brightball wrote: post #72
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…

Seems like a good way to cope with this, from a market standpoint, would be for Linux development to focus on specific laptop. If say, Dell, were to pay Ubuntu to test and verify for some of their specific laptops and then Ubuntu subsequently was able to list "100% Certified" laptops for purchase it could create an opening. Same thing with developing to put it on Apple laptops with that very specific hardware set, et…

I happily paid a premium to System76 for their Linux laptop. Then I took a calculated risk and replaced their Ubuntu distribution with CentOS 7. I've had small hardware troubles (the biggest being video initialization during boot - sometimes it just locks up at a black screen; power cycle eventually resolves the issue, which does not recur until the next power cycle) - but my biggest troubles come from my employer's enthusiastic embrace of proprietary Microsoft protocols. For which I use the company issued Windows 7 machine, and the Mac users get a virtual machine image.

Re: Major Linux Problems on the Desktop, 2016 Edition

#228

Post by ggreer »

simoncion wrote: post #206
ggreer wrote: post #163

Earlier quoted context omitted.

Beware. I went out of my way to get an Ubuntu certified laptop[1]. It took me months to get it to a usable state. Graphics drivers crashed or corrupted the screen[2]. Bluetooth didn't work. Wifi didn't work. While suspended to RAM, it drained 10% of the battery every hour. In short, it was a nightmare. I've had it for almost two years now, and I've given up on getting Bluetooth to work. After resuming from suspend, t…

> Beware. I went out of my way to get an Ubuntu certified laptop[1]. It took me months to get it to a usable state. Why didn't you return it and get -say- a Thinkpad? (Were you -perhaps- just curious how shitty the "Ubuntu Certified Laptop" program is?) It clearly failed the "Fitness for advertised purpose" test. AFAIK -if you're in the US- the seller can't refuse to accept your return... unless it was sold as-is. >…

> Why didn't you return it and get -say- a Thinkpad?

The Lenovo X140e is a ThinkPad.[1] I didn't blindly trust Ubuntu's certification. I made sure to get a brand that historically has had good Linux support. I also knew about Nvidia graphics and avoided them. Still, I got burned.

I don't doubt your checklist is good advice for buying a Linux laptop, but it's simply too time consuming to check all of those things. Even if it wasn't, the likelihood of everything working well is low. All it takes is one bad driver for one piece of hardware and the laptop becomes a constant annoyance. Considering the number of hardware devices (Bluetooth, wifi, mic, camera(s), trackpad, GPU, fan, power saving, etc.) it's all but certain something will go wrong. Maybe audio won't automatically switch between headphone and speaker output. Maybe the fan will run at a few discrete speeds instead of gradually ramping up/down. Maybe it will wake from sleep if you open the lid, but not if you hit a key on the keyboard.

I'd rather just pay money and get something that I know will work. That's why my main development machine is a MacBook. I wish there was a competing brand of unix laptops, but so far… no dice. :(

1. http://shop.lenovo.com/us/en/laptops/thinkpad/x-series/x140e... Though after I purchased it, some people told me it wasn't a true ThinkPad, whatever that means.

Re: Major Linux Problems on the Desktop, 2016 Edition

#229

Post by addicted »

vezzy-fnord wrote: post #160
ris wrote: post #152

Earlier quoted context omitted.

"Right, because most Linux proponents are kernel hackers." They don't have to be. All they have to do is not go around smugly suggesting they know better than kernel developers and they're ok in my books. Incidentally, precisely how many of those research kernels have become widely used, mainstream kernels capable of high-throughput? And do you really think it has turned out that way because the whole industry is ful…

I'm not sure what fantasy world you live in where the software industry is always adopting the most technologically superior solutions by default. No industry works like this. YMMV on mainstream (they are widely adopted, though), but: OKL4, PikeOS, QNX... It's quite obvious you have no background on the issues and are using this as an opportunity for provocation.

Your comment would imply that Javascript may not be the most technologically advanced solution for execution on remote clients. This is obviously wrong, so by implication the Software Industry DOES adopt the most technologically superior solution by default.

Re: Major Linux Problems on the Desktop, 2016 Edition

#230

Post by ris »

vezzy-fnord wrote: post #218
ris wrote: post #212

Earlier quoted context omitted.

"OKL4, PikeOS, QNX" High throughput, mister, high throughput. Realtime != high throughput. It just means deterministic throughput. FSVO deterministic. Show me people running big farms of servers running these operating systems where even single-percentage computational overheads really matter. (added:) The reason for this is that it costs one hell of a lot flipping your page tables and flushing your TLBs every time y…

QNX4 is high throughput, mister. Other contenders include eMCOS and FFMK, though those are obscure. That said, I don't even understand the logic. HPC clusters where single-percentage overheads really matter are an extremely specialized use case, so of course COTS u-kernels might not cut it. Where's the shocker here? Response to added: Not necessarily with message passing properly integrated with the CPU scheduler. Re…

"QNX4 is high throughput, mister."

Ok then, show me the server farms...

I'm not even really talking about HPC, just the massive datacentres that run everyone's lives. All for the most part running monolithic kernels. I doubt the thousands of engineers who work on such systems consider the "huge monolithic kernel" "undebuggable". And I don't see examples of microkernel OSs that are able to cut it in these circumstances.

Even in a mobile device, you don't really want to waste battery doing context switches inside the kernel.

Microkernels have their place, but believing that the world that chooses not to use them are just clearly dumbasses is bullshit dogma.

Post reply on HN