...the article in question contains multiple factual errors. The general feeling I get from reading it is that it obscures rather than clarifies the issue. FreeBSD does have a handbook which goes to some lengths to explain these things. Oh, and people, never do "make depend all install" like the article suggests. Make doesn't rescan the dependency file after the "depend" step, so the kernel is built with possibly incorrect dependency information.
I'm sorry, but that simply isn't correct. FreeBSD is Walnut Creek CDROM's single largest source of income, and is in no way subsidized by Linux sales. Walnut Creek CDROM is nowhere near financial trouble - in fact, they've been hiring people lately, and spending money quite generously on FreeBSD development.
> BTW, FreeBSD 3.1-RELEASE *cannot* go all the way to 4 GB without some serious tuning, so there you have.
Depends on what you consider "serious tuning". You need to grab a recent version of the boot loader (e.g. off of a recent FreeBSD 3.1-STABLE or 4.0-CURRENT installation floppy) and make three rather trivial modifications to the kernel source, as described in section 13.15 of the FAQ.
4.0-CURRENT as of late February (or eraly March) and 3.1-STABLE as of late April support large memory configurations out of the box.
Note that if you patch a 3.1-RELEASE system to support large memory configurations, you will lose BSD/OS binary compatibility. This has been fixed in 4.0-CURRENT and 3.1-STABLE.
FreeBSD uses very little GNU software outside of the toolchain, although there is quite a bit of GPLed software (e.g. Perl, CVS, Taylor UUCP). GPLed code (GNU and non-GNU) represents about one-sixth of the source tree; I'd say about half of it is GNU. Feel free to download the source tree and verify this on your own.
As to Tom's article, the only thing that surprises me is that RMS' claim surprised the Linux community. Wake up, people, you've been preaching this guy's gospel (by using and promoting his license) for how many years before you discovered he was a self-centered jerk with a political agenda?
"Nothing much new on this front, Linux has always had incredible support for these basic building blocks."
Who are you kidding? According to the blurb about Stanford's matchbox-sized HTTP server, Linux can push a whooping 27 kBps across a PLIP line. I used PLIP for over half a year between my laptop and my home box, under FreeBSD 2.2 and 3.0, about a year ago. Sustained transfer rate averaged 80 kBps and peaked around 90 kBps.
Now, let's sit down and discuss Linux's realtime capabilities and POSIX 4 conformance... if you can convince me that it performs better than QNX or VxWorks, I'll give in.
(Yes, I know of RTEMS, but I consider it a commercial OS because of its development model, regardless of its being distributed under GPL)
Slashdot Mirror
...the article in question contains multiple factual errors. The general feeling I get from reading it is that it obscures rather than clarifies the issue. FreeBSD does have a handbook which goes to some lengths to explain these things. Oh, and people, never do "make depend all install" like the article suggests. Make doesn't rescan the dependency file after the "depend" step, so the kernel is built with possibly incorrect dependency information.
--
Actually, it servers more RedHat installations than ftp.redhat.com and all other mirrors added up.
I'm sorry, but that simply isn't correct. FreeBSD is Walnut Creek CDROM's single largest source of income, and is in no way subsidized by Linux sales. Walnut Creek CDROM is nowhere near financial trouble - in fact, they've been hiring people lately, and spending money quite generously on FreeBSD development.
> BTW, FreeBSD 3.1-RELEASE *cannot* go all the way to 4 GB without some serious tuning, so there you have.
Depends on what you consider "serious tuning". You need to grab a recent version of the boot loader (e.g. off of a recent FreeBSD 3.1-STABLE or 4.0-CURRENT installation floppy) and make three rather trivial modifications to the kernel source, as described in section 13.15 of the FAQ.
4.0-CURRENT as of late February (or eraly March) and 3.1-STABLE as of late April support large memory configurations out of the box.
Note that if you patch a 3.1-RELEASE system to support large memory configurations, you will lose BSD/OS binary compatibility. This has been fixed in 4.0-CURRENT and 3.1-STABLE.
Actually, the login limit is 5000 since the upgrade, and was 3600 for a long time before that.
For naked, unadultered throughput and usage figures, go see http://www.emsphone.com/stats/cdrom.html.
FreeBSD uses very little GNU software outside of the toolchain, although there is quite a bit of GPLed software (e.g. Perl, CVS, Taylor UUCP). GPLed code (GNU and non-GNU) represents about one-sixth of the source tree; I'd say about half of it is GNU. Feel free to download the source tree and verify this on your own.
As to Tom's article, the only thing that surprises me is that RMS' claim surprised the Linux community. Wake up, people, you've been preaching this guy's gospel (by using and promoting his license) for how many years before you discovered he was a self-centered jerk with a political agenda?
http://home.sol.no/~gisle/oks97.html
Who are you kidding? According to the blurb about Stanford's matchbox-sized HTTP server, Linux can push a whooping 27 kBps across a PLIP line. I used PLIP for over half a year between my laptop and my home box, under FreeBSD 2.2 and 3.0, about a year ago. Sustained transfer rate averaged 80 kBps and peaked around 90 kBps.
Don't take my word for it - try it out for yourself: http://www.freebsd.org/
Now, let's sit down and discuss Linux's realtime capabilities and POSIX 4 conformance... if you can convince me that it performs better than QNX or VxWorks, I'll give in.
(Yes, I know of RTEMS, but I consider it a commercial OS because of its development model, regardless of its being distributed under GPL)
I don't know about Linux, but in Unix network adapters don't have device nodes.