Slashdot Mirror
FreeBSD Vows to Compete with Desktop Linux
AlanS2002 writes "FreeBSD developer Scott Long is being reported as saying that FreeBSD is quickly approaching feature parity with Linux. Apparently this is being achieved through efforts to more tightly integrate GNOME with FreeBSD, with one of the priorities being to 'GNOME's hardware abstraction layer--which handles hardware-specific code--working with FreeBSD'."
Wasnt the goal of BSD to be secure and reliable, like debian, only moreso? How come now they're "competing with desktop Linux" ?
To head off some confusion: This isn't about the FreeBSD base system; it's about third party code (like GNOME and KDE) in the FreeBSD ports tree. The FreeBSD base system already has feature parity with Linux (ok, there are a few things Linux has which we don't, but there are also things we have and Linux doesn't) -- the problem now is to get groups like GNOME and KDE to use the features we're making available to them.
Tarsnap: Online backups for the truly paranoid
I don't know what Linux distributions you've been using recently but I have recently installed Fedora Core 5 on my laptop and my experience was the opposite: that they must have been primarily focused on important features for desktop users. FC5 supported suspend and resuming my laptop, where FC4 didn't. FC5 supported my Centrino wireless with autodetection and configuration for both open access and WEP and WPA PSK protected networks right from the GNOME Desktop. FC5 automatically detected my USB-attached smart UPS on my desktop at work and can report the remaining run-time. It was the least-hassle desktop Linux install I've done yet.
As far as software installation, I don't use it but you can go to Applications->Add/Remove software and graphically browse thousands of software packages that are a click and a download away from being installed.
Compete with DESKTOP Linux? Shouldn't they aim a little higher, compete with OS/2???
I have nothing to hide. So, why are you spying on me?
I don't think FreeBSD devs care who's using OSX. They are not the same even if they do use similar kernels.
Can you point out the study or survey which shows that most Linux devs spend their time on useless eye-candy? Because I don't think that is the case.
If by beating Linux to the market you understand having the code taken by a company, and not seeing anything really valuable back in return, then yeah, you can praise OSX as much as you want.
I'll do the stupid thing first and then you shy people follow...
In ports. KDE have been tightly integrated with FreeBSD for years.
They aren't using similar kernels: Darwin uses XNU, a hybrid kernel. Many of the things running on higher levels are shared by both, though.
In 1908, the Ford company released the Ford Model T. The first Model Ts were built at the Piquette Manufacturing Plant. The company moved production to the much larger Highland Park Plant to keep up with the demand for the Model T, and by 1913 had developed all of the basic techniques of the assembly line and mass production. Ford introduced the world's first moving assembly line that year, which reduced chassis assembly time from 12½ hours in October to 2 hours, 40 minutes. However these innovations were not popular and turnover of workers was very high. Turnover meant delays and extra costs of training, and use of slow workers. In January 1914 solved the problem by doubling pay to $5 a day, cutting shifts from nine hours to an eight hour day, and instituting hiring practices that identified the best workers. Productivity soared and employee turnover plunged, as the cost per vehicle plummeted. Ford cut prices again and again and invented the system of franchised dealers who were loyal to his brand name.
By the end of 1913, Ford was producing 50% of all cars in the United States, and by 1918 half of all cars in the country were Model T's. Henry Ford is reported to have said that "any customer can have a car painted any color that he wants so long as it is black." This was because black paint was quickest to dry; earlier models had been available in a variety of colors. But most were black."
What the Model T was to the automobile DOS/Windows is to computer software. People faced with new technology that manages to takeoff tend to choice a brand that they gravitate toward in order to provide them with a base from which a general learning curve can be traced. As with the Model T, once a general concensus is arrived at as to what the new technology can do for the masses then competing models come into play and bells and whistles are taken in hand after the basics have been learnt. The computer industry has achieved a saturation level and the basics have been put in place. Now there is a chance for more competition. It's likely that Linux on the desktop is coming soon.
That freeBSD has chosen to announce its competition with Linux is more supplemental support to show that the basics of the desktop have been put in place. Competition between Linux and freeBSD is great and will foster competition between F/OSS alternatives that will soon provide greater incentive for the general computer population to move from Windows to alternatives.
I suspect the initial gauge of this movement will be a greater market share taken by Apple.
Just my loose change
"Academicians are more likely to share each other's toothbrush than each other's nomenclature."
Cohen
Windows eats Linux and poops FreeBSD
I am confused - are you trying to depict Windows as a gourmet or rather as an entity with a magic colon?
from personal experience i have to say i am biased towards GNU/Linux with Slackware being my favorite, i recently tryed both DesktopBSD & PC-BSD on my first primary partition, they were both decent KDE desktops and i was familier with CUPS so setting up my printer was not a problem, but with GNU/Linux when i tried ubuntu breezy it made setting up a GNU/Linux desktop a total "no brainer" (including printer, scanner & digital camera) that should help non-techies setup a GNU/Linux desktop a lot easier, the two BSD desktop flavors (DesktopBSD & PC-BSD) stand a good chance to give the GNU/Linux desktop camp some competition which is a good thing :)
Politics is Treachery, Religion is Brainwashing
There are separate teams working on KDE and GNOME integration. It just so happens that the interview was conducted with a GNOME on FreeBSD developer, so the focus was on GNOME. Be assured that FreeBSD's KDE integration is very good and will be even further improved on in the future. DesktopBSD, for example, features KDE as the default desktop.
Also, KDE is officially a cross-platform environment, with KDE4 being developed not only on Linux and FreeBSD but also on MS Windows. I don't know what the officiall position is for GNOME, but from what I hear they are a pretty Linux-centric project.
Ack. When is this rumor going to die?
OS X, back when it was called NEXTSTEP, forked off of BSD 8 years before FreeBSD did, even before 4.4lite came on the scene. You can trace its lineage yourself, if you'd like. Since then, there's been a lot of code borrowing but everyone borrows from FreeBSD and FreeBSD is far from the only OS whose code Darwin has borrowed. Using just that to say that Darwin is based on FreeBSD would make little more sense than using the same fact to claim that GNU/Linux and Windows XP are based on FreeBSD.
But as to your point about BSD in general beating Linux to the desktop with OS X, yeah, you're right. I think Apple showed how it really needs to be done, too. In my experience with trying to teach people to use Linux, the thing that consistently hurts Linux on the desktop is what I'd call its unixyness - stuff like complicated directory hierarchies based on abbreviated names only serves to intimidate the non-geek; even if you tell them they don't need to care about anything outside their home directory, they still know it's there. A lot of Linux's celebrated choices are bad; too. The moment a user ever has to care about QT vs GTK+ and figure out why they are behaving a bit differently, or what the heck CUPS is, or any of that, Linux starts to feel like a border town on the edge of the Wild.
He is exactly right! Consistently, users choose KDE...
I would love to see that backed up with some actual facts? I'd say the users are pretty evenly divided (this is definitely what I see at work).
I am not a BSD user and I am not going to even test it, but I think this is a good thing - bigger free desktop market will lead to better Free Software, more people will report bugs and more people will discuss new features.
He's just tired of the car/OS analogy and
decided to introduce the bodily function/OS analogy.
Brilliant! I can't believe he posted AC!
Linux will always be ahead on cutting edge hardware because of the nature of the licences.
History shows that the 'always' part in there is seriously wrong..
BSD gets a driver, linux will have in after a quick port.
Linux gets a driver, BSD has to wait and re-impliment.
That is how it seems to a person who has absolutely no idea about kernels and drivers and the different BSD distributions.
First, there are quite a few BSD variations all with their own set of rules for integrating drivers, where some see no problem in using gpl code, others see no problem in using closed source drivers in cases, and yet others swear that everything must be free and open.
Second, differences between a BSD style kernel and the linux kernel are substantial enough that a 'quick port' is seldom an option for technical reasons alone.
Can we please have a car analogy?
I use FreeBSD on a daily basis, I have FreeBSD servers, a FreeBSD development machine, and a FreeBSD daily use desktop (irc, email, web browsing, im, etc.) As it stands now yes, FreeBSD has both the newest versions of KDE and Gnome, and as far as I know the newest version of all the bigger window managers. However, as it stands now FreeBSD is not really a viable desktop in the same way that Linux is. This is because of the two major 3rd party softwares, neither of which are open source. Flash on FreeBSD is rather a joke, which is not to say that the people who work on the flash ports aren't doing well, but going to any flash site is a gamble. Pandora and Google Video, both sites that I go to regularly, lock up Firefox completely. And then there's Java. Java is marked restricted in the ports because of licensing issues, is non-redistributable (hope I spelled that right). Java is a real pain in the arse on FreeBSD. In my experience, the chances of a successful build are about 50/50 at best. You have to download several larger files and move them into the distfiles directory, start the build and cross your fingers and wait.. many hours.. There are other problems as well, for FreeBSD as a desktop os like Linux, but these are the major two... everybody expects to be able to browse the web on a desktop OS with little to no trouble. And as it stands now FreeBSD is unable to deliver an easy to use, out-of-the-box solution for desktop use. I hope this doesn't start a flame war, just adding my two cents.
OS X, back when it was called NEXTSTEP, forked off of BSD 8 years before FreeBSD did, even before 4.4lite came on the scene. You can trace its lineage yourself, if you'd like. Since then, there's been a lot of code borrowing but everyone borrows from FreeBSD and FreeBSD is far from the only OS whose code Darwin has borrowed. Using just that to say that Darwin is based on FreeBSD would make little more sense than using the same fact to claim that GNU/Linux and Windows XP are based on FreeBSD.
Referenced from the site you mention yourself is the BSD family tree.
If you had bothered to look at it, you'd have noticed that:
Darwin is based on Rhapsody, NetBSD 1.4 and FreeBSD 3.2
OS X 10.2 imported code from FreeBSD 4.4
OS X 10.3 imported code from FreeBSD 5.1
If you had ever bothered to use a FreeBSD 5.x machine for a while, and used a machine with OS X for a while from the shell, you'd have noticed how the userland is virtually identical, to a level way beyond how some linux distributions are similar..
Where OS X really did not derive from FreeBSD at all is at the kernel level and of course the gui.
One of the big problems with any flavour of Linux that I've used is the laptop support. Even though I've always specifically bought laptops with very good linux compatibility, it's still hit and miss. A large chunk of the computers sold in retail stores now are laptops and they're getting more and more popular as the price of them continues to drop. Suspend and wifi needs to Just Work.
What I would like to see is a small core list of laptop models that are essentially "certified" to work. Pick the most popular lines, get them working 100% then add more and more models without breaking support for the laptops that worked previously. Ubuntu in particular seems to have a shockgun whack-a-mole approach to supporting laptops and it's maddening.
You won't get too far against linux with that license, buddy.
========
77 77 77 2e 6d 65 6c 76 69 6e 73 2e 63 6f 6d
I realize this article is about the ports tree, but FreeBSD's main source *has* been moving at a blistering rate of development the past few years. Recently there was an article about linux 2.6 getting buggier - and unfortunately the same is true of FreeBSD 5.x and 6.x ... Some things to consider:
* 6.x came out shockingly fast after 5.x
* 4.x was orphaned correspondingly quickly (despite being arguably the only stable freebsd branch left)
* vinum (software raid) support, among other things, was broken thanks to the introduction of geom around 5.1, and gvinum is finally beginning to approach stability as of 6.1
* The new scheduler, ULE, was introduced in one 5.x release and then abandoned when it proved to be completely unstable.
* As a reaction, one of the lead developers forked dragonflybsd off of the last truly stable freebsd release, the 4.x branch. Others have just given up.
* Bugfixes are getting left on the floor in favor of adding features ( just look at a relatively old release such as freebsd 5.3's TODO list: http://www.freebsd.org/releases/5.3R/todo.html - note that most of these problems are *still* not fixed in 6.1 )
People choose the BSD's for stability - or at least, they used to. FreeBSD has been going down a features at all cost route in some kind of effort to play catchup with their perceived rival linux for some time. In doing so, it is losing what makes it unique, and it needs to stop, or else people will abandon FreeBSD for other BSDs, linux (which is now more stable IMO), and even mac os.
-DH
They don't behave differently. At least, the differences are no worse than on the Mac or Windows where apps frequently reinvent the standard toolkit (*cough*Aperture).
or what the heck CUPS is
The only time a Linux user would have to care about this is if their printer isn't supported. And most are (albiet with varying degrees of driver quality).
If only it would:
/dev/dsp, rather than one app locking access to that device to the exclusion of all others. Linux does this via ALSA, but FBSD has no similar, new audio architecture to replace OSS (as ALSA finally has). KDE's artsd + artsdsp is available, but we all know that the entire arts package sucks horribly.
* Mix multiple audio inputs to
* Have better Java and Flash support. Ever try to get native Java working on FreeBSD? First you have to download the Linux Java distribution, install it, then download the FBSD patchset for native Java, build and install it. This takes a day, even on my 2.4GHz, 768MB laptop. And Flash? Don't make me laugh. Flash support is attemptedly enabled via a wrapper, but the Flash version that is currently stable is 5. I'm running 7 on the Gentoo install I'm typing this on, and that's behind the Windows world's Flash version 8.
* Similar to the Java problem, too many apps in FBSD require Linux support. If I'm going to run a Linux app on FBSD, why not just run Linux? Moreover, if parallel FBSD and Linux binaries are necessary (as with Java), then this is going to be a monster waste of HDD space.
* Make compiling the kernel easier. Yes, configuring the kernel is doable by hand, but as any newbie programmer should be able to tell you, the more opportunity you have for human input, the more opportunity there is for failure. More typing/manual config means a higher probability that some piece of kernel functionality goes missing in the build. Why not an ncurses interface with basic (but I must emphasize, also imperfect) dependency resolution, like Linux has?
Look, I love FreeBSD and prefer it to Linux. Its overall design is more sophisticated, saner, and better-organized than Linux, and I find the ports system to be better-designed and more-useful than Gentoo's portage (where are the descriptions of each port in portage guys? I want to know if what I'm about to install is really what I want, and I don't want to have to go google it first!). All that, and FBSD exists under a free-as-in-freedom, rather than free-as-in-communism license. I've run it on my server for years, and with the huge, disappointing exception of the 5.[01] days, it's very stable (current uptime with 6.0-RELEASE is 159 days).
But over various times in the last 6 years, I have tried it as a desktop, and every time I have, there has always been some FBSD-specific behavior that has caused me to switch back to Windows or Linux. FBSD 6.0 is certainly the most usable desktop release yet, and it's thisclose to there for me. But still, not quite. (Frankly, I want an OSX box, and my next laptop will almost undoubtedly be a dual-core MacBook. Then I can have the best of all worlds: a FBSD userland, compatibility with most OSS *nix apps, and commercial-ware app availability. But until then...)
So, I'm happy with FBSD maintaining its role as a rock-solid server OS. Let's not assume everything is a nail when holding a hammer here...
Is Capitalism Good for the Poor?
Based on statistical analysis of slashdot, yes! :P
Beware he who would deny you access to information, for in his heart he dreams himself your master. -Anonymous
12 Dec 2005 - Linus Torvalds states that "only idiots will use [Gnome]".
20 Apr 2006 - Linus claims "that [...] FreeBSD [People] are incompetent idiots."
12 May 2006 - The FreeBSD folks announce a tightly integratin of GNOME with FreeBSD.*
* You didn't click that link, did you?
What I find rather peculiar is this competitive behaviour that's constantly being exercised by *BSD crowd. GNU/Linux camp regard *BSD Unices as the sister OS(es), something they're in some sort of "friendly competition" with, while the *BSD guys continue to look down on Linux and its users, telling on their official pages/blogs/birthday parties... how inferior Linux is in regard to software installation, OS management, security... This superiority complex of theirs is really annoying, especially given it is not based on facts. Compete against Windows damn it - that's the enemy, you morons...
FreeBSD's hardware support isn't as wide reaching as linux from what I have found. If you have normal hardware (ie. popular), you wont find any problems with compatiblity from FreeBSD. If you are ever putting a computer together for the specific purpose of running FreeBSD, always check the hardware compatibility matrix. I had an instance at work where my boss bought the hardware for the servers and had me put it together and get FreeBSD installed. He didn't check the hardware for compatibility and 2 of the 4 RAID cards didn't have drivers for FreeBSD (while linux had drivers for both cards).
For the most part, FreeBSD has good hardware support. Most of the hardware you find will be supported. FreeBSD is a strong, solid server OS. I'm interested in how they are going to push for a stronger desktop presence. In my general setups, I'll use Linux exclusively for desktop (although, I wouldn't have a problem building a server with Gentoo or Debian, I just find FreeBSD a stronger solution), and use FreeBSD for servers. I'd prefer to see FreeBSD focus on just server optimization but, hopefully, we will see some bigger advances from both linux and FreeBSD from this 'competition.'
Are you telling me that you don't see the connection between government and laughing at people? - Interviewer
FreeBSD
[x] easy hardware detection for a wide variety of hardware
[x] Brainless software installation
[x] excellent wireless support...
next list ?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I'm sure ALSA is great for something. Maybe high-end audio, sure. But for my mostly consumer-level needs I've had a lot more success with OSS. I am absolutely willing to admit that this is the fault of my own shoddy configuration: on my GNU/Linux system when using mplayer with ALSA the synchronization is always bad but using "OSS output" (which plays through ALSA anyway) works fine; in xmms ALSA output is garbled, and OSS output sounds great. All I can figure is that my .asoundrc must be bad but hell if I can find good resoureces on how to get good sound quality and sync with ALSA and still have dmix working. But for some reason the OSS emulation works perfectly. On my laptop with FreeBSD I've never once had to touch the OSS config (with the exception of telling it which kernel module to load at startup, then later just compiling it in statically) and it works perfectly with mixing.
Furthermore, is there a reason beyond just mindshare that there aren't drivers for these high-end cards (it seems that mindshare is the major reason that a lot of decent Linux/ALSA audio/music programs don't work with anything else, though the developers always put in their FAQs when asked about BSD support, "BSD doesn't support ALSA, which is superior," but don't actually back up this assertion. I've never seen a good defense of the "OSS sucks, ALSA rules" argument, so if you have a good reason that ALSA is technically better I'd like to hear it.
Thanks to ALSA Linux can be used in recording studios nowadays.
Name a studio using Linux in any meaningful way for audio recording.
"Sufferin' succotash."
As some one who has spent the last year fixing up the systems the FreeBSD admins left behind, I feel qualified is stating that FreeBSD is a terrible business-level operating system. When I started at my company, a bunch of previous admins replaced many core pieces of infrastructure with FreeBSD. One of my core requirements when I got hired was to get them onto Red Hat Enterprise, and part of the reason they threw a lot of money at me was I knew both systems, and I could easily take stuff from a FreeBSD environment.
First, and I must say this, I don't "hate" FreeBSD. Life is too short to argue which operating system is the best overall (I still cringe that I did this sort of fanaticism with Atari and Amiga back in the day, and learned a valuable lesson about what really matters). FreeBSD is a great, tweakable, DIY hobbyist OS done for those who tinker with those sorts of things (which is how I learned it). But FreeBSD in the business enterprise is like hiring a bunch of guys who work out of their basement to do your IT work: may be good in some instances, but is a poor long-term strategy.
Why? Here are some of the problems:
- Hardware support. This is my #1 problem. You want FreeBSD to run on some of those new HP DL380 G4's with the dual Xeons? Oops... sorry. The special scsi blade won't run well with them when you need RAID5. But wait, there's a guy in the Netherlands who has a driver that sort of works... but his website hasn't been updated since 2002, and it's still considered alpha, and compiling it with the specialized kernel breaks...
- Software support. Almost neck and neck with #1. Let's leave out the scant vendors that support the BSD kernel, because FreeBSD fanatics always go, "Oh yeah... what about XXXX...?" For every example that some major vendor that supports FreeBSD that some gives me, I can give you ten examples of companies that don't. And those that do always patch or update their FreeBSD as an afterthought. "New FooPack 3.00 has been released! BSD? Um... yeah, in our FTP site the 1.24 version may still work, but it's EOL and unsupported." Then the stuff about ports is stupid. I don't want to keep my ports tree up-to-date and then have to recompile all the time.
- Finding anyone who knows about BSD is rare. Too rare. Last time I said this, some snide person commented that, "Well any person who worked on Sun systems should know FreeBSD." No. No, they don't. First, most Sun admins never worked on FreeBSD if they have even heard of it, and even if the "translation is easy," most Sun admins know they have Sun to support them when things go terribly wrong. FreeBSD is all community-based, except for a few small unheard-of enterprises, and neither one looks like a good strategy when mentioning them to management.
- FreeBSD community is very RTFM. Fine. There is nothing wrong with that at all. Except when people don't have time to RTFM. Your server is borked, and you don't know why, and you don't have the luxury of scanning bulletin boards, dealing with mailing lists, and snide FreeBSD gurus who say, "Look, we can't do this FOR you," like they have read, "Zen and the Art of Motorcycle Maintenance" too many times.
The UNIX admins who forced FreeBSD on my company are gone. Most of them were considered foul-tempered and uncooperative zealots. Management had to go to the boards, and found much of the same reactions from the FreeBSD community. We had serious issues with these systems, and me and 2 other admins had to bail them out over the last year. Sure, we pay for Red Hat and Windows licenses, but FreeBSD gave us so much grief, that mentioning it to anyone is either done so as sarcastic humor or an insult:
Admin1: Hah! I totally fixed this.
Admin2: What did you do?
Admin1: Aw man, I don't have time to explain.
Admin2: Heh. Don't FreeBSD me, document it! Share the love.
Admin1: Ouch, man. Just was uncalled for.
Admin3: What did he say?
Admin1: He pulled the FreeBSD card on me.
Admin3: Dude, not cool. That was harsh.
Again, I don't hate FreeBSD as a concept. I just know it's not right for the business environment.
Yeah, modded "insightful" by GPL fanboys. Look, factually speaking, you're wrong. Apple has contributed code to FreeBSD.
w s&file=article&sid=938&mode=&order=&thold=
Read this:
Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD.(...) By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. http://osviews.com/modules.php?op=modload&name=Ne
OpenBSM is derived from the BSM audit implementation found in Apple's open source Darwin operating system, which upon request, Apple relicensed under a BSD licence (wikipedia citation) OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation http://www.trustedbsd.org/openbsm.html
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
The reason for my surprise is that FreeBSD is much kinder to the people that make all the applications - the developers.
I'd cite:
* documentation - the man pages and the handbook in FreeBSD are a dream of clarity and completeness.
* API's - stable and (again) well documented. Including the kernel API's.
* Solid driver support - eg my wireless link runs roughly 2x the speed on FreeBSD vs Linux since FreeBSD-4.x days (and, yes, I'm up to date with my Gentoo linux machine).
* The code - the kernel code in FreeBSD is logical, neat, elegant and just makes sense.
Compare Linux - the documentation is a mess frankly, albeit a lovable mess. It's all over the place and incomplete.
The linux API's are a complete nightmare - Linus HimSelf famously proclaims and maintains his right to change any kernel API as and how he sees fit. For a driver developer that's a nightmare, even if the kernel team keep the current kernel-supplied drivers up to date with the ever-changing API. Third-party kernel driver developers (I was one for 7 years on Linux, SCO (!), AIX, HPUX, Solaris and FreeBSD) shudder at that - anyone care to remember the kiobufs DMA fiasco around Linux 2.4.12???
As for the huge monolithic kernel source, Linux is getting close to really, really, really needing to be broken up into a microkernel architecture, just for maintainability issues alone.
As for Gnome (shudder) just look what they did with documentation (man pages anyone - forget it!) never mind supporting the command-line properly (who gave them the right to obsolete the good old-fashioned, universal X "-geometry" etc options).
All that said, FreeBSD is not ahead as most of the posts here testify. So why is that?
Technical inferiority? I don't think so... I can only think it must be the license. Commercial interests should surely like the FreeBSD model better but the GPL just "Keeps Them Honest" and prevents the balkanization that commercial UNIX always suffered.
BTW - as a hint to any FreeBSD developers out there, some things that would really help Linux'ers to have the confidence to explore FreeBSD would be:
* a decent disc format that can be properly shared with Linux - ext2 just about works but can't be exported by NFS on FreeBSD - and when I boot back to Linux I invariably get heaps of file system corruptions to fix up - not nice. While I'm at it, what about ext3? Maybe my ignorance here - perhaps there is JFS or XFS available and compatible on both - but people need to be sure that they can dual-boot a FreeBSD system and still see their data and be _sure_ it's safe. Don't bother me with Reiser - too many scars on that one.
* a live-CD version of FreeBSD, like Knoppix - I started my FreeBSD adventure with Freesbie, a 4.x (now -5.3) live-CD. Anything like that for 6.1?
KSE was not implemented to design
When I first proposed KSE, my proposal was that all system calls become asynchronous - you dispatch the system call. Then, if you wanted POSIX semantics, you suspended yourself until the result was available.
The intent was to implement all of the POSIX blocking semantics at the Libc layer, and all the operational semantics at the kernel layer, and to permit any number of dispatches to occur concurrently.
The way you implement multithreading in this environment is to use call-conversion scheduling: you trade a normally blocking system call for a non-blocking system call plus a context switch. This basically gets you multithreading for free.
The intent of this approach is to utilize your full process quantum, rather than giving it away and suffering an unnecessary context switch overhead, while you still had work pending that could be done in user space within the same process.
In one posting, I put it like this: "If a kernel gives me a quantum, it's *my* damn quantum, and I'll use as much of it as I can, and if I can't use any more,*then* I will yield to a voluntary context switch".
The way you obtain SMP scalability (which was *NOT* the original reason threads were invented in the first place, BTW, since they predated commercially viable SMP system by a long ways) is by permitting multiple processors to return to user space on completed async system calls.
Intelligent readers will not that by not giving away the quantum you were given, you basically get a form of CPU affinity thrown in for free, without any modification to the kernel scheduler, up to the point where you would context switch to a process other than yourself, and cache-bust/TLB-shootdown anyway. This was not a bad idea.
-
What happened instead was an implementation of SA (Scheduler Activations). They kept the KSE name. I came up with it initially - "Kernel Schedulable Entitites" - because I didn't want people to be thinking about solving the problems we intended to solve in a way that was constrained by the ideas that would carry over from using words like "activations" or "threads" or whatever. Semantic loading constrains free thought on technical issues a heck of a lot more than people give it credit for.
But SAs fell far short of my intended vision for the original implementation, a vision I could not implement on my own without buy in from the rest of the FreeBSD community.
-
Once we got buy-in that we were going to do *something* in this area, we had a big meeting. It was hosted at Whistle Communications, where Julian and I and others worked, and where we tended to host BAFUG meetings. Jason Evans and others attended.
I was unfortunately unable to sell my async call gate approach to the problem ("too many changes"), and a compromise was worked on scheduler activations, and a user space thread scheduler that would cooperate with the kernel scheduler.
Compared to what we ended up with, the changes required for the async call gates would have been a lot less code. But I fully admit: my suggested approach would have been impossible to implement incrementally - it would have been all or nothing, and stepping over that threshold would have cost a lot. I failed to sell it adequately, and can only fault myself.
-
Realize that this was not a bad compromise, given the technology at the time: context switches were murder, and crossing the user/kernel protection domain was a heck of a lot more expensive than it is on todays hardware. Also, the vast majority of SMP Intel boxes available in 1996/1997 were at best 2 processor boxes (I still have my dual P90 ASUS box).
Later, the expense of scheduler activations became plain, but it was still not too bad, until things like TLS - "Thread Local Storage" - and other POSIX semantics changes started to make things more painful.
-
Meanwhile, FreeBSD got thread reentrancy work done in its kernel, and a separation of address spaces and contexts, that it would have needed to have, no matter what threading approach was used. So KSE's, even implements as the were, instead of how I had originally envisioned them, was well worth it.
-- Terry
http://www.soundonsound.com/sos/feb04/articles/mir rorimage.htm
They're planning to use Ardour, Rosegarden, JAMin through JACK which uses ALSA.