we would gladly accept a contribution of a debian package, or better yet, infrastructure to let us build a debian package on redhat.
Unfortunately, we can only build in house what's convenient, and to be frank, a FreeBSD package would be easier for us to build than a debian package, because at least I already know how to build one and we have an in-house FreeBSD box.
because we didn't have time to get it working elsewhere.
1.4.0 seems to work on a bunch of other Linuxen: TurboLinux, Mandrake, SUSE. And it compiles on FreeBSD.
If you are a reasonable C++ programmer you can probably get it working on a good POSIX system. Mac OS X is much more painful due to lack of poll() and other really common system calls -- there's someone working on it, though.
what he was saying was to use an n-byte (in this case, 4-byte) value, and then sign it with a public key system. A larger value might be better.
You do NOT give the private key to the end-user -- this is done at the FACTORY, not at the client. The result of this operation is the license key.
Public key signatures are considered "secure" in that there are no major known attacks that can be made against them without the private key, but they can be verified by the public key only. Anyone with the public key can verify that the value in question was signed by the private key, but cannot sign a different value. Since the signatures are generally dozens or hundreds of bytes, this isn't too fun to brute force.
So, a server can verify that the key is legitimate, and it would be a publishable result if you could reliably produce license keys without the private key (which would never be anywhere on the client side).
Of course, you would have to type one of those 256-character pgp public key blocks as your license key...
Re:I doubt this is windows in disguise
on
LindowsOS Marches On
·
· Score: 2, Insightful
Err... don't forget Case 4a:
Case 4a) Lindows is Linux running Wine (which doesn't belong to CodeWeaver!) with additional patches and fixes to improve its compatibility.
As Wine is open source, and, as you say, took several years to get there, why not just fix it up some more? Wine is open source under a BSD-style license, so there's no reason for them not to adapt it (as it's perfectly legal and ethical to use it in a closed-source product)?
Whatever you think of mp3.com, the person who created it certainly has a reasonable bit of money to throw at something, and it seems to me that this kind of rolls up into the anti-authoritarianness of the mp3.com idea.
Even if you consider mp3.com lame, they did produ ce something real.
Getting sued by Microsoft (particularly over something as easily fixable as a trademark violation) is good for them. They get free publicity by being sued, let Microsoft threaten them for a few months, and then settle, getting free publicity again (and perhaps a few reporters who will give them a review when they release a 1.0 version).
I'm curious as to your sources for this information. Searching on google was generally unhelpful, so any references you have would be great. there seemed to be a fair bit of "will my film be damaged" questions, and a fair number of "x-rays damage ccds" articles, but i didn't see any on eeproms (flash was unhelpful as a keyword because it associated w/ camera flashes, as was cmos, which pulled up no results).
i agree. If you like the eclectic nature of Kanno's music, and not just the jazzy part, you might want to try some of her other stuff. I like the Macross Plus music, personally, although Turn A Gundam is very Copeland-esque...
One of theys days, i'm hoping all of the mixing fuses into a single sound...
FreeBSD / NetBSD have both allowed non-BSD licensed software to be included in their kernels, WITH a few understandings. Note that these are my interpretations of what those understandings are.
Examples of (historically) non-BSD licensed software in FreeBSD include softupdates, vinum, and the FPU emulator for non-FPU 386/486s.
General principles have included
1. the piece is optional and the kernel works fine without it. (true of all of them)
2. the piece offers functionality that is otherwise unavailable. (true of all of them)
3. if the piece is "major functionality", it will become BSD-licensed at some future time. (true of vinum and softupdates)
I don't know what the core teams will say, but I'm speculating (purely speculating) that IPFilter will probably fall into the "major functionality" segment, so it will probably need to eventually become BSD-licensed to survive.
But, I'm not sure. Generally, I respect FreeBSD-core to do the right thing.
As far as I have read about copyright law (note that i am not a lawyer), the ability to distribute derivative works (e.g. modified ones) is a right granted exclusively to the copyright holder, which he must EXPLICITLY (e.g. by putting it in the license) permit others to do.
If he doesn't, then you probably can't distribute source patches which are clearly derivative works, and probably can't distribute modified binaries, whatever their origins.
Here are a few tips that help. They are not exhaustive, nor necessarily the best way.
Debugging tips
0. If you are running linux: apply the patch that causes the thread that had the segfault to dump core. The default Linux semantics (under 2.2.x at least) are for the threads to exit STARTING with the one that had the problem. Then, the LAST thread dumps its program counter / stack info into your core file. The result: you get what look like "random" crashes when really they aren't very random.
There is a patch which fixes this behavior. try
this patch .
1. See if you can get your program to crash in a debugger or dump core. I presume that you are getting this by your comments.
Record the places that you get crashes. Each time anyone gets a crash, have them record where, as best as they can.
Try to figure out what's getting overwritten, even if it's not clear when or how.
3. Try to increase the frequency of the crash (e.g. by running on an SMP machine). this usually provides people with more incentive and a better chance to test if any given change really fixed things.
4. The next few hints fall into the category of "reduce the problem code". It sounds to me like you don't have a good feeling as to where the problem is happening. Try to eliminate sections of the code, by any means necessary. examples include one big lock to force serialization, test programs that only excercise certain modules of your code, etc. I know there is often a temptation to just jump in, but some extra scaffolding to reduce the possible problems is almost always valuable on hard debugging problems.
Reduce the amount of data shared between threads. We are using a message passing interface, where each thread more or less has its own data. This has been a big win. We often copy data before passing on to the next thread, just to make sure.
5. Understand what is and isn't thread safe in your libs. For example, did you know that it is almost impossible to make the C++ std string thread safe, without changing the implementation? that's because the implementation is copy on write. So, even when you're not sharing any data between threads, you are....
I hope some of these help. threading problems aren't easy, particularly in c++...
There are a number of them, but I'm not sure which ones are most appropriate.
First, some of the Quicknet cards have a "line" interface (the Linejacks). These don't work with VOCAL directly, so you may want to use OpenH323 instead (OpenH323 appears to have an H323 PSTN gateway that uses these cards). If you'd like, you can try to use the OpenH323 gateway with VOCAL (apparently someone has gotten this to work), but it's hackish.
I think some Komodo boxes are appropriate for a home or something.
I know that there are other high density solutions which are available, but they seem like overkill.
If you're interested in running VOCAL, I'd recommend a Linux box running the old egcs 1.1.2 compiler. We use Redhat 6.2 internally for development. If you use Redhat 7 (or one of the newer 2.95 or 2.96 compilers), we have patches that help.
Yes, I know this compiler isn't really as ISO C++ as it ought to. But we wrote all of our code to this compiler, so it's the best supported one.
BSD would require porting (which I will be working on when I have a chance). The big issues are threads -- the code requires reasonable thread support, and can occasionally require preemption between threads, so some thread libraries (e.g. pth) may not be enough.
Solaris works, but you'll need the Forte Compiler (SunPro) to make it work easily.
Ethernet Phones
Then, you'll need some phones. I think the Cisco 7960 phones are nice, and you can get SIP for them (but they are expensive). Other manufacturers can be gotten from SipCenter's web site, as well as this German site. We are one floor above the Komodo guys, and their boxes are quite reasonably priced (although I'm not sure how to get a SIP version).
Another alternative would be to use a Linux box as a phone.
More expensive would be a quicknet card or two. They're $100-$200 dollars, and sound better then sound cards.
Cheapest is a sound card. We have soundcard support in vocal, but it's not great (although some of that is our fault).
Gateways
You don't strictly need one of these if you're just interested in trying out VoIP, want to do an intercom-type system, or are trying to make calls over the Internet, but if you want to be able to receive calls from or place calls to the PSTN (the "real" telephone network), you'll need to get a gateway or two. Here, I know that Cisco makes them, as well as some other guys (Sonus? Nuera? Look at Henning's page and SipCenter for more gateway manufacturers).
My experience is that sound cards don't get the level of latency you need to be happy w/ VoIP. Quicknet cards are better, and hardware that can go straight to the ethernet are also better (e.g. ethernet phones).
High latency is usually the cause of echo. Note that there is also echo cancellation, but again, you'll probably need specific hardware / software to get that (hardware echo cancellation is clearly better, but software ec is probably better than none at all if you hear a lot of echo).
If we do allow "community" ads based on ad karma, an additional option would be "support this ad". If you see an ad (or a "art-ad") that you think is cool and is a "community" ad, being able to click on a link to say "spend some of my karma to keep running this ad" would be cool.
I also think that "save this ad for later" is valuable.
You should also be able to use these features without giving an email address -- the person using it shouldn't need to provide anything except click on a "i will accept an ad login cookie" and then they can get features.
Another related useful idea would be "see ad history", for whenever you saw an ad, and then later want to go back and look.
Finally, if you do click through, you should be able to rate whatever you clicked through via the ad system:
1. see an ad
2. click on it
3. it turns out the site is an "only works with ie5 on windows2000 with the latest shockwave and windows media player" one.
4. go back one page, click on "rate this ad", give them the -1, Proprietary Web Features .
Here are a few thoughts. Since I am not a lawyer, not only do i not know what a court would think, you shouldn't put too much stock in my opinion.
If you're more concerned with the notion of "how do i communicate to others what I would like to let you do with this source code I've written", then perhaps this will make some sense.
First, a program an a library are trivially convertible between each other, at least in C/C++.
Consider a program, which has a function main(). Perform the following steps:
1. rename the function main() to main2().
2. link all of the.o files in the program into a library.
3. create a function main(), which calls main2(), possibly passing argc/argv, and possibly returning the return value from main2() .
Practically, this is a very different beast than a real library, which implements a hopefully thoughtful API. However, there is no obvious technical difference between all the.os of a program in an AR archive and a library, so it's not clear to me what a court would think.
You could also try a dual license under GPL/MPL or LGPL/MPL. Both of these would allow users to do things like linking in non-GPL code, while allowing GPL code to be linked in, although this may still not be possible (since it is the third-party's GPL code that is causing the problem, code you have written).
You could license under a BSD license. Again, you would not be able to link w/ third parties' GPL code and proprietary code at the same time, since that would violate the third parties' GPL (unless they explicitly allowed this).
Finally, you could offer your code under a GPL w/ a "module exception". Linux is licesnsed this way (it explicitly indicates that it does not view third-party closed-source modules to be in violation of the GPL). Again, if someone didn't like this interpretation of the GPL, no one would be able to link in their GPL'ed code w/ a proprietary plugin or module.
Yes. The official title is (amusingly) "alien of extraordinary ability", and it qualifies Linus for expidited treatment. Here are a few articles about this:
It does not appear that FreeBSD will mount BSD/OS partitions correctly.
A simple way to work around this would be to boot the old BSD/OS machine, export all the filesystems via NFS, and then from your new Linux/BSD machine mount the affected filesystems via NFS and then use tar to copy over the files.
While not as nice nor as fast as other options, it is reasonably reliable and avoids bugs in potentially complex code.
Can you update a FreeBSD system without installing
on
FreeBSD 4.1 Released
·
· Score: 1
While the following is only incidental experience, I believe that you CAN upgrade FreeBSD w/out delete/reinstall. I know, because I have had a system for 4 years which I have updated w/out ever having to reformat the drive.
I started out in May 1996 w/ 2.1.0 on a P133 w/ SCSI drives. This machine is currently in use w/ a 3.x system on a K6-2/450. The only thing that hasn't been replaced is the HD subsystem (which has been upgraded, however). In that time, I've done the following:
- My original install was done on a FIPS'ed windows partion. - I Upgraded the OS to 2.1.5, 6, and 7, using a CD. - Realized that I wanted more disk space, so used FIPS to reduce the size of Windows. Each time, instead of reformatting my drive, I added another FreeBSD slice. - moved from Southern California to northern California. - Upgraded to 2.2BETA via a single floppy and 33.6k modem. - Bought several more SCSI hard drives. - Upgraded to 2.2.1 (or so) via CD, and messed up the/etc on my main drive. To repair, I installed on an empty partition and used that partition as a "fix-it" partition to fix my root/etc - Survived the FreeBSD SCSI driver renaming / replacement - Upgraded to later 2.2 stables by recompiling. I retrieved the source via CTM (in which you are emailed the patches) and FTP, but recompiled all of the userland. - Upgraded to 3.0 via CD upgrade (again). This also switched AOUT to ELF. - Upgraded several more times on 3.0, each via CD.
Now, I have not brought this machine up to 4.0 (since I have a 2nd machine now that I use for my "desktop" and the old box is my "server") but I have to say that FreeBSD has been savable at every point along the path.
However, I would never start an upgrade w/out backups sufficient to restore the data I care about onto a bare install -- anything else is asking for trouble.
First, realize that the machines they are talking about are Pentium (not PII/III) class machines. Thus, they require SIMMs, not DIMM memory. This is why they're using K6/2-500s and the like--they run in Socket 7 mainboards (albeit only at 66MHz memory bus). Memory like this is available quite cheaply.
Second, good quality motherboards are basically there for the salvage -- on the news page they mention a an ASUS P55T2P4, which is, I believe, a 430HX board. But there's a big integer compute difference when it's outfitted w/ a 500MHz K6/2 vs the (likely) P133 that used to be sitting there.
Thirdly, they mention that the machines are outfitted with at least 32MB of memory. This is not 128MB. You don't need 128MB to do a lot of tasks on either *BSD or Linux -- as long as you're doing things that have a <32MB resident set, you're going to be fine on either. FreeBSD is particularly good in low memory situations (its swap performance is better than Linux in my experience), but i'm pretty sure that this isn't important, because they are looking for big integer performance first and foremost. Otherwise, they're probably better served with fewer, faster nodes w/ K7s or PII/IIIs.
Note that the machines have local HDs, so they can do local swap -- they don't need to keep shells, etc. swapped in over a network drive, either.
So this sounds good, for the right task. there are obviously a bunch of tasks that would be better served by other styles of clusters, or other resource allocations, but for doing fast integer calculation on the super-cheap, this is a great way to go.
I have one of these since my cassette player is broken.
I got mine (not good quality, but audio wise my cds still sound better than fm radio) for about US$15 at Fry's (an electronics supermarket in California, mostly).
I've had a chance to use Zope recently, and it's a great piece of software. I expect that in a year or two everyone who's doing this stuff will be seriously interested in it -- it will let you do just about everything from the web, it should start getting tool support to make integration with tools more transparent, and it will be documented.
However, until that time, the documentation is a significant source of headaches.
As an example, in trying to write some DTML (Zope's dynamically generated HTML variant) to do some coding, I spent several hours trying to figure out what syntax was needed to reference a variable. This was WHILE reading the manuals, looking at every faq possible on the Zope site, etc.
I consider myself a good figure-outer of things that are poorly documented, as I'm willing to experiment mercilessly, but this was ridiculous.
That said, power isn't lacking in using Zope. The web front-end makes using it easy for non-full-time developers, the versioning makes it easier to recover from mistakes (it keeps a complete revision history for all of the files in Zope), the software is Open Source and Free Software (BSD-licensed), and you can extend it with a real language (Python).
But the documentation will be a killer until the first O'Reilly book comes out, I expect...:(
Slashdot Mirror
Favorite stat from 10 seconds of perusal:
Popularity of the name Trinity:
Year of birth Rank
2001 67
2000 74
1999 216
1998 555
1997 547
1996 687
1995 683
1994 821
1993 951
Curious, isn't it. Something seems to have caused a sudden jump in popularity in the middle of 1999!
While i really enjoyed the matrix, i can't say that it ever occured to me that it would cause a sudden spike in people naming their daughters trinity.
- Linphone (http://www.linphone.org/)
- SIPSet (http://www.vovida.org/)
Neither has g.729a support, though, so they're not going to work with net2phone, i don't think.Unfortunately, we can only build in house what's convenient, and to be frank, a FreeBSD package would be easier for us to build than a debian package, because at least I already know how to build one and we have an in-house FreeBSD box.
because we didn't have time to get it working elsewhere. 1.4.0 seems to work on a bunch of other Linuxen: TurboLinux, Mandrake, SUSE. And it compiles on FreeBSD. If you are a reasonable C++ programmer you can probably get it working on a good POSIX system. Mac OS X is much more painful due to lack of poll() and other really common system calls -- there's someone working on it, though.
err... no.
what he was saying was to use an n-byte (in this case, 4-byte) value, and then sign it with a public key system. A larger value might be better.
You do NOT give the private key to the end-user -- this is done at the FACTORY, not at the client. The result of this operation is the license key.
Public key signatures are considered "secure" in that there are no major known attacks that can be made against them without the private key, but they can be verified by the public key only. Anyone with the public key can verify that the value in question was signed by the private key, but cannot sign a different value. Since the signatures are generally dozens or hundreds of bytes, this isn't too fun to brute force.
So, a server can verify that the key is legitimate, and it would be a publishable result if you could reliably produce license keys without the private key (which would never be anywhere on the client side).
Of course, you would have to type one of those 256-character pgp public key blocks as your license key...
Case 4a) Lindows is Linux running Wine (which doesn't belong to CodeWeaver!) with additional patches and fixes to improve its compatibility.
As Wine is open source, and, as you say, took several years to get there, why not just fix it up some more? Wine is open source under a BSD-style license, so there's no reason for them not to adapt it (as it's perfectly legal and ethical to use it in a closed-source product)?
Whatever you think of mp3.com, the person who created it certainly has a reasonable bit of money to throw at something, and it seems to me that this kind of rolls up into the anti-authoritarianness of the mp3.com idea.
Even if you consider mp3.com lame, they did produ ce something real.
Getting sued by Microsoft (particularly over something as easily fixable as a trademark violation) is good for them. They get free publicity by being sued, let Microsoft threaten them for a few months, and then settle, getting free publicity again (and perhaps a few reporters who will give them a review when they release a 1.0 version).
http://www.halfbakery.com/
thanks for any information you can provide.
One of theys days, i'm hoping all of the mixing fuses into a single sound...
FreeBSD / NetBSD have both allowed non-BSD licensed software to be included in their kernels, WITH a few understandings. Note that these are my interpretations of what those understandings are.
Examples of (historically) non-BSD licensed software in FreeBSD include softupdates, vinum, and the FPU emulator for non-FPU 386/486s.
General principles have included
1. the piece is optional and the kernel works fine without it. (true of all of them)
2. the piece offers functionality that is otherwise unavailable. (true of all of them)
3. if the piece is "major functionality", it will become BSD-licensed at some future time. (true of vinum and softupdates)
I don't know what the core teams will say, but I'm speculating (purely speculating) that IPFilter will probably fall into the "major functionality" segment, so it will probably need to eventually become BSD-licensed to survive.
But, I'm not sure. Generally, I respect FreeBSD-core to do the right thing.
As far as I have read about copyright law (note that i am not a lawyer), the ability to distribute derivative works (e.g. modified ones) is a right granted exclusively to the copyright holder, which he must EXPLICITLY (e.g. by putting it in the license) permit others to do.
If he doesn't, then you probably can't distribute source patches which are clearly derivative works, and probably can't distribute modified binaries, whatever their origins.
the boxes offer a vga/tv switch. I think you can actually get a plain cable that you just swap in/out, too.
The hardware itself is all on your dreamcast.
Debugging tips
0. If you are running linux: apply the patch that causes the thread that had the segfault to dump core. The default Linux semantics (under 2.2.x at least) are for the threads to exit STARTING with the one that had the problem. Then, the LAST thread dumps its program counter / stack info into your core file. The result: you get what look like "random" crashes when really they aren't very random.
There is a patch which fixes this behavior. try this patch .
1. See if you can get your program to crash in a debugger or dump core. I presume that you are getting this by your comments.
Record the places that you get crashes. Each time anyone gets a crash, have them record where, as best as they can.
Try to figure out what's getting overwritten, even if it's not clear when or how.
3. Try to increase the frequency of the crash (e.g. by running on an SMP machine). this usually provides people with more incentive and a better chance to test if any given change really fixed things.
4. The next few hints fall into the category of "reduce the problem code". It sounds to me like you don't have a good feeling as to where the problem is happening. Try to eliminate sections of the code, by any means necessary. examples include one big lock to force serialization, test programs that only excercise certain modules of your code, etc. I know there is often a temptation to just jump in, but some extra scaffolding to reduce the possible problems is almost always valuable on hard debugging problems.
Reduce the amount of data shared between threads. We are using a message passing interface, where each thread more or less has its own data. This has been a big win. We often copy data before passing on to the next thread, just to make sure.
5. Understand what is and isn't thread safe in your libs. For example, did you know that it is almost impossible to make the C++ std string thread safe, without changing the implementation? that's because the implementation is copy on write. So, even when you're not sharing any data between threads, you are....
I hope some of these help. threading problems aren't easy, particularly in c++...
There are a number of them, but I'm not sure which ones are most appropriate.
First, some of the Quicknet cards have a "line" interface (the Linejacks). These don't work with VOCAL directly, so you may want to use OpenH323 instead (OpenH323 appears to have an H323 PSTN gateway that uses these cards). If you'd like, you can try to use the OpenH323 gateway with VOCAL (apparently someone has gotten this to work), but it's hackish.
I think some Komodo boxes are appropriate for a home or something.
I know that there are other high density solutions which are available, but they seem like overkill.
If you're interested in running VOCAL, I'd recommend a Linux box running the old egcs 1.1.2 compiler. We use Redhat 6.2 internally for development. If you use Redhat 7 (or one of the newer 2.95 or 2.96 compilers), we have patches that help.
Yes, I know this compiler isn't really as ISO C++ as it ought to. But we wrote all of our code to this compiler, so it's the best supported one.
BSD would require porting (which I will be working on when I have a chance). The big issues are threads -- the code requires reasonable thread support, and can occasionally require preemption between threads, so some thread libraries (e.g. pth) may not be enough.
Solaris works, but you'll need the Forte Compiler (SunPro) to make it work easily.
Ethernet Phones
Then, you'll need some phones. I think the Cisco 7960 phones are nice, and you can get SIP for them (but they are expensive). Other manufacturers can be gotten from SipCenter's web site, as well as this German site. We are one floor above the Komodo guys, and their boxes are quite reasonably priced (although I'm not sure how to get a SIP version).
Another alternative would be to use a Linux box as a phone.
More expensive would be a quicknet card or two. They're $100-$200 dollars, and sound better then sound cards.
Cheapest is a sound card. We have soundcard support in vocal, but it's not great (although some of that is our fault).
Gateways
You don't strictly need one of these if you're just interested in trying out VoIP, want to do an intercom-type system, or are trying to make calls over the Internet, but if you want to be able to receive calls from or place calls to the PSTN (the "real" telephone network), you'll need to get a gateway or two. Here, I know that Cisco makes them, as well as some other guys (Sonus? Nuera? Look at Henning's page and SipCenter for more gateway manufacturers).
I hope this helps.
My experience is that sound cards don't get the level of latency you need to be happy w/ VoIP. Quicknet cards are better, and hardware that can go straight to the ethernet are also better (e.g. ethernet phones).
High latency is usually the cause of echo. Note that there is also echo cancellation, but again, you'll probably need specific hardware / software to get that (hardware echo cancellation is clearly better, but software ec is probably better than none at all if you hear a lot of echo).
If we do allow "community" ads based on ad karma, an additional option would be "support this ad". If you see an ad (or a "art-ad") that you think is cool and is a "community" ad, being able to click on a link to say "spend some of my karma to keep running this ad" would be cool.
I also think that "save this ad for later" is valuable.
You should also be able to use these features without giving an email address -- the person using it shouldn't need to provide anything except click on a "i will accept an ad login cookie" and then they can get features.
Another related useful idea would be "see ad history", for whenever you saw an ad, and then later want to go back and look.
Finally, if you do click through, you should be able to rate whatever you clicked through via the ad system:
1. see an ad
2. click on it
3. it turns out the site is an "only works with ie5 on windows2000 with the latest shockwave and windows media player" one.
4. go back one page, click on "rate this ad", give them the -1, Proprietary Web Features .
Here are a few thoughts. Since I am not a lawyer, not only do i not know what a court would think, you shouldn't put too much stock in my opinion.
.o files in the program into a library.
.os of a program in an AR archive and a library, so it's not clear to me what a court would think.
If you're more concerned with the notion of "how do i communicate to others what I would like to let you do with this source code I've written", then perhaps this will make some sense.
First, a program an a library are trivially convertible between each other, at least in C/C++.
Consider a program, which has a function main(). Perform the following steps:
1. rename the function main() to main2().
2. link all of the
3. create a function main(), which calls main2(), possibly passing argc/argv, and possibly returning the return value from main2() .
Practically, this is a very different beast than a real library, which implements a hopefully thoughtful API. However, there is no obvious technical difference between all the
You could also try a dual license under GPL/MPL or LGPL/MPL. Both of these would allow users to do things like linking in non-GPL code, while allowing GPL code to be linked in, although this may still not be possible (since it is the third-party's GPL code that is causing the problem, code you have written).
You could license under a BSD license. Again, you would not be able to link w/ third parties' GPL code and proprietary code at the same time, since that would violate the third parties' GPL (unless they explicitly allowed this).
Finally, you could offer your code under a GPL w/ a "module exception". Linux is licesnsed this way (it explicitly indicates that it does not view third-party closed-source modules to be in violation of the GPL). Again, if someone didn't like this interpretation of the GPL, no one would be able to link in their GPL'ed code w/ a proprietary plugin or module.
I hope that that makes sense.
It does not appear that FreeBSD will mount BSD/OS partitions correctly.
A simple way to work around this would be to boot the old BSD/OS machine, export all the filesystems via NFS, and then from your new Linux/BSD machine mount the affected filesystems via NFS and then use tar to copy over the files.
While not as nice nor as fast as other options, it is reasonably reliable and avoids bugs in potentially complex code.
While the following is only incidental experience, I believe that you CAN upgrade FreeBSD w/out delete/reinstall. I know, because I have had a system for 4 years which I have updated w/out ever having to reformat the drive.
/etc on my main drive. To repair, I installed on an empty partition and used that partition as a "fix-it" partition to fix my root /etc
I started out in May 1996 w/ 2.1.0 on a P133 w/ SCSI drives. This machine is currently in use w/ a 3.x system on a K6-2/450. The only thing that hasn't been replaced is the HD subsystem (which has been upgraded, however). In that time, I've done the following:
- My original install was done on a FIPS'ed windows partion.
- I Upgraded the OS to 2.1.5, 6, and 7, using a CD.
- Realized that I wanted more disk space, so used FIPS to reduce the size of Windows. Each time, instead of reformatting my drive, I added another FreeBSD slice.
- moved from Southern California to northern California.
- Upgraded to 2.2BETA via a single floppy and 33.6k modem.
- Bought several more SCSI hard drives.
- Upgraded to 2.2.1 (or so) via CD, and messed up the
- Survived the FreeBSD SCSI driver renaming / replacement
- Upgraded to later 2.2 stables by recompiling. I retrieved the source via CTM (in which you are emailed the patches) and FTP, but recompiled all of the userland.
- Upgraded to 3.0 via CD upgrade (again). This also switched AOUT to ELF.
- Upgraded several more times on 3.0, each via CD.
Now, I have not brought this machine up to 4.0 (since I have a 2nd machine now that I use for my "desktop" and the old box is my "server") but I have to say that FreeBSD has been savable at every point along the path.
However, I would never start an upgrade w/out backups sufficient to restore the data I care about onto a bare install -- anything else is asking for trouble.
First, realize that the machines they are talking about are Pentium (not PII/III) class machines. Thus, they require SIMMs, not DIMM memory. This is why they're using K6/2-500s and the like--they run in Socket 7 mainboards (albeit only at 66MHz memory bus). Memory like this is available quite cheaply.
Second, good quality motherboards are basically there for the salvage -- on the news page they mention a an ASUS P55T2P4, which is, I believe, a 430HX board. But there's a big integer compute difference when it's outfitted w/ a 500MHz K6/2 vs the (likely) P133 that used to be sitting there.
Thirdly, they mention that the machines are outfitted with at least 32MB of memory. This is not 128MB. You don't need 128MB to do a lot of tasks on either *BSD or Linux -- as long as you're doing things that have a <32MB resident set, you're going to be fine on either. FreeBSD is particularly good in low memory situations (its swap performance is better than Linux in my experience), but i'm pretty sure that this isn't important, because they are looking for big integer performance first and foremost. Otherwise, they're probably better served with fewer, faster nodes w/ K7s or PII/IIIs.
Note that the machines have local HDs, so they can do local swap -- they don't need to keep shells, etc. swapped in over a network drive, either.
So this sounds good, for the right task. there are obviously a bunch of tasks that would be better served by other styles of clusters, or other resource allocations, but for doing fast integer calculation on the super-cheap, this is a great way to go.
I have one of these since my cassette player is broken.
I got mine (not good quality, but audio wise my cds still sound better than fm radio) for about US$15 at Fry's (an electronics supermarket in California, mostly).
Runs on 2 AA batteries.
I've had a chance to use Zope recently, and it's a great piece of software. I expect that in a year or two everyone who's doing this stuff will be seriously interested in it -- it will let you do just about everything from the web, it should start getting tool support to make integration with tools more transparent, and it will be documented.
:(
However, until that time, the documentation is a significant source of headaches.
As an example, in trying to write some DTML (Zope's dynamically generated HTML variant) to do some coding, I spent several hours trying to figure out what syntax was needed to reference a variable. This was WHILE reading the manuals, looking at every faq possible on the Zope site, etc.
I consider myself a good figure-outer of things that are poorly documented, as I'm willing to experiment mercilessly, but this was ridiculous.
That said, power isn't lacking in using Zope. The web front-end makes using it easy for non-full-time developers, the versioning makes it easier to recover from mistakes (it keeps a complete revision history for all of the files in Zope), the software is Open Source and Free Software (BSD-licensed), and you can extend it with a real language (Python).
But the documentation will be a killer until the first O'Reilly book comes out, I expect...