Originally posted by ncopa
View Post
Announcement
Collapse
No announcement yet.
Arch BSD: Arch Linux Atop The FreeBSD Kernel
Collapse
X
-
-
Originally posted by LightBit View PostYou mean LinuxThreads library? Well that is because Linux now uses NTPL, which uses Linux specific system calls. So they had to do their own, which is probably not slower than LinuxThreads.
I'm not freebsd user and never was, I'm occasional OpenBSD user.
So Light Weight Kernel Threads are very similar to Linux kernel threads? I couldn't found any reference.
Virtual kernel feature is similar to User Mode Linux, but it's not performance feature:
Comment
-
Originally posted by kraftman View PostThat's right and freebsd used LinuxThreads library in the past and switched later to some crap (probably, because of same political reasons like GCC to llvm switch, so not because of the reason you described).
And of course Linux is totally unpolitical.
Originally posted by kraftman View Post
In computer operating systems, a light-weight process (LWP) is a means of achieving multitasking.
Comment
-
Originally posted by ryao View PostDo you have a reference for your Linux threads comment? If you know how a kernel works, you should know how absurd that statement is.FreeBSDSoftware.org offers a vast collection of free and open-source software for FreeBSD, empowering users to unlock the full potential of our favorite operating system.
There are two major classes of threads for FreeBSD. The first is the default FreeBSD thread package, referred to henceforth as "uthreads" or "user threads". The other is the Linuxthreads port, which is a port of Linux's kernel threads based on the clone() call (or, in FreeBSD's case, the rfork() call).
TWC considered using an alternate thread library to work around these problems. Specifically, the thread library contained in the LinuxThreads port described at [LinuxThreads]. However, there are binary incompatibilities between the structures defined by FreeBSD's thread library and the LinuxThreads' thread library. Thus, any libraries used by a multithreaded application that use threads internally must be linked against the same thread library as the application. As a result, for our applications to use LinuxThreads, all of the libraries they link against that use threads internally would also have to link against LinuxThreads. As a result of those libraries using LinuxThreads, other applications that use those libraries would also have to link against LinuxThreads. This would require TWC to custom compile several packages including XFree86, Mesa, Python, and a CORBA ORB as well as other applications depending on those packages rather than using the pre-built packages from stock FreeBSD releases. Since the workarounds for FreeBSD's thread library were not too egregious, they were chosen as the lesser of two evils.
Compilers do not matter very much as far as performance goes. Better aglorithms and code that plays well with cache will always matter more than anything a compiler could do.
Dtrace and ZFS could be called a "tech preview" in FreeBSD 7.x and FreeBSD 8.0-8.2. It is fairly mature in FreeBSD 8.3 and later. At this point, ZFS and Dtrace are no more of a "tech preview" than DragonflyBSD is.
Lastly, DragonflyBSD has influences from AmigaOS, not Linux.
DragonflyBSD has its merits, but it is different, not better.
Comment
-
Originally posted by LightBit View PostProbably it was also political reason. (they could port NPTL instead)
And of course Linux is totally unpolitical.
Only similarity I see:
"The serializing token code is evolving into something quite similar to the "Read-copy-update" feature now available in Linux. Unlike Linux's current RCU implementation, DragonFly's is being implemented such that only processors competing for the same token are affected rather than all processors in the computer."
Comment
-
Originally posted by kraftman View PostLinux is unpolitical in a very different and positive contest.
And Ubuntu not switching to systemd is of course unpolitical.
Also Git replaced BitKeeper, because of political reasons.
Originally posted by kraftman View PostThen take a look here:
"The serializing token code is evolving into something quite similar to the "Read-copy-update" feature now available in Linux. Unlike Linux's current RCU implementation, DragonFly's is being implemented such that only processors competing for the same token are affected rather than all processors in the computer."
Comment
-
Originally posted by blackout23 View PostNow if only someone would develop ArchWindows.
but seriously, and especially after Win8, I'm definitely sure an ArchDOS would be infinitely better, (even for a modern Tablet), than any "ArchWindows" -?! - ewww.
IMHO, ArchBSD is all that foronicks would need, 'ya know, like it's BSD, but it feels like Linux. It's the best of both UNIX worlds, and we'd never know the difference.
...waiting.Last edited by scjet; 25 January 2013, 12:23 PM.
Comment
Comment