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'."
I couldn't find a single example of Scott's "vow to compete" with Linux in the article. All he did was express his hopes of feature parity within a year or so. The "vow to compete" is a useless and sensationalist addition by the author, so let's keep it civil and avoid flame wars.
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...
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.
the problem now is to get groups like GNOME and KDE to use the features we're making available to them.
The obvious problem for large projects like GNOME is of course that they need to make a good experience on a pretty wide variety of platforms. To use any platform-specific feature it will need to be either emulated, replicated, worked around or otherwise made available on all platforms; or it could only go in as an optional extra that nothing else is actually depending on. So, making advanced FS logging capabilities a cornerstone of the desktop, for example, would be out since far from all platforms will have the requisite framework. "You can only run desktop X if you also use filesystem Y" is likely to go over like a lead balloon.
Fortunately, good ideas in the OS space tends to be picked up by everybody sooner or later. Over time there just aren't that many good ideas that will not be available everywhere as time goes on.
Trust the Computer. The Computer is your friend.
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).
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.
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).
Wasnt the goal of BSD to be secure and reliable, like debian, only moreso? How come now they're "competing with desktop Linux" ?
Because security and reliability aren't sexy. They don't gain you new users like features do. Same reason Microsoft keeps adding features to Windows rather than fixing security problems, and keeps adding features to Word instead of making the interface better so the features it has become more useful.
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