Slashdot Mirror
FreeBSD 6.0 to Target Wireless Devices
BSDForums writes "FreeBSD is hoping to move beyond the server and desktop market by providing expanded wireless support. FreeBSD developer Scott Long said that 'one of the primary reasons for improving wireless support is to give companies the tools to put FreeBSD into their wireless devices. The guy at FreeBSD who is adding wireless support is under contract from wireless companies to do the work.'"
If you look in FreeBSDs mailing list archive, their is a message explcitily saying we need to be more like NetBSD.
There is also con-currently somebody ranting about the "off-site" development of FreeBSD features:
Myself, I'd rather FreeBSD sort out it's current problems out before thinking about introducing New problems.
*
God help us if someone ran FreeBSD on routers, oops, oh wait, someone does. Some little company known as Juniper. JunOS is derived from FreeBSD.
"To those who are overly cautious, everything is impossible. "
Juniper uses FreeBSD (they call it 'JunOS'). Their routers have become quite popular for very high traffic installations, due in no small part to the efficient networking code of the FreeBSD kernel. Also, don't forget that the f-root name server (actualy a distributed network of servers) is exclusively FreeBSD.
I posted something to this effect on the original CNet article
I work in embedded development myself (previously video game consoles, then DOCSIS cable modems, now video equipment), so I've seen the shift from expensive proprietary systems (like vxWorks) to free (as in money) systems like Linux.
The proprietary systems typically have high up-front costs, along with a per-unit royalty, which inflates the cost of the devices. Linux allows for cheaper devices (whether or not the savings are passed to the customer remains to be seen), at a cost (complying with the GPL). This can be somewhat mitigated by making modules that are not licensed under the GPL.
BSD entering the space will provide some good competition for Linux. Whether newer designs switch to BSD will depend on the chipmakers (like Broadcom), as they are the people who usually write the drivers. Most devices nowadays are just the reference design hardware tweaked a bit with the reference software. So, whatever OS is used for the reference designs is what will be the dominant OS in the embedded space.
Only time will tell, but if FreeBSD can pull this off, they'll definitely gain some traction.
-- Joe
Actually, KHTML is LGPL.
I agree with your comment, but you mention that the bet is that companies will foster further development of the projects even if they're not forced to provide code back [I'd quote but I'm posting this from links]. I have my doubts.
The filesystem is the package manager
It's a lot easier to develop for FreeBSD since it has one consistent version controlled set of user space and kernel code with timed regular releases.
It is stable and companies don't have to worry as much about keeping their own specially forked version to support their device,
WTF are you wibbling about? Where's all the closed source binary-only stuff in my copies of /usr/src? Where's this garbage you speak of?
Unless you qualify your statements, you're just spreading FUD.
OpenBSD were planning a RAID system called bioctl, they wanted to fix up various cards which were particularly poor-running by writing complete drivers and having the functionality for them all be run through bioctl, much like ifconfig does with all network cards.
For months Theo and others talked to Adaptec for documentation on the AAC card, after four they gave an ultimatum - basically saying give us documentation or we are removing support for the aac card. Adaptec's reponse was to say that within another four months an SDK would be available for usage.
Needless to say, that wasn't what OpenBSD wanted or asked for. So it was removed.
Scott Long gave a rather heated opinion on OpenBSD's choice to give Adaptec an ultimatum on if they wanted the cards supported or not. Basically calling Theo de Raadt and anyone that supported him thugs and bullies.
That is one example of binary cruft in FreeBSD, however, there is also the Atheros wireless HAL written by Sam Leffler of Atheros.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
I can't speak for *your* copy of /usr/src, since you could have rm -rf /usr/src/sys/contrib. Mine has plenty, though. The policy of FreeBSD is (and I beleive has been for a long time) that the "contrib" directories have much more lenient restrictions on what licenses are acceptable. See, for example:
/usr/src/sys/contrib/dev/ath -name *.uu /usr/src/sys/contrib/dev/ath/COPYRIGHT
find
cat
I beleive sys/contrib/dev/nve also has binary-only drivers too. (No COPYRIGHT notice there, so who knows what the terms are.)
First of all: why are those 'remote', legal possibilities not existant in FreeBSD?
Because BSD has already been through a clarifying legal process, one that Linux has yet to go through -- or rather it's in the middle of a big honkin' legal process right now. See for more info 4.4BSD and descendants in the BSD article on wikipedia. You are correct that one prime BSD advantage is the lack of GPL lock-in, but it is not the only advantage in the current Linux legal climate -- no matter what the validity of SCO claims, as we all know the FUD is the point.
I watched C-beams glitter in the dark near the Tannhauser gate.