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 389094
To view parent comment, click here.
To read all comments associated with this story, please click here.
Ludicrous
Member since:
2009-08-19

As much as I appreciate all the GNU/Linux developers for their generous work, how could you possibly accuse FreeBSD for not innovating when GNU/Linux itself is just another UNIX clone with GNU claiming that GNU is not UNIX?

What do you have against a friendly competition in the free UNIX arena, especially against a true UNIX (in terms of where the source code started, not the UNIX trademark)?

I, for one, am glad that there are other open alternatives that work toward the evolution of the UNIX environment. (such as the new malloc which apparently sped up memory allocation).

I also wonder where GNU/Linux would be without all the funding it receives from commercial entities.

As far as NIH, a few that comes to mind in recent years would be...
dtrace->SystemTrap
ZFS->btrfs
GCD->(I wonder if this will be re-invented also...)

I'm sure plenty of GNU and Linux developers would like their works to speak for their quality instead of flame-inducing comments overriding their significance.

Reply Parent Score: 10

sbergman27 Member since:
2005-07-24

Because FreeBSD make nothing worthwile of it's own accord ...

Geez, Moully. Your *BSD hatred is becoming (or actually, has long become) very tiresome. I usually just ignore you. But *please* stop slavering and frothing so. I happen to prefer Linux to *BSD for my particular use cases. As a user, I happen to prefer copyleft to more permissive licensing. But I'm glad that the *BSDs are there. And the *BSD guys are doing a great job for the folks they serve. You are an embarrassment to those of us who like Linux but respect authors and users of other OSes. You are an embarrassment to those of us who prefer copyleft, but respect authors who choose other licenses under which to release their works.

You have preferences, as most of us do. But you lack the *respect* for others that most of us learned in kindergarten. In fact, sometimes I feel that you got stuck in kindergarten and are forever posting from there.

Some might tell me to stop feeding the troll. But you are not a troll. I've known you too long to think that. You are simply overenthusiastic and tactless.

Edited 2009-10-14 02:32 UTC

Reply Parent Score: 12

ebasconp Member since:
2006-05-09

Because FreeBSD make nothing worthwile of it's own accord ... Otherwise you would have named them by now.


Because you are a Linux user you must bash the nice work being done in the BSDs arenas?

AFAIK, jemalloc was born inside of FreeBSD, this is one of the best memory allocators found currently and is being used in Firefox since 3.0. FreeBSD does not aport anything?

The "ports" package manager was born in FreeBSD and similar technology is being used in OpenBSD (port collection), NetBSD and DragonFly (pkgsrc), MacOSX (MacPorts and DarwinPorts) and in Linux (Gentoo's Portage)...

"Jails" is another good contribution of BSD implementing similar technologies in Solaris (Zones).

HammerFS is a nice filesystem written by the main DragonFly developer.

OpenSSH was born in OpenBSD.

Reply Parent Score: 8

Bill Shooter of Bul Member since:
2006-07-14

Sorry for feeding your negativity, but FreeBSD did create jemalloc which is now used in Firefox 3 for increased multithread memory allocation performance.

Reply Parent Score: 6

Mark Williamson Member since:
2005-07-06


As far as NIH, a few that comes to mind in recent years would be...
dtrace->SystemTrap
ZFS->btrfs
GCD->(I wonder if this will be re-invented also...)


To be fair, ZFS vs btrfs (and probably dtrace vs SystemTap too) was not just NIH but a licensing issue. I don't mean to open up the question of whose fault this was but it's worth noting that the code for ZFS and Dtrace could not be included in the mainline Linux kernel because of the interaction between licenses.

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.

Reply Parent Score: 5

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