Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
I for one do mourn POSIX, and standardization in general. I think
it's very sad that a lot of stuff these days is moving forward
without going through a rigorous standardization. We had this
little period known affectionately as the "Unix Wars" in the
1980s/90s and we're well on our way to a messy repeat in the Linux
space.
— Jon
Masters
You're missing something; that is one of the greatest powers of
open source. The many eyes (and minds) effect. Someone out there
probably has a solution to whatever problem, the trick is to find
that person.
— Russell King
Unfortunately there is no EKERNELSCREWEDUP, so we usually use EINVAL.
— Andrew Morton(Log in to post comments)
Quotes of the week Posted Nov 15, 2012 19:48 UTC (Thu) by alexl (subscriber, #19068) [Link]
I don't quite understand the problem people are having with non-POSIX stuff. For example, Gnome uses non-POSIX apis for things such as file change notification (inotiy,dnotify,fen,fam), more scalable poll (epoll,kqueue), power management, tracking logins on multiple consoles, etc.
None of these are in POSIX, because POSIX is all about encoding the shared behaviour of multiple unix versions at some previous time, and none of these problems are solved by existing versions of POSIX. So, do we just not do power management because its not in POSIX? Do we not nicely handle multiple logged in users on different consoles?
That said, it would obviously be nice if people cooperated more, so that we did not have to have 4 file change notification implementation is glib. That is not always so easy to do in practice though. I'm pretty sure that Robert Love had enough problems pushing inotify patches into Linux. If he had to also synchronize with *BSD and opensolaris people we would likely not have a file change notification API yet. And even if we did, it would not be in POSIX.
Quotes of the week Posted Nov 15, 2012 21:55 UTC (Thu) by wahern (subscriber, #37304) [Link]
Linux could have adopted kqueue, but instead has spent the past 10 years slowly reimplementing every feature. In some cases, reimplementing it multiple times. Linux is asymptotically approaching kqueue.
The BSDs, OTOH, rarely have a problem adopting useful Linux features. The most recent example are extended pipe(2), socket(2), and similar calls which allow specifying, e.g., O_CLOEXEC at descriptor creation time to eliminate the fork race with multiple threads.
BSDs are also converging on O_NOSIGPIPE, which is almost identical to the above, but which Linux refuses to adopt for no good reason other than obliviousness, or a severe aversion to adopting things not invented in Linux-land. Instead Linux only has MSG_NOSIGNAL, which only works with the send and recv syscalls, requiring old-style signal masking tricks for real-world code.
People who are predisposed to not caring about anything but Linux always frame the portability issue in negative terms--e.g. POSIX is useless because it's anachronistic and nobody supports all of it anyhow. That attitude is part of the problem. Portability is about keeping the lines of communication open, and actually seeing value in changes which ease porting software. POSIX is just one part of that. Portability done right improves everybody's software--both kernel and application.
Quotes of the week Posted Nov 15, 2012 22:08 UTC (Thu) by alexl (subscriber, #19068) [Link]
O_NOSIGPIPE would be very very nice. It would be awesome if linux could pick that up.
Quotes of the week Posted Nov 15, 2012 22:14 UTC (Thu) by alexl (subscriber, #19068) [Link]
I would also love xstat/fxstat. It almost seemed to happen with David Howells last push, but it seems to have died out... :(
Quotes of the week Posted Nov 16, 2012 6:41 UTC (Fri) by krakensden (subscriber, #72039) [Link]
My only experience using a kqueue semi-replacement on Linux is inotify, but... *christ* it was nice compared to kqueue on Darwin, with no unsolvable race conditions either.
EIEIO Posted Nov 15, 2012 20:18 UTC (Thu) by proski (subscriber, #104) [Link] GNU Hurd uses EIEIO ("Computer bought the farm") if the kernel is in trouble.
Quotes of the week Posted Nov 15, 2012 21:34 UTC (Thu) by smoogen (subscriber, #97) [Link]
Jon is too young to have remembered what a bleeding pain it was to get any POSIX standard together or how few systems were really compliant with them (you instead had a set of POSIX calls in a library that wrapped the local ones that maybe did things very differently.).
Quotes of the week Posted Nov 16, 2012 22:50 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
The most important thing about standards isn't following them, it's having them. It's more important to have a standard *in theory* than in reality, because if you can get it on paper this makes getting it in fact at a later time much more feasible than if you never wrote it down in the first place.
When POSIX was introduced nobody was compliant, but there was then a specification and from that point forward each successive generation of Unix hackers had a target at which to aim. Computer 'generations' are fast and in a few years we got BSD and Linux systems that are just about as close to fully POSIX compliant as sanity will allow; the lie that was written down as a standard has become a reality.
If nobody had tried and no standard was produced there would be an *even bigger* mess today. Success isn't interoperability today, success is an agreement on what tomorrow's interoperability should look like.
We need more standards, more things that we agree on written down formally, and not just "here's how it's going to be done" READMEs from individual people/projects. The more topics that we can get coverage for in standards today the better our systems will interoperate in 20 years.
|
|||||||||||||