Slashdot Mirror

I'm a security freak, and I'd love to run OpenBSD... but I *need* SMP support and applications to run on top of it.

SMP support is available for sure on FreeBSD, you might want to check out this link to the FreeBSD hardrware FAQ to read more, i don't know if FreeBSD is an option for you?

The question is, how smooth is the transition from FreeBSD ports to OpenBSD ports?

In my experience, very simple, i haven't had any trouble at all. But anyway, this new ports proposal would unify the lot and make it even simpler :)

Fross

I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like .deb with a simpler style?

There is already a package system. It is something like Red Hat, but there are no categorizations (at least in the OpenBSD version; I really only have some experience with it). You can check out the (in no particular order) OpenBSD man pages and port info, the FreeBSD port section of the FreeBSD handbook, and the NetBSD pkgsrc info. Reading those pages should give you more information about BSD ports/packages.

-- Floyd

I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like .deb with a simpler style?

There is already a package system. It is something like Red Hat, but there are no categorizations (at least in the OpenBSD version; I really only have some experience with it). You can check out the (in no particular order) OpenBSD man pages and port info, the FreeBSD port section of the FreeBSD handbook, and the NetBSD pkgsrc info. Reading those pages should give you more information about BSD ports/packages.

-- Floyd

And I quote:

"Basically any 3D rendering was quite likely to have been done on the FreeBSD machines (we can't say exactly what because CPUs are allocated automatically from a pool via a queuing system). This includes things like the big completely CG view of the foetus fields or the shots of the Nebuchadnezzar and its environment."

(in classic reference to The Matrix, of course.)

Also notable: the single BIGGEST movie in Hollywood, ever, as much as we hate to admit it...

When "Titanic" opened on Dec. 19, 1997, Linux developers rejoiced. Not because the movie proved how bad an actor Leonardo Di Caprio was but because the Titanic owed its existence to the Linux operating system -- specifically, the 105 Linux servers that crunched numbers in the backroom of the offices of special-effects company Digital Domain.

In reference to Titanic, which, IIRC, was the single most-money-grossing movie in Hollywood's history ever. Thanks in no small part to Open Source.

• 7/8 stage superpiplined core
• 32KB Instruction, 32KB Data Caches.
• 2KB Mini-Data Cache to avoid data cache thrashing
• Performance Monitoring Unit (Like on PII and up)

of open source is, that it is marked as "stable" when and only when it is really stable (and not when marketing has decided to ship the product), and yet you can still have your bleeding edge program when you like it.

Open source does guarantee that bugs will be found rather than left concealed, and that they can be fixed straightforwardly. It doesn't in any sense keep them from being made or released in the first place.

The fact of the matter is that some open-source and free-software projects have a vastly better track record in terms of stability (which includes security) than some others.

For FreeBSD, there exists the PicoBSD project, basically an initiative to produce slimmed-down versions of FreeBSD useable in embedded and/or read-only environments. However, this is for FreeBSD, not OpenBAS, and while I personally prefer FreeBSD, it does not match OpenBSD in terms of security (while still being more secure than the average Linux distribution). On the

For FreeBSD, there exists the PicoBSD project, basically an initiative to produce slimmed-down versions of FreeBSD useable in embedded and/or read-only environments. However, this is for FreeBSD, not OpenBAS, and while I personally prefer FreeBSD, it does not match OpenBSD in terms of security (while still being more secure than the average Linux distribution). On the

Small and embedded FreeBSD (PicoBSD)
PicoBSD is a one floppy version of FreeBSD which in its different variations allows you to have secure dial-up access, small diskless router, or even a dial-in server. All of this on only one standard 1.44MB floppy disk. It runs on a minimum 386SX CPU with 8MB of RAM, and no hard drive is required!

You are painfully ignorant of the history of Linux and BSD, and are blaming Linus for something that is not his fault.

See A Brief History of FreeBSD for some of the gory details of how FreeBSD got started, out of personal and legal fights over the old 386BSD code in 1993. FreeBSD didn't get fully clear of the legal problems until December 1994.

Meanwhile, Linus started writing Linux in 1991, and he did so because there was no freely available Unix-like operating system for x86. For heavens sake, Red Hat had already been founded by the time FreeBSD had a clear legal status!

So don't blame Linus for not working on BSD. He did NOT fail us miserably. (By the way, I have nothing against BSD - I use FreeBSD at work, and have an OpenBSD machine at home.)

And what's with your attitude that people should do what's best for the community? What community? Who decides what's best for the community? You? A system like that really would deserve the label "communism" that Free Software has been unjustly stuck with.

Free Software has historically been about people writing software that "scratches their own itch". If somebody's itch is to play DOOM on their camera, who the hell gives anyone else the right to say they should be doing something else?

God forbid that we end up with an "Open Source Community" that tells people what to do.


Torrey Hoffman (Azog)

If you visit TPC.org , you will find that they don't have one benchmark, but rather about four, with substantially different purposes:

• TPC-C is intended to determine throughput of a transaction processing system in creating transactions;
• TPC-H measures performance on what is intended to be an "ad-hoc DSS environment."
• TPC-R measures performance on "business reporting," intended to be more like "typical DSS reports."
• TPC-W measures performance on a "web transaction" workload.

The notion that there can be a comparable benchmark between the databases is something of which people should disabuse themselves.

If you need to have high performance transactional behaviour, I would point out that ODBC is NOT the issue; regardless of whether the SQL-CLI drivers suck, the important point is that neither database fully supports the industry standard SQL/XA or X/Open DTP and XA standards.

Serious transaction systems commonly use transaction monitors like BEA Tuxedo or Encina, interfacing via XA to a relational database (like Oracle, Sybase, DB/2, Sleepycat DB, TimesTen, ...). From that perspective, MySQL and PostgreSQL are both still "toys," although SDTP - A Multilevel-Secure Distributed Transaction Processing System outlines how an XA interface to PostgreSQL was constructed in Common Lisp for use in a set of applications running on FreeBSD.

If you build a benchmark based on an application exercising the strengths of MySQL, it will probably perform badly when used with PostgreSQL, and vice-versa.

Take these systems seriously when they start supporting things like XA, and when BEA makes Tuxedo available for use with them.

I would like to see benchmarks of the DRI drivers that are more crossplatform (work being done on FreeBSD for example)

Especially considering the fact that their site is running on FreeBSD.

1. /usr/games
2. Take a look at the FreeBSD Ports Collection under "games". Here's a link. Sure, most of them suck. Deal with it.
3. Most geeks are too busy writing scripts'an'programs'an'config files'an'nat to do *real* work rather than write games. I haven't seen too many games written by DMR, Eric Allman, Kirk McKusick, RMS*, et. al.
   At the most the average geek has an xpilot or freeciv session running.

There is a native FreeBSD Netscape, no Linux emulation required. Usually, Linux emulation is needed for things like games.

You get a really good description if you're installing ports, by using these listings.

You probably haven't compiled a custom kernel yet. Do it. Instructions are in the handbook. It'll speed up your boot time quite a bit.

I don't use GNOME :)

There is a native FreeBSD Netscape, no Linux emulation required. Usually, Linux emulation is needed for things like games.

You get a really good description if you're installing ports, by using these listings.

You probably haven't compiled a custom kernel yet. Do it. Instructions are in the handbook. It'll speed up your boot time quite a bit.

I don't use GNOME :)

Virtually none. BSD is Unix. To the end user, it may be difficult to tell that it's even a different OS. To the admin, there's obviously going to be a difference, simply because it's a whole other kernel and the system is wired differently. But really, I had a little Linux experience and a bit more experience as a Solaris user when I started using FreeBSD and it took me less than a day to set up a nat-ing firewall/gateway.

... major changes would I have to make?

Again, cosmetic, really. For whatever may be new to you, the man system is VERY thorough. I've seen manpages that list under BUGS "This man page is too long". =)

Specifically is it source/binary compatible with linux.

Source? It's just as source compatible as another Unix. Meaning, if your code will compile on IRIX or Solaris too... then it's pretty much a given that it will compile under FreeBSD. There are quite a few hacked programs out there that somebody may have written that will run only on Linux - but do you really need that software in the first place? Plus there's always Ports. If there's a port for the app you want (and chances are there is) then it WILL compile. =)

If you can't get the source for some app to compile, then FreeBSD does have Linux binary-compatibility. I believe it can even be compiled into the kernel. To be honest, I've never used it... simply because I haven't needed to.

Does it have a similar "feel" to linux, how hard would it be to adapt to it?

It's Unix! You can run your favourite shell, XFree86 with KDE or Gnome and Enlightenment (or any other combo under the sun). ls is ls, xterm is xterm, etc...

How does the hardware support compare? Will it run on the "typical" PC?

It's been said that Linux tends to support more of the bleeding-edge than FreeBSD. I don't know how true this is. FreeBSD has kernel-level support for PnP, PCMCIA, USB and a whole slew of other stuff. There isn't a piece of hardware in my system that isn't supported fully in FreeBSD.

On the "typical" PC, you should absolutely NO problems.

Does it have any advantage (speed, stability, security or other)?

This is kind of a contentious issue. There was an article a few days ago about this very issue. FreeBSD outperformed Linux at some disk access benchmarks, I believe. I don't put much stock in those tests though. I think it's fair to say that performance is, at the least, on par with any of the Linux distros.

Stability and security always depend on the admin. There are some rock-solid Linux boxes out there and there are some that can barely stay up for 20 minutes.

It's not fair to say that FreeBSD is more stable or secure, because it all depends on what services you need and run.

I just want to know if it's worth playing with.

IMHO, it is. You'll be pleasantly surprised. I installed FreeBSD 3.4-release on a whim when my Redhat installer failed on an old 486. I haven't gone back since. =)

--

I believe IP should be free.

Cool. Here's some free IP, and here's some more free IP, and here's some more free IP.

This page also lets you get at some free IP, although you have to go to one of the subdirectories, download and unpack the tarball, and get it from the appropriate directory (kernel/net/ipv4).

looking for a document that gives a complete list of all the hardware that is supported by FreeBSD, but can I find such a document? nah.

Try reading the release notes.

There is a special build of FreeBSD that fits on a single floppy disk called PicoBSD. Their project page is at http://www.freebsd.org/~picobsd.

They have several versions that allows you to dial-up your ISP or even have it acts as a router :)

I used it in a 486/25 machine with an older NIC card and an external 28.8kbps modem as a mini-dialup router. Worked great until I got rid of the boxen and got DSL installed :)

I have an ensoniq AudioPCI sound card (and it is ensoniq rather than Creative) from reading the kernel documents and the LINT config file it seemed that my card wasn't supported. I wasn't too bothered by this, but thought I'd double check by looking for a document that gives a complete list of all the hardware that is supported by FreeBSD, but can I find such a document? nah.
With linux I don't know if there is one, but I think the .txt files that come with the kernel probably list things in their heading and if you use (menu/X)config you will see all hardware listed for you anyway.

Today looking through google to double check that my card isn't supported I come across this telling me my card is supported by FreeBSD. Now I haven't time to reboot and check whether it works, but it would be nice if there was the centralised documentation that would help me out here.

The original 4.4BSD code is available in the ports tree:

http://www.free bsd.org/cgi/url.cgi?ports/shells/44bsd-csh/pkg/DES CR
http://www.freeb sd.org/cgi/url.cgi?ports/misc/44bsd-more/pkg/DESCR

The original 4.4BSD code is available in the ports tree:

http://www.free bsd.org/cgi/url.cgi?ports/shells/44bsd-csh/pkg/DES CR
http://www.freeb sd.org/cgi/url.cgi?ports/misc/44bsd-more/pkg/DESCR

As long as the CVS repository is still around, you can always check them out. I know FreeBSD's goes back to 2.0, which was the first unencumbered-by-AT&T release.

• Significantly improved IPSEC functionality. In particular, IPSEC security associations must no longer be manually keyed: the new code supports racoon, the KAME IKE daemon, which is located in /usr/ports/security/racoon. Racoon has been shown to interoperate well with other vendor IKE systems, meaning that FreeBSD 4.1 can be used in a heterogeneous IPSEC environment. However, racoon *is* still a work in progress, meaning that there may still be bugs, configuration syntax changes, etc.
• About 9 months of fixes and improvements to the IPv6 code relative to what was in 4.0-RELEASE.
• FreeBSD 4.1 can now be installed on an IPv6-only network - this will be the first release of FreeBSD that never needs to operate using IPv4 at all! ftp7.jp.freebsd.org (Listed as Japan #7 in sysinstall) is an IPv6-reachable mirror site for installation and package-fetching.
• The ALTQ traffic-shaping system has not yet been merged - it will hopefully be added before the release of 4.2. The more experimental KAME code has also not been merged. If you need those features, consider using the the 4.1-RELEASE+KAME snapshots from ftp://ftp.kame.net which will become available after 4.1-RELEASE.
• KNOWN ISSUES: NFS mounts over IPSEC do not seem to work reliably in all cases - mount hangs and possible data corruption have been observed.

--

Well, we mainly used the one in the FreeBSD handbook. It comes with FreeBSD, but it's also available on the web sites, for example here in the online handbook or on one of the mirrors. It works fairly well.

He was actually talking about an operating system that can actually use them now, instead of talking about how great its going to be when they can use them in the future.

1. You want each client to run and admin their own webserver.
2. You don't want each client to be able to affect the others. This means no rampant interfering resource usage.

1. Two ways to run multiple indepentenly admined web servers come to mind:
   • The new FreeBSD kernel supports the jail syscall. This can attach collection of processes to a particular ip address. I rather suspect that this is exactly the sort of thing that it is meant to be used for.
   • On linux, you can permission individual ports. Each client runs their webserver on a different port. Use ip masquerading to redirect connections to diffent ips (port 80) to different ports (localhost).
2. Unix timesharing systems have been hit with all sort of internal dos attacks. My personal favorite is the shell script which does nothing but call itself in an infinite loop. Hence the creation if killall. All of these attacks (which can be negligence as much as anything intentional) have defenses. Unix is meant to be multi-user, even if we forget in the PC-laden age. We have:
   • Quotas - x% of the hard drive, coming right up.
   • Process limits - With not too hostile users, it shouldn't be too difficult to keep their web servers from running away. Note that csh is the ussual interface to this functionality.

And if this package doesn't take off and becomes unsupported... then where are you? It doesn't quite sound like the sort of thing which will work with the next version of whatever OS it is for. Unless it is a colletion of perl and shell scripts (about what I would use), in which case you could patch it up if necessary. Do you get a source code license for your 25K? Is their customer care any good?

It might be worth it, if they make it truely easy to multi host, and give you a source license, and you are short of rack space and/or using really expensive boxen. But I wouldn't bet on it.

1. You want each client to run and admin their own webserver.
2. You don't want each client to be able to affect the others. This means no rampant interfering resource usage.

1. Two ways to run multiple indepentenly admined web servers come to mind:
   • The new FreeBSD kernel supports the jail syscall. This can attach collection of processes to a particular ip address. I rather suspect that this is exactly the sort of thing that it is meant to be used for.
   • On linux, you can permission individual ports. Each client runs their webserver on a different port. Use ip masquerading to redirect connections to diffent ips (port 80) to different ports (localhost).
2. Unix timesharing systems have been hit with all sort of internal dos attacks. My personal favorite is the shell script which does nothing but call itself in an infinite loop. Hence the creation if killall. All of these attacks (which can be negligence as much as anything intentional) have defenses. Unix is meant to be multi-user, even if we forget in the PC-laden age. We have:
   • Quotas - x% of the hard drive, coming right up.
   • Process limits - With not too hostile users, it shouldn't be too difficult to keep their web servers from running away. Note that csh is the ussual interface to this functionality.

And if this package doesn't take off and becomes unsupported... then where are you? It doesn't quite sound like the sort of thing which will work with the next version of whatever OS it is for. Unless it is a colletion of perl and shell scripts (about what I would use), in which case you could patch it up if necessary. Do you get a source code license for your 25K? Is their customer care any good?

It might be worth it, if they make it truely easy to multi host, and give you a source license, and you are short of rack space and/or using really expensive boxen. But I wouldn't bet on it.

1. You want each client to run and admin their own webserver.
2. You don't want each client to be able to affect the others. This means no rampant interfering resource usage.

1. Two ways to run multiple indepentenly admined web servers come to mind:
   • The new FreeBSD kernel supports the jail syscall. This can attach collection of processes to a particular ip address. I rather suspect that this is exactly the sort of thing that it is meant to be used for.
   • On linux, you can permission individual ports. Each client runs their webserver on a different port. Use ip masquerading to redirect connections to diffent ips (port 80) to different ports (localhost).
2. Unix timesharing systems have been hit with all sort of internal dos attacks. My personal favorite is the shell script which does nothing but call itself in an infinite loop. Hence the creation if killall. All of these attacks (which can be negligence as much as anything intentional) have defenses. Unix is meant to be multi-user, even if we forget in the PC-laden age. We have:
   • Quotas - x% of the hard drive, coming right up.
   • Process limits - With not too hostile users, it shouldn't be too difficult to keep their web servers from running away. Note that csh is the ussual interface to this functionality.

And if this package doesn't take off and becomes unsupported... then where are you? It doesn't quite sound like the sort of thing which will work with the next version of whatever OS it is for. Unless it is a colletion of perl and shell scripts (about what I would use), in which case you could patch it up if necessary. Do you get a source code license for your 25K? Is their customer care any good?

It might be worth it, if they make it truely easy to multi host, and give you a source license, and you are short of rack space and/or using really expensive boxen. But I wouldn't bet on it.

1. You want each client to run and admin their own webserver.
2. You don't want each client to be able to affect the others. This means no rampant interfering resource usage.

1. Two ways to run multiple indepentenly admined web servers come to mind:
   • The new FreeBSD kernel supports the jail syscall. This can attach collection of processes to a particular ip address. I rather suspect that this is exactly the sort of thing that it is meant to be used for.
   • On linux, you can permission individual ports. Each client runs their webserver on a different port. Use ip masquerading to redirect connections to diffent ips (port 80) to different ports (localhost).
2. Unix timesharing systems have been hit with all sort of internal dos attacks. My personal favorite is the shell script which does nothing but call itself in an infinite loop. Hence the creation if killall. All of these attacks (which can be negligence as much as anything intentional) have defenses. Unix is meant to be multi-user, even if we forget in the PC-laden age. We have:
   • Quotas - x% of the hard drive, coming right up.
   • Process limits - With not too hostile users, it shouldn't be too difficult to keep their web servers from running away. Note that csh is the ussual interface to this functionality.

And if this package doesn't take off and becomes unsupported... then where are you? It doesn't quite sound like the sort of thing which will work with the next version of whatever OS it is for. Unless it is a colletion of perl and shell scripts (about what I would use), in which case you could patch it up if necessary. Do you get a source code license for your 25K? Is their customer care any good?

It might be worth it, if they make it truely easy to multi host, and give you a source license, and you are short of rack space and/or using really expensive boxen. But I wouldn't bet on it.

I agree, currently the Linux kernel isn't very "easy" for people who love the DirectX install routine for being so quick and painless (too bad there's no uninstall routine[!]).

ESR is working on making the Linux Kernel config scripts smarter with his CML2.

I'd personally love to have the equivalent of apsfilter for video and sound cards -- just run SETUP, answer some questions, and all is done for you.

But everything takes time. Linux has had to get to the point where people asked, "hey, can I just slap my new soundcard drivers on this thing?" before the quesition could be answered.
---

But where will they get the manual from? CSRG is gone, and there are now three major BSD4.4lite-based OSes. My guess is they would go with FreeBSD's manual, since FreeBSD is the most successful, well known, and, some would argue, the most advanced of the three. But, truth be told, OpenBSD has an excellent manual, and I'll sometimes even consult it when I work with FreeBSD boxen.

Speaking of manuals, an excellent resource is the FreeBSD Project's manual webpage, actually a CGI script which allows to you to consult manuals from CSRG BSD, FreeBSD, NetBSD, OpenBSD, several Linux distributions, SunOS (pre- and post-BSD-Exodus), as well as less common Unices such as Minix (har har), Plan 9, Ultrix, and Seventh Edition.

While we're ontopic, Sun Microsystems publishes a Solaris reference which is essentially the printed manual, but I would not recommend this book. All of Sun's Solaris books are absolutely horrid. (Which I've never understood; their Java books are wonderful.) Complete wastes of money. The only remotely useful things are the discussions of the mail system and network filesystems in the "Advanced System Administration" book.

Hands down, the best single Unix command reference book you can buy at the moment is O'Reilly's Unix in a Nutshell, but that is straight SVR4, with some Solaris-specific commands thrown in for good measure. You'll get what amounts to an abbreviated manual, along with stuff on shells, editors, and maybe a few system calls. If you would like to do system-level programming, Stevens' Advanced Programming in the UNIX Environment will counter-balance the Nutshell book nicely. Can never have too many reference books. :)

Forgive me, I love computer books, and tend to talk about them a lot

But that still does nothing for BSD users. Face it, guys, BSD is seen by much (dare I say most?) of the business IT world as "old" UNIX. Which it is, of course, but I don't find anything particularly wrong with that. But, it's a stumbling block which caused me to stop pushing it. (That, and the fact that my company is large enough to need the two dozen Sun and IBM boxen. I don't see many companies switching from Big Iron to clusters of x86 Free Unix boxen, but the high value and TOC of cheap x86 Unix are going to keep the current wave of IT startups going for another ten years.)

I honestly don't think I would buy BSD in a Nutshell. I'd rather have a printed manual, to complement Unix in a Nutshell, rather than replace it. Isn't that all I'd need? The vi and emacs syntax will be the same. So will awk, sed, and grep (for the most part). I'll be carrying two books around either way, so that stuff is just redundant.

Some say, "why have a printed manual at all, when everything is available on the system or online?" But you may be doing work at a location with both old and new SunOS boxes, and you're working on new SunOS, and you want to be make sure your shell scripts are portable between boxes. Having a printed BSD manual might come in handy then. Or you're on the subway going home from work, and you get in an argument with your geek buddies about proper BSD shutdown syntax. Or if you're like me, you just love computer books. So I'd buy the manual. But not the Nutshell book.

Okay, I'm ranting again.

"InfoMonk" mentions a mysterious BSD book in the works? I'm excited. I think a book on mid-level kernel work would do well. (Something to fill the void between The Complete FreeBSD and Design and Implementation of the 4.4BSD-lite OS.) Or a book on BSD-specific networking and TCP/IP. Hey, Roblimo, get us an interview with TOR so I can bug him about this. ;)

---------///----------

FreeBSD's 4.0-RELEASE branch supports IPv6. If you're interested in getting your own IPv6 Internet address and being connected to Internet6, the Kame project is what you're looking for.

FreeBSD's 4.0-RELEASE branch supports IPv6. If you're interested in getting your own IPv6 Internet address and being connected to Internet6, the Kame project is what you're looking for.

PicoBSD is a FreeBSD distribution trimmed down to the bare minimum so it can run on a floppy. You may want to check this out as the most current versions (see the mailing list or the source) are very configurable and run on various types of hardware (floppy, CD, SanDisk, etc).

There are also several links to other information available from the PicoBSD (small@freebsd.org) mailing list archives here (current) and also here (2000).

PicoBSD will run everything FreeBSD will, provided you can get it onto the boot media, including stuff in the ports tree. Stock FreeBSD firewall include ipfw and ipfilter with NAT (IPMasq for you Linux types) and various other options.

--
Eric is chisled like a Greek Godess

PicoBSD is a FreeBSD distribution trimmed down to the bare minimum so it can run on a floppy. You may want to check this out as the most current versions (see the mailing list or the source) are very configurable and run on various types of hardware (floppy, CD, SanDisk, etc).

There are also several links to other information available from the PicoBSD (small@freebsd.org) mailing list archives here (current) and also here (2000).

PicoBSD will run everything FreeBSD will, provided you can get it onto the boot media, including stuff in the ports tree. Stock FreeBSD firewall include ipfw and ipfilter with NAT (IPMasq for you Linux types) and various other options.

--
Eric is chisled like a Greek Godess

PicoBSD is a FreeBSD distribution trimmed down to the bare minimum so it can run on a floppy. You may want to check this out as the most current versions (see the mailing list or the source) are very configurable and run on various types of hardware (floppy, CD, SanDisk, etc).

There are also several links to other information available from the PicoBSD (small@freebsd.org) mailing list archives here (current) and also here (2000).

PicoBSD will run everything FreeBSD will, provided you can get it onto the boot media, including stuff in the ports tree. Stock FreeBSD firewall include ipfw and ipfilter with NAT (IPMasq for you Linux types) and various other options.

--
Eric is chisled like a Greek Godess

PicoBSD is a FreeBSD distribution trimmed down to the bare minimum so it can run on a floppy. You may want to check this out as the most current versions (see the mailing list or the source) are very configurable and run on various types of hardware (floppy, CD, SanDisk, etc).

There are also several links to other information available from the PicoBSD (small@freebsd.org) mailing list archives here (current) and also here (2000).

PicoBSD will run everything FreeBSD will, provided you can get it onto the boot media, including stuff in the ports tree. Stock FreeBSD firewall include ipfw and ipfilter with NAT (IPMasq for you Linux types) and various other options.

--
Eric is chisled like a Greek Godess

:) FreeBSD is the system of choice for high performance network applications. FreeBSD will outperform other systems when running on equivalent hardware. The largest and busiest public server on the Internet, at ftp.cdrom.com, uses FreeBSD to serve more than 800GB/day of downloads. FreeBSD is used by Yahoo, USWest, Xoom.com and many others as their main server OS because of its ability to handle heavy network traffic with high performance and rock stable reliability.

:| Linux performs well for most applications, however the performance is not optimal under heavy network load. The network performance of Linux is 20-30% below the capacity of FreeBSD running on the same hardware as Linux. As long as you are not trying to squeeze the last ounce of performance out of your hardware, or performing mission critical transactions, Linux is a very good choice for a server OS.

:( Windows NT is adequate for routine desktop apps, but it is unable to handle heavy network loads. A few organizations try to make it work as an Internet server. For instance, barnesandnoble.com uses Windows-NT, as can be verifyed by the error messages that their webserver produces, such as this recent example: Error Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Can't allocate space for object 'queryHistory' in database 'web' because the 'default' segment is full. For their own "Hotmail" Internet servers, Microsoft uses FreeBSD.

I always get this *slightly* wrong, so bear with me.

BSD sets off on branches with a fairly broad set of features. So, the 3.x branch changed a whole lot of stuff from 2.x and added (for instance) support for the Alpha.

4.x binned the whole of 3.x's IDE architecture and replaced it with a new ATA one. The jail system call was added. A new network card driver architecture for cards that use the MII physical layer went in. Stateful extensions were put on the firewall. Lots of USB stuff. IP6 is now *very* integrated, SSL is quite integrated and all is good. Go see the changes for your self. I use it every day with no problem.

Anyway, development continues along all these branches until no-one needs/wants it any more. There are thousands of incredibly serious users of the 3.x branch that have no desire to break their scripts so development continues along 3.x. Most users now use 4.x that I believe has just had its' first "-STABLE" release. I should cvsup and buildworld, really.

There is a 5.x branch that is merging some of the work from BSDi. This is cowboy country, for hackers developers and nutters only. Not for production servers.

So there you go. A more verbose explaination is yours for the taking in the FAQ.

Dave :)

I always get this *slightly* wrong, so bear with me.

BSD sets off on branches with a fairly broad set of features. So, the 3.x branch changed a whole lot of stuff from 2.x and added (for instance) support for the Alpha.

4.x binned the whole of 3.x's IDE architecture and replaced it with a new ATA one. The jail system call was added. A new network card driver architecture for cards that use the MII physical layer went in. Stateful extensions were put on the firewall. Lots of USB stuff. IP6 is now *very* integrated, SSL is quite integrated and all is good. Go see the changes for your self. I use it every day with no problem.

Anyway, development continues along all these branches until no-one needs/wants it any more. There are thousands of incredibly serious users of the 3.x branch that have no desire to break their scripts so development continues along 3.x. Most users now use 4.x that I believe has just had its' first "-STABLE" release. I should cvsup and buildworld, really.

There is a 5.x branch that is merging some of the work from BSDi. This is cowboy country, for hackers developers and nutters only. Not for production servers.

So there you go. A more verbose explaination is yours for the taking in the FAQ.

Dave :)

Actually Matt Dillon's proposed SMP architecture is basically the same as the one in Linux 2.2/2.4 :)

The page in question doesn't fully describe the architecture planned for FreeBSD SMPng; in, for example, the 2000-05-21 through 2000-05-28 freebsd-arch archives, there's a lot of discussion, including this "short summary" note, which start out saying:

What is being proposed here is a major kernel architectural change. The locking provided by SPLS in the traditional BSD kernel goes away and is replaced by mutexs. This model is very different. Interrupts do not in general get blocked. When interrupt service code needs access to some piece of data which is actively being modified by what is traditionally thought of as the "top half" the interrupt thread will block at that point. The finer grained the locking the less chance of a collision, but the number of locking operation goes up and a price has to be paid.

I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).

You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:

Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.

I forget whether there were any messages discussing interrupt threads.

Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?

Actually Matt Dillon's proposed SMP architecture is basically the same as the one in Linux 2.2/2.4 :)

The page in question doesn't fully describe the architecture planned for FreeBSD SMPng; in, for example, the 2000-05-21 through 2000-05-28 freebsd-arch archives, there's a lot of discussion, including this "short summary" note, which start out saying:

What is being proposed here is a major kernel architectural change. The locking provided by SPLS in the traditional BSD kernel goes away and is replaced by mutexs. This model is very different. Interrupts do not in general get blocked. When interrupt service code needs access to some piece of data which is actively being modified by what is traditionally thought of as the "top half" the interrupt thread will block at that point. The finer grained the locking the less chance of a collision, but the number of locking operation goes up and a price has to be paid.

I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).

You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:

Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.

I forget whether there were any messages discussing interrupt threads.

Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?

Actually Matt Dillon's proposed SMP architecture is basically the same as the one in Linux 2.2/2.4 :)

The page in question doesn't fully describe the architecture planned for FreeBSD SMPng; in, for example, the 2000-05-21 through 2000-05-28 freebsd-arch archives, there's a lot of discussion, including this "short summary" note, which start out saying:

What is being proposed here is a major kernel architectural change. The locking provided by SPLS in the traditional BSD kernel goes away and is replaced by mutexs. This model is very different. Interrupts do not in general get blocked. When interrupt service code needs access to some piece of data which is actively being modified by what is traditionally thought of as the "top half" the interrupt thread will block at that point. The finer grained the locking the less chance of a collision, but the number of locking operation goes up and a price has to be paid.

I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).

You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:

Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.

I forget whether there were any messages discussing interrupt threads.

Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?

The MPEG is available at the FreeBSD blender mirror site, or if not you can find it at ftp.blender.nl, but please, be nice, because I don't think they want their little IAE connection to be slashdotted by people d/ling 36Mb files!!

*cough*cough*cough*cough*cough*cough*cough*

Sorry, I got a bad cold.

a great way to code a new kernel is to look at other, open-source kernels. Also, learn assembly if you don't know it already. It is a low-level language so you get a feel for the architecture, and the concepts in assembly are definitely needed in kernel development.

If you make all of your machines identical the amount of problems you will have decreases dramatically. Since we've been creating machines from images rather than by hand the amount of problems we've had has decreased dramatically.

You can use either ghost for NT/95 systems or you can use tar and dd for *NIX. If you have one UNIX box you can use it to make images of HDDs, just plug them into a spare IDE port and dump from disk to image. You can also make a boot floppy and mount the images via NFS. (My personal favorite UNIX is FreeBSD which has its own stripped down version called picobsd although the best place for information is the mailing list (small@freebsd.org) or list archives. Check it out!)

--
Eric is chisled like a Greek Godess

OpenBSD did not have procfs installed by default where as *BSD did. And from what I understand from my security junkie programming buddies, FBSD is still probably vulrable to a procfs exploit (although it hasn't been written yet). OpenBSD worked really hard on this one and fixed the problem right.

Code junkies wanna check out the code? OBSD procfs patch
FBSD procfs patch

% make love;
STDERR: don't know how to make love. Stop.

I mean, wtf? I was hoping to get some daemon lovin' before 5.0! Oh well, at least Solaris will always be my slut. >:)

This looks promising, though... though not the level of Stile's Linux stuff.

---------///----------