Nooooooo. This is for public access servers to download files. You can't just set up a tunnel for every Joe Downloader that comes along and wants the files. SSL/TLS will do the job just fine.
For rarely changing (relative to how many times downloaded) files on public rsync servers, a high blocksize would be more appropriate. I regularly use 8192 bytes. I'd use even larger, like 65536, if it weren't for the fact that something is broken at 32768 and larger. When the file being downloaded is compressed already, the rsync algorithm is not very effective for much more than resuming incomplete transfers, or transferring only the part of the file after a change is detected (on average, half the file).
In some cases other blocksizes are better. If the file is not compressed and is an ISO image, using a blocksize of 2048 allows re-building an ISO where a significant amount of file data has simply been moved around the image when it is reconstructed. Since the ISO format uses 2048 byte filesystem blocksize, those are the "snap-to" points for content data blocks. The rsync algorithm does quite well with uncompressed ISO images. It can also be used for uncompressed tar images when the blocksize is chosen to match the tar blocksize, which is often smaller like 512 bytes. Since PKZIP files are compressed with separate compression states per file, these may also be improved on by rsync, depending on the boundary for starting each file that PKZIP format uses (which at the moment I do not know).
Try running the FTP server behind one firewall with NAT while the client is behind its own firewall with NAT, and both machines have the same private address. Really confusing at best.
What rsync needs is a port assignment (in addition to its existing 873 for clear connections) for SSL/TLS. Alternatively a "STARTTLS" feature added to the rsync protocol could do the same job. What this gets us is the ability to create a secure SSL service where passwords and data are reasonably confidential, while not having to worry about adding users to the host system itself (which is required for either rsync over ssh, or for scp as an alternative) which exposes a risk of accidentally making them shell users (not everyone wants to do that).
The MD5 cache does not need to be stored in RAM. In fact that would be harder to do across different rsync sessions. The cache would be in the form of a configured alternative file path. The config might look like:
md5cachepath =/home/public-md5
That would be put into each context in the/etc/rsyncd.conf file. It would represent a parallel file tree to the one specified by "path =" with every name matching with an optional.md5 extension. If the md5cachepath is the same as path then the extension is required. When it processes a file it would check for the cache file and its date. If it does not exist or the date does not match, it just forces live checksumming. It would probably be best to have only a single process creating the checksum cache files.
Read the standards for judgement page. They require PowerPoint format presentations. OK, does this mean I finally have to install an office package on my Linux workstation, such as Star Office or Open Office?
Spam is not about content. Not everyone even agrees what constitutes spam when they are evaluating it based on content, so how can a program or a recipient community do this? What makes mail spam is stuff like sending it unsolicited and in bulk. It won't matter what the content is.
I have signed up with some companies for announcements about their products. While that company may not be spamming, their content could have a lot of the same wording as another company selling similar products, but is sending it to harvested addresses. The latter is spam, but the former is not. How do you tell based on the content?
Tools that evaluate a message based on content are probably going to classify both messages the same way. If they are both classified as spam, then one of them will be "collateral damage". If they are both not classified as spam, then the other will be "leaky pinky". So I still prefer to block spam on the basis of the behaviour of the sender.
One person's spam is another person's treasure. That, of course, relates to the content of the message, as opposed to the behaviour of the sender. You might get the same thing from the same sender as I do, and you might consider it spam (various reasons) while I might have actually signed up to get it. Many companies have been known to augment their mailing lists with extra addresses, so this can even happen even though I signed up and you never did. And so it goes that for you it would be spam, and for me it would not be (although if I found out the sender was doing that, I'd sure be quite a bit more than piss off at them).
I really don't like the idea of other people... or programmed logic for that matter... making the decision for me what is or is not spam based on its content. The real issue with spam is not what the content is (with a few exceptions for some recipients), but the behaviour of the sender. For example suppose you post a message on an online message board that you're looking around for a place to buy a new motherboard that was just announced by its manufacturer. Then shortly afterwards you get an email from The Motherboard Palace stating that they have just received a big shipment of that new motherboard you wanted, and are offering a 20% discount on orders placed within 24 hours of the mailing. Now is that spam? What if they mailed it also to 999,999 other people without you knowing that? Now is that spam?
You're just giving them a legal defense. While the court might not grant that to an obvious slimeball, in other cases involving borderline businesses (that you and I would still call a spammer, but the judge might not), the argument that it is not practical to use the list can be effective. If there is a single state mandated list, it would probably end up being a law suit against the state for not operating it properly. But if there are simply volunteer lists, such as ones to declare your residency, there could end up being many of them, and the argument would certainly say "we use the ones that are usable, so you should have registered with them".
This is not silencing the speakers. As long as people have the right to not filter out the messages, and thus read them, then those that care will, and those that don't, won't.
Compare this to how free speech was done in the days the Constitution was written. Most speech was in the form of coffee/tea house discussion, public speeches at the center of town, debates in Congress or the legislatures of the states, and printing up your comments in a newspaper. If someone who had an important message (their opinion) for you were to barge into your home to deliver it, and the constable came and dragged them back out and threw them into the middle of the street, would this be called silencing? No. They could speak their mind from the street. In fact there are laws limiting even when that could be done (e.g. disturbing the peace). Most towns did have a central podium just for things like people making their speeches.
The issue is not what is said (that is protected) but rather, how they impose on us to deliver it (that is not protected).
Comparing a snailmail box to an email box is a bit more complex. As long as I do not have to pay to receive the mail, that is, the sender pays all costs, then I can just as easily throw it away. Of course I do have a minor cost in doing that, but the major cost is on the sender, and that is a limiting factor. But email is quite different. This is not a case of a single entity handling all the delivery. Instead, email is a peering setup with a sender agent and a receiver agent (e.g. the ISPs). Email can be scaled up high on the sending end with extremely small cost, while the recipient has higher costs for each message received (even if it is refused). The issue is not about what is being sent, but rather, the costs that are imposed upon me (and in particular, that my costs are higher than the sender's costs).
Unless I say otherwise, this very Slashdot posting can be considered a solicitation to email me privately, but only for something related to it, basically a reply. So it would not be unsolicited for you to email me privately for that purpose. The implication is that it would not be for other purposes initially. Of course there is a content tie-in with that, but it's no longer public speech when addressed to a single person. It's certainly not bulk to reply to me privately once.
But I do agree that private filters are (still) the best way to go. Different people have different preferences on how agressive that can be. A business might not want to filter very much for fear of not receiving mail from a prospective customer. And if their mail volume is high, the spam might be a drop in the bucket in comparison. An individual, however, may find it best to be especially aggressive and filtering, including filtering whole ISPs that harbor spammers (and yes, that means "collateral damage"). It should be the choice of the recipient.
Do Not Mail versus Do Not Call (extensions)
on
Do-Not-Email Registries?
·
· Score: 3, Insightful
With a Do Not Call list, one single entry covers all my phone extensions. Since the teleslimers will be comparing only the basic phone number, and not the number with its extension, against the list, by simply having my number without any extension in the list, a proper lookup will match and they can skip that number. None of my extensions will be called.
The issue is how to do this for email addresses. Many mail servers allow for "extensions" by having a certain special character such as "-" or "+" or "." followed by an "extension". By simply having the email account of the part before the separator, you automatically have every possible extension. Some people call this tagged email. And example would be jsmith-foobar@example.net where only jsmith@example.net would be in the list.
Many people even have their own vanity domain names, and regardless of what username is used before the @-sign character, they get the mail like the whole username were the extension.
For a registry to work, for at least those who are required to use it, it must meet at least these two requirements:
Supports all user email addresses, including extensions
Easy for the bulk mailers to compare their lists against
The raw list itself must not be distributed
I looked at the registry run by the Washington Association of Internet Service Providers and found that the verification process only works one at a time. This makes their registry virtually useless. Of course, distributing the addresses in the raw will be worse, as it will get in the hands of spammers out of the country, and everyone will just get more spam because now spammers will have a list of address that are even more likely to have someone reading. And some will be mass mailing to such a list just to destroy the effectiveness of registering.
One option is to distribute an SHA1 checksum of each address. Then all that needs to be done on the mailer's end is to test each address by generating the checksum and looking that up in the database.
But even that has a risk, and I'm wondering if even that should be allowed. That risk is that spammers will run all their millions of email addresses through the process, and produce a subset of those who are registered, and then from out of the country... they will spam the hell out of just those.
In the end I think the only real solution is for a law that establishes two distinct networks (same address assignment base, but disjoint routing), one where spamming is allowed, and one where it is entirely prohibited under threat of jail time (for the executives in the case of corporations, LLCs, etc). Each ISP can then choose to service one or the other or set up dual but separate facilities to serve both. Wanna bet which network most will choose?
How do you write the law to block unsolicited bulk email but not valid business to business email?
Since unsolicited bulk email is not valid business to business email, the law only needs to say that it is not legal to send mail that is unsolicited and/or bulk (I favor using just "or").
I would agree that banning particular content would be a violation of the US First Amendment. But I would disagree about being truthful in labeling, and the requirement being connected with behaviour (specifically, that the mailing is unsolicited, which has nothing to do with First Amendment). As for the "do not mail me" registry, I see no Constitutional issue with it, but I don't think it will actually work.
I have yet to see one that is easy to get into. Do consider the fact that I have nearly an infinite number of email addresses, including several domains where any username part always gets the mail to me.
And what about email addresses that don't even have an existing mailbox? There are a few hundred email addresses in a few domains I have which have no mailbox or user, yet spammers are sending them mail (which gets rejected for no such user). This still costs money because it uses up the capacity of my mail server. Opt-out registries won't work if they require verifying the email address exists.
Verification is only one at a time and way too hard to do
My conclusion is this site is a joke. Do they expect to handle millions of lookups an hour?
What they should do is distribute a list of the 160-bit SHA1 checksums of the registered addresses. Then it's simply a matter of the spammer hashing each email in their mailing list and looking that up against the list. If there's a match, bingo.
The problem is the cases are too small and don't even have a place to put a fan in the back. And even then, there would be the problem that there are too many holes in the front which are not in front of the drives.
My drives are cooled by 3 small (40mm) fans right in front of the drive itself. It's a mounting bracket for 3.5 inch (88.9 mm) drives to fit in 5.25 inch (133.35 mm) drive bay and includes the fans in the bracket assembly. The temperature drop on these is enormous, going from "can't touch for more than 2 seconds" to "can hardly tell if they are on". It's more like a drop from 70 degrees (158 F) to 20 degrees (68 F). Fortunately the vibration is quite small (can only hear it, not feel it) and I haven't had a drive die in these assemblies, yet (9 drives total across 5 machines going 3 years now).
Just display a picture of a keyboard with the letters randomly re-arranged. Key in your password by clicking on the correct letter, wherever it is. Spies would have to be viewing your your screen. Mix it so part is entered by mouse, part by keyboard, part by voice, etc.
Loopback devices are a silly hack. It was nice to add a quick feature. But what is really needed is a smooth, seamless, truly integrated solution which works at the virtual device layer, above individual device drivers, but below filesystems and direct device opening. The reasons for this include the fact that you can't partition loopback devices (that's another issue) and the number of loopback devices being limited. This needs to be made totally transparent except for the fact of enabling it and setting the key (probably an integrated ioctl() and/or/proc operation). Every device (and partitions count) need to be able to have their own separate key and encryption state.
Too often there is no opportunity to maintain your own code. I find I'm sitting around idle most of the time if all I'm doing is maintaining my code. So of course if I were working in the programming field (I'm not, although I have done some programming projects on the job before) the project manager would end up moving me around to keep me busy (and challenged). Where's my old code? It's running in that other department or that other company. If I do end up doing any code maintenance or changes, it's someone else's POS.
So what advice would you give to the senior programmer/systems engineer who is also asking (and needs to ask) the question: How to be a Programmer? I've found that typically only 15% or so of programmers really know what they are doing. That figure rises as you move up the ranks and is finally double that at the senior level... 30%.
Good hardware. Bad management. But that latter one is the fundamental reason I've recently decided to drop the Sparc Architecture in projects I work on. The one I do have that architecture is relevant is BICK. It lets you build a Linux bootable ISO image to make a CDR that can boot your own customized CD based system on either Intel x86 or SUN Sparc architecture even from the same CD. The reason I did that wasn't the trickery of doing 2 architectures on one CD, but rather, because I have worked with SUN machines many times, and having such a tool would be cool (e.g. carrying around one rescue CD for both architectures). However, for several reasons I have decided to drop SUN Sparc from the next version. This serious attitude problem Sun has is a major component of the reasoning (and is also why I will not select SUN hardware for future use in my business). The fact that they won't work with the OpenBSD team isn't by itself the reason I do this, but it is quite representative of an overall problem with SUN that is the reason.
Slashdot Mirror
Nooooooo. This is for public access servers to download files. You can't just set up a tunnel for every Joe Downloader that comes along and wants the files. SSL/TLS will do the job just fine.
For rarely changing (relative to how many times downloaded) files on public rsync servers, a high blocksize would be more appropriate. I regularly use 8192 bytes. I'd use even larger, like 65536, if it weren't for the fact that something is broken at 32768 and larger. When the file being downloaded is compressed already, the rsync algorithm is not very effective for much more than resuming incomplete transfers, or transferring only the part of the file after a change is detected (on average, half the file).
In some cases other blocksizes are better. If the file is not compressed and is an ISO image, using a blocksize of 2048 allows re-building an ISO where a significant amount of file data has simply been moved around the image when it is reconstructed. Since the ISO format uses 2048 byte filesystem blocksize, those are the "snap-to" points for content data blocks. The rsync algorithm does quite well with uncompressed ISO images. It can also be used for uncompressed tar images when the blocksize is chosen to match the tar blocksize, which is often smaller like 512 bytes. Since PKZIP files are compressed with separate compression states per file, these may also be improved on by rsync, depending on the boundary for starting each file that PKZIP format uses (which at the moment I do not know).
Try running the FTP server behind one firewall with NAT while the client is behind its own firewall with NAT, and both machines have the same private address. Really confusing at best.
What rsync needs is a port assignment (in addition to its existing 873 for clear connections) for SSL/TLS. Alternatively a "STARTTLS" feature added to the rsync protocol could do the same job. What this gets us is the ability to create a secure SSL service where passwords and data are reasonably confidential, while not having to worry about adding users to the host system itself (which is required for either rsync over ssh, or for scp as an alternative) which exposes a risk of accidentally making them shell users (not everyone wants to do that).
The MD5 cache does not need to be stored in RAM. In fact that would be harder to do across different rsync sessions. The cache would be in the form of a configured alternative file path. The config might look like:
md5cachepath = /home/public-md5
That would be put into each context in the /etc/rsyncd.conf file. It would represent a parallel file tree to the one specified by "path =" with every name matching with an optional .md5 extension. If the md5cachepath is the same as path then the extension is required. When it processes a file it would check for the cache file and its date. If it does not exist or the date does not match, it just forces live checksumming. It would probably be best to have only a single process creating the checksum cache files.
Read the standards for judgement page. They require PowerPoint format presentations. OK, does this mean I finally have to install an office package on my Linux workstation, such as Star Office or Open Office?
Spam is not about content. Not everyone even agrees what constitutes spam when they are evaluating it based on content, so how can a program or a recipient community do this? What makes mail spam is stuff like sending it unsolicited and in bulk. It won't matter what the content is.
I have signed up with some companies for announcements about their products. While that company may not be spamming, their content could have a lot of the same wording as another company selling similar products, but is sending it to harvested addresses. The latter is spam, but the former is not. How do you tell based on the content?
Tools that evaluate a message based on content are probably going to classify both messages the same way. If they are both classified as spam, then one of them will be "collateral damage". If they are both not classified as spam, then the other will be "leaky pinky". So I still prefer to block spam on the basis of the behaviour of the sender.
One person's spam is another person's treasure. That, of course, relates to the content of the message, as opposed to the behaviour of the sender. You might get the same thing from the same sender as I do, and you might consider it spam (various reasons) while I might have actually signed up to get it. Many companies have been known to augment their mailing lists with extra addresses, so this can even happen even though I signed up and you never did. And so it goes that for you it would be spam, and for me it would not be (although if I found out the sender was doing that, I'd sure be quite a bit more than piss off at them).
I really don't like the idea of other people ... or programmed logic for that matter ... making the decision for me what is or is not spam based on its content. The real issue with spam is not what the content is (with a few exceptions for some recipients), but the behaviour of the sender. For example suppose you post a message on an online message board that you're looking around for a place to buy a new motherboard that was just announced by its manufacturer. Then shortly afterwards you get an email from The Motherboard Palace stating that they have just received a big shipment of that new motherboard you wanted, and are offering a 20% discount on orders placed within 24 hours of the mailing. Now is that spam? What if they mailed it also to 999,999 other people without you knowing that? Now is that spam?
You're just giving them a legal defense. While the court might not grant that to an obvious slimeball, in other cases involving borderline businesses (that you and I would still call a spammer, but the judge might not), the argument that it is not practical to use the list can be effective. If there is a single state mandated list, it would probably end up being a law suit against the state for not operating it properly. But if there are simply volunteer lists, such as ones to declare your residency, there could end up being many of them, and the argument would certainly say "we use the ones that are usable, so you should have registered with them".
This is not silencing the speakers. As long as people have the right to not filter out the messages, and thus read them, then those that care will, and those that don't, won't.
Compare this to how free speech was done in the days the Constitution was written. Most speech was in the form of coffee/tea house discussion, public speeches at the center of town, debates in Congress or the legislatures of the states, and printing up your comments in a newspaper. If someone who had an important message (their opinion) for you were to barge into your home to deliver it, and the constable came and dragged them back out and threw them into the middle of the street, would this be called silencing? No. They could speak their mind from the street. In fact there are laws limiting even when that could be done (e.g. disturbing the peace). Most towns did have a central podium just for things like people making their speeches.
The issue is not what is said (that is protected) but rather, how they impose on us to deliver it (that is not protected).
Comparing a snailmail box to an email box is a bit more complex. As long as I do not have to pay to receive the mail, that is, the sender pays all costs, then I can just as easily throw it away. Of course I do have a minor cost in doing that, but the major cost is on the sender, and that is a limiting factor. But email is quite different. This is not a case of a single entity handling all the delivery. Instead, email is a peering setup with a sender agent and a receiver agent (e.g. the ISPs). Email can be scaled up high on the sending end with extremely small cost, while the recipient has higher costs for each message received (even if it is refused). The issue is not about what is being sent, but rather, the costs that are imposed upon me (and in particular, that my costs are higher than the sender's costs).
Unless I say otherwise, this very Slashdot posting can be considered a solicitation to email me privately, but only for something related to it, basically a reply. So it would not be unsolicited for you to email me privately for that purpose. The implication is that it would not be for other purposes initially. Of course there is a content tie-in with that, but it's no longer public speech when addressed to a single person. It's certainly not bulk to reply to me privately once.
But I do agree that private filters are (still) the best way to go. Different people have different preferences on how agressive that can be. A business might not want to filter very much for fear of not receiving mail from a prospective customer. And if their mail volume is high, the spam might be a drop in the bucket in comparison. An individual, however, may find it best to be especially aggressive and filtering, including filtering whole ISPs that harbor spammers (and yes, that means "collateral damage"). It should be the choice of the recipient.
With a Do Not Call list, one single entry covers all my phone extensions. Since the teleslimers will be comparing only the basic phone number, and not the number with its extension, against the list, by simply having my number without any extension in the list, a proper lookup will match and they can skip that number. None of my extensions will be called.
The issue is how to do this for email addresses. Many mail servers allow for "extensions" by having a certain special character such as "-" or "+" or "." followed by an "extension". By simply having the email account of the part before the separator, you automatically have every possible extension. Some people call this tagged email. And example would be jsmith-foobar@example.net where only jsmith@example.net would be in the list.
Many people even have their own vanity domain names, and regardless of what username is used before the @-sign character, they get the mail like the whole username were the extension.
For a registry to work, for at least those who are required to use it, it must meet at least these two requirements:
I looked at the registry run by the Washington Association of Internet Service Providers and found that the verification process only works one at a time. This makes their registry virtually useless. Of course, distributing the addresses in the raw will be worse, as it will get in the hands of spammers out of the country, and everyone will just get more spam because now spammers will have a list of address that are even more likely to have someone reading. And some will be mass mailing to such a list just to destroy the effectiveness of registering.
One option is to distribute an SHA1 checksum of each address. Then all that needs to be done on the mailer's end is to test each address by generating the checksum and looking that up in the database.
But even that has a risk, and I'm wondering if even that should be allowed. That risk is that spammers will run all their millions of email addresses through the process, and produce a subset of those who are registered, and then from out of the country ... they will spam the hell out of just those.
In the end I think the only real solution is for a law that establishes two distinct networks (same address assignment base, but disjoint routing), one where spamming is allowed, and one where it is entirely prohibited under threat of jail time (for the executives in the case of corporations, LLCs, etc). Each ISP can then choose to service one or the other or set up dual but separate facilities to serve both. Wanna bet which network most will choose?
Actually, it probably won't work at all, at least as long as the registries are impractical to use.
Since unsolicited bulk email is not valid business to business email, the law only needs to say that it is not legal to send mail that is unsolicited and/or bulk (I favor using just "or").
I would agree that banning particular content would be a violation of the US First Amendment. But I would disagree about being truthful in labeling, and the requirement being connected with behaviour (specifically, that the mailing is unsolicited, which has nothing to do with First Amendment). As for the "do not mail me" registry, I see no Constitutional issue with it, but I don't think it will actually work.
I have yet to see one that is easy to get into. Do consider the fact that I have nearly an infinite number of email addresses, including several domains where any username part always gets the mail to me.
And what about email addresses that don't even have an existing mailbox? There are a few hundred email addresses in a few domains I have which have no mailbox or user, yet spammers are sending them mail (which gets rejected for no such user). This still costs money because it uses up the capacity of my mail server. Opt-out registries won't work if they require verifying the email address exists.
Pros:
Cons:
My conclusion is this site is a joke. Do they expect to handle millions of lookups an hour?
What they should do is distribute a list of the 160-bit SHA1 checksums of the registered addresses. Then it's simply a matter of the spammer hashing each email in their mailing list and looking that up against the list. If there's a match, bingo.
The problem is the cases are too small and don't even have a place to put a fan in the back. And even then, there would be the problem that there are too many holes in the front which are not in front of the drives.
My drives are cooled by 3 small (40mm) fans right in front of the drive itself. It's a mounting bracket for 3.5 inch (88.9 mm) drives to fit in 5.25 inch (133.35 mm) drive bay and includes the fans in the bracket assembly. The temperature drop on these is enormous, going from "can't touch for more than 2 seconds" to "can hardly tell if they are on". It's more like a drop from 70 degrees (158 F) to 20 degrees (68 F). Fortunately the vibration is quite small (can only hear it, not feel it) and I haven't had a drive die in these assemblies, yet (9 drives total across 5 machines going 3 years now).
Just display a picture of a keyboard with the letters randomly re-arranged. Key in your password by clicking on the correct letter, wherever it is. Spies would have to be viewing your your screen. Mix it so part is entered by mouse, part by keyboard, part by voice, etc.
Loopback devices are a silly hack. It was nice to add a quick feature. But what is really needed is a smooth, seamless, truly integrated solution which works at the virtual device layer, above individual device drivers, but below filesystems and direct device opening. The reasons for this include the fact that you can't partition loopback devices (that's another issue) and the number of loopback devices being limited. This needs to be made totally transparent except for the fact of enabling it and setting the key (probably an integrated ioctl() and/or /proc operation). Every device (and partitions count) need to be able to have their own separate key and encryption state.
So add on to the message: "Oh, by the way, I'm trying to make a living, too. But at least I have a real job where I don't harass people every day."
That reply to my comment is excellent. It deserves the mods.
Too often there is no opportunity to maintain your own code. I find I'm sitting around idle most of the time if all I'm doing is maintaining my code. So of course if I were working in the programming field (I'm not, although I have done some programming projects on the job before) the project manager would end up moving me around to keep me busy (and challenged). Where's my old code? It's running in that other department or that other company. If I do end up doing any code maintenance or changes, it's someone else's POS.
So what advice would you give to the senior programmer/systems engineer who is also asking (and needs to ask) the question: How to be a Programmer? I've found that typically only 15% or so of programmers really know what they are doing. That figure rises as you move up the ranks and is finally double that at the senior level ... 30%.
Good hardware. Bad management. But that latter one is the fundamental reason I've recently decided to drop the Sparc Architecture in projects I work on. The one I do have that architecture is relevant is BICK. It lets you build a Linux bootable ISO image to make a CDR that can boot your own customized CD based system on either Intel x86 or SUN Sparc architecture even from the same CD. The reason I did that wasn't the trickery of doing 2 architectures on one CD, but rather, because I have worked with SUN machines many times, and having such a tool would be cool (e.g. carrying around one rescue CD for both architectures). However, for several reasons I have decided to drop SUN Sparc from the next version. This serious attitude problem Sun has is a major component of the reasoning (and is also why I will not select SUN hardware for future use in my business). The fact that they won't work with the OpenBSD team isn't by itself the reason I do this, but it is quite representative of an overall problem with SUN that is the reason.