Conundrum with aucat and rc_scripts
Hi, I've configured the ices package to stream whatever happens to be flowing into my sound card line input using this roundabout method (seems to work the best given that ices will read from a FIFO but not stdin): 1. aucat writes line in to FIFO at /dev/aucat/.raw; 2. lame reads from above and writes to FIFO /dev/lame/.mp3; 3. ices reads from above and sends to my icecast server. The following commands in a sh script run from root's shell form the meat of the above chain of events: /usr/local/bin/lame --quiet -r -a -b 56 /dev/aucat/.raw /dev/lame/.mp3 /usr/bin/aucat -o - /dev/aucat/.raw /etc/rc.d/ices start However, if I try to adjust /etc/rc.local to include the first two lines (which need to be running before ices gets called by rc_scripts in rc.conf.local), aucat refuses to start. I've also taken the above commands and created a slightly more robust watchdog script that is run as a cronjob. crontab entry: * * * * * /root/bin/wd_ices.sh /root/bin/wd_ices.sh: #!/bin/sh AUCAT_PID=`/bin/ps ax|grep -v grep|grep 'aucat -o -'|sed -e 's/^ *//' -e 's/ .* //'` LAME_PID=`/bin/ps ax|grep -v grep|grep 'lame '|sed -e 's/^ *//' -e 's/ .*//'` ICES_PID=`/bin/ps ax|grep -v grep|grep 'ices '|sed -e 's/^ *//' -e 's/ .*//'` if [ $AUCAT_PID -eq -o $LAME_PID -eq -o $ICES_PID -eq ]; then echo ices and/or its streams were not running and were restarted on `date`. /etc/rc.d/ices stop kill $LAME_PID /dev/null 21 kill $AUCAT_PID /dev/null 21 sleep 5 /usr/local/bin/lame --quiet -r -a -b 56 /dev/aucat/.raw /dev/lame/.mp3 /usr/bin/aucat -o - /dev/aucat/.raw /etc/rc.d/ices start fi exit Unfortunately, this doesn't work exactly as expected either. While aucat actually starts up, cron doesn't seem to like something about it and gets stuck trying to send a message to root. `ps ax` shows the problem, which just stalls there and won't go away: -PID- ?? I 0:00.04 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t If I kill lame (which brings down aucat and ices), sendmail will then get the message through and exit. Can anyone tell me how to get lame and aucat running properly at startup before /etc/rc.d/ices gets called by rc.local? Can anyone tell me how to get the same working with cron without those sendmail problems? Thanks. Breeno
Re: vpn with an iphone
jul wrote: Hello has someone setup a vpn tunnel between openbsd and an iphone ? it seems ipsec part is strictly limited to cisco ipsec with a user account/password so not good for us. Else there is pptp and l2tp but i'm not sure there is anything in base to do this. Ports seems to only have pptp as a client and i'm looking for server. any informations ? thanks a lot Cheers I apologize for the fairly off topic nature of this post, but I am assuming there may be other OpenBSD users out there trying to wrap their heads around what it would take to make an iPhone work with OpenBSD's default VPN method. The iPhone implements racoon to perform the IPsec portion of the iPhone L2TP. On a jailbroken phone, you can see an instance of the racoon process start / stop if you connect to / disconnect from an L2TP connection. You can also find the racoon executable in /usr/sbin if your iPhone is jailbroken. Unfortunately, racoon on the iPhone does not include setkey, which as far as I can tell is required to set up an IPsec tunnel with OpenBSD. There was a setkey floating around for firmware 1.x of the iPhone (see the post at http://forum.insanelymac.com/index.php?showtopic=98756 and find the download at http://pr0g.free.fr/iphone/setkey). I tried using this version of setkey on my 2.x firmware iPod Touch but, as is the case with most software compiled on 1.x, the program failed with an error. One would expect that it should be possible for an enterprising person to fetch ipsec-tools for Darwin (the latest as of writing is at http://www.opensource.apple.com/darwinsource/10.5.5/ipsec-34.0.2/) and compile a working setkey for the iPhone. Once done, creating an IPsec tunnel between an iPhone and OpenBSD should be nearly identical to creating such a tunnel using OS X or FreeBSD. Hopefully you can use this information. Breeno
Re: Modern operating systems are flawed by design, including OpenBSD.
Obviously someone made a mistake running that story, as April 1st is still over half a year away. Breeno mak maxie wrote: http://www.computerworld.com.au/index.php?id=264209080rid=-219 Microsoft Windows is the only operating that supports signed binaries. _ [EMAIL PROTECTED] http://msn.com.hk
Re: dmesg IBM x3650 OpenBSD 4.3
gm_sjo wrote: 2008/10/10 Theo de Raadt [EMAIL PROTECTED]: Wow. Good luck. Can't you see we've been down that road before with those bastards? But really. Good luck. You really are too optimistic, but sure, learn the reality for yourself. I'm sure calling vendors 'bastards' on a public mailing list is really going to help the cause. When you have proven yourself even 10% as helpful to the cause of OpenBSD as Theo is, then maybe, just maybe, you are justified in criticizing his tactics. I look forward to that point in time, but until then I really have no reason to side with you, nor should anyone else who is informed on this matter. Theo has proven very well that the most effective method of dealing with these 'bastard' vendors (that ignore or undermine OpenBSD) is to use negative reinforcement. Corporations only understand and react appropriately to bad publicity that threatens their profits. Anything else merely encourages them to continue to ignore OpenBSD, because they perceive that it costs less to ignore OpenBSD than it does to help. Breeno
Re: dmesg IBM x3650 OpenBSD 4.3
gm_sjo wrote: 2008/10/10 Breen Ouellette [EMAIL PROTECTED]: When you have proven yourself even 10% as helpful to the cause of OpenBSD as Theo is, then maybe, just maybe, you are justified in criticizing his tactics. I look forward to that point in time, but until then I really have no reason to side with you, nor should anyone else who is informed on this matter. Dear lord, it's brainwashed minions such as yourself that make me wonder why I continously donate money to the 'cause'. But of course, that's irrelevant, right? Your personal attack does not improve your standing in this matter. You are trying to deflect the issue: that you don't agree with Theo's tactics. Yet, you have failed to provide a single good reason for why people should believe you. Theo's trash talking about trashy vendors has a history of effectiveness, while the wishy washy avoidance that you advocate has never proven effective. Show us one vendor that has released documentation because OpenBSD developers and users sat back and waited quietly for it. And again, what exactly was it that have you done for OpenBSD that makes your opinion worth listening to, let alone superior to Theo's? Breeno
Re: Petition to VIA
[EMAIL PROTECTED] wrote: Hi everybody, I don't know if it's known but there's a online petition for VIA. Hopefully some people sign up and name also OpenBSD (in the optional-section). It's about VIAs policy with docs/drivers and the lies they spread (about supporting Opensouce). Link: http://www.petitiononline.com/vialinux/petition.html Kind regards, Sebastian I still say the best petition is to avoid buying VIA products - and then post about it in a public forum, list the alternatives you chose for your task, and send the link to VIA. If enough people would follow this simple process then Via would react. The TdR method is also sometimes effective, but it seems to have diminishing returns the larger the target corporation. I haven't seen or heard of a single company being persuaded by an online petition. That's not to say that it couldn't or hasn't happened - I've just never heard of it. You would think that people would hear more about them if online petitions of companies were indeed successful. Corporations are concerned with one thing - profit. Take from their profit, be vocal about the reasons in a public forum while listing alternatives (both of which also threaten their profit), and make the corporation aware of it. They will then be forced to address the situation or continue to risk a negative and public boycott. Breeno
Re: Richard Stallman...
Deanna Phillips wrote: Marco Peereboom writes: Blah blah blah my feelers are hurt. Do I need to mail you some maxi pads? Do I need to point out that you've attempted to insult someone by comparing him to some bullshit stereotype about women? Well said. Flinging mud is all well and good as long as it is flung at the right people. To bring in half the human population into this flame fest is at best grossly overeager and at worst extremely and unfairly prejudicial. Breeno
Re: [EMAIL PROTECTED]: Re: Real men don't attack straw men]
Marco, I can definitely see another angle: RMS spoke about OpenSolaris without getting his facts straight. When his bullshit was exposed he backtracked and had the author of the article post this correction: [RMS added this comment later:] Since that interview I've learned that not all of OpenSolaris is free software; it is distributed with many non-free programs. I am not sure that the free parts can even run on their own. I cannot endorse OpenSolaris in its present form as a system to use. RMS has an agenda and he has been spewing sincere misinformation for a while now to try stay in the spotlight. Check out this link for another example of RMS badmouthing a project without checking his facts first: http://fitz.blogspot.com/2007/07/stallman-shoots-free-software-movement.html RMS can get away with running at the mouth because when he is wrong he dodges the criticism and twists his original statements to try and squirm out of taking responsibility for them. It is exactly what he tried to do here recently, but thankfully some of the OpenBSD developers got quite vocal about it. Even so, I still wouldn't call it a decisive victory against hypocrisy, misinformation, and slimy tactics. Given that it has been voiced on this list that RMS makes the rounds badmouthing projects with little to no justification, and that this isn't the first time he has done it to OpenBSD (and he is likely to come back in a year and do it again), maybe it is time that his exploitation of free software projects be chronicled in a single location on the Internet. He counts on his positive publicity to lend credence to his endorsements, so a counter balance of centrally available bad RMS pontification might cause him to do some research before opening his mail program or mouth in the future. At the very least, it may cause some journalists to actually fact check his statements before publishing them. For example, his Wikipedia article is one sided propaganda: http://en.wikipedia.org/wiki/Richard_stallman Unfortunately, I do not know what central repository should be used for this purpose. If there are any Wikipedia editors on this list then they might want to update the article so that it properly reflects the criticism RMS has generated when he has spoken on subjects which he understood only poorly. It might seem like a smear campaign, but at least it would be ACCURATE - which is more than can be said of RMS' smearing. Breeno Marco Peereboom wrote: These messages somehow did not make it to misc@ so I am resending them. My reply to RMS did make it to [EMAIL PROTECTED] I basically asked RMS why he endorses Solaris which is not even remotely free. I encourage people to try to understand the FSF reasoning for this endorsement. I can't come up with anything else but a bought endorsement. Original message: -- Date: Wed, 26 Dec 2007 09:07:15 -0600 From: Marco Peereboom [EMAIL PROTECTED] To: Richard Stallman [EMAIL PROTECTED] Cc: misc@openbsd.org Subject: Re: Real men don't attack straw men In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.17 (2007-11-01) Richard, can you please educate me why you endorse Solaris? http://itmanagement.earthweb.com/osrc/article.php/12068_3717476_3 Per that interview you are endorsing an OS that basically won't run without proprietary drivers. I love Solaris as an OS but it isn't free. The CDDL clashes with the GPL; or can you explain why suddenly CDDL is GPL compatible? Did someone tell you its free? Might it have something to do with money? http://www.fsf.org/donate/patron/index_html We are talking about the same Sun that rejects open source drivers for proprietary reasons. Like this beautiful piece of software written by David Gwynne: http://www.itee.uq.edu.au/~dlg/mfi/ This was rejected in favor of LSI's proprietary driver that adds nothing over David's driver. Eagerly awaiting your answers, /marco -- RMS' answer: -- X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.2.2 (2007-07-23) on mail.peereboom.us X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS autolearn=ham version=3.2.2
Re: Real men don't attack sign men
Marc Balmer wrote: Richard Stallman wrote: I doubt someone who is truly unfriendly could organize a hackathon, a friendly social event. He may be perfectly friendly to others. What is relevant is that he tends to be unfriendly to me. What is relevant is that you are a hypocrite and come to our mailing lists talking bullshit about OpenBSD. You do not only offend Theo, but all of the OpenBSD / OpenSSH developers. And many of the OpenBSD users, as well, who appreciate the work done by the OpenBSD developers and do not wish to see the project slagged off the cuff by people in the spotlight. Breeno
Re: Real men don't attack straw men
- This is a reply to David's email to me. I have left out his original message since it was sent privately and without permission to repost to the list. - This is all I have left to say on the matter. How you take it from here is up to you. OpenBSD only endorses OpenBSD. I have never seen a single piece of software outside of the OpenBSD base endorsed by OpenBSD. It has a ports tree which makes it possible to run a large number of software packages, some of which do not meet the definition of free software put forth by the FSF. However, this does not constitute endorsement. Merriam-Webster: 2 a*:* to approve openly /endorse/ an idea; /especially/ *:* to express support or approval of publicly and definitely /endorse/ a mayoral candidate b*:* to recommend (as a product or service) usually for financial compensation shoes /endorsed/ by a pro basketball player The ports tree offers a number of similar software packages of varying licences. There is no endorsement by OpenBSD of any single package as being better than any other package. Options are offered, and it is up to the user to decide which one to use. OpenBSD doesn't define itself as a censor of anything outside of the base system. The only reasons I have ever seen for leaving something out of ports were based on legal issues, which isn't censorship but merely covering the project's hindquarters. RMS' statement that OpenBSD endorses non-free software goes too far, and the intention was to detract from OpenBSD - no matter how much sugar coating it came with. On the FSF side of the fence, gcc allows interoperability with non-free systems and software. That hardly means the FSF endorses it, but Theo has been using that example to illustrate the ludicrous and hypocritical nature of RMS' statements. OpenBSD surely tolerates and allows a broad range of software to be installed through ports and executed on the system. This is not at odds with the OpenBSD project goals: http://openbsd.org/goals.html Based on this, I see no hypocrisy from OpenBSD. If RMS had made the statement that OpenBSD doesn't actively prevent the user from running non-free software then I think there wouldn't be an issue here - what operating system does? Then again, it wouldn't have the same impact as claiming that OpenBSD contains and endorses non-free software. That's far more accusatory. But it's wrong. As for Theo being abrasive, it has never been my experience that he is, but I have been fortunate to meet him in person, and so I don't fill in the blanks left by email correspondence with images of this Theo-monster everyone writes about. I read his emails for what they are - uncompromisingly intolerant of ignorance and sincere misinformation, which doesn't sit so well with the bleeding-heart majority. People expect their sincere misinformation to be countered with polite explanations. Nothing but wimpy social custom requires such - and the older I get the more I've come to agree with Theo's stance of fighting the ridiculous with ridicule. It is the most effective and reasonable method of dealing with these people. RMS, on the other hand, comes in with a half baked idea that OpenBSD endorses non-free software, AND he openly endorses censorship of all non-free software. I can't get behind that. If he isn't happy with the landscape of non-free software then he should work on improving the landscape of free software to compete with these non-free packages he despises. My opinion is that he has failed to convince the world that all software should be free. He can't make his vision of free software stand on its own two feet so instead he is trying to kick out the legs of everything else which doesn't actively support his vision. Well, I for one have never felt that censorship of any sort is a viable way of growing a competing idea. Censorship ultimately leads down an evil path. I'm out. Breeno
Re: Real men don't attack straw men
Rui Miguel Silva Seabra wrote: On Thu, Dec 13, 2007 at 11:54:47AM -0700, Theo de Raadt wrote: Richard, your pants are full of hypocritical poo. You too. I still remember cheering when I read http://monkey.org/openbsd/archive/ports/0108/msg00460.html * From: Theo de Raadt [EMAIL PROTECTED] * Date: Fri, 24 Aug 2001 12:11:00 -0600 * Cc: [EMAIL PROTECTED] I am just curious - why exactly were all the DJB ports dropped? Precisely because of what the commit message says: Removed qmail; license does not permit modification [camield 2001-08-14] Sadly you're too quick to launch the 'hypocrit' word... http://www.openbsd.org/4.2_packages/i386/zangband-2.6.2p1.tgz-long.html According to Sourceforge: http://sourceforge.net/projects/zangband License: Other/Proprietary License Its was not a question of the license being proprietary, it was a question of qmail not allowing modification. To get it running on OpenBSD required modification - so it was removed from ports. The qmail licence was quite clear: If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute. If every port required 'a detailed review of the exact package that you want to distribute' from maintainers then we would have far less ports. We'd have far less maintainers! Theo made the right decision not to tolerate it. To do anything else would open the floodgates of maintainer hell. Now that qmail is moving to the public domain I wouldn't be surprised if it re-enters the ports system since it will no longer contain this restriction. Of course, it will require someone willing to maintain the port. The zangband licence, on the other hand, reads: /* * Copyright (c) 1989 James E. Wilson, Christopher J. Stuart * * This software may be copied and distributed for educational, research, and * not for profit purposes provided that this copyright and statement are * included in all such copies. */ There is no explicit requirement to obtain the author's approval before distributing a modified version. Since OpenBSD doesn't have to go out of its way to please the original creator with unreasonable demands zangband has been kept in ports. You are wrong. It does not matter how sincerely you present your misinformation, it still marks you as lazy, apathetic, and willing to make statements without first understanding the situation or researching your ideas. If you don't like Theo because he doesn't handle you or others with kid gloves, then just say so. Just say I don't like Theo because he hurts my feelings and be done with it. Stop trying to make ridiculous arguments based on misinformation. One thing I can almost guarantee - Theo will be far more pleasant in response to you if you simply stop spreading bullshit. It would be so wonderful if people would simply read and understand the essay /On Bullshit/ by Harry Frankfurt before posting anything to this list. The traffic here would be succinct and entirely useful. Much like OpenBSD. http://en.wikipedia.org/wiki/On_Bullshit Breeno
Developers: First Reply Gets My Copy Of /On Bullshit/
OpenBSD developers, In recognition of all the bullshit flying around recently on misc@, I would like to offer to mail my copy of of the essay /On Bullshit/ by Harry Frankfurt as a gift to the first OpenBSD developer to request it. This essay is bound in a blue hardcover 4 x 6 (10cm x 15cm) in size, and spans approximately 70 pages. It can be read in less than one hour. Just let me know where to send it and I will drop it off at the courier. For everyone else, we are all lucky enough to be able to access the full text at the following link: http://web.archive.org/web/20031204195648/www.jelks.nu/misc/articles/bs.html Breeno
Re: Developers: First Reply Gets My Copy Of /On Bullshit/
It's yours Bob. Given the address you've posted, I imagine that you might want me to send it in care of someone with the initials RMS? Breeno Bob Beck wrote: Me! Me! Ship it to my address: 51 Franklin Street, Fifth Floor Boston, MA 02110-1301 USA -Bob * Breen Ouellette [EMAIL PROTECTED] [2007-12-14 13:02]: OpenBSD developers, In recognition of all the bullshit flying around recently on misc@, I would like to offer to mail my copy of of the essay /On Bullshit/ by Harry Frankfurt as a gift to the first OpenBSD developer to request it. This essay is bound in a blue hardcover 4 x 6 (10cm x 15cm) in size, and spans approximately 70 pages. It can be read in less than one hour. Just let me know where to send it and I will drop it off at the courier. For everyone else, we are all lucky enough to be able to access the full text at the following link: http://web.archive.org/web/20031204195648/www.jelks.nu/misc/articles/bs.html Breeno
Re: Real men don't attack straw men
Benjamin M. A'Lee wrote: On Fri, Dec 14, 2007 at 08:06:35PM -0700, Theo de Raadt wrote: That's bullshit. Read it again. The BSD license gives the recipient some abilities, but retains others. One of those is that the source code must retain the license. Other restrictions... why do we care? Our code is still alive. HP and Cisco has included OpenSSH -- with changes they did not give back we are sure -- in all their router products, and none of you would argue that the world is not a richer place because of that. As a result of our giving nature, the internet at large is much more secure now. This is my point exactly: why should a GPL developer be forced to give their *changes* back? They're still required to acknowledge your copyright, but if HP and Cisco are permitted to keep changes to themselves, why shouldn't the GNU project or the Linux kernel do so (or, rather, release their changes to the code under a licence that isn't useful to OpenBSD). Please note that I don't think it's at all fair for a free software project to behave like that, and modifications to OpenBSD code should be given back to OpenBSD, but if a proprietary company doesn't have to give changes back to OpenBSD in a way that's useful to OpenBSD, why should GNU or Linux be required to do so? You aren't getting it. The licence stipulates that one set of rules apply if you redistribute the source code, and another set of rules apply if you distribute a binary. This is why different rules apply to GPL developers. Their own licence requires them to redistribute source, so they must follow the part of the BSD licence which applies to source redistribution. That said, I'm not completely getting it either. Everything to follow is conjecture on my part and may not be accurate or correct. Theo would probably know whether or not attaching an additional GPL licence actually results in more restrictions being applied to the code. To me, the BSD licence was there first and supersedes the GPL. And I see no requirement in the BSD licence to retain additional restrictions or grant additional freedoms placed on the code by subsequent contributors after the initial BSD release. To me, any person could ignore the GPL in any code appearing in a file which was originally licenced BSD. Or just strip the GPL out of the file and leave the original BSD licence, for that matter. The opposite seems to be true as well - a file originally released under the GPL which then has a BSD licence tacked onto it would not suddenly allow people to distribute the program only in binary form. Neither licence appears to me to allow subsequent authors to create additional restrictions or freedoms. But then, what prevents a GPL author from creating a separate new file with clean GPL code and then adding some glue to the original BSD file to reference the new file? Or, along a different path of thought, a closed developer that was selling software built on BSD code seemingly could not prevent others from distributing BSD based binaries from their package for free. The BSD licence doesn't indicate that binary redistributions can be restricted to paying customers only. The binaries could be picked out and distributed for free by anyone who followed the second clause requirements of the BSD licence. Only new code that the closed developer distributed under a pay-for licence could be legally restricted to paying customers. I suppose the problem for the end user is proving which binaries contain only BSD licenced code. The fallacy of my confusion here will probably be immediately obvious ten minutes after I send this off. Oh well, here I go sticking my head out. I'm ready for the clue stick! Thanks in advance. Breeno
Re: Real men don't attack straw men
David H. Lynch Jr. wrote: Theo de Raadt wrote: Hell, the OpenBSD ports tree should perhaps contain patches which REMOVE such commercial operating system support. That's a fork Richard would surely approve of. Richard, your pants are full of hypocritical poo. I have no doubt that in some context Richard is hypocritical. Though most of us would be hard pressed to structure our lives to be consistent with our beleifs and principles to the extent that he has. But this is not about EMACS, nor is it about hypocracy. It is about OpenBSD. You were right up until this point. I highly doubt that many OpenBSD developers or users care whether or not RMS endorses OpenBSD. I know I don't. RMS has made statements which detract against OpenBSD and contradict the actions of his own organization, the FSF. They do not even take his fundamentalist stance with some of their own software, as pointed out by Theo. Calling him on his hypocrisy is this project's most reasonable defense against his statements. Anything else would require more effort from OpenBSD than it took RMS to muck about in the first place. And it's not worth any additional effort. RMS has not thrown the gauntlet at OpenBSD, he has thrown mud. We are throwing it back because we don't feel OpenBSD deserves it. There will never be an opportunity for cooperation between OpenBSD and the FSF because the FSF has an agenda which is at odds with OpenBSD. The project is trying to remove the GPL where ever possible, and I think that is part of what motivated RMS to make his negative statements about the OpenBSD project. To me, the tone of your email indicates that you think we should stand here and listen to his crap, and then try to build a relationship from it. He didn't come here to build anything. He came here wagging his tongue like a loon and those of us that support OpenBSD are now exposing him for what he is. He brought this on himself and he deserves it. Shame on him and shame on those who try to make excuses for him. Breeno
Re: Real men don't attack straw men
ropers wrote: This site uses ABLOBE Flush*, but it's TEH FUNNAY: http://googlefight.com/index.php?lang=en_GBword1=OpenBSDword2=Richard+Stallman *) But it's also lynx(1) compatible: Follow the IFRAME: content link to see the gist of things. In the Flush version there's also a winning stick figure knocking the kumquats out of a losing one. Try these match ups: - TdR vs RMS - OpenBSD vs gNewSense - Theo de Raadt vs Richard Stallman - Common Sense vs Richard Stallman And my personal favourite: The World vs Richard Stallman :) Thanks for the lighter side, ropers. Breeno
OpenBSD 4.2 / Soekris net4801 / vpn1411 - No More 'Corrupted MAC on input' Using OpenSSH
With the release of 4.2 I thought I would check again to see if the vpn1411 still fails with 'Corrupted MAC on input' on a Soekris net4801. I am happy to say that I can no longer reproduce the error using the GENERIC kernel. In the past I could pop up the error within minutes using this simple script: --- #!/bin/sh while true do cat /var/log/messages done --- Last night after about 10 minutes my ssh window was still happily spitting out text, so I opened up four more windows and ran an instance of the script in each window. Eight hours later and there was not a single failure. I was curious if something was recently changed in the Hifn driver. CVS shows that there were two patches put in in the last six weeks, but neither of those are in 4.2. The latest release of OpenBSD appears to be using version 1.152 of the driver, which has been in use for 16 months as far back as OpenBSD 4.0. Does anyone know if this was intentionally fixed, or is this an unintentional byproduct of code being cleaned up somewhere else? Breeno
Re: OpenBSD Install Goal
Marco Peereboom wrote: I installed FreeBSD once in my life. Took me 3 tries and I am sure some kittens were murdered in the process. I am also pretty sure I wept at some point. Honestly I can't remember a much worse installer; maybe SCO OpenServer but not by much. I second that! If FreeBSD is the OP's model for positive software evolution, then I am glad that OpenBSD has left the 'archaic' installer more or less alone, and concentrated on high quality additions to the meat and potatoes of the project, namely the tools and drivers in the OS itself. Theo was just posting about 'gimme gimme gimme culture' and look what rears up and slobbers all over this list! Breeno
Re: Hifn 7955: fatal: cipher_init: EVP_CipherInit: set key failed for aes256-cbc
I do not have experience with the net5501, but as for the vpn1411, you may want to check out this thread: http://marc.info/?l=openbsd-miscm=117826557508813w=2 It talks about recompiling the GENERIC kernel minus a few options, which has the side effect of fixing SSH connection problems with the vpn1411 and the net4801. Why? I dunno. I'm not a developer, and my understanding of C is roughly equivalent to the average English writing skills of children in junior high. Give it a shot, and please report back to the list if it fixes things with the net5501 combined with the vpn1411. Breeno
Re: [OT] Open Source OSS for OpenBSD?
Theo de Raadt wrote: On 6/13/07, Edd Barrett [EMAIL PROTECTED] wrote: Hi guys, I have been reading a thread on opensolaris.org regarding the open-sourcing of 4front's OSS. After explaining why CDDL licensing is unsuitable for OpenBSD, some of the developers have expressed an interest to contact Theo regarding licensing and OpenBSD. I do not know much about licensing, nor do I feel that I should email Theo personally as he may not appreciate it. Just thought I would point out the thread here. http://www.opensolaris.org/jive/thread.jspa?threadID=32401tstart=0 Is OpenBSD even interested in multi threaded OSS? I wouldn't mind it. ...After much deliberation - we're going with CDDL for BSD. I don't know why OpenBSD can't work with CDDL since FreeBSD and NetBSD can. - http://www.opensolaris.org/jive/thread.jspa?threadID=32401tstart=0 It appears that the question might be whether anyone over in their camp is concerned with releasing code under a license even permissive enough to be included. They don't seem to care that OpenBSD as a project seems to have more stringent goals and policies than others. Noone cares about being Open and Free anymore. They just care about being called Open and Free, and how convenient -- a bunch of laywers generated an organization that will label then Open and Free when they are not in fact so. You know, phrases like 'free as in beer / free as in speech' have oversimplified and diluted open and free principles to the point that it is now equivalent to 'cheap and easy'. Complaining that OpenBSD has 'more stringent goals and policies than others' stems from this laziness. Free and open goals and principles have taken a back seat to easy solutions for cheapskates and greedy corporations. A sincere belief that something is open and free is held higher than having a factually verifiable open and free license. Sincerity should never overshadow fact in the realm of software. Sincerity is an emotional response where a factual response is most appropriate. Principles have taken a back seat to cheap and easy thinking. I propose a new phrase to describe 'Open and Free' projects that don't approve of OpenBSD's policies because they are 'more stringent ... than others': 'They aren't free as in speech. They aren't even free as in beer. They are cheap and easy as in prostitutes.' Society is failing to produce quality because it is acceptable, and in many cases preferable, to be sincere rather than factual. All these projects which don't understand OpenBSD's uncompromising policies are suffering from sincerity syndrome. They think that they can just feel like their projects are free and open and then say that they are. We live in a society of bullshitters, and the bullshitters have infiltrated open and free software. We have an uphill battle to fight because bullshitting has become generally accepted behaviour. Most people are bullshitters. We need to stop tolerating it in ourselves and in others. Breeno
Re: c2k7 hackathon is over
Theo de Raadt wrote: The c2k7 hackathon is over, with roughly 50 developers attending the event for 10 days in Calgary. So many projects were started or finished, it is basically impossible for me to describe all the projects. Hope you guys out there enjoy the changes that we've made. Thank you Theo and everyone else who participated. The effort that you make grows a little more impressive with each successive release. Three cheers for OpenBSD! Breeno
Re: Mac Mini (intel) status
Luca Losio wrote: Thank you. The goal is to have the mini replace my dying sparc64 as a web server. Small, low power draw, quiet: I like that. Quite expensive also When you compare its price/performance versus something like a Soekris, it looks pretty good and is still a reasonably small form factor. Are there better options? Perhaps. Feel free to share your hardware suggestions. If you know of a platform which is similar in size, low power, has similar performance, has similar build quality, and is lower priced than a Mini then please share your info with the rest of the group! Your comment on its own is of little value since most of us are already aware of the pricing of the Mini, or we can easily find out if we aren't. Breeno
Re: Contributing and Shame [Was: Lenovo notebooks?]
Otto Moerbeek wrote: On Sat, 28 Oct 2006, Breen Ouellette wrote: I honestly do not know as I do not have access to the size of the user base nor the financial needs of the project. If 5000 users gave $100 per year to the project that would be half a million dollars. Are there 5000 users? Is half a million per year more or less than the project earns now? Half a million seems like a lot, but it only represents 10 developers on a yearly salary of $50,000, and I personally feel that there are developers that are worth at least that much for a full time contribution. Do the paid developers currently take more or less salary to work full time on OpenBSD? How much of the yearly budget needs to go toward hardware purchases? Operating expenses? Does Revenue Canada get its dirty little fingers into this? There are too many unknown variables to answer this. There is one known factor, though: almost all developers work as volunteers, the project does not pay salaries (there have been exceptions, but I'm talking about the current situation). Some developers work for companies and do OpenBSD (related) stuff in their work time, but in general, developers work in their spare time. The exception being Theo, of course. That is why I went with what I believe is a fairly conservative number for the user base, although it is a wild guess. But it seems that 5000 people could make an impressive difference to project funding if they were so inclined to donate a mediocre amount on a yearly basis. Based on the DARPA funding days, did having more developers on salary help the situation? There comes a point where throwing money at a problem doesn't help anymore, but I have never seen a concrete financial goal for OpenBSD so I don't know if there is one. Perhaps a donations thermometer on the front page, with appropriate links to Project Goals or Donations listing specifics of how additionally raised funding will be applied, would give some people more incentive to donate. This kind of thing can light a fire under some people. I would equate it to the vendor mailing campaigns. A lot of us wouldn't write emails if Theo didn't tell us where to send them. Once he provides a direction, though, the emails start flying. Maybe the same would be true with money! It seems like a fairly low impact way to try and boost donations, at any rate. Breeno PS - This topic came up back in 2003, but the thread degenerated into an argument about 'selling printed copies of the BSD license on shiny paper for $500 a pop'. The point was also made that some people will not change their donating habits if there is a donation meter. I actually fall into that category. However, I am open to the idea that not everyone falls into that category, just as not everyone falls into the CD-buyer category. Some people need a little convincing - which a meter plus goals might achieve. Since this is squarely in Theo's court - sorry in advance if this is still an idea that you have no interest in implementing.
Re: Contributing and Shame [Was: Lenovo notebooks?]
Tobias Weingartner wrote: In article [EMAIL PROTECTED], Breen Ouellette wrote: I feel that if the user base can meet the financial needs of the project then the user base is doing its part. Unfortunately, I know of several people who use OpenBSD that will never send in a flat penny. These are the same people that have 2TB of disk space on their main desktop, running a pirated copy of Windows XP, with 2000 CDs and DVDs of pirated music and movies sitting on their bookshelf. They feel that everything that isn't nailed down should be free. I believe that you mean they feel that anything that is not nailed down is free to be stolen. There is quite the chasm between free and stolen property. Indeed. That sums up the attitude very nicely. Breeno
Contributing and Shame [Was: Lenovo notebooks?]
Eliah Kagan wrote: That would still be most OpenBSD users, wouldn't it? I honestly do not know as I do not have access to the size of the user base nor the financial needs of the project. If 5000 users gave $100 per year to the project that would be half a million dollars. Are there 5000 users? Is half a million per year more or less than the project earns now? Half a million seems like a lot, but it only represents 10 developers on a yearly salary of $50,000, and I personally feel that there are developers that are worth at least that much for a full time contribution. Do the paid developers currently take more or less salary to work full time on OpenBSD? How much of the yearly budget needs to go toward hardware purchases? Operating expenses? Does Revenue Canada get its dirty little fingers into this? There are too many unknown variables to answer this. I feel that if the user base can meet the financial needs of the project then the user base is doing its part. Unfortunately, I know of several people who use OpenBSD that will never send in a flat penny. These are the same people that have 2TB of disk space on their main desktop, running a pirated copy of Windows XP, with 2000 CDs and DVDs of pirated music and movies sitting on their bookshelf. They feel that everything that isn't nailed down should be free. As a non-developer, I feel that *whatever* I do (short of becoming a developer), I am not giving back in kind for the high value that I have received. Yet this makes me feel grateful (and somewhat humbled), not ashamed. While I can definitely relate to your feelings of gratefulness, OpenBSD isn't merely given away as a kindness to the user base. It needs to be open and free to meet the goals of the project. If it wasn't as open as it is then it wouldn't be as secure as it is. And what is the shame in taking something for free and not reciprocating when someone gives it to you for free and makes clear that there are no strings attached and that they want it that way? The shame enters the picture when you place expectations for additional output from the people giving freely. I see people griping all the time for this or that feature, or support for this or that hardware. I see this from people who contribute nothing and never will. People complain that certain hardware is not supported very well, but have they ever written even one email to the vendor demanding open documentation? These people should be ashamed, but of course they never will. I agree with everything you say in principle, I'm just not convinced it is the best position to take on the matter. I wish people and companies who use OpenBSD would recognize the value they receive and contribute back accordingly to ensure that the project can continue on to bigger and brighter things. But... wish in one hand, shit in the other, and see which one fills up first. Breeno
Re: Contributing and Shame [Was: Lenovo notebooks?]
Eliah Kagan wrote: On 10/28/06, Breen Ouellette wrote: The shame enters the picture when you place expectations for additional output from the people giving freely. I see people griping all the time for this or that feature, or support for this or that hardware. I see this from people who contribute nothing and never will. I see what you're saying. On the other hand, I'm not sure the shame is less justified when people who do contribute place expectations for additional output from the people giving freely. In fact, whether or not such a person donates seems totally irrelevant to their placement of unjustified expectations. I agree with that totally. I just haven't encountered a person who donates and treats it as a 'fee for future services', although I imagine such people must exist. I am certain they would be shamed on the lists. People complain that certain hardware is not supported very well, but have they ever written even one email to the vendor demanding open documentation? These people should be ashamed, but of course they never will. These people should be ashamed (if indeed it is ever true to say that someone *should* experience some emotion...which it is not) because they fail to exercise their own autonomy, instead begging others who they see as being in positions of authority to magically fix the situation. This has nothing to do with loyalty or duty to the OpenBSD project, monetary or otherwise. I disagree with this because OpenBSD developers have made their goals clear, and magically fixing every problem thrown their way, especially fixes for lazy/stupid problems, is not one of those goals. However, I often see Linux or FreeBSD people writing about capturing a larger user base by being receptive to the user base needs, and talking as if they have to bend over backwards to try and accommodate user requests to grow market share. I don't feel that Linux users whining and complaining about 'missing' (aka unnecessary, superfluous) features is shameful behaviour because it seems to be expected behaviour in these communities, or at least segments of these communities. I also disagree with your position because shame is not just a feeling - it is also an action. Since shame may be inflicted by a community at large on individuals which go against the culture of that community, it is within reason to say that the behaviour we have been discussing is shameful in the OpenBSD community. When someone comes in and complains about something unreasonable to the OpenBSD community at large they are often publicly shamed on these lists. That same behaviour of expecting magic fixes, if it were applied to a larger community like that of North America (sorry if you aren't from this continent), would not be shameful in the least. People in North American culture whine and complain for fixes from higher authorities (governments, legal systems, corporations, gods, employers, unions, and on and on) all the time without being shamed by those around them. In fact, in most cases those around them agree wholeheartedly. How many people in North America are proactive in their daily lives? I believe the number is very few. In my wife's home town in mainland China there is a plaque on the temple. It lists the names of the heads of every household in the town and how much money has been donated by that family for the upkeep of the temple. Those who donate little to nothing are shamed by others in the town. People will refuse to talk to them, or do business with them, or help them in any way. They are called names and ridiculed where ever they go. It is a powerful incentive for people to donate for the upkeep of the temple, and people will put themselves in debt to make payments and avoid the shame. It works so well that it is dysfunctional. Should people who do not contribute to OpenBSD be shamed in this manner? Probably not. It seems to lead to very insular communities with serious problems (at least from what I have seen in China). However, if we define new ways to shame those who deserve it, beyond badmouthing them on this list, it could be beneficial to the OpenBSD project. Theo has shown some success in shaming companies about their restrictive policies. Perhaps there are other ways to use shaming to the advantage of the project. Of course, it is a dangerous tool and could become a major problem for the project as well. Breeno
Re: Lenovo notebooks
Johan P. Lindstrvm wrote: Shame on everyone who dont buy their CD's. Try it out from a local FTP and when the time comes, twice a year so far, get your release on CD, plenty of nice stickers and the artwork is always amazing. I never buy the CDs because I don't have a use for them. I agree that, like everything else about the project, they are of a very high quality. It's just that I'm a minimalist. However, I do donate to the project regularly. There have been a few years where I haven't, but unemployment coupled with medical bills can be a bitch. I think your statement may be a little too broad. Not everyone who avoids the CDs deserves shame. It's the people who only take from the project, and never give back in kind for the high value that they have received, who should feel ashamed. Breeno
Re: GPL = BSD + DRM
Han Boetes wrote: Heey Theo, Why don't you tell _him_ to shut up? I'm going to go out on a limb here... I think Theo has better things to do than spend all day telling people to shut up on [EMAIL PROTECTED] He reserves it for only the most special of posts. Of course, I could be wrong and Theo could tell me to shut up at any moment. :) Breeno
Re: bsdstats.org WOW
Miod Vallat wrote: For historical reference, info taken from bsdstats.org: [...] What is the point discussing completely bogus so-called statistics? At best, I would suggest that some are proud to be OpenBSD users. At worst, I would say that being an OpenBSD user gives some people an excuse to ego stroke. Call it ego masturbation, if you will. Stats like this are the porn they use to get off. The reality is probably somewhere in the middle, but it is no different than cheering for a sports team. Whether or not the stats are accurate, some people seem to feel a need to cheer on the work of others in an attempt to claim a piece of the fame for themselves. I really seem to be on a roll this month. I'm sure I'll insult at least a couple dozen people with these comments. :) Breeno
Re: bsdstats.org WOW
Clint M. Sand wrote: On Thu, Oct 19, 2006 at 12:04:45AM -0600, Breen Ouellette wrote: The reality is probably somewhere in the middle, but it is no different than cheering for a sports team. Whether or not the stats are accurate, some people seem to feel a need to cheer on the work of others in an attempt to claim a piece of the fame for themselves. This might be true if a goal of OpenBSD was to be the most widely used OS. It's not. Next month FreeBSD might be the most widely used. Using your logic we should be sad. Who cares. OpenBSD is not for everyone and we like it that way. I agree 100% with you. Just forwarding my belief on why OTHERs care about these kind of stats. Breeno
Re: blobs are bad
Theo de Raadt wrote: Why do some people feel the need to make up utter bullshit defences for the vendors, when there is not one ounce of fact to back it up? Why? I think that might be my fault. When I ASKED earlier this month if it was a possible excuse, it might have been picked up and run with as a theory. I looked at some of the docs that people forwarded to me and it seems unlikely that said documentation could actually make a patent case any stronger. I should have closed off the thread by saying as much. Anyone who read the full thread and followed through to the example docs should have come to the conclusion that it was a bad hypothesis. A hypothesis labeled as a theory only does harm. This hypothesis has been proven incorrect, which makes it even worse to label it a theory. If people accept this 'theory' as credible, and if Intel neither confirms or denies it, then people will accept it as a valid excuse for why Intel doesn't release docs. We shouldn't be making excuses for Intel. Trying to use it as a tool to shame Intel about their bad behaviour will not work. A corporation does not feel anything, let alone shame. So, to bring this topic to rest: the example hardware documentation which was linked in a previous thread DOES NOT INDICATE that such documentation could be used to bring lawsuits against a company. Such documentation as I have seen only shows how to utilize the hardware. It does not disclose how the intellectual property is implemented, which is what would be required to bring a lawsuit. People who say otherwise have failed to do their homework, or they are liars. I regret bringing up this topic in the first place. In the future I will try to be more clear that I am asking a question, not forwarding theories, and I will follow through to the thread conclusion with the results of the question. There are no valid reasons for Intel requiring NDAs for their hardware documentation. Every single theory and excuse has been proven incorrect. Until Intel provides such documentation they deserve only our contempt, and to have our dollars flow to the competition. Breeno
PF binary search tree
From: Daniel Hartmeier (danielbenzedrine.cx) Date: Wed Dec 12 2001 - 08:31:08 CST On Wed, Dec 12, 2001 at 03:08:37PM +0100, Nicolas Prochazka wrote: With OpenBSD 2.9 and ipf , our internet connexion was down due to a ip state overflow. (the default IPSTATE_SIZE was near 4000) and we increase to 7069 to solve the problem.) but perharps is not the same issue with openbsd 3 + pf ? pf uses a binary search tree instead of a hash table, which doesn't require pre-defining a maximum size. The tree will just grow until memory allocation fails. With 64MB RAM that typically doesn't happen until you have over 6 state entries. Daniel I have been doing some research and I came across this message from some time ago. Is this still relevant? If so, can anyone tell me if the PF binary search tree is more or less memory efficient than the ipfilter hash table? What is the fallout if PF cannot allocate anymore memory for the binary search tree? Does it drop connections or puke all over? I am trying to convince my current employer to move away from ipfilter and over to PF. Any assistance would be appreciated. Breeno
Re: blobs are bad
Theo de Raadt wrote: But Craig, it's the same with women. They'll only hang out with you if they feel there is enough positive vibe in you. And since you so clearly show that you are a pessimist at heart, you're out of luck too! If you keep saying something good won't happen -- well then you can bet it won't happen. Theo, you aren't planning on becoming a motivational speaker, are you? ;) Breeno
Re: RMS vs TdR (WAS: Re: OLPC)
Shane J Pearson wrote: You find a lot of things obvious for a guy who is so presumptuous. For the record, I respect the intentions of RMS and I highly respect the intentions and practical thinking of Theo, the OpenBSD project, the developers and much of the user base. I've been enjoying OpenBSD since 2.5 and I try to buy OpenBSD items and donate whenever I am financially able. I tried to donate brand new SCSI disks when Theo asked for them for the older machines and I purchased a brand new SCSI card for an Aussie developer and had it sent to him, while I was mostly unemployed with small funds. My intentions are honourable here. I messed up by touching something that could be controversial. But really, I was pro OpenBSD in an OpenBSD list. So shoot me. If you are referring to me (which I think is a safe assumption based on your quoting), then you've read way too much into *my* opinion. I'll be careful in the future to try to avoid accidentally becoming the catalyst to the few overly sensitive folks here. Hmm. Let's see. Jack's original post is listed in its entirety below. I do not see any quotes around the word interesting. If you read it then you may agree that his meaning is obvious, you may not. However, it was followed up by three posters, one of which was you responding to further messages downstream from the original post, where two of the posts make comments which could be considered disparaging, and which could also reasonably be seen as leading towards a greater debate over the merits of the celebrities behind two groups of software licencing thinking. I've seen that more than once on this list and it goes nowhere, and yes, I am sensitive about it because I have never seen a single positive thing come from it.. It is merely a waste of bandwidth and the time of list readers. So yes, I posted an abrasive message to the list in an attempt to curb such discussion from taking place again. Around here, ego bruising tends to get better results than asking nicely. Anyone who sticks around after having made several posts to misc@ is probably someone who is genuinely interested in OpenBSD. :) I would never accuse a poster otherwise unless they were being absolutely crystal clear that they don't support OpenBSD. Where your particular misunderstanding seems to come into play is where you see Jack reference his earlier message, the one posted below, by quoting the word interesting. He was not implying anything. You either missed part of the thread or were fishing for an argument. It seems more likely that you missed part of the thread considering you take sole ownership of my previous negative comments. I would merely offer that you re-read the entire thread and consider that you may have not been the focus of my attention. Jumping into the middle of a thread without understanding the entire context is a recipe for disaster. In any case, you have made your intentions clear. Whether I was referencing you, another poster, all of you, or anyone who was thinking about joining into the thread and fanning the flames, well, I will leave that as an exercise for the reader, should any such reader care to waste any more time on this topic :) Breeno PS - I would avoid bringing up donations as a way of indicating that you are supporting the project. If you dig back in the lists you will find a post I made to another list, ports@ maybe, asking a question with the request that replies be sent to my email as well as the list, as I was not subscribed to that list. I got slammed for not supporting the project by participating in the list. I replied that I participate in misc@ instead because I can actually be useful there (sometimes) and that I donate to the project. I was then accused by several parties of attempting to buy help by bringing up my donations, when I was merely trying to indicate that I *DO* support the project in the ways available to me, as you did above. Just a friendly warning from someone who has already been burnt. It really is amazing just how much drama there are on these lists considering their intended purpose. List: openbsd-misc Subject:Re: OLPC From: Jack J. Woehr jwoehr () absolute-performance ! com Date: 2006-10-10 16:21:45 Message-ID: 1415ECD7-F7E8-4127-8DF3-A04EF94E7F61 () absolute-performance ! com [Download message RAW] On Oct 10, 2006, at 9:38 AM, Theo de Raadt wrote: Some of you may have been following the OLPC discussion. Here is one place you can read more about it: http://www.thejemreport.com/mambo/content/view/286/ The differences of opinion between Theo and RMS are at least as interesting as the differences between either one and OLPC / the chip vendors! -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Intel breaking patents - related to closed documentation?
I just spotted this in the news: http://news.com.com/Transmeta+sues+Intel+for+patent+infringement/2100-1006_3-6124965.html?tag=nefd.top If Intel makes a habit of stealing patented technology would open access to their hardware documentation then make it easier for the patent holder to sue? The reason I ask is that I am merely trying to understand if Intel's real motivation for NDAs could be to protect themselves from lawsuits if they are stealing IP. If any developers are willing to comment that would be great. I've never seen hardware documentation from a vendor so I don't know what it usually contains. Thanks. Breeno
RMS vs TdR (WAS: Re: OLPC)
Jack J. Woehr wrote: On Oct 10, 2006, at 5:38 PM, Shane J Pearson wrote: By interesting, you mean one is well meaning, but a little kooky and not always in touch with reality and the other is focused and committed to maintaining some sanity in the world of computing? No, I didn't mean that. I meant that both gentlemen are personal friends of mine and that the contrast between these two giants of free and open source software could hardly be more striking. Obviously there are elements trying to start an RMS/GNU versus TdR/BSD holy war. If you don't find it interesting that two men could take a stand for free and open ideals, and yet interpret those ideals so differently, then fine, it isn't interesting to you. Thanks for sharing, I guess. I don't find it very interesting myself yet I don't feel the need to tell the world, but that's just me. Maybe you've got it all worked out as part of your life plan. If you don't like RMS (or TdR for that matter) or his version of free and open ideals, then fine, you have the right to feel that way in most locales. I'm not particularly fond of RMS' views and ideas myself. But when you reply to the original poster's message feigning that you don't understand his point, well, then you come across as stupid. An inquisitive child could understand the difference between these two mens' views, and understand that some people might find it interesting. Really, truly stupid. And willing to share it with the rest of the world on a public mailing list, no less! Brilliant! If you want to start a holy war about the merits of these two positions then start a thread, preferably somewhere else, and howl into the wind. Nobody cares. We've all made up our minds about which side of the fence we are on. You aren't going to change my mind, or anyone else's. You are only making yourselves out to be a bunch of idiots. This sure doesn't help the image of the OpenBSD user base at all. When we aren't taken seriously it is, in part, because of childish melodrama like this thread. Breeno PS - Jack, some friendly advice, you are only encouraging them each time you reply. They obviously don't care about why you find interest in this subject. They only want to find a way to link you to RMS and then trash you.
Self Restraint (Was: Re: GPL = BSD + DRM [Was: Re: Intel's Open Source Policy Doesn't Make Sense])
Han Boetes wrote: You lie. You insult. You threaten. I'd love to meet _you_ in person too. Well I have met him (Theo) in person several times, and I think he's a pretty stand up guy. I've never known him to lie, but insults and threats usually flow freely when he feels the behaviour of others warrants it. I don't know you, Han, but you have been on this list long enough to know that most of the time your opinion is in the minority, sometimes even a minority of one. There's nothing wrong with that, you are allowed your opinions in those places that value freedom, and many of us on this list come from such places. However, given the long list of threads where your opinion is not shared by most of us, you may want to think about self-imposing a limit of technical discussion only while on OpenBSD lists. This is Theo's sandbox (I know there are others in the project, but Theo is the manager, lets not start that argument again), which means he is gracious enough to allow you to remain even though he has made it obvious that he doesn't appreciate your opinions. If nothing else, he is true to his word about being open. Most others would have banned you by now. I don't want to discuss this with you because there is nothing positive that would come from such a discussion. I'm just trying to point out that there is nothing being gained any time you clash with the list. Hopefully you will see reason in restricting the content of your posts. If not you will simply be added to my block list, as I suspect others have already done, which will not benefit you in any way. Breeno
Re: Intel's Open Source Policy Doesn't Make Sense
Wolfgang S. Rupprecht wrote: a) Intel doesn't own the technology, but licensed it from another vendor. The licensing terms don't allow Intel to release full details. b) Intel has agreements with other customers/vendors to not release information about a particular piece of hardware. c) Intel doesn't feel that it's worth the cost to provide information for driver developers. d) There are so many patents issued for obvious techniques used in computer peripheral chips that releasing documentation might tempt an ethically challenged company to sue them for royalties. Intel has been on record as stating that patent issues are now a significant problem for them. -wolfgang That's just their way of saying that AMD is patenting technology that Intel has to licence, and that is just so very terrible for them. I mean, shame on AMD for taking the shiny toy away from Intel. :) And seriously, is Intel insinuating that they are using patented technology without licencing it? That seems rather bogus to me. Ignorance of breaking the law does not waive their liability under the law, and if they get caught in this kind of lie then I hope the legal system stomps all over them. It would serve them right. If Intel doesn't like the patent system, then they can lobby against it. But they are just a hair's width shy of admitting guilt if they actually make arguments like the one attributed above. Breeno PS - before I get accused of being a 'commie' in this latest round of discussions regarding bad corporate behaviour, I'd just like to say that it was my understanding that believing the law should not be broken is not how you define a communist.
Re: Open source support for Intel wifi chipsets
Theo de Raadt wrote: As far as I am concerned, yes we can email and complain, but they are so arrogant that nothing will change. Arrogant people change when their arrogance is too publically displayed. Not only that, but arrogant people leave their jobs and sometimes the replacements aren't as arrogant. Intel is no different than any other company. Give it enough reason to change and it will. Dollars are the lifeblood of any company, and as Intel continues to lose more and more dollars in the current environment, you might be surprised to find that they change their tune. They haven't existed this long by being inflexible. If it doesn't work out this time, the exercise still sets a very good example of which other vendors will take notice. It's only 15 minutes out of your life to be sure that Intel is still aware of your concerns, on the off chance that they will listen this time around. Given everything that the OpenBSD developers and community have done for me, I am more than willing to spend a little of my time to return the favour. Theo is calling for all of us to help out in a way that each and every one of us is capable of doing. I think we owe it to him, to those he represents, and to ourselves. Breeno
Re: Intel policy wrt OSS [was: Re: cvs.openbsd.org: src]
Theo de Raadt wrote: Majid Awad at Intel has stated to developers that he is the current person who is responsible for this particular area. So go ahead, let him know how you feel about this. Again, his email address is [EMAIL PROTECTED] So let's win back the rights to run the hardware we purchased. Theo, in the past you have asked that we CC you with any messages we send off to the offending company. Do you want this to happen in this situation as well? Breeno
Intel Open Source Policy
Mr. Awad, I have recently become aware that things are still not progressing within Intel regarding the less than friendly policies your company has towards open source projects. This is not the first time which I have indicated to your company that I oppose these policies as a consumer, and I am saddened to hear that Intel refuses to make good on the evangelism of Intel personnel who have recently been stating that Intel is open source friendly. To become truly open source friendly, I suggest that Intel needs to adopt these two simple policies: - Provide a simple and completely open method by which open source projects may redistribute firmware for Intel products. As it stands, firmware redistribution licences either require the consumer or the open source project to needlessly give up rights to be granted a redistribution right. This is now clearly at odds with the majority of other players in the industry, and it is a continuing thorn in the side of the open source movement. Additionally, it seems that Intel is more than willing to redistribute firmware freely when it corrects a major quality issue, so there is much displeasure within the open source community that Intel is only willing to open up to avoid a consumer backlash. We are beginning to think that we should induce such a backlash to move this issue forward. PLEASE NOTE: we are not asking for access to the source code of any Intel firmware. We merely want the unrestricted ability to redistribute firmware within our projects. - Provide complete and open documentation for Intel hardware so that our developers may create reliable open source drivers for Intel products. Without documentation, our developer community must resort to reverse engineering of Intel products, which does not result in code which is of the same high quality as that which is created through the aid of complete documentation. Again, this is an area in which Intel is clearly outside the majority. It seems unfathomable that Intel would allow itself to be put into a position where a consumer would mistake a poorly reverse engineered driver for a poorly produced Intel product, yet this is taking place right now due to Intel's failure to open documentation fully. PLEASE NOTE: we are not asking Intel to supply source code for their currently existing software or any future software. We simply want access to the same hardware documentation that Intel's own development team has access to, and we want that documentation to be provided in a manner which does not tie up our developers in NDAs or other legal instruments which strip them of their rights. When Intel chooses to comply with these requirements then Intel employees will be able to truthfully make the statement that Intel is open source friendly. As it stands, any attempt by Intel at this stage to paint the company as open source friendly will likely result in the open source community making statements refuting this as, at best, incorrect. It is highly likely that Intel will be painted in a much more negative light - and rightly so, since the open source community would have to be on board for Intel to actually be considered friendly to it. I am speaking merely as a consumer - my only association with open source projects is as a user and financial contributor. However, since I first became aware that Intel was not supporting open source development, I have since ceased the purchase of all Intel products, and I currently advise all my personal and business contacts to avoid Intel as well. Within the company I work for I try to educate all purchasing agents as to the situation because we use open source software in several facets of our business. I know that I am not the only open source supporter taking this action, and I am sure that it is having an effect on Intel's bottom line. Should Intel correct this behaviour in the future, I will be sure to change my stance towards the company and make all of my contacts aware of the situation. Hopefully Intel will be able to come to a decision which will benefit both Intel and the open source community. Sincerely, Breen Ouellette
Re: The future of NetBSD
Whyzzi wrote: On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: what my point is, though, is if we aren't willing to accept 'vendor written drivers', then it is *we* that are limiting our growth but limiting what hardware we can run stably on ... Sadly, you've twisted the point in the wrong direction. Since we aren't willing to accept 'vendor written drivers', those vendors don't deserve our advocacy or our dollars. *We* did not limit our growth, the vendors limit theirs: by not being able to sell to our market. Time and Again I've seen the OpenBSD team make a request documentation in order to make drivers, time and again I've seen that request denied. Simply put, the vendor is closing their door on a chance to make more revenue and thus increase profits for their company by not providing the correct documentation to open source developers. Not only that, but since when is it part of OpenBSD's goals to meet some sort of growth projection? In particular, it is stated on the Project Goals page of OpenBSD.org: Pay attention to security problems and fix them before anyone else does. This cannot be achieved by allowing closed source / closed documentation into the project. It's Open BSD. It only makes sense that the project supports hardware vendors which support the project goals. We don't need every vendor to recognize that it is in their best interests to support the project goals, but we definitely DO NOT want to imply to vendors that we will compromise those goals. We are the customers - and when the vendor loses sight of what customers want, they lose sales and another vendor moves in to fill the void. If we don't make it clear that we want open documentation then no one will provide it. The market is dynamic - just look at any stock exchange! Use that to your advantage and don't support closed vendors. I don't know why so many projects appear to be centered on the idea that they need to outstrip the user bases of other OSes. If it works for you then use it (and support it, financially if you cannot support it any other way!). If it doesn't work for you then go find something that does. Who cares how many other people are using it? Worry about the goals of the project and the results (vendors getting on board, a larger user base, etc.) will follow. I think it is likely that the user bases of certain projects don't want to take responsibility for their hardware purchases, and as a result have hoodwinked the developers into making poor decisions about project goals. The users want to go out and buy any part and have it just work. They don't want to do any research first to make sure it is the right purchase. They want to close their eyes to reality and instead hope that the companies selling hardware will do the right thing, when it flies in the face of common sense for an entity whose entire purpose is maximize shareholder profit to do the right thing. It is a typical case of consumer apathy, and the projects that cater to this apathy will only hurt themselves in the long run. They will grow unmanageable projects which constantly break, and that breakage will be outside of the control of the developers and in the hands of hardware vendors trying to push new products. Dozens of messages on this topic and it is merely doing what I predicted it would do - wasting the resources of the OpenBSD mailing list. Nothing is being solved by this discussion, and the very little of it that deals with OpenBSD only does so in a roundabout way. Breeno PS - KILL THIS THREAD. Stop replying to it and it will go away. There never was any point to it which affected OpenBSD. The woes of a subset of NetBSD devs / users do not affect OpenBSD. If NetBSD ever did die as a project then the user base would move on, the devs would move on, and new developers would move in to tackle new projects and pick up slack. Open Source is a dynamic environment and change will not kill it. Change is unavoidable but people adapt to it.
Re: SSH login slow troubleshoot Techniques
Siju George wrote: Hi, My OpenBSD 3.9 on an amd64 is very very slow for SSH login. As already mentioned, if reverse lookup doesn't work your login will pause for a substantial amount of time before you are prompted. Assuming this is a network under your control, if your LAN is small you could just update the hosts files on your machines. If you have more than a few machines on the network, or a heterogeneous network where it isn't as simple as copying around a hosts file, you might want to look into using DNS internally. There have been a few times where my ISP has had DNS trouble which downed large numbers of their customers, but my machines were able to continue right along with no problems because of my internal DNS server. There's a little more work involved in setting it up, but once you read the man page for named and the BIND 9 Administrator Reference Manual (free PDF download) it comes together pretty quickly. I use an invalid TLD of .int to make sure I don't collide with a domain in the outside world, which has never failed me for internal use. You may even want to use DHCP to assign static IPs by using host declarations which assign a fixed-address to each host based on the MAC address. But I digress. Breeno
Re: Soekris
Nick Holland wrote: The thing could still be a frustrating first OpenBSD system for someone. It's a great machine for what it is...but not as a Welcome to OpenBSD system. My overall recommendation stands. Get used to OpenBSD on familiar hardware, then get used to unusual hardware with an OS you are familiar with (preferably, OpenBSD. :) I'd also say you are right in that assessment, with the possible exception - if the original poster is using a hard drive with a Soekris then the only functional difference between it and a desktop computer will be the lack of a video card in the Soekris. As stated before, an older used system will cost next to nothing, which will more than offset the additional costs incurred due to higher power requirements. Unless you NEED the Soekris it is just an overly expensive toy. Breeno
Re: The future of NetBSD
Charles M. Hannum wrote: [I'm CCing this to FreeBSD and OpenBSD lists in order to share it with the wider *BSD community, not to start a flame war. I hope that people reading it have the tact to be respectful of their peers, and consider how some of these issues may apply to them as well.] This is completely irrelevant to OpenBSD, except in that it seems to vindicate Theo de Raadt for the crap he went through when he was ousted from the NetBSD project. What possessed you to post this to an OpenBSD list? Now, thanks to the cross posting, the misc@openbsd.org list gets to endure a bunch of cross posts from NetBSD users and FreeBSD users on topics which are completely outside the scope of this list. Great. If you don't like the direction (or lack of it) that the NetBSD project is taking, and since your post indirectly talks up nearly every aspect of OpenBSD that Theo implemented to escape the problems he encountered with NetBSD, while simultaneously talking down a lot of the politics within NetBSD that Theo has complained about, maybe you need to take your reasoning one step further and follow Theo's lead - fork NetBSD. Whining on *BSD lists is not going to get you where you want to go. You might as well pray to a god to send NetBSD a messiah. If you want a leader then be a leader. I could go on, but then I am just exacerbating the problem. This really isn't relevant to OpenBSD, and I urge other lists' users to consider whether CCing your reply back to misc@openbsd.org is relevant. Thanks in advance for your consideration. Breen Ouellette
Re: News From HiFn
Peter Philipp wrote: On Wed, Jul 12, 2006 at 09:45:19AM -0600, Bob Beck wrote: (I tried to shut up and not continue this thread but you've sucked me in...) Well I tried to shut up too, but Travers sucked me in, who was sucked in by another guy who was uhm.. 3 weeks late after the thread sorta died? This is the thread that never ends, yes it goes on and on my friends. Some people started ranting it, not knowing what it was, and they'll continue ranting it forever just because... Breeno
Re: News From HiFn
J.C. Roberts wrote: This should take care of any of the long standing issues OpenBSD has had with the HiFn's procedures for releasing documentation. This is good news. Thanks for your contribution! To all the nay-sayers out there: this proves that sometimes companies do 'get' their customers' wishes. Consumer action does work - as long as the consumer actually gets involved. While you might not always be able to get the attention of companies through consumer action, apathetically accepting the status quo guarantees that you never will. Thanks to everyone who got involved - you proved that somewhat open is no more acceptable than not at all open by bringing Hifn on board. Breeno PS - Someone who participates in editing vendorwatch.org might want to update the Hifn status page.
Re: News From HiFn
Theo de Raadt wrote: I will ask this honestly: Why should we bleed our little hearts over a company who acted like assholes towards us for years, and only changed their policy due to public pressure? To make ourselves feel better? I think it is pointless. They still did not apologize. I agree with Theo, and yet I agree with others who subscribe to the 'reward for good behaviour' line of thinking. I think the issue is one of perspective, and the scale for rating companies over at vendorwatch.org is too simple. Obviously for the developers it is frustrating that they have to push and push and push for years with no results, only to blow up and cause a community outcry which finally gets the vendor to open up. In the meantime, Theo has been painted (again) as abrasive, whiny, thick-headed, and who knows what else by the larger Open Source community, thanks in large part to outlets like Slashdot which present a snapshot which completely fails to report the scope of this ongoing problem. And now that the docs are open again, there will be pressure on the OpenBSD team to fix the errors in the Hifn code - for a product which has been a source of frustration for quite a while. When one thinks about it one should be able to sympathize with the developers a little more than the companies which jerk them around. For the users who jumped on the bandwagon less than four weeks ago it seems like a great victory. For the developers it's not so easy to set aside the hassle they've gone through and pound on that code. A primary motivation for the developers is, after all, to have fun working on code. And still, if companies that do respond favourably after a public outcry continue to get badmouthed after the fact, there won't be much incentive for companies to open up in the future. We do need a way to recognize that something positive came about after putting up with a lengthy negative period. What does 'Somewhat Friendly' mean, anyway? To turn the tables, if OpenBSD was rated on the same system, would it be 'Friendly', 'Somewhat Friendly', or 'Unfriendly'? And what relevance would that have? The developers may not be a bunch of hand holding saps, and could be rated as 'Hostile' on occasion, but that doesn't change the fact that OpenBSD is a kick ass system governed by some very strong goals and philosophies. I think we need a more objective rating system. Here's a five point system which is more useful: 'Supplies Hardware', 'Donates Money', 'Supplies Docs Freely', 'Works Well With Developers', and 'Listens To Customers'. This is not necessarily the rating system we should use, but it seems to me to be a step in the right direction. A major issue is ensuring that this process works with developers which working against them. Theo et al are busy working on OpenBSD and they don't likely want to spend all their time complaining about vendors on vendorwatch.org. However, their participation is necessary to ensure that vendorwatch.org meets its mandate. Hopefully the process can be improved. We turned around Hifn in under four weeks (I expected it to take at least four months!) with a heated mailing list discussion and some poorly organized free press. Think of what we could do if we had a smoothly working process which put everyone on the same page! Breeno
Re: News From HiFn
Theo de Raadt wrote: So they gave us docs. Now we need to say they are nice? No way. They have received money from hundreds of you. You are customers. They are a company. Now if you (like them) cannot figure out what that means, that they have a RESPONSIBILITY to their customers, and that they only responded once their CUSTOMERS complained, then I mean, come on -- please don't give us advice on rolling over and playing lame. 95% of the planet does nothing to complain when there is a serious problem with a company, and then when 5% of the people complain enough to force them fix it, you wish to congratulate the ... company? Theo, do you consider this a gain or a loss? Or is it merely regaining lost ground? As a developer your point of view is different than many of the ordinary users on this list. In what direction do you think this should go? What balance do you think should be struck between holding companies accountable for their past transgressions and rewarding them for moving in the direction we want them to go? And finally, do you really care about getting an apology from Hifn? It seems rather meaningless considering that a legal entity can't feel regret. What do you really want? Looking forward to your thoughts. Breeno
Re: Hifn policy on documentation
Siju George wrote: I 've been told by people ( more than one ) off list how *uncivilized* it is to forward *private* mail publicly *even when it has some bad content*. I wouldn't sweat it too much. It would be one thing to bait him by first promising not to go public with his mail and _later_ taking it public, but it seems unreasonable to expect that an aggressive, unsolicited email will be kept private by the receiver. If someone sends me a crazy-angry email like you received, the first thing I do is get it on the public record. If you don't want to be judged on something you have written unsolicited in anger, then do not send angry, unsolicited email! Just yesterday Poul-Henning Kamp reposted to soekris-tech select parts of private email replies which I made to him regarding the Hifn debate. He chose to repost only those parts of my messages for which he had snappy answers, failed to disclose the remainder of my messages, and then ended the discussion by implying that I was a communist. In the same sentence he also implied that my world view is uncompromising, while it was obvious that in his own world view he is ultimately right and a difference of values is not possible - disagreeing with him makes you wrong by default. Discussion over. The weirdest part is that he was backing up someone who wanted me to take my rhetoric off list, so I responded to him in private and then he selectively replied back to the list. Go figure. It wasn't even worth mentioning until you brought up this somewhat similar situation. Ultimately, people will weigh the facts and decide what they want. Many people will feel that you did nothing wrong, just like many people will read Mr. Kamp's public responses to my private messages and realize that he is not presenting the whole picture. I'm sorry that some people convinced you to back down on your position, but for what it's worth I thought you did the right thing by posting the Cohen reply. I actually felt that your original message was too strongly worded and that Cohen had good reason to be angry, but, on [Cohen's] own account or otherwise, it was damned unprofessional of him to respond in private as he did. He should have posted a professional message to the list requesting a retraction of the accusation that he was lying, barring contrary evidence of his honesty. It actually ended up reinforcing my perception that they lack a pulse (or maybe a soul) over at Hifn. If this is how a PR rep for the company reacts to unflattering statements, what about the average Joe in their employ? It's no wonder Theo has problems with them. Breeno
Re: cruxports for OpenBSD
Marc Balmer wrote: * Han Boetes wrote: I've been working for quite some time now on an alternative package-manager for OpenBSD, and since things start working rather fine now I think it's time to let you guys know. this is about the most idiotic wast of time I ever heard of. what is wrong with our own package tools, which at least to very dedicated and bright people work on? what's next? hls? han's own version of ls? hcat? Why does it matter? If he wants to do it then no one can stop him. If he makes something worth while then other people will use it. Deriding people for going against the status quo is kinda silly considering that OpenBSD does it quite frequently. This isn't an argument to the quality of his work as I have not evaluated it. Just pointing out that he has the right to work on whatever pleases him, and that your response seems fairly agitated given that it really has very little impact on your life. Maybe I am missing something. Breeno
Re: Hifn policy on documentation
Darrin Chandler wrote: Look, it's pretty obvious from early exchanges in this thread that these issues have been discussed by the principal parties over a fairly long period of time. How many brilliant insights have been added by this thread? More important, has this thread opened up Hifn's specs? Has this discussion accomplished anything at all? 1) The principle parties' exchanges didn't go anywhere. It is time to crank the heat up a couple of notches. If the principle parties come in and ask us to stop it will go a lot futher than you, some random person, asking us to stop. I don't see Theo complaining, and he has a far greater vested interest than you. I haven't seen other developers complaining, and the same goes for them. I haven't even seen Hifn complaining, although that would only weaken their position further. 2) It's not about brilliant insights. It is about customer dissatisfaction. People are posting so there is a record that they are not happy with the situation, and this record covers very clearly why they are not happy with the situation. This goes a long way towards punishing Hifn for what we perceive as acts which are not in our best interests as customers. The alternative is silence, which allows Hifn to continue to dupe customers. I do not want to see another person duped like this, and it is now my personal mission to do what I am able to prevent it from happening again. 3) Has this thread opened up Hifn's specs??! You expect results to take place in an unreasonable amount of time. Change doesn't always happen overnight, especially when corporations are involved. 4) This discussion has definitely accomplished something - it has created a freely accessible, mirrored record which points out some very serious flaws in the policies of a supposed security minded company. As a consumer I have relied on exactly this sort of thing time and time again to avoid bad purchases. I wish this thread had existed three months ago so I wouldn't have purchased a blasted Hifn product that sits unused on my shelf! And above all this, this thread shows that, for the most part, users are behind the policies of the OpenBSD project. This sends a clear message to the industry that we will hurt their bottom line if they screw around with us. I only wish more projects and organizations would toe this line. Breeno
Re: Hifn policy on documentation
Wolfgang S. Rupprecht wrote: I guess the part I don't understand is why are open source folks so wary of running black-box *.o binaries from a vendor but are quite eager to use blackbox crypto cards (that effectively run blackbox *.o firmware)? This is a pretty poor argument in my books. They could undermine us in the hardware, so why don't we just give them the keys to the kingdom and allow them to do it in software? HUH??? Given your argument we may as well just let them have root access to our machines. Or maybe they could install cameras in our offices and homes while they are at it. Breeno
Re: Hifn policy on documentation
knitti wrote: oh come on, this discussion is already as off topic as it can be, no need to add FUD to it. any algorithm the cards claim to implement _is_ fully documented, so you can test any output except that of the RNG against a 'known good' implementation This is a great point. However... This is not off topic. This topic definitely affects OpenBSD and serves a purpose. I do not understand why people think this is off topic. Since when was misc@ only for posting about technical problems? Talking about the World Cup matches would be off-topic. Talking about Billy Graham's last sermon would be off topic. Hifn's crappy policy and why we don't like it is definitely on topic. Breeno
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Breen Ouellette wrote: I am still going to install 3.9 on a PC and try an ssh connection which doesn't involve WinXP / PuTTY. I finally got around to it and I still get the error when connecting from a PC installed with OpenBSD 3.9 to my net4801 / vpn1411 running OpenBSD 3.9. So, just in case someone came across this thread and thought that PuTTY was the cause of the problem, it definitely is not, you can thank Hifn for this one. Breeno
Re: rate limiting an interface
Thordur I. Bjornsson wrote: Lawrence Horvath [EMAIL PROTECTED] wrote on Thu 15.Jun'06 at 13:27:54 -0700 Can i rate limit both ways, incomming and outgoing, the pf documentation for queues sd only one way, but is there a way to keep the system from downloading as much to it? so as to keep under my quota going both ways? Think about this, a bit. If you dont realize whats wrong with the notation of limiting incoming traffic to not download as much to it then well, shit. I've never tried it so I could be way off, but has anyone thought about doing the reverse of prioritizing ACKs to limit downloads? Specifically, assign the ACKs to a cbq with a small fixed bandwidth so that the source is fooled into thinking that you can't receive as fast as you really can. With a little math you should be able to come up with a bandwidth amount for ACKs that will result in the chocked download you require. Of course, this assumes that your packets are max size and that this is TCP traffic only. Like I said, I've never tried it, but it may be worth a shot. Breeno
Re: Fwd: Hifn policy on documentation
Siju George wrote: This is the mail I got from Hifn representative for my response to his mail and clarifications in misc. ... Hank Cohen On my own account. Well, hopefully this will encourage Mr. Cohen to think hard about a situation before he wallows in and posts something to a public list which is not in the interests of his customers. I would also like to point out that I never received a reply to my message. I guess that Hifn employees only respond when customers insult them on public lists. This doesn't bode well for the documentation issue. Breeno
Re: Hifn policy on documentation
L. V. Lammert wrote: BS aside, it's obvious you don't deal in US markets! While the implementation may be flawed, dealing with export regulations, silly as that may seem to non US organizations, CAN be business threatening. Not to be taken lightly. This issue has nothing to do with export regulations, this is either a smoke screen or over-reaction on the part of Hifn. No one is asking Hifn to export hardware to Iran. No one is asking Hifn to export hardware at all. No one is asking for driver source code. As someone pointed out earlier in this thread, documentation may be sent out of the USA thanks to free speech laws. If entire algorithms can be printed in book form and exported, then certainly documentation on how to utilize a piece of hardware may leave the country without restriction. The documentation without the hardware is good for nothing. It's like having the operating documentation for a private jet - without the plane you aren't leaving the ground! If anyone would like, we (as a US company) would be happy to use 'our' registration information (providing the remaining license terms are acceptable)! That probably isn't the issue, however, as the point about actually obtaining hardware is also significant to US export markets. Irrespective if the fact that more 'powerful' h/w can be obtained with no restriction, getting 'current' h/w out of the states CAN be a REAL hassle. Something tells me that this is not going to fly. It only circumvents the problem - it does not correct it. Using subversive means to bypass a ridiculous system only supports and expands the ridiculousness of the whole situation. I would guess that this is about as likely to happen as Theo moving to the US to gain access to the docs. Breeno
Re: Hifn policy on documentation
Hank Cohen wrote: I hope that this clears the air. I was hopeful too, at the beginning of your message. As I neared the end I was becoming skeptical, and by the time I clicked through to the registration page I was fairly certain where this was heading. Several posts later and it looks like I was right. I'm not the only person who puts a great deal of value on personal data. Your company's personnel seems to do so as well - I have tried fairly hard over the last week to find contact information for your executives with no success. Hmmm, imagine that! I think that you may have misunderstood your target market, or at least a portion of it. Users of OpenBSD tend to be the most cynical type of person you are going to encounter. Many of us have gravitated towards OpenBSD because we have been burnt in the past. We tend to guard our data jealously. I haven't input my personal data on a website request form for years, and I am not about to start. And I'm nowhere near as hardcore as some of the people here. We have good reason not to trust corporations - look at Enron. If shareholders cannot trust their executives to fulfill the highest duty of a corporation - to maximize shareholder profit - then how can we trust any company (which we do not even have a financial interest in) to protect personal data which we supply? We might as well be done with it and just post it to a website for all the world to see. Why this should matter to you is that we (OpenBSD users) drive sales of your product. Hifn, on the other hand, does not drive sales of OpenBSD. The dynamic of this relationship puts the onus on Hifn to cater to OpenBSD's requirements if Hifn wishes to continue to benefit from the relationship. OpenBSD requires unrestricted access to documentation, which doesn't create a conflict with the export controls of the USA. Theo will pull Hifn from the source tree if push comes to shove, and at this point I could not care less. My Soekris vpn1411 is sitting on the shelf next to my machine rather than inside of it. This is due to the fact that it does not work the way it should. I would prefer to see something good come of all of this, but if I have to trash my vpn1411 then it really doesn't make the situation any worse than it already is. At least for me. It will definitely make it worse for Hifn. If this situation does not resolve itself for the better then I will not buy any further Hifn technology. But it gets even worse: I will not recommend Hifn technology. In fact, I will speak very openly and very negatively about the company and their products. This might not seem like a big loss until you look deeper at who I know. My friends all work in the IT industry. We talk about work all the time. Several of them work for the federal and provincial governments and crown corporations of Canada. They will certainly be seeing Hifn products in a new light. One of them works for one of Canada's largest cities in the emergency preparedness department. These guys take their security seriously because they are on the front line of terrorism prevention. He will definitely listen with great interest to what I have to say about Hifn, and he will be sure to pass it up the chain. My wife works for one of the big four global accounting firms. The national IT personnel will hear all about Hifn next month at the company BBQ. My uncle owns several oil and mining companies in Canada. My other uncle was in the military and is well connected. Other relatives and friends work in government, law, accounting, and engineering all across the country. The subject of Hifn is likely to come up the next time I see each of them, as well. Now multiply my contacts by the number of OpenBSD users who take this stuff seriously (which just so happens to be the majority of them). It's not a pretty picture. I'm behind Theo 100%. The average person might consider him to be over-reacting. I would counter that the average person will never be involved in the purchase of a Hifn product. I strongly suggest that you consider who you are about to alienate before you go and do it. There is still an opportunity to make this into a positive situation for Hifn and OpenBSD. Breen Ouellette
Re: Hifn policy on documentation
Dag Richards wrote: Marc Balmer wrote: I live in Switzerland. Do I give a fuckin' rats ass for US Export Regulations? Not care about US Export Regs? But that just means you want the terrorists to win. After all our President is your President right? I think nearly everyone here is fully aware of how American influence affects the rest of the world. Using American laws as a scape goat to try and pump personal information out of developers steps right into the deep end of unreasonable legal wrangling. Hifn should realize that their target market is interested in keeping information safe and private, rather than exploiting developers for private information and using inapplicable law as a sort of defacto shield against trouble with their government. It only diminishes their reputation and perceived trustworthiness in the eyes of customers, many of whom are making or influencing the purchasing decisions for large foreign or multinational organizations. This is just another symptom of the US slide towards isolationism. External competitive pressures are increasing every year and many American institutions, both in government and private sector, are seeking to restrict the trade of goods and ideas as a band aid to fix the problem. The terrorist attacks of 2001 merely provided the powers that be the excuse they needed to push isolationism further down the throats of the American people. Anyone who has been paying attention to China in the last ten years will have a very good idea of where this type of policy is going to lead the US economy. The sickest part is how China uses it's excess foreign currency to buy American debt instruments, thereby encouraging low interest rates in the US so that the American people can buy more Chinese goods at Wal-Mart. We may soon see the last remaining super power of the previous century decline into obscurity. Another decade will tell us for sure. Ahem. Sorry about that. Slightly off topic. :) Breeno
Cryptography Accelerators
Hello. Given the recent post by Theo about the poor state of Hifn cooperation, I am curious to know how OpenBSD developers rate the other companies producing cryptography accelerators. The Cryptography page (http://www.openbsd.org/crypto.html) seems to be somewhat outdated, stating 'Hifn was initially a difficult company to deal with (threatening to sue us over our non-USA reverse engineering of their crypto unlock algorithm), but more recently they have been very helpful in providing boards and support'. Since this runs contrary to what Theo has said on the subject, I am wondering if the products from Broadcom or SafeNet are better supported. Or does it make more sense to shoot for a total solution like the VIA C3? Or are there other viable options? Thanks. Breeno
Re: system lock-up - RTFM?
Stuart Henderson wrote: On 2006/06/06 13:11, Sam Chill wrote: There is a very handy program called memtest86 which can test your memory to see if it is bad. It tells you if it's bad, but it doesn't tell you if it's good. Of course not. It doesn't even tell you if your memory is bad. It merely tells you if there is a problem reading and writing test patterns to memory. An error detected by memtest86 could just as easily indicate a CPU, mainboard, or power supply problem. And there simply is no reasonable method in existence which can tell you if your memory is good. If there was, no bad memory would ever leave the factory. There are merely degrees of quality. This doesn't diminish memtest86's usefulness as a tool for avoiding a part by part elimination rebuild. As a former owner of two different custom PC shops, I would like to point out that memtest86 successfully located memory reads or writes as the problem on virtually all trouble PCs out of thousands of builds that I have performed over the years (most of the rest were hard drive errors, a few were related to faulty optical drives). The only systems which had memory problems that were not detected by memtest86 were systems in which low grade parts were used for the build. If you use second or third tier manufacturers for your mainboard, memory, and power supply then you deserve your memory errors as far as I'm concerned. Stick with parts that are high quality, follow the RAM compatibility list for you mainboard, and you will likely never experience any memory errors. And if you do, there is a very good chance that memtest86 will catch them. If you still fall into the minuscule percentage of memory errors that slip through these actions, then you will likely have to part out and test the machine piece by piece. Out of three thousand or so computer builds, I can count the number of machines that fall into this category on one hand. Also, be sure to run memtest86 for at least a 12 hour period. I have seen machines which do not necessarily spit out a memory error on every pass of memtest86. If memtest86 passes without error for twelve hours, then download and run the hard drive diagnostic software provided by the manufacturer. After that, get ready for several stimulating hours of part by part elimination by exchanging each suspect part for another of similar type (not the same type) of equal or greater quality than the suspect part. After each part exchange you will have to reinstall the OS to ensure that you are not experiencing errors which were introduced into the OS during the last install. You will find the problem via this route. FUN!! Breeno
Re: system lock-up - RTFM?
Shane J Pearson wrote: I have a faulty DDR2 SODIMM in my laptop which memtest86 shows to fail in the same place every single time. This machine has 2 SODIMMS. If I swap their positions in the memory slots in my laptop, memtest86 shows the errors follow the module to the other slot, while showing the original potentially faulty slot to be fine. Same deal if I swap the memory between my laptop and my girlfriends. Problem follows module. Yeah, sure, in some cases when memtest86 reports a memory error it is an indication of faulty memory. But there are many situations where memtest86 detects a memory error which is related to a faulty CPU, mainboard, or power supply, or where a memory module is not compatible with the mainboard but is otherwise fine, or where there is an issue with heat buildup. An error in memtest86 does not specify which part is giving you problems, only that the problem is memory related! At best, you can only expect memtest86 to identify a memory read or write error. It is up to the thinking being to eliminate the possible reasons for the memory error. If you blindly believe that your memory is bad when memtest86 detects an error then you are setting yourself up for a lot of pain and sorrow if in fact the problem is related to your northbridge overheating, as an example. You've basically stated this above. You found an error with memtest86 which alerted you to a problem (or more likely your laptop misbehaving alerted you to a problem and memtest86 narrowed the scope of the problem). You then took action and tested your memory in different configurations and then on a different machine, and by using your brain you were able to narrow down the problem to the memory stick itself. You identified the stick, memtest86 only started you on the right path by pointing out that there was a memory error. If it hadn't been the stick, then you would have had to consider something else. Did you actually read and then understand my original post? The difference between a memory error and a faulty stick of RAM may be subtle, but there is a difference none the less. Telling someone new to memtest86 that it detects bad memory sticks is misleading and could give them a nice headache if their problem is not the stick. Breeno
Re: How to enable hw crypto?
Theo de Raadt wrote: I thought my mail was clear enough. Not necessarily. This thread was originally about the Hifn 7956 whereas my interest is in the 7955. You stated that about a year ago Hifn policies changed and that they decided they would no longer provide documentation. I know the 7955 and the 7956 come from the same product line, but since you did not address the 7955 specifically there was an outside chance that OpenBSD had received full documentation for the 7955 before this Hifn policy change, but then suffered for documentation on the 7956. Thus my request for clarification. I suppose that your message would be clear to a developer familiar with the hardware. I do not know the differences between these two parts. Is the 7956 merely a higher clocked part, or does it differ in implementation from the 7955? Since they are part of the same product line it would logically follow that they were implemented identically. However, how many companies have different implementations across the same part number, let alone product lines? I am merely covering all the possibilities left open by your message. I suppose it is safe to assume by your reply that the two parts utilize the same implementation but that the 7956 is a higher clock than the 7955. In other words, the people in the 7955 message thread are fscked as well. In any case, I guess it is time to send Hifn an email and let them know that they are losing future sales as a result of this change in policy. I suggest that other owners of Hifn products follow suit. I am also going to send a message to Soekris expressing my displeasure at the fact that their product sales page for the vpn1411 lists it as fully supported by OpenBSD when that is obviously not the case. As a Hifn technology implementer I would hope that Soekris would also pass their concern about this documentation issue back up the chain to Hifn. On that note, does anyone in the project have an email address or two for Hifn? Specifically an address for someone who would have maximum impact on the policy decision making process. Breeno
Re: Xen/OpenBSD Summer of Code project
Anil Madhavapeddy wrote: The eventual plan is to get dom0 support in OpenBSD; we'll see how long it takes. Out of curiousity, do you know how the GPL licence of Xen affects dom0 support in OpenBSD? Breeno
Re: How to enable hw crypto?
Theo de Raadt wrote: So it does not really matter if you give further debugging information. There is some bug, and we don't know what it is, and I wish it was fixed because in some way we find it embarrassing to have something not work in OpenBSD, but hey, what can we really do? Theo, Does this apply to the 7955 as well? When did Hifn stop providing documentation? Breeno
Re: Windows to copy open bsd
Darrin Chandler wrote: Ask Gates, Ballmer and crew what MS's goals are. Or find it on the MS site. If none of that works you can speculate (I'm not going to). Do you think their goals fall as much in line with what you want as does OpenBSD's goals? Actually, this is very easy and does not require any speculation. The goal of any for-profit corporation is summed up in one line: Maximize shareholder profit. Therefore, MS will make it their goal to improve security only when it affects the bottom line. Most of the time they don't even have to improve security to affect the bottom line - they just have to go through the motions of appearing to improve security. If more people would come to understand the staggering importance of that single minded goal of any corporation the world would be a better place. Instead of appealing to corporations to exhibit the behaviours of a person, all we need to really worry about is appealing to (or threatening) their bottom line. Theo has been doing this for years, and he's one smart cookie. No, that image just does fit - Theo is one smart saltine cracker. :) Breeno
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Didier Wiroth wrote: Hello, Hmm I get the corrupted mac error again on current, while connecting to the net4801 with windows + putty. Connecting with openbsd ssh client does not produce the error, I only get it with latest windows and putty client Is anyone else able to test: a) with a windows client + putty b) to a connect via ssh to a soekris 4801 running current + mini pci soekris vpn 1401 c) do you get the corrupted mac on input errors? I knew it was going to happen. :) I will set up a PC with OpenBSD 3.9 Release and follow up with the latest snapshot and try making some connections that don't involve PuTTY. I'll get my results back by tomorrow. Breeno
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Didier Wiroth wrote: Sorry ;-) I've reposted a new message a few minutes later ... May I ask you a question, do you use a custom kernel on your soekris box? - Original Message - From: Breen Ouellette Date: Thursday, June 1, 2006 22:43 Subject: Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]) To: misc@openbsd.org No, I do not use a custom kernel, and I haven't tried a custom kernel for at least five years (I caved in to the undeniable truth that Theo knows far better than I do on matters pertaining to OpenBSD). I've got a 2.5 Seagate hard drive (got sick of CF read limitations), I do a full install every release, and I try to stick to the base install as closely as possible (the only package I add is apg). Now I am just plain confused! I am still going to install 3.9 on a PC and try an ssh connection which doesn't involve WinXP / PuTTY. Breeno PS - Just in case someone figures I have a heat problem due to the hard disk: I run open top. CPU is 55 degC and HD is 34 degC. I am even modifying my case this week to add a chipset heatsink on the CPU and an 80mm Vantec Stealth to cool the case. I'll run my tests again when these mods are complete.
vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Didier Wiroth wrote: I run the test for almost 20 minutes, there was no problem anymore! Regards Didier Thank you for your report. Here's where I stick my head out farther than I probably should and hope it doesn't get taken off. I checked the hifn code to see if it had changed since 3.9 Release. It hasn't. I took a look at the list of includes and noticed that several files have changed since 3.9 Release. Not being skilled enough to know if this is the right train of thought, I have to ask: is it possible that something was changed before 3.9 Release which broke hifn, and was later (lately) adjusted back to a state which works with hifn? If so, if the cause is not identified now is there a possibility that hifn could be broken again in the future? The reason I ask is that hifn has a somewhat muddy history of breakage which has often been blamed on hardware. Is the hardware junk or is the problem hard to nail down? Or is this a combination of both - is the previous evidence of junk hardware + hifn problems resulting in a knee jerk reaction of blaming the hardware by default? Also relevant for mere users like myself (ie not qualified to fix this problem), should we just downgrade to an earlier release or upgrade to current, or is this the sort of thing that would get patched if a problem was indeed identified? Thanks. Breeno
Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
jared r r spiegel wrote: On Mon, May 29, 2006 at 10:01:21PM -0600, Breen Ouellette wrote: A few months ago, Didier Wiroth posted to this list that his net4801 with a vpn1411 was giving him 'Corrupted MAC on input' errors. He was looking for a solution to this problem. i think i chimed in on that one. since i put may.1st snapshots on my 4801, it has not happened at all. this was the same situation for me as before; i started to see the 'corrupted MAC on input' after one snapshot, and then a few snapshots later, it went away entirely. this last time, it showed up after a december-ish snapshot (iirc, whatever i had in my last post about it ...), and since may.1 snapshot, it is entirely non-present Just so you are aware, this problem is not necessarily limited to OpenBSD. A NetBSD user stated on the Soekris tech list that he had seen the error a couple of times, but he no longer has a net4801/vpn1411 combination to test the script against. As well, a FreeBSD user reported the same trouble in a different thread. The problem is that this error is sporadic enough that no one appears to have confirmed the cause so that the responsible party(ies) may be notified. Since many types of hardware error can be responsible for similar behaviour it has been too easy to blame it on a ghost in the system. However, I started out with just a net4801, which I used for more than a year before getting the vpn1411. During that year my box ran flawlessly, so when the errors cropped up after installing the vpn1411 I was in the relatively unique position of knowing that the net4801 was fine, while most people seem to buy the set, experience errors, get told it is a hardware problem (bad RAM, bad NIC, bad network device), and take it at face value. It still could be a hardware problem, but it is not the only possibility and I would like clear evidence before I blame the card. The fact that I have only seen this reported on BSD systems could be an indication that there is a problem with the Hifn driver _IF_ they all share a common code base. Having a quick look at the source code on the web indicates to me that several sources have been used to create the Hifn driver. Perhaps a developer can enlighten us about whether or not there is a shared code base (or cooperation) between projects. I have seen my script run for several minutes before glitching out, so if you have the time to run it for a solid 10 minutes using SSH2/AES it will go a long way to confirming that you haven't just been lucky to avoid the error since you began using the May 1st snapshot. I've personally used several SSH2/AES sessions for regular use for more than 30 minutes in the last week without experiencing an error (yet at other times it has failed within a minute of regular use). It seems rather unlikely (although not impossible) that the OpenBSD developers would regress the code to a breakable state and then fix it again, so my money would be on your being lucky the last few weeks and that most people sluff this off as a problem with hardware. In fact, the WebCVS shows that the last change to the Hifn driver was 4 months ago, which would indicate that for the May 1st snapshot to fix this problem the error would have to exist outside of the driver itself, lending more credibility to the hypothesis that you still have a problem but you just haven't experienced it. Thanks for your post. I hope you take it one step further and run that script (and then report your result to this list)! :) Breeno
Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
Peter Strvmberg wrote: I have a net4801 with a vpn1411 and I occasionally got the error (but not for a good while now). I also have a vpn1411 in a generic i386 mb and I *never* seen the error on that machine. Peter, Could you provide a model number for your generic i386 mainboard? Is it a vpn1411 you are using on the non-Soekris board, or the vpn1401 (PCI or mini-PCI)? Have you used your net4801 without the vpn1411? If so, did you get any of these errors without the vpn1411? What version of OpenBSD are you using on these machines? Would you be so kind as to run the script (over ssh) which I posted in the original message? Preferably on both the machines you have with a vpn1411 for a minimum of ten minutes. It would be very helpful. Thanks for the info, I hope we hear more! Breeno
Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
Didier Wiroth wrote: Hello, I had the same problem and symtoms as you. net4801 + 1411 vpn + corrupted mac on input. I've upgraded to a current build a few minutes ago, I did not get any errors anymore. So, just to verify, as of -current you can no longer cause the error by running the script (for a minimum of ten minutes) in the top post? Thanks. Breeno
Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
Peter Strvmberg wrote: Eh, sorry, it was a 1401 in my soekris :-) The soekris has a ral(4) minipci and a vpn1401 pci The i386 is a Intel L440GX+ with a vpn1401 and a sk(4) (Linksys EG1064) Both are running -currentish, updated about once or twice a month That is actually interesting. If you have the problems using the PCI version of the card on a net4801, then that removes the mini-PCI slot as a source of the error (which nudges the problem a bit in the direction of the drivers as a source of the error). Would you be willing to run that script to verify that it causes the error on your equipment? Thanks for the update. Breeno
Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
Stoyan Genov wrote: I seem to no-longer be able to find what I once found in google search results, so take this with a grain of salt, but if my memory serves me correctly, there exists a series of net4801 boards with a problematic capacitor somewhere in the PCI bus circuitry which could be causing the problem. Or maybe this is just a myth. I think you may be thinking of the capacitor problem with the net4501. Different beast. I use two net4801 boards with vpn1411 cards and I DO get these errors ocasionally with all patch- (post-release) kernels since OpenBSD 3.6 Would you be willing to run the script from the top post to confirm that you get the error? Please run the script for a minimum of ten minutes. Thanks. Breeno
[Fwd: 'Corrupted MAC on input' points to vpn1411 problem]
Hello. I recently posted this message on the Soekris tech list, but given the sparse amount of traffic there I am hoping that misc@ will prove to be a better source of the test data required to keep this problem moving toward a positive conclusion, rather than stalling as has happened as recently as a few months ago. Thanks. Breeno Received: from 24.72.118.207 (SquirrelMail authenticated user [EMAIL PROTECTED]) by webmail.breeno.net with HTTP; Sun, 28 May 2006 06:50:43 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Date: Sun, 28 May 2006 06:50:43 -0700 (PDT) Subject: 'Corrupted MAC on input' points to vpn1411 problem From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello everyone! A few months ago, Didier Wiroth posted to this list that his net4801 with a vpn1411 was giving him 'Corrupted MAC on input' errors. He was looking for a solution to this problem. Mike Tancsa replied that he has seen the same error a couple of times on FreeBSD 6.1-PRERELEASE. Damien Miller posted a number of possible problems which could cause this error. Unfortunately, my current line of testing indicates that, at least in my situation, none of these possibilities is the culprit. I am fairly certain at this point that the problem is related to the vpn1411. I am not sure if it is the hardware itself or the driver for OpenBSD. There is a small outside chance that this is related to PuTTY, which I am using to connect to the net4801, but given that others are also experiencing this issue it seems to be an outside possibility. My testing: When I first noticed this problem I was performing an operation which displayed a large amount of text. Subsequent errors also happened when dealing with large amounts of text being output to the PuTTY window. I decided to make a script to reliably trigger the error: START sshtest.sh #!/bin/sh while true do cat /var/log/messages done END sshtest.sh This script provided me with infinitely large amounts of text output. Within seconds of running it the first time I received the error in question. I then cross checked the various protocol versions and encryption ciphers available: SSH2/AES: Corrupted MAC on input SSH2/Blowfish: OK for 10 minutes, used CTRL-C to escape loop SSH2/3DES: Corrupted MAC on input SSH1/Blowfish: OK for 10 minutes, used CTRL-C to escape loop SSH1/3DES: Incorrect CRC received on packet As the above data shows, errors only occur with the ciphers that are accelerated by the vpn1411. Blowfish is not accelerated and never choked during testing. I removed the vpn1411 and ran all the tests again. All combinations passed 10 minutes of testing. To verify the culprit of this error requires further data. I need the following testers: net4801/vpn1411/OpenBSD 3.9 - verify the same errors using my testing methodology. Test against another Unix box rather than PuTTY if possible. net4801/vpn1411/FreeBSD, NetBSD, or Linux - verify the same errors using my testing methodology. Test against another Unix box rather than PuTTY if possible. If other platforms get the same errors then it is likely a problem with the vpn1411 itself. If only OpenBSD produces the errors then there could be a problem with OpenBSD's implementation of the Hifn driver. If the error doesn't occur between Unix boxen, then PuTTY is the likely culprit. Please post your test data to this list. Thank you, namaste, and good luck. Breeno
