Linked by Thom Holwerda on Tue 13th Oct 2009 18:24 UTC, submitted by Lazarus
FreeBSD Not too long ago, Apple open sourced its Grand Central Dispatch library, which aids in developing multithreaded code. It was suggested that it could be ported to other platforms, and the FreeBSD team has done exactly that. They have also done a lot of work related to getting GCD to work in a POSIX environment.
Thread beginning with comment 389175
To view parent comment, click here.
To read all comments associated with this story, please click here.
sbergman27
Member since:
2005-07-24

That's not to say that Linux folks wouldn't have gone all NIH and tried to reinvent the wheel even if the code could be incorporated directly, there are surely some examples of that out there. But in this instance they really did have a valid reason not to just use the existing code.

The valid reasons go beyond that. Kernel code is hard to transplant. Could the kernel portion of Dtrace really have been ported to Linux more easily than starting from scratch? They are *very different* kernels. Sure, a map of Denver and Houston are very similar; They *are* both maps, aren't they? It's just the streets and intersections that differ. Just move the proper stop lights from one to the other and everything will work just fine, right?

Systemtap was not NIH. It was just what made sense. (I won't comment on the user space portion since I feel I'd be talking out my ass if I did. Fact is, I don't have an informed opinion on it.)

ZFS vs btrfs is a little different. ZFS was a radical change in layering philosophy for Sun. The Linux kernel devs are not at all convinced that they would want to follow Sun down that path. And even if it weren't for that... I'm not sure that I would want to see our default filesystem "bolted on" like that. No matter how good ZFS may be.

So am I a compulsive Linux Kernel apologist? Not really. I am currently watching in mild horror as the formerly vanquished DevFS, defeated by the FUD-slinging efforts of Greg Kroah-Hartmann, to be replaced (accompanied by much user pain) by udev... is now coming back, in the form of DevFS II, which is to replace (also surely to be accompanied by much user pain) udev. And did I mention that Greg is co-author or DevFS II?

It's not really called DevFS II. But that's how I think of it. I don't recall its real name.

Edited 2009-10-14 17:41 UTC

Reply Parent Score: 3

Mark Williamson Member since:
2005-07-06

The valid reasons go beyond that. Kernel code is hard to transplant


I imagine this would also be the case, although I've never transplanted kernel code between significantly differing kernels myself.

However, Linux kernel policy is that the driver in kernel.org should be natively Linux-ified, which would make it hard to have a common source code project and hence make it harder to share code. It could be done if there was a reason, I'm sure.

Licensing issues just meant that there was simply no chance of anyone having the motivation to tackle these other problems in the first place.


ZFS vs btrfs is a little different. ZFS was a radical change in layering philosophy for Sun. The Linux kernel devs are not at all convinced that they would want to follow Sun down that path. And even if it weren't for that... I'm not sure that I would want to see our default filesystem "bolted on" like that. No matter how good ZFS may be.


Sure. Although it would still be nice if ZFS could be supported somewhat for compatibility reasons. Looks like the best we'll do on that is either the existing FUSE port, or a kernel port based on the code in GRUB.


So am I a compulsive Linux Kernel apologist? Not really. I am currently watching in mild horror as the formerly vanquished DevFS, defeated by the FUD-slinging efforts of Greg Kroah-Hartmann, to be replaced (accompanied by much user pain) by udev... is now coming back, in the form of DevFS II, which is to replace (also surely to be accompanied by much user pain) udev. And did I mention that Greg is co-author or DevFS II?

It's not really called DevFS II. But that's how I think of it. I don't recall its real name.


devtmpfs, something like that? It's not a complete replacement for udev AIUI, which either makes it nicer or nastier depending on your perspective. Possibly even both. I'm not entirely keen on it, it smells a bit funny to me. But maybe I will be proven wrong.

Reply Parent Score: 2

korpenkraxar Member since:
2005-09-10

I am currently watching in mild horror as the formerly vanquished DevFS, defeated by the FUD-slinging efforts of Greg Kroah-Hartmann, to be replaced (accompanied by much user pain) by udev... is now coming back, in the form of DevFS II, which is to replace (also surely to be accompanied by much user pain) udev. And did I mention that Greg is co-author or DevFS II?

It's not really called DevFS II. But that's how I think of it. I don't recall its real name.


Oh nooo!! Not again :-( I sure hope Red Hat, KDE and other teams have developed solid and flexible enough hardware abstracting layers to keep us from smashing to badly into that transition. Make sure to enjoy your easily pluggable hardware while it lasts ;-)

Reply Parent Score: 2