FreeBSD Vows to Compete with Desktop Linux 370
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'."
Re:didnt they have a completely goal? (Score:5, Insightful)
Re:Did they alreay win? (Score:5, Insightful)
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.
Re:Did they alreay win? (Score:3, Insightful)
Re:Did they alreay win? (Score:3, Insightful)
Re:This isn't about the FreeBSD base system. (Score:5, Insightful)
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.
Re:How On Earth Is This Offtopic?? (Score:3, Insightful)
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).
This is a good thing. (Score:3, Insightful)
Re:Did they alreay win? (Score:5, Insightful)
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.
No one wants this (Score:5, Insightful)
* 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 [freebsd.org] - 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
Re:Did they alreay win? (Score:4, Insightful)
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).
FreeBSD would be better on desktop, if only... (Score:3, Insightful)
* 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...
Hmmm... (Score:2, Insightful)
Re:Did they alreay win? (Score:3, Insightful)
[x] easy hardware detection for a wide variety of hardware
[x] Brainless software installation
[x] excellent wireless support...
next list ?
Re:so what - now the truth about BSD is trolling?? (Score:1, Insightful)
Re:didnt they have a completely goal? (Score:3, Insightful)
By that measure Ethereal is well done, but that is clearly not true since it is filled with remote exploits and developed by a team that does not care about security. The Coverity scannings are useful for catching some types of bugs, but a low "Defect Reports/KLOC" does not imply that the software is safe nor that it is well designed.
Re:didnt they have a completely goal? (Score:4, Insightful)
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.
The puzzle is that FreeBSD isn't already way ahead (Score:2, Insightful)
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?
Re:This isn't about the FreeBSD base system. (Score:3, Insightful)
Unfortunately a lot of developers do think like this. For a long time a certain program wouldn't work under FreeBSD, because it only supported ALSA. Every bug report on the problem was summarily closed with a message on the order of "we can't fix this until FreeBSD follows the ALSA audio standard."
KSE was not implemented to design (Score:4, Insightful)
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
Re:BSD is not ready for Business (Score:3, Insightful)
What's your point?
Sounds like a project management problem to me, not an operating systems issue.
smash.
Re:FreeBSD would be better on desktop, if only... (Score:3, Insightful)
Kernels are too complicated to let the illiterate futz about with them. If you don't know what you're doing, then stay the hell out of there!
You can't abstract complexity away. That is a myth. A GUI does not simplify anything, all it does is give the illusion that something is simple. You may think the complexity has gone away because you can click a box instead of typing "yes" to build a driver. But it's just as easy to click the WRONG box as it is to mistype "yes".
Besides, as I said before, there is no reason to configure the FreeBSD kernel. Every driver you need is already a loadable module. And even if you do need to fiddle with it for some odd reason, it's EASIER to configure and build than Linux, even without the GUI.