Weekly Edition
Return to the Development page
| |||||||||||||
Quotes of the week
at this point in time, i personally can see absolutely no reason why a
regular user should not have access to RT scheduling or memlock if the
kernel and PAM (or equivalent) are normally and appropriately configured.
give the user the ability to memlock 75% of the system RAM, make sure that
the RT scheduling parameters reserve 5% of the CPU for non-RT tasks. done.
— Paul Davis (thanks to David Nielson)
For example, I really find it appalling that Linux had proper threads
support (and even in the libc!) so early, at a time where OpenBSD
didn't. I think Linux really hurt the open source ecosystem with
that, as people could write threaded up for Linux that then wouldn't
work on OpenBSD.
— Lennart Poettering
(Log in to post comments)
Quotes of the week Posted Jan 25, 2013 12:57 UTC (Fri) by rvfh (subscriber, #31018) [Link]
Had to read Lennart's full answer to get the irony...
Quotes of the week Posted Jan 25, 2013 14:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Still, his point is accurate.
(Though it does say something about the continuing awful documentation for glibc that glibc already *had* an interface -- heck, a whole library, libanl -- for doing just what the proposal suggested, if in an inconvenient way; but because the thing's existence was only documented in a random PDF on Uli's homepage, next to nobody knew it was there...)
Quotes of the week Posted Feb 13, 2013 14:39 UTC (Wed) by mirabilos (subscriber, #84359) [Link]
Well, threads – particularily, POSIX threads – are *evil*.
Quotes of the week Posted Feb 15, 2013 10:05 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> Well, threads – particularily, POSIX threads – are *evil*.
And it's not even a joke. They *are* evil. I wish the kernel supported some other kind of parallelism as well (coroutines, maybe?) that doesn't have to emulated using threads.
Quotes of the week Posted Feb 15, 2013 10:33 UTC (Fri) by khim (subscriber, #9252) [Link] Kernel? WTF? Why kernel should know or even care? Kernel runs two (or more) processes with a shared address space, what happens inside of these two processes is entirely up to userspace. Even clone(2) syscall which creates such processes does not know anything about threads: it just returns different return values in different processes but it does not change %xSP, it does not allocate new stack, etc. Sorry, but you are barking on the wrong tree.
|
|||||||||||||