For what it's worth, I've done this sort of thing a few times, and I currently have two sort of cookie-cutter solutions in mind:
1. A good quality server-class PC with some hardware RAID storage running FreeBSD and PostgreSQL, usually along with Apache, mod_ssl and mod_php4 to build web-based applications. Often this will go along with a copy of Cyrus IMAPd and SquirrelMail for handling e-mail (one of these days I am going to write an IMAP<->SQL bridge in Perl as a replacement for Cyrus).
2. I have yet to personally work on something that exceeds the capabilities of this configuration, but if it happens, I would probably switch to using Sun server class machines running Oracle. Presumably at that time the application would have a big enough budget to spend that sort of money.
MySQL does not pass the ACID test. Lots of people don't think that's important, but if you have a 10 step transaction and step 9 fails, it's a lot easier to simply say "ROLLBACK WORK;" than it is to undo steps 1 through 8. Never mind the fact that without transactional atomicity you have a potential race condition.
For what it's worth, my page at FreeBSD has some instructions on how to set up PPPoE and/or PPTP on a FreeBSD server to use as a way to secure a wireless LAN.
People may find my wireless LAN -- they may even DHCP an IP address from it, but they won't be able to actually do anything once they do.:-)
I am sure I'm not the only one, but I must say that am pleased with the progress Mozilla makes from one release to the next. I quickly hacked the FreeBSD mozilla port to build 0.9.2 and the difference is quite palpable. The biggest surprise is that the memory footprint of mozilla is now *only* double that of Netscape 4.x. Every day and in every way it gets better and better.
I could go out today and write a book (or produce a movie, or paint a picture) called _Gone With the Wind_ and Margaret Mitchell's estate has no control over it.
Except that, as you point out, such an act would be governed under trademark law. I suspect that "Gone With The Wind" is, in fact, a trademark, as (probably) are most movie titles.
To bring this back on-topic, it is doubtful that anyone could claim trademark status on every track title they put out on a CD, and in any case, Gracenote is not in a position to defend third party trademarks (which given that legal theory they would be infringing in any case).
In a hallway at the Cal-West school of law in San Diego, there is a drawing (woodcut?) entitled The Lawsuit.
In it, there is a cow, with the plaintif pulling on the head, the defendant pulling on the tail, and a lawyer seated appropriately milking it.
'nuff said.
Re:Sorry kids, but this ain't news:
on
FreeBSD on DVD
·
· Score: 2
I don't believe that's entirely accurate.
Preorders for a FreeBSD distro on DVD were solicited at one point, but according to the FreeBSD mailing lists I have seen, no one actually took them up on it, so it was not done.
The problem was that they were charging 3 times the going rate without any particular proposed added value (the fact that you didn't have to swap the CDs wasn't worth triple the money).
I believe, now, that this is being addressed either by reducing the price or adding value. I am not exactly sure which. But if they're not doing either of these, then they're not any more likely to succeed as the last time it was tried, IMHO.
That is certainly true of FreeBSD 4.x and previous. The FreeBSD kernel at the moment has a single giant lock (think: n kids and 1 bathroom). But I do feel compelled to point out that FreeBSD 5.x is slated to have the locks pushed down with an eye towards making the kernel highly scalable across multiple CPUs. Will 5.0-RELEASE be as good as Solaris in this regard? Probably not. It took Sun a long time to get it right. FreeBSD hopefully will be able to get it right quickly.
It's clear from their comments that they did not turn on Softupdates on the filesystems when they set up their FreeBSD machine for the testing. It's no wonder that they found disk I/O to be slower on FreeBSD, therefore.
Traditionally, Linux has traded speed for safety in filesystem meta data handling. FreeBSD has always refused to do so, insisting that metadata be updated synchronously. With softupdates, the metadata is cached, but the cache is flushed in the right order. The upshot is that you get the speed and the safety.
In short (too late), I am sure that their opinion of FreeBSD would improve markedly if they would set it up properly.
From what I see, just about every other OS represented has a defender saying exactly the same thing. That doesn't speak well for the thoroughness of the testing. I'll leave it at that.
That doesn't make the encryption end-to-end. It is still cleartext when it's in the various spools along the way. I submit that it is just as easy to snoop on it there than when it's on the wire.
I'm sure I won't be the only one to say it. I think S/MIME is the way to go. PGP has too many variations that don't conveniently interoperate. S/MIME basically has one. You can even generate S/MIME messages with shell scripts and openssl's smime commands. Find out how here.
Think about this: The whole purpose beind certification (and PGP's key signing is just another kind of certification, make no mistake) is to be able to have some assurance that the public key you're encrypting or validating signatures with belongs to whom you think it does. With PGP there is no certifying authority. I know there was supposed to be a distributed trust model with PGP, but in actual practice it hasn't worked out that way. I don't trust keys unless I have signed them, and I only sign them when I have verified them. Why? Because to do otherwise I would have to manage a list of trusted signers, which is no different than S/MIME, but the number of signatures that those trusted signers would be giving out would be relatively low. My trust would not reap much benefit.
By contrast, those issuing S/MIME certificates by and large are in the business of doing so. They generally have posted policies that allow me to determine whether I trust them or not. So far, that's no different than PGP. But the difference is that there are relatively few organizations that have gone to the trouble of becoming S/MIME CAs, which means that trusting one of them nets me a large number of other users with whom I can interoperate without any prior introduction. I dare say that with a single root CA cert (the thawte freemail one), I can probably get over 90% of S/MIME users all at once, and I have some assurance given the rules for their so-caled Web of Trust system that the identities being offered were properly screened.
Moreover, S/MIME has key expiration mechanisms built into it, which PGP lacks. Turning your key over frequently helps make sure brute force attacks don't result in an attacker being able to forge signatures (by the time they brute-force the keypair, it's expired).
And if Thawte ever decided to either charge for their services or pull the plug, it would be simple to 'fork' to a new free system -- If Thawte certificates are trusted, then simply demanding a prospective user of the free system that they sign a random plaintext and send it back would be sufficient to get proof of their name and e-mail address (which is the only thing Thawte certifies in any event).
Oh, by the way, yes, Microsoft uses it. That doesn't make it evil on its face.
As long as they make it possible to run a decoder under Windows, it will be possible to do something like VMware or other hardware simulators and single-step it and rip the secrets out.
It would require a platform that is impossible to simulate in order to secure the bits. The closest thing we have to that is the sort of smart card technology employed by DirecTV. They stay up late devising new ways to make sure that the code in the smart card isn't running in a simulator or in a trojaned card or what not. Just surf the net looking for "3 muskateer" cards (for sale in Canada, of course, where I hear it's not really a crime to decrypt US satellite TV. IANABarrister, of course) to get an idea how successful they are.
v.90 is lousy. It has very low bandwidth and an incredibly high bandwidth:latency ratio.
ISDN is the solution. I daresay that most home users would be perfectly happy for the most part with 128kbps links of relatively low latency. Keep in mind, also, that ISDN has an incredibly low first-packet latency as well. If you have automatically dialed on-demand ISDN connection, I put it to you that you'd be hard pressed to tell the difference between that and DSL unless you tried downloading ISO images or movies or the like.
What killed ISDN was Pac$Bell's greed. I was perfectly happy with ISDN until they made it metered. If Pac$Bell would simply once again offer unmeasured residential ISDN I am sure it would supplant DSL very quickly indeed.
I have a Passat TDI and I love it. It is a stick shift, but if you have to learn how to drive a stick, the easiest car to do it with is a diesel because of the phenominal amount of low-end torque. You also get a lot of practice shifting, because you have to upshift at about 15 mph (~23 km/h). Peak torque is at about 2k rpm, peak HP is at about 3k, red line is at about 5k rpm.
0-60 is not bad in this car, but 60-90 takes a very long time.:-)
Anyway, more to the point of what I titled this reply about...
Just about all of the locomotives in the US are diesel-electric. That is, a diesel engine turns an electric generator and the electricity runs electric motors. This works well because (as I understand it) electric motors have the great advantages of having wide enough torque curves to not require transmissions and they can start from a dead stop and they can run equally well in both directions. They also optimize the diesel engine's performance because they can run it at a more-or-less fixed RPM.
What I don't get is why they haven't done this for cars yet. The only things that suck about electric cars, really, are the batteries. A diesel-electric car fixes all that.
Some people suggest that such a car should also have a battery and use the engine only when necessary. IMHO this just adds weight and expense. We've had more than 50 years of experience making diesel-electric locomotives. Why can't we do the same with cars right now?
What most people mean by this is the non-postscript printers -- the inexpensive inkjet models which for the most part lately have turned out to be WinPrinters.
Hey HP: If you really want us to believe you when you say you are jumping into the whole open source thing, how about contributing (GPLed if you like) ghostscript drivers for your deskjets? A lot of us would sit up and take notice if you did, and it really can't be that hard to do (given that you guys have all of the documentation we don't).
I prefer HP's inkjet technology, but support for Epsons in ghostscript is far better.
Back in the 1984-1986 timeframe I wrote a BBS for Apple ][s called CMS. There were a bunch of them running in San Diego trading mail back and forth. It used adresses of the form user@sytem%area. Every once in a while the system would call out to its neighbor to pass the traffic along. Each system had a route table for the next hop to a particular destination. If I remember properly, there was even support for file attachments. The mail moved around via xmodem, which I had added for file transfer areas and seemed the easiest thing to do.
In 1986 I shut down CMS-Point Loma, which was the node I ran, and left for college. There I got introduced to Suns and from then on my//gs served only as a terminal to dial into the Unix lab.:-)
I still tend to buy only SCSI disks. They cost more, but tend to have better specifications, in general.
The manufacturers figure that people buying SCSI disks are probably building RAID arrays. There the high bus bandwidths actually help, unlike a typical desktop installation.
My desktop machine is fully U160, meaning a potential buss throughput of 160 MB/s. dd if=/dev/da0s1 bs=10m of=/dev/null count=64 shows a throughput of about 35 MB/s. So I could have 4 disks running flat out and the disks would still be the bottleneck. Never mind that we're not doing any seeking with that command. It's more likely that you would expect to see upwards of 8 drives or so before buss bandwidth starts to be an issue.
Oh, remember that typical motherboard memory bandwidth tops out below 160 MB/s too, so those transfer rates really only count when you're using a RAID controller (as opposed to software RAID).
Kirk McKusick spoke briefly at FreeBSDCon '99 about his experiments with IDE/ATA and SCSI. His results (as expressed on the videotape) may not be fully up-to-date (I don't think he used UDMA66). But he was able to demonstrate that more than one target per bus on ATA did particularly poorly compared to SCSI.
Oh, also... Make sure you turn write caching OFF if you expect your data to survive a power failure. FreeBSD 4.mumble turns it off by default and 4.3 now makes it configurable. Kirk also mentioned that people were telling him that "small file tests" showed that ATA was on a par with SCSI. He found that this was due to write caching (that is, the drive lies about when the data has been written). To use his words, "wrong answers can be delivered quickly."
Slashdot Mirror
That's as may be (and I don't know what Yahoo runs), but you can indeed run Oracle on FreeBSD using the Linuxulator.
For what it's worth, I've done this sort of thing a few times, and I currently have two sort of cookie-cutter solutions in mind:
1. A good quality server-class PC with some hardware RAID storage running FreeBSD and PostgreSQL, usually along with Apache, mod_ssl and mod_php4 to build web-based applications. Often this will go along with a copy of Cyrus IMAPd and SquirrelMail for handling e-mail (one of these days I am going to write an IMAP<->SQL bridge in Perl as a replacement for Cyrus).
2. I have yet to personally work on something that exceeds the capabilities of this configuration, but if it happens, I would probably switch to using Sun server class machines running Oracle. Presumably at that time the application would have a big enough budget to spend that sort of money.
MySQL does not pass the ACID test. Lots of people don't think that's important, but if you have a 10 step transaction and step 9 fails, it's a lot easier to simply say "ROLLBACK WORK;" than it is to undo steps 1 through 8. Never mind the fact that without transactional atomicity you have a potential race condition.
People may find my wireless LAN -- they may even DHCP an IP address from it, but they won't be able to actually do anything once they do. :-)
I am sure I'm not the only one, but I must say that am pleased with the progress Mozilla makes from one release to the next. I quickly hacked the FreeBSD mozilla port to build 0.9.2 and the difference is quite palpable. The biggest surprise is that the memory footprint of mozilla is now *only* double that of Netscape 4.x. Every day and in every way it gets better and better.
Keep up the good work, guys!
To bring this back on-topic, it is doubtful that anyone could claim trademark status on every track title they put out on a CD, and in any case, Gracenote is not in a position to defend third party trademarks (which given that legal theory they would be infringing in any case).
In a hallway at the Cal-West school of law in San Diego, there is a drawing (woodcut?) entitled The Lawsuit.
In it, there is a cow, with the plaintif pulling on the head, the defendant pulling on the tail, and a lawyer seated appropriately milking it.
'nuff said.
I don't believe that's entirely accurate.
Preorders for a FreeBSD distro on DVD were solicited at one point, but according to the FreeBSD mailing lists I have seen, no one actually took them up on it, so it was not done.
The problem was that they were charging 3 times the going rate without any particular proposed added value (the fact that you didn't have to swap the CDs wasn't worth triple the money).
I believe, now, that this is being addressed either by reducing the price or adding value. I am not exactly sure which. But if they're not doing either of these, then they're not any more likely to succeed as the last time it was tried, IMHO.
paraphrase> "FreeBSD is not CPU scalable"
That is certainly true of FreeBSD 4.x and previous. The FreeBSD kernel at the moment has a single giant lock (think: n kids and 1 bathroom). But I do feel compelled to point out that FreeBSD 5.x is slated to have the locks pushed down with an eye towards making the kernel highly scalable across multiple CPUs. Will 5.0-RELEASE be as good as Solaris in this regard? Probably not. It took Sun a long time to get it right. FreeBSD hopefully will be able to get it right quickly.
It's clear from their comments that they did not turn on Softupdates on the filesystems when they set up their FreeBSD machine for the testing. It's no wonder that they found disk I/O to be slower on FreeBSD, therefore.
Traditionally, Linux has traded speed for safety in filesystem meta data handling. FreeBSD has always refused to do so, insisting that metadata be updated synchronously. With softupdates, the metadata is cached, but the cache is flushed in the right order. The upshot is that you get the speed and the safety.
In short (too late), I am sure that their opinion of FreeBSD would improve markedly if they would set it up properly.
From what I see, just about every other OS represented has a defender saying exactly the same thing. That doesn't speak well for the thoroughness of the testing. I'll leave it at that.
That doesn't make the encryption end-to-end. It is still cleartext when it's in the various spools along the way. I submit that it is just as easy to snoop on it there than when it's on the wire.
Think about this: The whole purpose beind certification (and PGP's key signing is just another kind of certification, make no mistake) is to be able to have some assurance that the public key you're encrypting or validating signatures with belongs to whom you think it does. With PGP there is no certifying authority. I know there was supposed to be a distributed trust model with PGP, but in actual practice it hasn't worked out that way. I don't trust keys unless I have signed them, and I only sign them when I have verified them. Why? Because to do otherwise I would have to manage a list of trusted signers, which is no different than S/MIME, but the number of signatures that those trusted signers would be giving out would be relatively low. My trust would not reap much benefit.
By contrast, those issuing S/MIME certificates by and large are in the business of doing so. They generally have posted policies that allow me to determine whether I trust them or not. So far, that's no different than PGP. But the difference is that there are relatively few organizations that have gone to the trouble of becoming S/MIME CAs, which means that trusting one of them nets me a large number of other users with whom I can interoperate without any prior introduction. I dare say that with a single root CA cert (the thawte freemail one), I can probably get over 90% of S/MIME users all at once, and I have some assurance given the rules for their so-caled Web of Trust system that the identities being offered were properly screened.
Moreover, S/MIME has key expiration mechanisms built into it, which PGP lacks. Turning your key over frequently helps make sure brute force attacks don't result in an attacker being able to forge signatures (by the time they brute-force the keypair, it's expired).
And if Thawte ever decided to either charge for their services or pull the plug, it would be simple to 'fork' to a new free system -- If Thawte certificates are trusted, then simply demanding a prospective user of the free system that they sign a random plaintext and send it back would be sufficient to get proof of their name and e-mail address (which is the only thing Thawte certifies in any event).
Oh, by the way, yes, Microsoft uses it. That doesn't make it evil on its face.
As long as they make it possible to run a decoder under Windows, it will be possible to do something like VMware or other hardware simulators and single-step it and rip the secrets out.
It would require a platform that is impossible to simulate in order to secure the bits. The closest thing we have to that is the sort of smart card technology employed by DirecTV. They stay up late devising new ways to make sure that the code in the smart card isn't running in a simulator or in a trojaned card or what not. Just surf the net looking for "3 muskateer" cards (for sale in Canada, of course, where I hear it's not really a crime to decrypt US satellite TV. IANABarrister, of course) to get an idea how successful they are.
v.90 is lousy. It has very low bandwidth and an incredibly high bandwidth:latency ratio.
ISDN is the solution. I daresay that most home users would be perfectly happy for the most part with 128kbps links of relatively low latency. Keep in mind, also, that ISDN has an incredibly low first-packet latency as well. If you have automatically dialed on-demand ISDN connection, I put it to you that you'd be hard pressed to tell the difference between that and DSL unless you tried downloading ISO images or movies or the like.
What killed ISDN was Pac$Bell's greed. I was perfectly happy with ISDN until they made it metered. If Pac$Bell would simply once again offer unmeasured residential ISDN I am sure it would supplant DSL very quickly indeed.
I have a Passat TDI and I love it. It is a stick shift, but if you have to learn how to drive a stick, the easiest car to do it with is a diesel because of the phenominal amount of low-end torque. You also get a lot of practice shifting, because you have to upshift at about 15 mph (~23 km/h). Peak torque is at about 2k rpm, peak HP is at about 3k, red line is at about 5k rpm.
:-)
0-60 is not bad in this car, but 60-90 takes a very long time.
Anyway, more to the point of what I titled this reply about...
Just about all of the locomotives in the US are diesel-electric. That is, a diesel engine turns an electric generator and the electricity runs electric motors. This works well because (as I understand it) electric motors have the great advantages of having wide enough torque curves to not require transmissions and they can start from a dead stop and they can run equally well in both directions. They also optimize the diesel engine's performance because they can run it at a more-or-less fixed RPM.
What I don't get is why they haven't done this for cars yet. The only things that suck about electric cars, really, are the batteries. A diesel-electric car fixes all that.
Some people suggest that such a car should also have a battery and use the engine only when necessary. IMHO this just adds weight and expense. We've had more than 50 years of experience making diesel-electric locomotives. Why can't we do the same with cars right now?
What most people mean by this is the non-postscript printers -- the inexpensive inkjet models which for the most part lately have turned out to be WinPrinters.
Hey HP: If you really want us to believe you when you say you are jumping into the whole open source thing, how about contributing (GPLed if you like) ghostscript drivers for your deskjets? A lot of us would sit up and take notice if you did, and it really can't be that hard to do (given that you guys have all of the documentation we don't).
I prefer HP's inkjet technology, but support for Epsons in ghostscript is far better.
The list doesn't go back very far, unfortunately.
//gs served only as a terminal to dial into the Unix lab. :-)
Back in the 1984-1986 timeframe I wrote a BBS for Apple ][s called CMS. There were a bunch of them running in San Diego trading mail back and forth. It used adresses of the form user@sytem%area. Every once in a while the system would call out to its neighbor to pass the traffic along. Each system had a route table for the next hop to a particular destination. If I remember properly, there was even support for file attachments. The mail moved around via xmodem, which I had added for file transfer areas and seemed the easiest thing to do.
In 1986 I shut down CMS-Point Loma, which was the node I ran, and left for college. There I got introduced to Suns and from then on my
I still tend to buy only SCSI disks. They cost more, but tend to have better specifications, in general.
The manufacturers figure that people buying SCSI disks are probably building RAID arrays. There the high bus bandwidths actually help, unlike a typical desktop installation.
My desktop machine is fully U160, meaning a potential buss throughput of 160 MB/s. dd if=/dev/da0s1 bs=10m of=/dev/null count=64 shows a throughput of about 35 MB/s. So I could have 4 disks running flat out and the disks would still be the bottleneck. Never mind that we're not doing any seeking with that command. It's more likely that you would expect to see upwards of 8 drives or so before buss bandwidth starts to be an issue.
Oh, remember that typical motherboard memory bandwidth tops out below 160 MB/s too, so those transfer rates really only count when you're using a RAID controller (as opposed to software RAID).
Kirk McKusick spoke briefly at FreeBSDCon '99 about his experiments with IDE/ATA and SCSI. His results (as expressed on the videotape) may not be fully up-to-date (I don't think he used UDMA66). But he was able to demonstrate that more than one target per bus on ATA did particularly poorly compared to SCSI.
Oh, also... Make sure you turn write caching OFF if you expect your data to survive a power failure. FreeBSD 4.mumble turns it off by default and 4.3 now makes it configurable. Kirk also mentioned that people were telling him that "small file tests" showed that ATA was on a par with SCSI. He found that this was due to write caching (that is, the drive lies about when the data has been written). To use his words, "wrong answers can be delivered quickly."