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

211–220 of 384 posts

Re: Major Linux Problems on the Desktop, 2016 Edition

#211

Post by comex »

Symmetry wrote: post #189
AnimalMuppet wrote: post #164

Earlier quoted context omitted.

> they are widely adopted, though For some definition of "widely". And feel free to stop adding personal attacks to your comments. They do not enhance the credibility of your posts.

Every iPhone now shipping and most Android devices too I believe are running their main operating system kernel as a layer on top of an L4 kernel. They mostly handles low level security and the cell modem and stay out of the way except for that. Still, I think that should certainly count as widely adopted.

Correction: in Apple's case, the Secure Enclave, which runs L4, does not run on the application processor but on a separate ARM processor integrated on chip. Competitors tend to use TrustZone and hypervisor mode for this, but Apple currently uses them only for kernel patch protection rather than anything more important.

Not that that changes the core fact that Apple is shipping L4.

Re: Major Linux Problems on the Desktop, 2016 Edition

#212

Post by ris »

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.

"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 you have to switch to ("pass a message", whatever) to a different subservice of your kernel.

(also added:) Oh and interestingly many (most?) users of OKL4 go on to host Linux inside it because, hey, it turns out that doing all your work in a microkernel ain't always all that great. So 90% of the "kernel" work in these systems is happening in a monolothic kernel.

Re: Major Linux Problems on the Desktop, 2016 Edition

#213

Post by jcastro »

izacus wrote: post #30
jcastro wrote: post #12

This "Android is not Linux" meme is pretty silly. "Android contains the only Linux component - the kernel" can also describe any distribution/OS using Linux.

So how does classifying Android as being Linux help anyone? Who does that definition help? The most important drivers (video, camera) aren't compatible with desktop, userspace isn't either, most binaries won't work properly due to use of libbionic, etc. So what kind of useful definition is "Android is Linux" when you can't really reuse any Android components on desktop Linux distributions?

It's just completely arbitrary. Other than "It uses a linux kernel" there's no list anywhere of what makes something "a real Linux". Everything around the kernel is a pile of reusable components that make up an operating system.

As far as I can tell there's no gatekeeper that says "Tool A in combination with the kernel is a real linux, but android components don't count." And no one could be that gatekeeper because Free Software lets people use what they want. So who draws that line?

This is a list of complaints of what happens when putting certain blocks that make an OS not work like a cohesive whole. One vendor (Android) decided to use an entirely different set a blocks (as is their right), and then people are like "Well that doesn't count." How does it not count? If you don't like the set of blocks that are out there you make your own blocks, that seems to be a fundamental point of using OSS in the first place, the right to say "I want to use different blocks". It's not any less a Linux than my Ubuntu machine or my Nest thermostat or whatever flavor is on my router.

Re: Major Linux Problems on the Desktop, 2016 Edition

#214

Post by ris »

jacquesm wrote: post #154
ris wrote: post #124

Earlier quoted context omitted.

"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." I don't think you know what you're talking about. It shows. Name me one non-"monolithic" OS kernel in mainstream use that manages high throughput. And macos doesn't count as a microkernel.

QnX.

High throughput. As I've said elsewhere, realtime != high throughput. Just deterministic throughput. Users of these systems are willing to use slightly overpowered hardware if it means hitting processing deadlines.

Re: Major Linux Problems on the Desktop, 2016 Edition

#216

Post by ris »

mystikal wrote: post #157
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…

There are zillions of academic solutions that if implemented properly would be better than the industrial version. Academics are just notoriously bad at building real-world systems. I think this is mostly because it's a waste of time and money as far as publications are concerned.

This is basically the "everyone's a dumbass" argument.

Re: Major Linux Problems on the Desktop, 2016 Edition

#217

Post by gerbilly »

zanny wrote: post #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 tha…

I found that using Eclipse on KDE lately was very problematic.

Something about SWT requiring Gnome themes, that had been recently unilaterally converted to use CSS for styling, or something...

Gah!

It took lots of fiddling to be able to open dialogs on Eclipse without crashing the whole application, and even after all that fiddling it never worked right.

Had to switch to Gnome to get it to work right, on linux, but hated that...

I know it's not KDE's fault if Gnome wants to change how it's themes work, or that SWT uses gnome, but between that and systemd making everything utterly confusing I don't use linux as a desktop os anymore, despite using it since Yaggsdril.

tl;dr: I now develop on OS X now, so I can open dialogs in Eclipse without crashing.

Re: Major Linux Problems on the Desktop, 2016 Edition

#218

Post by vezzy-fnord »

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

Earlier quoted context omitted.

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.

"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.

Response to added #2: Hosting a single-server is a valid microkernel use case. What's your problem? Isolation and separation kernels are a major research and usage interest.

Re: Major Linux Problems on the Desktop, 2016 Edition

#219

Post by zxcvcxz »

wvenable wrote: post #19
edtechdev wrote: post #9

I've been using Ubuntu Linux as my primary OS since 2006, and I can't disagree with many of the annoyances. Especially with regards to graphics drivers and the switch to the Unity desktop. I tried Linux Mint with the Cinnamon desktop and it is nicer, but couldn't commit to it I guess. But everytime I use Windows and Macs again, I get even more annoyed. Mainly with how slow things are. Even on a new Windows 10 desktop…

> it's not uncommon to have to wait minutes for things to settle down after booting and logging in This is no longer my experience with Windows on an SSD. I'm always a bit shocked when I reboot and I'm back at my desktop in under 30 seconds. On a machine without an SSD, I'm annoyed at how slow everything is -- not just booting.

It seems to me that Linux is slightly faster on an SSD and a hell of a lot faster on an HDD than Windows 10 when it first boots up. I have the exact same problems the parent describes.

Re: Major Linux Problems on the Desktop, 2016 Edition

#220

Post by 0xcde4c3db »

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

He apparently softened somewhat on the issue and did eventually (2008 / 2.6.26) merge a debugger into mainline. I don't think he ever really had a good answer to Alan Cox pointing out that you can't always reason your way through hardware misbehavior.
Post reply on HN