American Megatrends's NAS based on custom FreeBSD

Asmodai writes "American Megatrends unveiled its StorTrends NAS software with NDMP support. This piece of software, which plugs into the StorTrends and ServTrends storage solutions, is a custom developed FreeBSD. Looks interesting for those who are interested in NAS and SAN and the subsequent managing and monitoring." It's interesting that this press release (because that's what it is) mentions FreeBSD by name.

Comments

Truly free

[Ulwarth]

This is what the BSD'ers mean when they say that the BSD license is truly free, because you can use it for anything.

Let's face it, the GPL is more "selfish" - we just don't see it that way because we are comparing it to proprietary software licensing.

Re:Truly free

[Ami Ganguli]

To each his own. The reason I prefer the GPL is that I know that people building on my work have to contribute their improvements back to the community. I think that's fair: they got something for free, they should give something back.

I can see why companies like Apple and AMI might choose to keep their patches to themselves, and I suppose if the BSD people don't mind then that's Ok, but I think that in the long run software under GPL will go further. If the NAS software were released then AMI might lose a competitive edge in the short term, but they also lose out on features that those competitors add to the product.

Similarly with Apple. The BSDs are solid and in some ways better than Linux, but IBM and others are scaling Linux up to massive systems. Now Apple is trying to push OsX into the server market and they're going to miss out on those developments. So they got to keep some enhancements to themselves, but they lose out on other people's technology.

Re:Truly free

[hawk]

>I can see why companies like Apple and AMI might choose to keep their
> patches to themselves,

Except for the minor detail that Apple *doesn't* keep them to themselves. They sent massive number of bugfixes back, and released Darwin under a free license. . .

hawk

Re:Truly free

[Ami Ganguli]

That's interesting. I knew they'd released Darwin, but I always thought (ok, assumed) they held on to bits. Are the drivers available? What about the file system changes?

Does that mean you can run an Apple box with Darwin and have everything work except the GUI?

Re:Truly free

[hawk]

Yes. yes. yes. :)

Not just on an apple box, ut on a generic x86 box!

I actually have a paper on the economics involved that was presented last summer. It's at

http://www.personal.psu.edu/reh18/research/01.sc e/ Open_Source.conference.ps

I'll be adding a longer section on when a viral license makes sense, as well as a brief section on when a VIRAL licesnes has economic advantages (after discussion there, it's close to irrelevant) and a short literature review before it goes to a journal. Unlike the rest of the economics I do, this one has no math beyond addition, and, even more amazingly, no greek characters.

Darwin is closely tied to FreeBSD now; Jordan Hubbard now works for them.

In a nutshell, Darwin is not a a distinguishing product for apple, but rather a necessary component. It is less expensive for apple to keep to the public base and benefit from joint maintenance on Darwin than to keep private patches which must be maintained. There is a gain from making it all public, and no benefit to keeping any piece of Darwin private.

hawk

Re:Truly free

[Ami Ganguli]

An interesting article. I'd love to see the final copy.

Question: Wouldn't it make more sense for Apple to release under a viral license than a public licenese? Under the public license there's the risk that a competitor will build on Darwin and not release the source back to Apple. With a viral license a competitor can still build on Darwin, but at least Apple could see some benefit.

This comes back to my personal reason for choosing GPL: I'd like others to build on my work, but I'd like to get something back if they do so.

On a larger scale, we've got IBM, SGI, and Compaq (all competitors) contributing to the Linux kernel. I can't imagine that IBM, for example, would port their JFS to Linux if they thought Compaq could integrate it into Tru64 and use it to poach IBM's customers. The GPL ensures that everybody has to play by the same rules, so there is less risk.

Re:Truly free

[hawk]

> An interesting article. I'd love to see the final copy.

I actually submitted it here after the conference, but they never took nor accepted it . . .

> Question: Wouldn't it make more sense for Apple to release under a
> viral license than a public licenese?

apparently not :)

Under the public license there's
> the risk that a competitor will build on Darwin and not release the
> source back to Apple. With a viral license a competitor can still
> build on Darwin, but at least Apple could see some benefit.

That was my initial impression, and relates to the material I need to supplement.

There's a couple of things going on here. The first is that Apple sees no harm from someone running off with the code; they're no worse off than before. But Apple really has no competitors--or even potential competitors--for Darwin. Darwin is like a hard drive or memory chip for Apple; it's a commodity part used to build their specialized product. Apple would just as happily use FreeBSD, NetBSD, Linux, or MS-DOS underneath if it had all the needed elements and was stable.

Anyway, another firm has the same incentives as apple to contribute changes back to the common base. The competitor also can wander off with any of the *BSD for a base, and these are likely to be about as close as Darwin to what is needed for an arbitrary project--either will require massive modification, and if the changes aren't returned, the company is on its own for maintenance.

This leaves minimal chances for someone to run off with it, and no problem for apple if someone does (it saddles itself with unnecessary costs!)

On the other hand, if Apple went viral rather than public, it saddles *itself* with that license with regard to any contributions from the outside. This limits apple's options to later fork off on one-off projects--say, a tivo-like device.

Overall, there appears to be no net cost to Apple for choosing public over viral, and a couple of gains.

There's a bit more. One of the thoughts that came back from the conferrence is that generally, code must be so heavily modified to use for something else that lost revenue from the "wandered" variation is probably nil (there's not a huge advantage to the competitor in using the code base). Another is that public licenses give better ability to mix and match pieces under different public licenses, whereas viral licenses are incompatible with each other and, in many cases, third party closed source software.

Finally, the public license precludes a reaction that can fairly be characterized as "rabid" over suspected "violations"--this is just a hassle that firms don't need.

hawk

Re:Why FreeBSD?

[Amokscience]

Since all you want are some ideas:

* It's low cost.
* It allows for closed source distribution.* It's solid, stable code with heavy ties to ISPs (who would use such devices)
* FreeBSD is open source and future improvements or bug fixes can be rolled in without licensing fees/issues.

Love-hate relationship?

[embobo]

I've never had a custom-designed system based on FreeBSD (or Linux) but I would think that it would drive me insane, knowing that it was based on FreeBSD, but unable to use any of the flexibility FreeBSD offers.

Suppose, for example, the thing didn't support ftp. You know FreeBSD supports proftpd but I bet you are forbidden from installing it on the box. Suppose there is a huge bug in the mta on the box (never!). Do you wait for the vendor to supply a patch or do you start hacking?

The situation is similar to using a package manager. Whenever I install SuSE I try to keep it purely RPM-based but inveitably there is some piece of software I end up compiling myself, without making it a package before installing. From that point on I abandon yast and SuSE config because they don't know about that software and will happily trounce it's config files if one isn't careful. (Strangely, I never worry installing a port on a FreeBSD box. I'm more confident that the port isn't going to be sticking its nose where it doesn't belong.)

Re:Love-hate relationship?

[cnkeller]

Suppose, for example, the thing didn't support ftp. You know FreeBSD supports proftpd but I bet you are forbidden from installing it on the box. Suppose there is a huge bug in the mta on the box (never!). Do you wait for the vendor to supply a patch or do you start hacking?

If I recall correctly, Network Appliance servers run on a modified version of BSD as well. Simply put, you don't hack, ever. When you are running a database of several terabytes a NAS box; there is a reason you are paying several million dollars for the hardware: vendor support and accountability. I was on a project must like this in the classified world. If you are caught hacking into a box (even to fix something the vendor should be fixing), you are generally escorted out by a pair of large marines. In many places (not all), there is a zero hacking policy on multi-million dollar boxes that run critical systems.

Re:Love-hate relationship?

[hawk]

>I personally think that it's a pretty big deficiency of the GPL that it
>doesn't require access to be provided to allow the owner modify the
>system on which the source is used.

This would have the result of banning any ROM--or at least those soldered
to the mother board . . .

hawk

Re:Love-hate relationship?

[mindstrm]

You perhaps haven't worked in a real environment...
When you buy a NAS box or something.. you aren't concerned about it being super multi-purpose.

I don't *care* if I can install a web server on a box or not.. when I want a web server, I buy it.

Same goes for Unix. I mean, it's nice knowing some of your servers can double as other things... (more difficult/prohibitive with windows)... but you still don't do it. When you build a big database server.. you don't use it as your web server as well. Etc... etc.. etc..

Protocols

[hearingaid]

The device supports SMB/CIFS and NFS, unsurprisingly as those are the two most common file-sharing protocols at the moment. It's interesting though that, considering they're using FreeBSD, they didn't include AppleTalk support (easily available via the ports tree). It may be that with the advent of OS X, they think NFS is enough for the entire non-Win32 universe.

Re:Why FreeBSD?

[Zac Thompson]

Reminds me of an answer I read once, attributed to Torvalds:

Other than the fact Linux has a cool name, could someone explain why I should use Linux over BSD?

No. That's it. The cool name, that is.

Zac

Netgraph

[hodeleri]

FreeBSD gained the NetGraph code because it eventually came too difficult for the third party to cost effectively roll the FreeBSD source changes into their custom version. (I forget the company name, they're part of IBM now IIRC.)

Re:Netgraph

[benedict]

They were called Whistle and their flagship (only?) product was the InterJet.

They also contributed divert sockets and I believe they funded the development of soft updates.

BSD on Flash, they just moved media to memory?

[BrookHarty]

So this is just BSD on a flash rom? Or is this all integrated into the Bios, so you just power the machine on and configure? What size is the rom?

I could do the same thing with a cdrom, burn everything onto CDROM, boot cdrom, and not touch the harddrives. Looks like they just took software and moved it from media to memory.

Re:BSD on Flash, they just moved media to memory?

[unclei]

So this is just BSD on a flash rom? Or is this all integrated into the Bios, so you just power the machine on and configure?

Yes and no. The machine powers on and the OS loads from an IDE flash rom. The system has a default IP and you configure everything through a web browser. The flash is 32MB.

I could do the same thing with a cdrom, burn everything onto CDROM, boot cdrom, and not touch the harddrives.

You could, but you'd have to have a CDROM drive in the thing, which takes up valuable space in a 1U or even 3U rackmount server. Also, flash roms have no moving parts, which means one less thing to fail on a machine that needs to run 24/7/365. Also, the flash image can be updated automatically, without opening the box, via FTP. And of course, if you made it yourself, you'd be missing all of the custom hardware in there that does health/disk monitoring/alerting, etc, etc.

Short version: This is a lot more than justFreeBSD on a flashrom.

Re:Nice to see

[benedict]

I think maybe 5.2 will be a milestone. 5.0 is likely to be a beta in all but name. This is not intended as a put-down of the FreeBSD Project, btw.

Re:Why FreeBSD?

[spudnic]

I have actually had a (semi-tech) client refuse to use FreeBSD based on the devil mascot. I think it's rather foolish, but they said that they didn't want their company to be associated with satanic symbols. Apparently after pitching the idea to use FreeBSD, he went on the 'net and saw the logo.

We used Linux for their application instead and everything is working well. I wonder if he would have been offended by a fish?

Has anyone else run across anything like this?

Re:NAS? TLA overload!

[irix]

And in my business NAS means network access server (e.g. Cisco).

Is NetBSD's kernel/NFS performance mature enough?

[albert_tam]

I haven't paid much attention to the NetBSD kernel development (especially the NFS part) recently. As far as I know, quite a lot of efforts on "zero copy" were made to the NetBSD kernel in order to beef up the NFS send/receive performance with NICs.

If I understand correctly, a main bottleneck in the NetBSD kernel is memory copying from the user space to the kernel space.

Under regular circumstance, network i/o buffers are copied from user processes to kernel on the send side, and from kernel to user processes on the receiving side.

By implementing this "zero copy" method, the above copying process is eliminated and a gain in the system performance as well as network performance should be seen.

What I am interested to know is that, how mature is this "zero copy" and the overall NetBSD kernel (particularly NFS and the NIC component) to handle great amount of TCP network i/o.

Anyone cares to enlighten?

Re:Nice to see

[benedict]

Indeed; I'm particularly excited by the SMP and threading stuff. If the mandatory access control stuff makes it in (and Robert Watson says he thinks it will), it will be interesting to see what people do with it. That technology could allow FreeBSD to be used in places where freeware has never been used before.

oops, another bit . . .

[hawk]

>On a larger scale, we've got IBM, SGI, and Compaq (all competitors)
>contributing to the Linux kernel. I can't imagine that IBM, for
>example, would port their JFS to Linux if they thought Compaq could
>integrate it into Tru64 and use it to poach IBM's customers. The GPL
>ensures that everybody has to play by the same rules, so there is less
>risk.

They're in the same situation, with linux being a commodity part. None of these firms have a real interest in having their own flavor of unix; it's not practical to distinguish a unix enough to be a competitive advantage in a small system markets. These firms sell hardware and consulting; having a reliable unix to slap on the machines is necessary. [as a side note, this is Linux' biggest contribution to *nix: it provides a common reference point without anyone having to accept his competitor's version.]

Note that IBM pays a price if the JFS stuff is GPL'd: They can't use changes to it in their other systems (AIX), either. I suspect that they'd be better off in that regard with a public license . . .

hawk