Try them both to see which one is faster/you like more. And don't listen to anyone who tells you not to try the alternatives, they're probably zealots.
Don't let my sig fool you, I like Gentoo better on the desktop. It's just that little bit more convenient to get the latest everything.
Some stuff I can tell you:
With ULE enabled on FreeBSD 5.2, I can't tell the difference. No formal benchmarks, but I did everything I could to expose stuff that might annoy me later on. Dragging windows around really fast with "display content in moving windows" on and music playing. The sort of thing that would bring Linux 2.4 to its knees easily
FreeBSD 5.2 has some annoying things. Like you've got to manually enable the drivers for sound devices and USB mice. And you've got to recompile the kernel to get ext2 support. It's pretty easy and well documented, but you can't just install and have a working system with no additional work.
Gentoo didn't (for me) have any major issues. I mean, compile times can be a bitch, but you'll be doing that on FreeBSD eventually too.
FreeBSD can do some really nifty stuff that Linux can't. Like jails.
My advice is to wait until FreeBSD 5 hits STABLE and Linux 2.6 matures a little bit, install both, and see what's more fun.
you can switch back and forth between ext2 and ext3 on a partition without any problem: it is just a matter of giving the mount command the right filesystem type
Speaking from experience, it works fine. The worst that could happen is messing the journal up.
It was annoying because I had to learn to tweak the kernel before I had a working system. The error it gave me was not a "filesystem not supported by kernel" error, it said the node wasn't a block device. That threw me off. Once I looked at the configuration for the kernel, it was clear ext2 wasn't supported and I had it working in 20 minutes.
The problem was that I had to fix an problem that was happening without any diagnostic information useful to a novice. I mean, all it would have taken was a message "NOTE: FreeBSD 5.2 does not ship with ext2 support and that can cause this error. Please consult the FreeBSD Handbook for more information."
The partition I wanted to read was ext2. All the FreeBSD stuff I was setting up was UFS2, but I needed to get my stuff from my Linux partitions (actually ext3, but it's backwards compatible).
Gentoo has a bit of a learning curve as well. It's damned hard to trust portage, but once you start to get used to it, it has advantages over ports.
I won't hold it against them because 5.x isn't -STABLE yet, but I tried 5.2 and found it a bit lacking as compared to Gentoo. The lack of ext2 support and the way you have to manually tweak the modules to take care of dependencies is irritating.
From a cold start it took me like an afternoon to get up to where my Gentoo installation is. The amount of tweaking you have to do is made up for my how well documented it is.
What clinches it is that I want to be able to play with all the latest software on my desktop system. Gentoo is great for that, but FreeBSD is a bit behind. This isn't a server, it's a desktop behind my OpenBSD firewall. I can afford to live on the edge a little bit.
Are you aware that/compat/linux will work just fine in a jail, and that the Linux distribution in there (you get your choice of redhat or debian) runs a rull suite of GNU utilities? And it's all at native speed, not emulated, it's going through the same syscall mapping layer that BSD itself uses.
a) Going through the compatability layer won't do anything to keep GNU more portable. We're probably headed in the direction of every major OS having a Linux compatability layer... but that's just because Linux programmers don't think portable. That should be discouraged.
b) Keeping the code portable means no porting is necessary, the makefiles will take care of it. Except for making it fit properly into the ports tree that is, but that's relatively trivial.
c) Linux code can't use BSD specific stuff like kqueue. Portable code would handle that with ifdef's and so forth.
Well, they actually *do* help keep the GNU toolset portable and clean. Even if they aren't used, using the same stuff on more than one OS exposes problems before they become a remote root exploit.
Sure I like BSD. Says so in my sig. But if someone else does things right, I'm not going to yell at them.
Besides, with the GNU toolset on the FreeBSD kernel, you can set up a jail on the FreeBSD side, and then if you want both you can have both. There are differences, it's annoying sometimes, I'm sure some people want both.
I've tried to move to FreeBSD for a desktop, but I miss the nifty current stuff, and there's a few things that aren't there yet, and I just can't do without them on a desktop machine.
So, I use Gentoo for the desktop. By the philosophy of the OS, I'm always tempted to tweak and tinker and fiddle, and I do this a lot. It's actually fun sometimes, when Portage doesn't break anything.:)
On the other hand, I'm pissed if I have to interact with the OpenBSD machine explicitly at all. It's a firewall and CVS server, so it gets invoked implicitly a lot, but what kind of machine or where it is is never important. From my experience, Linux machines are pretty attention hungry, and even Debian wouldn't be as well suited to what I need as OpenBSD.
So... they've both got their place, and I'd be hard pressed to do without either of them. Trying to use one OS for everything takes a lot more work. Hell, trying to use one distro of Linux for everything takes a lot of work. The differences between Linux distros can be as big as the differences between a BSD and a Linux.
Maybe most people just don't care. Learning something new when they can get along just fine with what they have is too much to ask. Seriously, the fan on my roommate's CPU died, and it's an Athlon so I told him he shouldn't use it until the fan is replaced. He just shrugged and did something else. That's how little some people care. They're not going to spend a weekend expanding their horizons because they (correctly) don't see any benefit. It's something they don't care about, so even a large improvement won't give them anything they want.
When it doesn't require any new skills (eg, when some OEM uses a distribution that's just as restrictive), then people will start using it, and they won't be much better off than they are now. There are deals like that now, but they haven't really hit the mass market.
There will always be people that don't care, and they will never have as much freedom or as much power as the rest of us. And they won't mind, because they don't care.
The real uphill battle Linux faces is no longer MS, it's user indifference. You can't use merit to sell someone on something they don't care about.
Note that every TCP connection one opens to the outside results in a second connection being made in the other direction, back towards the client computer. Therefore, there is a limit (albeit a large one) on the number of computers that can sit behind a NAT device.
Using other ports for servers is basically a way of using bits that aren't meant for addressing things to address things, and it breaks some stuff. Also, one won't get much business if one requires that customers remember that one's web server is on port 5439.
This problem is particularly bad with SSH, with host key checks.
There are a few workarounds... You can tunnel the traffic between the LANs, which would allow all the applications to work but is a PITA to set up.
What works for me... My cable ISP gives me 2 IP addies without charging extra, so I slapped another card in my NAT box and I redirect connections as necessary, both in and out.
For example, with PF on OpenBSD 3.4:
rdr on $ext1_if proto tcp from any to ($ext2_if) port ssh -> $inthost
nat on $ext1_if proto tcp from $inthost to dynupdate.no-ip.com -> ($ext2_if)
...
pass in quick inet proto tcp from any to { ($ext1_if), ($ext2_if), ($int_if), $inthost } port ssh
This is a little oversimplified, so don't try to use this verbatim. $ext1_if, $ext2_if, $int_if get substituted with appropriate interface names, that is set up elsewhere in the file. $inthost is epanded to the internal IP address of my Linux box. Don't try to use a DNS name here if the DNS server runs on the same machine, as the server may not be running yet when the rules are parsed... dynupdate.no-ip.com is looked up and the IP is used. ($int_if) and stuff bracketted like that is expanded the the IP address of the interface, and when the address changes (eg, DHCP lease expires) the rule will be updated.
The first line forwards incoming connections from outside to my Linux box. Because of ARP issues that I don't feel like explaining, packets for both addresses come in on the primary interface. The second line is a special case for when my Linux box registers with no-ip... the connection goes out through the second interface, so it appears to originate from a different IP. This makes no-ip on the Linux box "just work" with no additional configuration necessary.
The last line passes in SSH connections. pass and block rules get processed after rdr and nat rules, so you need to pass connections to the IP of the internal host.
It's a pain, but even if you have enough IPs it's still handy to set stuff up such that everything is behind one firewall.
The problem with NAT is that it breaks some protocols, eg FTP. The protocol says something like "My IP address is X, make a connection back to me.", but with NAT the computer reports its IP as something that's not a valid public address. That not only breaks some protocols, but you can use that to tunnel in past a firewall onto a private network in some cases.
The other problem is more aesthetic than anything... but it can be a problem if the NAT device is badly configured. Because it has to translate incoming and outgoing packets, the NAT device must track the state of the incoming and outgoing connections. This takes memory, and sometimes there's not really any way for the NAT device to tell when the connection has been severed. So it has to time them out, and this can result in connections evaporating without warning when the server and the client want them to stay open.
Fortunately, you can usually set this to something more reasonable with OpenBSD or Linux (or another BSD, Solaris, whatever). OpenBSD 3.4 with "set optimization conservative" waits 5 days. I've never had any problems with that, but it's tweakable if necessary.
As the other poster said, a NERVA engine alone can't get you off the ground, and there's still a non-trivial risk. There is something to be said for using NERVA as an upper stage, but that's still not as safe as most people would like. I think the minimum NASA would be willing to try is a setup where the reactor was inactive and well protected until it was in an orbit where it could be left alone for at least a few months.
And of course, when you're in orbit there's no reason not to use ion engines or VASIMR or something. The best numbers I can find on nerva-like technology are about 2k seconds. Ion can do better than 5k seconds, and VASIMR can vary between about 1k and 30k seconds. And it can get over a kN of thrust with a 12 megawatt reactor, so it's fast enough to kick you out of the radiation belts without taking too long.
The standard I/O layer doesn't necessarily need to use any system calls (basically, anything under man 3 rather than man 2 is a library call, not a system call).
Well, I/O has to use system calls at some point because of the privileged instructions, but one call to mmap is better. I take your point.
It's handled in the system library (libc), which manages the system calls (mmap's, and so on).
I've done a little assembly on SPARC/Solaris... It was a while ago, and they were old machines even then, but at the time, for (say) read, you'd do something like:
Libraries can't intercept a trap... That goes straight to kerel space pretty much no matter what. I can imagine the compiler using a library instead of a trap for stuff, but that won't affect the old binaries, or old assembly programs.
Forgive me if I'm out of date.:) It's entirely possible that the compiler was putting reads through a library even then, and I was just doing it the dumb way.
Well, one thing you can do is directly address every byte on the largest disk drives we can get today. With an operating system that was designed for direct access, like Multics, you would never have to "read" any files: when you opened one, it would look just as if it had already been read in... all your physical memory would effectively be a big disk cache.
I dunno how Windows or Multics handle it, but on the UNIX side you can use mmap for that. It's slightly less elegant than an all-memory way of doing things, but it's really not that bad. One line for the mmap call, a few lines of tests to make sure it worked, and you're good to go.
Damn it, it's really annoying when people say this. The GNU Public License is satisfied by the distro distributors. That is the only thing that's needed. The GPL doesn't require that people prepend "GNU/" to the name of any product that makes use of GPL licensed code. Perhaps you haven't read it?
The choice of the OS name is pretty much arbitrary. I could take the Linux kernel and the GNU toolset, market the resulting OS under another entirely different name that doesn't incorporate "linux" or "gnu" anywhere. If that's okay, then how is calling it just plain "linux" wrong?
It's hard to interpret these demands as anything other than zealotry, and apart from being extremely annoying, zealotry is bad for business.
Slashdot Mirror
ULE has optimizations for HT/SMT and NUMA.
http://www.chesapeake.net/~jroberson/ULE.pdf
And FreeBSD also has some stuff that implicitly takes advantage of multiple CPUs, like a multithreaded network stack.
ULE has specific optimizations for HT and NUMA.
http://www.chesapeake.net/~jroberson/ULE.pdf
Don't let my sig fool you, I like Gentoo better on the desktop. It's just that little bit more convenient to get the latest everything.
Some stuff I can tell you:
- With ULE enabled on FreeBSD 5.2, I can't tell the difference. No formal benchmarks, but I did everything I could to expose stuff that might annoy me later on. Dragging windows around really fast with "display content in moving windows" on and music playing. The sort of thing that would bring Linux 2.4 to its knees easily
- FreeBSD 5.2 has some annoying things. Like you've got to manually enable the drivers for sound devices and USB mice. And you've got to recompile the kernel to get ext2 support. It's pretty easy and well documented, but you can't just install and have a working system with no additional work.
- Gentoo didn't (for me) have any major issues. I mean, compile times can be a bitch, but you'll be doing that on FreeBSD eventually too.
- FreeBSD can do some really nifty stuff that Linux can't. Like jails.
My advice is to wait until FreeBSD 5 hits STABLE and Linux 2.6 matures a little bit, install both, and see what's more fun.ext3 faq Speaking from experience, it works fine. The worst that could happen is messing the journal up.
It was annoying because I had to learn to tweak the kernel before I had a working system. The error it gave me was not a "filesystem not supported by kernel" error, it said the node wasn't a block device. That threw me off. Once I looked at the configuration for the kernel, it was clear ext2 wasn't supported and I had it working in 20 minutes.
The problem was that I had to fix an problem that was happening without any diagnostic information useful to a novice. I mean, all it would have taken was a message "NOTE: FreeBSD 5.2 does not ship with ext2 support and that can cause this error. Please consult the FreeBSD Handbook for more information."
The partition I wanted to read was ext2. All the FreeBSD stuff I was setting up was UFS2, but I needed to get my stuff from my Linux partitions (actually ext3, but it's backwards compatible).
Gentoo has a bit of a learning curve as well. It's damned hard to trust portage, but once you start to get used to it, it has advantages over ports.
I won't hold it against them because 5.x isn't -STABLE yet, but I tried 5.2 and found it a bit lacking as compared to Gentoo. The lack of ext2 support and the way you have to manually tweak the modules to take care of dependencies is irritating.
From a cold start it took me like an afternoon to get up to where my Gentoo installation is. The amount of tweaking you have to do is made up for my how well documented it is.
What clinches it is that I want to be able to play with all the latest software on my desktop system. Gentoo is great for that, but FreeBSD is a bit behind. This isn't a server, it's a desktop behind my OpenBSD firewall. I can afford to live on the edge a little bit.
b) Keeping the code portable means no porting is necessary, the makefiles will take care of it. Except for making it fit properly into the ports tree that is, but that's relatively trivial.
c) Linux code can't use BSD specific stuff like kqueue. Portable code would handle that with ifdef's and so forth.
Well, they actually *do* help keep the GNU toolset portable and clean. Even if they aren't used, using the same stuff on more than one OS exposes problems before they become a remote root exploit.
Sure I like BSD. Says so in my sig. But if someone else does things right, I'm not going to yell at them.
Besides, with the GNU toolset on the FreeBSD kernel, you can set up a jail on the FreeBSD side, and then if you want both you can have both. There are differences, it's annoying sometimes, I'm sure some people want both.
I'm just happy I won't have to SSH to my OpenBSD machine to get some decent man pages anymore.
There's room for both I think.
:)
I've tried to move to FreeBSD for a desktop, but I miss the nifty current stuff, and there's a few things that aren't there yet, and I just can't do without them on a desktop machine.
So, I use Gentoo for the desktop. By the philosophy of the OS, I'm always tempted to tweak and tinker and fiddle, and I do this a lot. It's actually fun sometimes, when Portage doesn't break anything.
On the other hand, I'm pissed if I have to interact with the OpenBSD machine explicitly at all. It's a firewall and CVS server, so it gets invoked implicitly a lot, but what kind of machine or where it is is never important. From my experience, Linux machines are pretty attention hungry, and even Debian wouldn't be as well suited to what I need as OpenBSD.
So... they've both got their place, and I'd be hard pressed to do without either of them. Trying to use one OS for everything takes a lot more work. Hell, trying to use one distro of Linux for everything takes a lot of work. The differences between Linux distros can be as big as the differences between a BSD and a Linux.
Maybe most people just don't care. Learning something new when they can get along just fine with what they have is too much to ask. Seriously, the fan on my roommate's CPU died, and it's an Athlon so I told him he shouldn't use it until the fan is replaced. He just shrugged and did something else. That's how little some people care. They're not going to spend a weekend expanding their horizons because they (correctly) don't see any benefit. It's something they don't care about, so even a large improvement won't give them anything they want.
When it doesn't require any new skills (eg, when some OEM uses a distribution that's just as restrictive), then people will start using it, and they won't be much better off than they are now. There are deals like that now, but they haven't really hit the mass market.
There will always be people that don't care, and they will never have as much freedom or as much power as the rest of us. And they won't mind, because they don't care.
The real uphill battle Linux faces is no longer MS, it's user indifference. You can't use merit to sell someone on something they don't care about.
Note that every TCP connection one opens to the outside results in a second connection being made in the other direction, back towards the client computer. Therefore, there is a limit (albeit a large one) on the number of computers that can sit behind a NAT device.
Using other ports for servers is basically a way of using bits that aren't meant for addressing things to address things, and it breaks some stuff. Also, one won't get much business if one requires that customers remember that one's web server is on port 5439.
This problem is particularly bad with SSH, with host key checks.
There are a few workarounds... You can tunnel the traffic between the LANs, which would allow all the applications to work but is a PITA to set up.
What works for me... My cable ISP gives me 2 IP addies without charging extra, so I slapped another card in my NAT box and I redirect connections as necessary, both in and out.
For example, with PF on OpenBSD 3.4: This is a little oversimplified, so don't try to use this verbatim. $ext1_if, $ext2_if, $int_if get substituted with appropriate interface names, that is set up elsewhere in the file. $inthost is epanded to the internal IP address of my Linux box. Don't try to use a DNS name here if the DNS server runs on the same machine, as the server may not be running yet when the rules are parsed... dynupdate.no-ip.com is looked up and the IP is used. ($int_if) and stuff bracketted like that is expanded the the IP address of the interface, and when the address changes (eg, DHCP lease expires) the rule will be updated.
The first line forwards incoming connections from outside to my Linux box. Because of ARP issues that I don't feel like explaining, packets for both addresses come in on the primary interface. The second line is a special case for when my Linux box registers with no-ip... the connection goes out through the second interface, so it appears to originate from a different IP. This makes no-ip on the Linux box "just work" with no additional configuration necessary.
The last line passes in SSH connections. pass and block rules get processed after rdr and nat rules, so you need to pass connections to the IP of the internal host.
It's a pain, but even if you have enough IPs it's still handy to set stuff up such that everything is behind one firewall.
The problem with NAT is that it breaks some protocols, eg FTP. The protocol says something like "My IP address is X, make a connection back to me.", but with NAT the computer reports its IP as something that's not a valid public address. That not only breaks some protocols, but you can use that to tunnel in past a firewall onto a private network in some cases.
The other problem is more aesthetic than anything... but it can be a problem if the NAT device is badly configured. Because it has to translate incoming and outgoing packets, the NAT device must track the state of the incoming and outgoing connections. This takes memory, and sometimes there's not really any way for the NAT device to tell when the connection has been severed. So it has to time them out, and this can result in connections evaporating without warning when the server and the client want them to stay open.
Fortunately, you can usually set this to something more reasonable with OpenBSD or Linux (or another BSD, Solaris, whatever). OpenBSD 3.4 with "set optimization conservative" waits 5 days. I've never had any problems with that, but it's tweakable if necessary.
From what I can see, most of the bugs are specific to certain platforms and drivers. The core stuff looks okay.
The parachute is probably visible from orbit. :)
Just wanted to mention that, in my always humble opinion, everyone at NASA has done an outstanding job on this.
As the other poster said, a NERVA engine alone can't get you off the ground, and there's still a non-trivial risk. There is something to be said for using NERVA as an upper stage, but that's still not as safe as most people would like. I think the minimum NASA would be willing to try is a setup where the reactor was inactive and well protected until it was in an orbit where it could be left alone for at least a few months.
And of course, when you're in orbit there's no reason not to use ion engines or VASIMR or something. The best numbers I can find on nerva-like technology are about 2k seconds. Ion can do better than 5k seconds, and VASIMR can vary between about 1k and 30k seconds. And it can get over a kN of thrust with a 12 megawatt reactor, so it's fast enough to kick you out of the radiation belts without taking too long.
mov FD, %o0
add %fp, BUFF, %o1
mov MAX, %o2
mov 3, %g1
ta 0
Libraries can't intercept a trap... That goes straight to kerel space pretty much no matter what. I can imagine the compiler using a library instead of a trap for stuff, but that won't affect the old binaries, or old assembly programs.
Forgive me if I'm out of date.
It's still a system call, that's not as fast as accessing a file you've mmaped yourself.
Damn it, it's really annoying when people say this. The GNU Public License is satisfied by the distro distributors. That is the only thing that's needed. The GPL doesn't require that people prepend "GNU/" to the name of any product that makes use of GPL licensed code. Perhaps you haven't read it?
The choice of the OS name is pretty much arbitrary. I could take the Linux kernel and the GNU toolset, market the resulting OS under another entirely different name that doesn't incorporate "linux" or "gnu" anywhere. If that's okay, then how is calling it just plain "linux" wrong?
It's hard to interpret these demands as anything other than zealotry, and apart from being extremely annoying, zealotry is bad for business.
god... if you want to see groupspeak in action, try macslash.