CompactBSD for Embedded Projects
miggidy_mac writes "FatPort (a wireless Internet service provider in Vancouver, BC) just released CompactBSD. It's a set of tools that allow you to build your own customized, lightweight distribution of OpenBSD and then burns it onto compact flash (or similar) so that it can be run on an embedded PC platform (like FatPort's own FatPoint). CompactBSD takes the security and networking features of OpenBSD that we know and love, and combines them with ease-of-build and small footprint, which is great for embedded devices. Check out the project on SourceForge."
I don't know. This seems awfully familiar to PicoBSD. I guess that any "new" implementation of old technology gets press. As the adage goes, everything old is new again.
Soekris Engineering PC104 sbcs designed specificaly for Free/Net/Open BSD and the occasional Linux. Very nice they be.
I'm not sure you can claim that any given subset of OpenBSD has the same level of security as the real thing. Presumably they're only including code that's been through a security audit, but how tested is any given configuration going to be?
--
E_NOSIG
All the embedded devices that were supposed to take off have died a dotcom death. There's the Netpliance I-Opener, the... Oh nevermind, I forgot this is Slashdot and everybody already knows about every hackable I-Appliance loss-leader hackable goodie released prior to IPO $$$ drying up.
I guess a nice small flashable *NIX distro would be great for making your own homebrew NAT box or router, but isn't there already a Linux distro (Linux router project? Must oogle google for that one later...) for this purpose? Oh well, diversity breeds creativity (according to a Disney employment ad, and the mouse never lies) so this has to be a GOOD THING.
Seriously though, one of my friends runs FreeBSD on his NAT box/file server and keeps touting it as better/easier/faster/sex life improving/more robust than Linux. Since I've set up MY Linux NAT box/file server, I haven't had to mess with it much and I really just think of it as a steady workhorse that does its job day after day without much fanfare. The only thing I can imagine BSD could improve is my sex life, but it's not working for my friend either so I think he's a liar.
In summary...
Small specialized BSD, Beer and Linux = Good
RIAA, DMCA, AOL and FIRE = BAD
(oh, lordy, when will I ever learn to stop fanning the flames???)
fifth sigma, inc.
Your friend is obviously coming on to you in the hopes of improving *both* of your sex lives.
Writers imply. Readers infer.
Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
Quick, better tell this guy!
From your MIT link... We have run benchmarks to measure filesystem performances. Benchmarks have been made on a middle-end PC, based on a i486DX2 processor, using 16 MB of memory and two 420 MB IDE disks. The tests were run on Ext2 fs and Xia fs (Linux 1.1.62) and on the BSD Fast filesystem in asynchronous and synchronous mode (FreeBSD 2.0 Alpha--based on the 4.4BSD Lite distribution).
Hey! Way to beat us BSD fans senseless with modern benchmarks! You must have looked around a fair bit to come up with this golden oldie!
I can't be bothered looking at the postscript if it's anything as compelling as you're first effort at this Troll disguised as information.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
This does bring up a good point... has anybody built a "meta-CVS", a mechanism where I can do a CVS checkout from a public repository, diff the checkout against the one I did yesterday, and then check-in to my own private CVS showing the date, the purported actual change/committer, and the real diff between the two code revs?
If "the entire OpenBSD tree was modified", a simple DIFF would tell the story. I have every OpenBSD release set since 2.4, each of which includes a full source tree.
It would be trivial to do a straight file-for-file diff between the Kernel sources for 2.9/3.0/3.1/current and see exactly what changed and approximately when, and compare this to what CVS claims was officially changed.
Migrated "away" to what platform?Assuming you can find checkouts for the appropriate time range, doing Diff's for the core kernel code between November 2001 and January 2002 should not be a huge task. But I'm not going to put the effort in on the word of an "anonymous coward".
I do not deploy Linux. Ever.