Re: Request for Funding our Electricity
Just to bring this issue back to the forefront. In light of shrinking funding, we do need to look for a source to cover project expenses. If need be the OpenBSD Foundation can be involved in receiving donations to cover project electrical costs. But the fact is right now, OpenBSD will shut down if we do not have the funding to keep the lights on. If you or a company you know are able to assist us, it would be greatly appreciated, but right now we are looking at a significant funding shortfall for the upcoming year - Meaning the project won't be able to cover 20 thousand dollars in electrical expenses before being able to use money for other things. That sort of situation is not sustainable. On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt wrote: > I am resending this request for funding our electricity bills because > it is not yet resolved. > > We really need even more funding beyond that, because otherwise all of > this is simply unsustainable. This request is the smallest we can > make. > > --- > > Hi everyone. > > The OpenBSD project uses a lot of electricity for running the > development and build machines. A number of logistical reasons > prevents us from moving the machines to another location which might > offer space/power for free, so let's not allow the conversation to go > that way. > > We are looking for a Canadian company who will take on our electrical > expenses -- on their books, rather than on our books. We would be > happiest to find someone who will do this on an annual recurring > basis. > > That way the various OpenBSD efforts can be supported, yet written off > as an off-site operations cost by such a company. If we reduce this > cost, it will leave more money for other parts of the project. > > We think that a Canadian company is the best choice for accounting > reasons. If a company in some other jurisdiction feels they can also > do this successfully, we'd be very happy to hear from them as well. > > I am not going to disclose the actual numbers here. Please contact me > for details if serious. > > Thanks. >
Re: Request for Funding our Electricity
And actually, if you're reading this, you can help by passing this on to people you know *off these lists*. When we post to these mailing lists saying these things we are asking for your help to get the word out to people who support open source projects. Those people are not necessarily here, and often, you (the people who use it and work with it) need to make the case to them that their support is important - far better that explanation comes from you rather than someone they don't know. -Bob On Tue, Jan 14, 2014 at 1:03 PM, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. > > > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks. >>
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. There's an equation that has to be satisfied here. It has a demand side and a supply side. You demand a certain amount of electricity and someone has to supply the money to pay for it. I'm going to be blunt here, in an effort to be helpful (it's also not foreign to the OpenBSD style). I get the impression that the demand for electricity is viewed as a given: you use what you use and people need to step up and provide the money to pay for it. If I'm wrong, please say so. But if I'm right, the demand can be adjusted. Sometimes you need to eat cornflakes instead of caviar. For example, I've never understood why this project supports the old architectures it does, considering the associated costs. The recent discussion of a need for a replacement Vax for package-building illustrates that. Perhaps this is an opportunity to reassess the scope of the project and trim some things that can no longer be justified on a cost-benefit basis. If the choice is between shutting the project down and reducing its scope to something sustainable, it's a no-brainer. This project has made really significant contributions, both in the obvious area, security, but also to the art of managing and building complex software that is reliable. To have it go away rather than trim its sails in way that acknowledges reality would really be a shame. /Don Allen > > > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks. >
Re: Request for Funding our Electricity
> On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: > >Just to bring this issue back to the forefront. > > > > In light of shrinking funding, we do need to look for a source to > > cover project expenses. If need be the OpenBSD Foundation can be > > involved in receiving donations to cover project electrical costs. > > > > But the fact is right now, OpenBSD will shut down if we do not have > > the funding to keep the lights on. > > > > If you or a company you know are able to assist us, it would be > > greatly appreciated, but right now we are looking at a significant > > funding shortfall for the upcoming year - Meaning the project won't be > > able to cover 20 thousand dollars in electrical expenses before being > > able to use money for other things. That sort of situation is not > > sustainable. > > There's an equation that has to be satisfied here. It has a demand > side and a supply side. You demand a certain amount of electricity and > someone has to supply the money to pay for it. I'm going to be blunt > here, in an effort to be helpful (it's also not foreign to the OpenBSD > style). I get the impression that the demand for electricity is viewed > as a given: you use what you use and people need to step up and > provide the money to pay for it. If I'm wrong, please say so. But if > I'm right, the demand can be adjusted. Sometimes you need to eat > cornflakes instead of caviar. For example, I've never understood why > this project supports the old architectures it does, considering the > associated costs. The answer to that is not news. On a regular basis, we find real and serious bugs which affect all platforms, but they are incidentally made visible on one of the platforms we run, following that they are fixed. It is a harsh reality which static and dynamic analysis tools have not yet resolved. Now, If you don't realize this is the reason we try to run on the older platforms, I am sorry but you have really not tried to stay in the loop of what makes OpenBSD a vibrant ecosystem. If you aren't in the loop regarding this, then your mail comes off pretty darn preachy. > The recent discussion of a need for a replacement > Vax for package-building illustrates that. The vaxes being asked for draw almost no power, but it supplies the same benefits as the other architectures. Regarding shutting them down, there other social problems. Yes, we remove about 10 of the architectures. We'd slowly lose the developers who like to work on those areas. They also work in other areas, but ... I suspect they would another BSD that supports them. > Perhaps this is an opportunity to reassess the scope of the project > and trim some things that can no longer be justified on a cost-benefit > basis. And maybe we've been doing that assessment continually for two decades. > If the choice is between shutting the project down and reducing its > scope to something sustainable, it's a no-brainer. This project has > made really significant contributions, both in the obvious area, > security, but also to the art of managing and building complex > software that is reliable. To have it go away rather than trim its > sails in way that acknowledges reality would really be a shame. This project "has made"? How about "this project will continue to". I really love how we keep getting advice. Anyone want to suggest we hold a bake sale?
Re: Request for Funding our Electricity
> Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. Darn' tootin'! > Anyone want to suggest we hold a bake sale? Make that a lo-carb bake sale.
Re: Request for Funding our Electricity
On 01/14/14 21:56, Theo de Raadt wrote: Hi, > Anyone want to suggest we hold a bake sale? I just donated a little bit. Looking for roughly 10 dozen like minded people. I'm not suggesting a bake sale but one thing I noticed with the freebsdfoundation.org's website, that I think works out good, is that they have a donation meter on how much was put in the hat. I think something like this would benefit OpenBSD too. Just there would need to be someone able to make such a meter on a website. Also showing how much came from private donations vs. corporate donations would be interesting to see. Cheers, -peter
Re: Request for Funding our Electricity
On Wed, January 15, 2014 00:03, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. > Hi. Could we collect this sum on special bank account, to gather correct sum for covering electricity expenses? Or OpenBSD Foundation will pay a bill from it's funds? Simplier - should I send money to Foundation right now or should I wait info about direct-electricity-expenses-acccount? Unfortunately I can't send $20k, but if 200 community members send $100 each... I hope this will help to have another year for searching a company Theo was mentioning in his irst letter. > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks. >> > >
Re: Request for Funding our Electricity
Kiril, a dedicated one purpose bank account or officially directed donations are somewhat problematic to a canadian not for profit - Normally for expenses the foundation supports we simply re-imburse the individuals for their costs from our funds. As far as the suggested "donation" meter that's an idea we'd probably like to put up - as it gets that crowdsourcing type interest going. But in this case it would likely not be 20K, more like a 150K yearly goal would be best. On Tue, Jan 14, 2014 at 2:16 PM, Kirill Bychkov wrote: > On Wed, January 15, 2014 00:03, Bob Beck wrote: >>Just to bring this issue back to the forefront. >> >> In light of shrinking funding, we do need to look for a source to >> cover project expenses. If need be the OpenBSD Foundation can be >> involved in receiving donations to cover project electrical costs. >> >> But the fact is right now, OpenBSD will shut down if we do not have >> the funding to keep the lights on. >> >> If you or a company you know are able to assist us, it would be >> greatly appreciated, but right now we are looking at a significant >> funding shortfall for the upcoming year - Meaning the project won't be >> able to cover 20 thousand dollars in electrical expenses before being >> able to use money for other things. That sort of situation is not >> sustainable. >> > > Hi. Could we collect this sum on special bank account, to gather correct sum > for covering electricity expenses? > Or OpenBSD Foundation will pay a bill from it's funds? > Simplier - should I send money to Foundation right now or should I wait info > about direct-electricity-expenses-acccount? Unfortunately I can't send $20k, > but if 200 community members send $100 each... > I hope this will help to have another year for searching a company Theo was > mentioning in his irst letter. > >> >> >> On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt >> wrote: >>> I am resending this request for funding our electricity bills because >>> it is not yet resolved. >>> >>> We really need even more funding beyond that, because otherwise all of >>> this is simply unsustainable. This request is the smallest we can >>> make. >>> >>> --- >>> >>> Hi everyone. >>> >>> The OpenBSD project uses a lot of electricity for running the >>> development and build machines. A number of logistical reasons >>> prevents us from moving the machines to another location which might >>> offer space/power for free, so let's not allow the conversation to go >>> that way. >>> >>> We are looking for a Canadian company who will take on our electrical >>> expenses -- on their books, rather than on our books. We would be >>> happiest to find someone who will do this on an annual recurring >>> basis. >>> >>> That way the various OpenBSD efforts can be supported, yet written off >>> as an off-site operations cost by such a company. If we reduce this >>> cost, it will leave more money for other parts of the project. >>> >>> We think that a Canadian company is the best choice for accounting >>> reasons. If a company in some other jurisdiction feels they can also >>> do this successfully, we'd be very happy to hear from them as well. >>> >>> I am not going to disclose the actual numbers here. Please contact me >>> for details if serious. >>> >>> Thanks. >
Re: Request for Funding our Electricity
On 1/14/14, Theo de Raadt wrote: >> On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck >> wrote: >> >Just to bring this issue back to the forefront. >> > >> > In light of shrinking funding, we do need to look for a source to >> > cover project expenses. If need be the OpenBSD Foundation can be >> > involved in receiving donations to cover project electrical costs. >> > >> > But the fact is right now, OpenBSD will shut down if we do not have >> > the funding to keep the lights on. >> > >> > If you or a company you know are able to assist us, it would be >> > greatly appreciated, but right now we are looking at a significant >> > funding shortfall for the upcoming year - Meaning the project won't be >> > able to cover 20 thousand dollars in electrical expenses before being >> > able to use money for other things. That sort of situation is not >> > sustainable. >> >> There's an equation that has to be satisfied here. It has a demand >> side and a supply side. You demand a certain amount of electricity and >> someone has to supply the money to pay for it. I'm going to be blunt >> here, in an effort to be helpful (it's also not foreign to the OpenBSD >> style). I get the impression that the demand for electricity is viewed >> as a given: you use what you use and people need to step up and >> provide the money to pay for it. If I'm wrong, please say so. But if >> I'm right, the demand can be adjusted. Sometimes you need to eat >> cornflakes instead of caviar. For example, I've never understood why >> this project supports the old architectures it does, considering the >> associated costs. > > The answer to that is not news. > > On a regular basis, we find real and serious bugs which affect all > platforms, but they are incidentally made visible on one of the > platforms we run, following that they are fixed. It is a harsh > reality which static and dynamic analysis tools have not yet resolved. > > Now, If you don't realize this is the reason we try to run on the > older platforms, I am sorry but you have really not tried to stay in > the loop of what makes OpenBSD a vibrant ecosystem. If you aren't in > the loop regarding this, then your mail comes off pretty darn preachy. > >> The recent discussion of a need for a replacement >> Vax for package-building illustrates that. > > The vaxes being asked for draw almost no power, but it supplies the > same benefits as the other architectures. > > Regarding shutting them down, there other social problems. > > Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. > >> Perhaps this is an opportunity to reassess the scope of the project >> and trim some things that can no longer be justified on a cost-benefit >> basis. > > And maybe we've been doing that assessment continually for two > decades. > >> If the choice is between shutting the project down and reducing its >> scope to something sustainable, it's a no-brainer. This project has >> made really significant contributions, both in the obvious area, >> security, but also to the art of managing and building complex >> software that is reliable. To have it go away rather than trim its >> sails in way that acknowledges reality would really be a shame. > > This project "has made"? How about "this project will continue to". > > I really love how we keep getting advice. I think you misunderstood the concept of supply and demand pointed out in the message you replied to. "We" are so used to leeching off the project, and for so long, that we feel entitled to /demand/ that you and your project /supply/ what we feel entitled to. Because of our dependence to this entitlement feeling, should anything threaten the supply of what you produce, must not be allowed. Even if "we" should need to go to our government representatives to address this threat! I can see it now: OBSD=OBama Software Distribution. It will be provided to everyone and anyone, whether or not they feel they need it. If anyone chooses to not use it, they still will be charged a "fee" for the CD set they don't need now, but /might/ need in the future. This program will be sustained by inflated CD prices (say $750 a copy), and by cutting bits of the project which will be deemed unnecessary, such as old and obsolete hardware support (VAX, Sparc, ...), stickers will be discontinued, OpenSSH will be removed from base; let's be honest about it, you really need encryption if you have something to hide (from the government). I understand they now have worked out all the glitches in their web-site, which will now host the new OBSD. Cheers, --patrick
Re: Request for Funding our Electricity
> > Anyone want to suggest we hold a bake sale? > > I will take this opportunity to suggest a probably bad idea but one > that crossed my mind nonetheless. > > I have not actively kept up with this list so forgive me if this can't > be done, or isn't in line with the community's values, but what about > doing a Kickstarter campaign for each OpenBSD release? Varying levels > of support could get the different levels of swag that are already > distributed: CD/DVD distributions, t-shirts, stickers, etc... The problem with this model is that once again - we are the ones who need to supply more; - we need to promising the goods; - we are the ones who need to invest; - we are supposed to do the extra work; - we are supposed to take time away from coding. Don't we do enough? Regarding the swag. The entire OpenBSD project now probably gets 1/4 of revenue out of CD, tshirt sales, but in this model we'd have to give much of that out to people who contribute, and it will probably be less. Remember to add shipping, now paid on this end, instead of by the buyer. > One could also just contribute $10-$20 to be a supporter, and receive > nothing material. $20? To break even with the above issues, call it $100 minimum. Does it still work? Is there evidence? And once this turn process on, if it doesn't work, are we even more dead in the water? > Nodejitsu recently raised $256k with their Scalenpm campaign. I would > imagine there are enough people out there who care about OpenBSD too > whereby a significant amount of money could be raised. Would that work every year? I doubt mindshare of this sort works repeatedly.
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 03:24:00PM -0700, Theo de Raadt wrote: > > I will take this opportunity to suggest a probably bad idea but one > > that crossed my mind nonetheless. > > > > I have not actively kept up with this list so forgive me if this can't > > be done, or isn't in line with the community's values, but what about > > doing a Kickstarter campaign for each OpenBSD release? Varying levels > > of support could get the different levels of swag that are already > > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > The problem with this model is that once again > - we are the ones who need to supply more; > - we need to promising the goods; > - we are the ones who need to invest; > - we are supposed to do the extra work; > - we are supposed to take time away from coding. Who would back the KickStarter but be unwilling to donate directly to the project? The community is already here, the project already accepts donations. I don't see what KickStarter offers besides the hipster cred of running a KickStarter, and hipster cred doesn't pay electrical bills. Anyways, talk is cheap so I'm going to go make a donation now. If everyone reading this did the same this thread could die, and OpenBSD wouldn't.
Re: Request for Funding our Electricity
No need to respond to this: just ideas if they're not already covered. I've just made my donation. For what it's worth - you can see the numbers on wikimedia's donations, from 2009. I wouldn't discount the $10 user base. http://en.m.wikipedia.org/wiki/User:Staeiou/Protocol [see the graphs on fundraising below]. Other idea if not already taken care of - You could also get non-coding contributors to handle the CD & stickers etc, if you don't already have that happening. Then the fundraising arm wouldn't take away from coding time. Thanks Jason On Wed, Jan 15, 2014 at 9:24 AM, Theo de Raadt wrote: > > > Anyone want to suggest we hold a bake sale? > > > > I will take this opportunity to suggest a probably bad idea but one > > that crossed my mind nonetheless. > > > > I have not actively kept up with this list so forgive me if this can't > > be done, or isn't in line with the community's values, but what about > > doing a Kickstarter campaign for each OpenBSD release? Varying levels > > of support could get the different levels of swag that are already > > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > The problem with this model is that once again > - we are the ones who need to supply more; > - we need to promising the goods; > - we are the ones who need to invest; > - we are supposed to do the extra work; > - we are supposed to take time away from coding. > > Don't we do enough? > > Regarding the swag. The entire OpenBSD project now probably gets 1/4 > of revenue out of CD, tshirt sales, but in this model we'd have to > give much of that out to people who contribute, and it will probably > be less. > > Remember to add shipping, now paid on this end, instead of by the buyer. > > > One could also just contribute $10-$20 to be a supporter, and receive > > nothing material. > > $20? To break even with the above issues, call it $100 minimum. Does > it still work? Is there evidence? > > And once this turn process on, if it doesn't work, are we even more dead > in the water? > > > Nodejitsu recently raised $256k with their Scalenpm campaign. I would > > imagine there are enough people out there who care about OpenBSD too > > whereby a significant amount of money could be raised. > > Would that work every year? > > I doubt mindshare of this sort works repeatedly. > >
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 12:40 AM, Donald Allen wrote: > On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: >>Just to bring this issue back to the forefront. >> >> In light of shrinking funding, we do need to look for a source to >> cover project expenses. If need be the OpenBSD Foundation can be >> involved in receiving donations to cover project electrical costs. >> >> But the fact is right now, OpenBSD will shut down if we do not have >> the funding to keep the lights on. >> >> If you or a company you know are able to assist us, it would be >> greatly appreciated, but right now we are looking at a significant >> funding shortfall for the upcoming year - Meaning the project won't be >> able to cover 20 thousand dollars in electrical expenses before being >> able to use money for other things. That sort of situation is not >> sustainable. > > There's an equation that has to be satisfied here. It has a demand > side and a supply side. You demand a certain amount of electricity and > someone has to supply the money to pay for it. I'm going to be blunt > here, in an effort to be helpful (it's also not foreign to the OpenBSD > style). I get the impression that the demand for electricity is viewed > as a given: you use what you use and people need to step up and > provide the money to pay for it. If I'm wrong, please say so. But if > I'm right, the demand can be adjusted. Sometimes you need to eat > cornflakes instead of caviar. For example, I've never understood why > this project supports the old architectures it does, considering the > associated costs. The recent discussion of a need for a replacement > Vax for package-building illustrates that. > > Perhaps this is an opportunity to reassess the scope of the project > and trim some things that can no longer be justified on a cost-benefit > basis. > > If the choice is between shutting the project down and reducing its > scope to something sustainable, it's a no-brainer. This project has > made really significant contributions, both in the obvious area, > security, but also to the art of managing and building complex > software that is reliable. To have it go away rather than trim its > sails in way that acknowledges reality would really be a shame. > > /Don Allen > I'm not involved deeply in OpenBSD, but you'd be surprised at the number of software that incorporates OpenBSD improvements that you and I use. If you run nsd or unbound: (from nsd changelog) Bugfixes: Fix for accept spinning reported by OpenBSD. OpenBSD security improvements are often submitted to other projects so that everybody can benefit: Fix bug where clear_remove() and clear_inodedeps() would not iterate over the entire pagedep and inodedep hash tables due to an off-by-one mistake in loops. Spotted by and diff from Pedro Martelletto. Sent upstream to Kirk and also fixed in FreeBSD. ok otto@ millert@ These are just 2 examples that I picked, but there are many more. OpenSSH wouldn't be reliable if it wasn't tested on HPPA and sparc64: (I'm pretty sure I saw a bunch of commits wrt to alignment issues that were discovered on HPPA or sparc64 for OpenSSH). If we "re-view the project", we end up with OpenBSD not being able to make continuous improvements to the whole world as well as it is doing right now. So let's do our best to allow the project to grow :-) ! >> >> >> >> >> On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt >> wrote: >>> I am resending this request for funding our electricity bills because >>> it is not yet resolved. >>> >>> We really need even more funding beyond that, because otherwise all of >>> this is simply unsustainable. This request is the smallest we can >>> make. >>> >>> --- >>> >>> Hi everyone. >>> >>> The OpenBSD project uses a lot of electricity for running the >>> development and build machines. A number of logistical reasons >>> prevents us from moving the machines to another location which might >>> offer space/power for free, so let's not allow the conversation to go >>> that way. >>> >>> We are looking for a Canadian company who will take on our electrical >>> expenses -- on their books, rather than on our books. We would be >>> happiest to find someone who will do this on an annual recurring >>> basis. >>> >>> That way the various OpenBSD efforts can be supported, yet written off >>> as an off-site operations cost by such a company. If we reduce this >>> cost, it will leave more money for other parts of the project. >>> >>> We think that a Canadian company is the best choice for accounting >>> reasons. If a company in some other jurisdiction feels they can also >>> do this successfully, we'd be very happy to hear from them as well. >>> >>> I am not going to disclose the actual numbers here. Please contact me >>> for details if serious. >>> >>> Thanks. >> > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: Request for Funding our Electricity
Hi, Loganaden Velvindron wrote: OpenSSH wouldn't be reliable if it wasn't tested on HPPA and sparc64: (I'm pretty sure I saw a bunch of commits wrt to alignment issues that were discovered on HPPA or sparc64 for OpenSSH). being myself a developer of several applications, I can only praise that. The quality of "Linux-x86" only software is quite evident lately. I have discovered in the past a lot of bugs in my own software by running it on different architectures and different operating systems. Even if we "love" our own BSD or Linux flavour... I once discovered a bug by testing on AIX/POWER... that affected any platform, but reproduced reliably only there. Sparc and PA-RISC discover a lot of bugs (I'd love to say for their superior architectures) due to alignments, stack treatment, structure handling. Often it is a burden, one has to fight with buggy compilers, strange bootloaders and aging hardware, but it has paid off more than once. This personal experience can surely be extended to other libraries and to whole operating system(s). Riccardo
Re: Request for Funding our Electricity
On 15 Jan 2014, at 16.35, Gilles LAMIRAL wrote: > Dear Theo, > >> Don't we do enough? > > You already do too much. I have long held the opinion that Theo is probably the best coder on this planet. That’s not any sort of ass-kissing, either, it’s my objective, unbiased opinion. And I know Henning personally, as in “live and worked together with him" - one hell of an expert. However, the dilemma that the project has found itself in now very clearly demonstrates that Theo is not a businessman and that there isn’t any other businessman at the helm, either. Imagining that people will suddenly start to pay for something that they have constantly been getting for free is absurd - their belief is that somebody else will surely step up first or somebody will fork in the name of fame. No business on this planet is going to allocate budget to paying OpenBSD’s electricity bills, let alone anything else, without 1) a detailed itemisation of the electrical bills, 2) a detailed justification of said line items, and 3) a satisfaction of their own business interest. It’s just not sexy for a philanthropist to support a relatively unheard of operating system when cancer is still left uncured. It’s not good to be removing coders from their tasks; the project needs a businessman or two. One who will handle the corporate feature requests and charge dearly for them. Things like routing technology and high-speed packet forwarding - things that can replace the exorbitant costs of maintaining cisco routers. This is the key. With the FBSD 10GB wire speed packet forwarding incorporated, OpenBSD would be ready to challenge Cisco in a very serious way. Completely free as always, but with paid support for this edge cases that make life what it is. Thanks Theo, Henning, and all of the rest of you. -mike
Re: Request for Funding our Electricity
Dear Theo, Don't we do enough? You already do too much. Regarding the swag. The entire OpenBSD project now probably gets 1/4 of revenue out of CD Why don't you do for the website software downloads what you do for the CDs? Make users pay the downloads from the official website as you make them pay for the CDs. No need to change the license. No need to care about parallel free downloads, they will be there soon for poor users or smart users than can type "openbsd download" in a search engine. Add lifetime of OpenBSD updates without extra payment (a mailing-list can announce them). Add 30 days money-back guarantee! (any reason qualifies). Add invoice. Would that work every year? Every day. I doubt mindshare of this sort works repeatedly. No doubt it will work but I guess I'm the only one on earth to know that. Of course, I already ear all possible arguments claiming it can't work, it won't be free/open software anymore etc. Openbsd won't just be gratis from the homepage, that's all. It works for me for more than three years for a very small software much worse, much smaller, less well known than the OpenBSD system. That's the buying of OpenBSD CDs that made me think about this business model. I'm lazy so I didn't want the hard stuff of building and sending CDs. Numerically it works 100 times (yes a hundred times) better than a permanent call for donation, that's what I measured, how surprising!, that is what I still benefit every day. You won't have to sell CDs or teeshirts anymore, just coding, paying electricity and coders. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 06:25:53PM +0200, MJ wrote: > > I have long held the opinion that Theo is probably the best coder on this > planet. That?s not any sort of ass-kissing, either, it?s my objective, > unbiased opinion. And I know Henning personally, as in ?live and worked > together with him" - one hell of an expert. > > However, the dilemma that the project has found itself in now very clearly > demonstrates that Theo is not a businessman and that there isn?t any other > businessman at the helm, either. Imagining that people will suddenly start to > pay for something that they have constantly been getting for free is absurd - > their belief is that somebody else will surely step up first or somebody will > fork in the name of fame. No business on this planet is going to allocate > budget to paying OpenBSD?s electricity bills, let alone anything else, > without 1) a detailed itemisation of the electrical bills, 2) a detailed > justification of said line items, and 3) a satisfaction of their own business > interest. It?s just not sexy for a philanthropist to support a relatively > unheard of operating system when cancer is still left uncured. Define sexy. Some people will say it's having flash running full speed on their web browser while streaming 3 youtube videos. For me it's being able to trust my operating system to behave in a way that keeps me in the loop and able to fix it. As for the legalese, some people said "You'll never get anywhere without a protocol number for CARP!", yet some ciscos support CARP nowadays. > > It?s not good to be removing coders from their tasks; the project needs a > businessman or two. One who will handle the corporate feature requests and > charge dearly for them. Things like routing technology and high-speed packet > forwarding - things that can replace the exorbitant costs of maintaining > cisco routers. This is the key. With the FBSD 10GB wire speed packet > forwarding incorporated, OpenBSD would be ready to challenge Cisco in a very > serious way. Completely free as always, but with paid support for this edge > cases that make life what it is. > I don't know what is your background with corporate IT, but my experience is that most of the time what the suits are looking for is the assurance they will have resources to fix arising issues, or in layman terms, a tech support to yell at. I do not see OpenBSD providing such a support. However there are quite a few companies that provide such service for their OpenBSD-based appliances. Does that mean OpenBSD roadmap should be based on what will sell with these companies? The answer (which is "no") has already be given many times on misc@, and I will let Theo add another layer of p[ao]int if he deems it necessary. Lastly, you suggest having a businessman in the project. That is, someone who gets a commit bit by doing something else than coding. It's not even about what this says to the world or the example it sets. It is just plain rude towards the developers. I am not downplaying the skills of businessmen; but you simply can't just say that contributing code the OpenBSD way is the same as selling the product, however tough that may be. This is not a race; this is about doing things right. regards, -- Vincent
Re: Request for Funding our Electricity
Regarding the "less architecture support to save electricity" argument, I'm not sure one follows the other. Computing power has grown to a point that emulators are perfectly valid - particularly for older systems. I think a push to package and maintain emulators for many of these older architectures would be beneficial in many ways. There's some amount of this already - there are instructions for the simh simulator for the VAX arch for instance. The obvious benefits I couldd see would be: 1) You could spin up builds on them w/ little to no effect on electricity usage. 2) Even if the OpenBSD foundation's arch X machine dies, there would still be infrastructure to maintain the port. 3) It would widen the possible number of developers if people could spin up older architectures in an emulator. 4) It would make OpenBSD a valuable tool for accessing older media and documenting older architectures. I know emulators are not perfect, so a physical machine would be superior. But if there was some encouragement for emulators for archs I think those would be useful benefits. Support for multiple archs brings interest and exposes bad code in ways limited arch support does not. Dropping that to save electricity is not a valid reason with today's compute power. Anyway, it's been a long time since I did stuff with OpenBSD, but I think it would be a shame to drop such support. So I'll back up my words with some cash. And if I get a roundtuit, perhaps some code or docs as well. Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Re: Request for Funding our Electricity
On 01/17/2014 06:08 PM, Kevin Lyda wrote: Regarding the "less architecture support to save electricity" argument, I'm not sure one follows the other. Computing power has grown to a point that emulators are perfectly valid - particularly for older systems. You still seem like you do not understand the issue and why they need to use hardware in the first place. so follow my hands, and read my lips, I will explain it slow, and sorry, Teo, what I will say, will seem like I repeat you. Support for different archs, even not mainstream ones help developers to provide more bug free code on i386, amd64, and some other "mainstream", just because some code errors are better visible on those "non mainstream" architectures. The virtualization is absolutely not an option here, because those let's call them "debug" architectures should run in hardware, to be further able to check the code. So, having OpenBSD running on as much archs as it is possible help developers to provide US, the users with much cleaner and much bug free code. -- With best regards, Gregory Edigarov
Re: Request for Funding our Electricity
Kevin Lyda wrote: Regarding the "less architecture support to save electricity" argument, I'm not sure one follows the other. Computing power has grown to a point that emulators are perfectly valid - particularly for older systems. I think a push to package and maintain emulators for many of these older architectures would be beneficial in many ways. There's some amount of this already - there are instructions for the simh simulator for the VAX arch for instance. The obvious benefits I couldd see would be: 1) You could spin up builds on them w/ little to no effect on electricity usage. 2) Even if the OpenBSD foundation's arch X machine dies, there would still be infrastructure to maintain the port. 3) It would widen the possible number of developers if people could spin up older architectures in an emulator. 4) It would make OpenBSD a valuable tool for accessing older media and documenting older architectures. I know emulators are not perfect, so a physical machine would be superior. But if there was some encouragement for emulators for archs I think those would be useful benefits. Even if emulators did work, you still have a couple of problems: *Instructions are executed as they should, not how they actually work *instructions will, at best, take a two instructions on the host if the architectures and endianness match; if not: The instruction has to matched against a lookup table and if there is a single equivalent instruction to do the same thing and you have the same endianness, that is three processors cycles. If its different endianness, then you now have between 32 and 128 more instructions (convert to the host endianness then back for 16 to 64-bit archs) Now if there isn't an equivalent instructions (welcome to the difference between CISC and RISC machines) you are probably going to have to run two all the way up to a couple dozen instructions to emulate just one, plus you still have the same problem with endianness like before *assuming all the above works, you are still tripling the effort in debugging because now you have to determine if the bug is in the emulated environment, the emulator itself, or the host OS. *Even if the above still works perfectly, you will still miss all the bugs caused by memory alignment (the host will fix any of that), which are the most common we find or the host ends up adding new ones. But all this is ignoring the real purpose of running on real hardware which is that the same code runs on all the boxes, so if one of them outputs something unexpected from the other machines, we know something is wrong. The only way to reduce our power for the older archs is if someone were able to re-build the entire system on more power-efficient, bug-compatible chips Support for multiple archs brings interest and exposes bad code in ways limited arch support does not. Exactly Dropping that to save electricity is not a valid reason with today's compute power. Anyway, it's been a long time since I did stuff with OpenBSD, but I think it would be a shame to drop such support. So I'll back up my words with some cash. And if I get a roundtuit, perhaps some code or docs as well. Please continue to do this. Cash, code and correct docs help OpenBSD, dreaming doesn't. Kevin And now to paraphrase Theo: Shut up, donate, and hack.
Re: Request for Funding our Electricity
On Fri, Jan 17, 2014 at 8:23 PM, Christopher Ahrens wrote: > *Instructions are executed as they should, not how they actually work That's a bug to be filed against an emulator. And it's easier to do that *now* when the older hardware is around to test for bug compatibility. And it's not full emulator if it doesn't emulate the bugs. > *instructions will, at best, take a two instructions on the host if > the architectures and endianness match; if not: > The instruction has to matched against a lookup table and if there > is a single equivalent instruction to do the same thing and you have > the same endianness, that is three processors cycles. If its > different endianness, then you now have between 32 and 128 more > instructions (convert to the host endianness then back for 16 to > 64-bit archs) All true, but kind of meaningless for faster newer machines. Following Moore's law, a current machine is likely at least 256 times faster than a 12 year old machine. And nearly every older architecture has a machine that is 12 years old. If supporting older architectures for the full lifespan of that arch you're going to get to a point where all the hardware versions of that machine are in production. You'll eventually have a choice between an emulator or nothing. The last machine of arch X running OpenBSD will not be running on the OpenBSD Foundation racks. And note I'm talking about emulators, not architecture optimised virtual machines. They're probably not ideal for coding device drivers (and even that's not completely true), but they're fine for doing userland and higher level kernel development. You'll find endianess, alignment, cross-arch pointer and int/float size bugs with an emulator just as easily as you can with hardware. The two remote bugs that were found in OpenBSD were both ones that were high enough up the stack that they could be debugged / hacked at on an emulator. And as machines get faster/cheaper you'd have the option of running a small network and run network fuzz testing within a single machine. And I must admit the resistance to this is weird. My point was that the "use less electricity means less ports" argument was wrong. That emulators provide a way forward with all architectures that *increases* developer interest (unlike removing them with reduces it). I'm not saying switch to all emulators all the time for all development *today*, I'm saying think about going that direction now when it's easier (hw bug compatibility testing, etc). It's a lot easier to ask for $X/year if there's a plan for X to reduce. Emulators are hardly some radical view - this is exactly what OpenBSD supports and advertises for the oldest hardware it supports. Am I really saying something new by pointing out to all older archs, "this is your future"? > Please continue to do this. Cash, code and correct docs help OpenBSD, > dreaming doesn't. Yelling at the forward march of time doesn't help either. Diodes don't live forever. Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Re: Request for Funding our Electricity
>That's a bug to be filed against an emulator. And it's easier to do >that *now* when the older hardware is around to test for bug >compatibility. And it's not full emulator if it doesn't emulate the >bugs. We are an operating system project. We have a full set of tasks ahead of ourselves. We are not people writing or improving emulators. In our experience, all of them are subtly erroneous in their behavior. At best. Members of our group have experience with just about all of them. > And I must admit the resistance to this is weird. I am going to make a guess here. You've never relied on the emulators yourselves. Yet you are acting like a know-it-all. You sure have advice for us, don't you. You feel you can tell a group with our success what processes we are supposed to do move to. You are very out of place. Imagine you told us a lot about your life, and we gave you advice.
Re: Request for Funding our Electricity
> Regarding the "less architecture support to save electricity" > argument, I'm not sure one follows the other. Computing power has > grown to a point that emulators are perfectly valid - particularly for > older systems. And that is based upon real experience you have with the emulators? I rather doubt it. I believe you are spouting.
Re: Request for Funding our Electricity
>And it's not full emulator if it doesn't emulate the > bugs. It's almost bedtime in Europe. Do you mind if I tell you a bedtime story? Years ago, a (back then) successful company selling high-end Unix-based workstations, having been designing its own systems and core components for years, started designing a new generation of workstations. As part of their design, they created a dedicated memory controller, which turned out to fit their hardware so well that it was reused on four other workstation motherboard designs. That memory controller had, among many registers, an arbitration register, used to configure the relative priority of onboard devices, as well as expansion slots, to acquire the data bus. Proper setting of this register is necessary to allow on-board devices and expansion slots to correctly perform DMA, while still allowing cache writeback to run and whatnot. The proper value for that register had to be decided at runtime. The recommended logic was to rely upon the minimal initialization done by the firmware, and then clear some bits and set some others depending upon what on-board devices would be present on the particular motherboard artwork, and what would be found in the various expansion slots. However, it turned out that, on the first few revisions of the memory controller, reading from this particular register was not reliable at all. Sometimes, one would read the correct value, and sometimes, one would read a completely wrong value, depending upon the recent activity occuring on the data bus. The hardware engineers could not figure out what exactly caused this. Most importantly, they could not figure out a reliable workaround to get the correct value out of this register. So they asked the software guys for help. And the company's homemade SVR4-based Unix grew a complex logic to decide, once and for all, which value to write to the register, without having to rely upon the previous value. And they told the hardware guys that it was ok not to worry about this issue anymore. OpenBSD runs on these systems, but we are not lucky enough to have all the necessary hardware documentation, and, for some of the bits in this register, we simply don't know when to set them, and when not to set them. Instead, the OpenBSD kernel still reads that register, several times, and has an ugly heuristic to decide when the value read is likely to be correct. And then we only flip the bits we know for certain we can tinker with. It's the best we can do. Assuming someone would write an emulator for that particular system: - if the ``unreliable read'' behaviour is not emulated, according to your logic, it's a bug in the emulator, which has to be fixed. - if the behaviour is emulated, how can we know it is correctly emulated, since even the designers of the chip did not spend enough time tracking down the exact conditions leading to the misbehaviour (and which bogus value would be put on the data bus). You may argue that, since the kernel has a workaround for this issue, this is a moot point. But if some developer has a better idea for the kernel heuristic, how can the new code be tested, if not on the real hardware? Miod
Re: Request for Funding our Electricity
On Fri, Jan 17, 2014 at 11:32:41PM +, Miod Vallat wrote: > >And it's not full emulator if it doesn't emulate the > > bugs. > > It's almost bedtime in Europe. Do you mind if I tell you a bedtime > story? > > Years ago, a (back then) successful company selling high-end Unix-based > workstations, having been designing its own systems and core components > for years, started designing a new generation of workstations. > Assuming someone would write an emulator for that particular system: > - if the ``unreliable read'' behaviour is not emulated, according to > your logic, it's a bug in the emulator, which has to be fixed. > - if the behaviour is emulated, how can we know it is correctly > emulated, since even the designers of the chip did not spend enough > time tracking down the exact conditions leading to the misbehaviour > (and which bogus value would be put on the data bus). > > You may argue that, since the kernel has a workaround for this issue, > this is a moot point. But if some developer has a better idea for the > kernel heuristic, how can the new code be tested, if not on the real > hardware? > The problem with this story is that the purported reasons for supporting old architectures is to shake out bugs. How do the bugs get shaken out? By exercising shared, core functionality in distinctive ways. Idiosyncracies such as the above are not the type of thing that helps shake out core bugs. So there are two ways to resolve this discrepency: either it simply makes more sense to shift to emulated environments for older hardware; or one of the primary reasons also includes actually running on creaky, old hardware--the coolness factor. I suspect the coolness factor looms large. And there's nothing wrong with that. OTOH, there's a strong case to be made for simply inventing crazy architectures out of whole cloth and writing an emulator for them.
Re: Request for Funding our Electricity
> > You may argue that, since the kernel has a workaround for this issue, > > this is a moot point. But if some developer has a better idea for the > > kernel heuristic, how can the new code be tested, if not on the real > > hardware? > > > > The problem with this story is that the purported reasons for supporting old > architectures is to shake out bugs. How do the bugs get shaken out? By > exercising shared, core functionality in distinctive ways. > > Idiosyncracies such as the above are not the type of thing that helps shake > out core bugs. You've missed the point. These idiosyncracies must be stepped over, so that we can have working platforms different from x86, to then go discover the core bugs! Luckily we have people in our group who support such other architectures in our tree, to give us this capability. Let's face it. OpenBSD has this as a bug reducing mechanism available, and most other systems do not anymore, having decided to chase only the market-chosen architectures. It is a true many-eyes "machined" solution. What other community has users who commonly run upstream software on 64-bit big-endian strict alignment platform with register windows adjusting the frames in odd ways, or 32-bit big-endian ones with mutex alignment requirements, or a pile of other requirements. Quite frankly, I am not alone in being sick of people who don't use emulators, stepping in to tell we should use emulators. Finally, we have people who want to work on those architectures. You prefer they quit? You think their experience and the time they spend will be better spent somewhere else, that they will continue to be valuable additions in some other role? First you are wrong, and secondly, who gave you the moral authority to try to reassign their time? Why is there this effort to convince us to do less?
Re: Request for Funding our Electricity
> OTOH, there's a strong case to be made for simply inventing crazy > architectures out of whole cloth and writing an emulator for them. I am looking forward to seeing yours. How long do I have to wait?
Re: Request for Funding our Electricity
On Fri, Jan 17, 2014 at 07:33:01PM -0700, Theo de Raadt wrote: > > > You may argue that, since the kernel has a workaround for this issue, > > > this is a moot point. But if some developer has a better idea for the > > > kernel heuristic, how can the new code be tested, if not on the real > > > hardware? > > > > > > > The problem with this story is that the purported reasons for supporting old > > architectures is to shake out bugs. How do the bugs get shaken out? By > > exercising shared, core functionality in distinctive ways. > > > > Idiosyncracies such as the above are not the type of thing that helps shake > > out core bugs. > > You've missed the point. > > These idiosyncracies must be stepped over, so that we can have working > platforms different from x86, to then go discover the core bugs! > > Luckily we have people in our group who support such other > architectures in our tree, to give us this capability. > > Let's face it. OpenBSD has this as a bug reducing mechanism > available, and most other systems do not anymore, having decided to > chase only the market-chosen architectures. It is a true many-eyes > "machined" solution. > > What other community has users who commonly run upstream software on > 64-bit big-endian strict alignment platform with register windows > adjusting the frames in odd ways, or 32-bit big-endian ones with mutex > alignment requirements, or a pile of other requirements. > > Quite frankly, I am not alone in being sick of people who don't use > emulators, stepping in to tell we should use emulators. I do use emulators, specifically for ARM, because it's just easier for me. And one of my co-workers is a contributor to the Hercules emulator. > Finally, we have people who want to work on those architectures. You > prefer they quit? No, I don't prefer they quit. I donate to OpenBSD because you guys do the hard work. And the golden rule of open source is that he who does the work gets to make the decisions about how he's going to go about doing that work. So, please don't misunderstand me. I'm not questioning why you guys use so much power with old hardware. I'm not writing the code, so it's not my place to question. And while emulators might, arguably, be more efficient in some abstract sense, what matters is how the work is being done today. And if you say using real hardware is easier for your workflow, so be it. And, FWIW, I love the idea of a CD subscription service. I often end up forgetting to buy a CD. I upgrade most of my systems remotely (with a 13 year track record of never losing a machine--thanks!), so I never have to actually use the CD.
Re: Request for Funding our Electricity
> I do use emulators, specifically for ARM, because it's just easier for me. > And one of my co-workers is a contributor to the Hercules emulator. Then you know it is not sufficient for our needs, yet we keep getting the same message from some people. The emulators are too slow, or they need to be run on super fast xeons and suddenly draw even more power. The suggestion is totally out of touch. > > Finally, we have people who want to work on those architectures. You > > prefer they quit? > > No, I don't prefer they quit. But you've instructed us to power the machines off and move to emulators. > So, please don't misunderstand me. I'm not questioning why you guys use so > much power with old hardware. It is not a lot of power; that is a myth. The power bill is around $1500/month, to run 2.5 racks of equipment with really good air conditioning. Relative to this, 1 full rack in a Calgary datacenter is over $1000/month. Considering this is 2.5 racks the current operation is VERY COST EFFECTIVE RELATIVE TO THE ALTERNATIVES. Has anyone come up with an offer for 3 free racks in Calgary? NO. Even if someone would, would it make sense? NO. > I'm not writing the code, so it's not my place to question. You said it yourself, it is not your place to question. Yet, you that is precisely what you are doing. > And, FWIW, I love the idea of a CD subscription service. I often end up > forgetting to buy a CD. I upgrade most of my systems remotely (with a 13 > year track record of never losing a machine--thanks!), so I never have to > actually use the CD. Why do you need a subscription? You can go order the ones you are missing (right now), and even save postage since a whole bunch fill arrive at once. There is no need to setup the additional overhead of managing subscriptions, for people like you. Wow, so many crazy suggstions.
Re: Request for Funding our Electricity
On Fri, Jan 17, 2014 at 08:38:05PM -0700, Theo de Raadt wrote: > > I do use emulators, specifically for ARM, because it's just easier for me. > > And one of my co-workers is a contributor to the Hercules emulator. > > Then you know it is not sufficient for our needs, yet we keep getting > the same message from some people. The emulators are too slow, or they > need to be run on super fast xeons and suddenly draw even more power. > The suggestion is totally out of touch. I don't know that personally. I do believe that the particular anecdote I replied to is an insufficient premise to support the avowed need mentioned in your ruBSD talk, namely the ability to stress core services like memory management in diverse ways. But I'm content taking your word for it. And I'm not trying to argue with you. Obviously the issue is far more complex than an interview and anecdote let on. > > > Finally, we have people who want to work on those architectures. You > > > prefer they quit? > > > > No, I don't prefer they quit. > > But you've instructed us to power the machines off and move to emulators. I never argued any such thing. > > So, please don't misunderstand me. I'm not questioning why you guys use so > > much power with old hardware. > > It is not a lot of power; that is a myth. It is a lot of power considering that my modern, 4-core Haswell Xeon 1U servers draw less than 50W at maximum load. I used to run OpenBSD on Sparc and Alpha, and they drew more power than that at idle. But that's beside the point, because I'm not attacking OpenBSD's infrastructure setup. > > I'm not writing the code, so it's not my place to question. > > You said it yourself, it is not your place to question. Yet, you that > is precisely what you are doing. I disagree. I merely made a point about an anecdote. I apologize if my quip about "coolness factor" struck a nerve. > > And, FWIW, I love the idea of a CD subscription service. I often end up > > forgetting to buy a CD. I upgrade most of my systems remotely (with a 13 > > year track record of never losing a machine--thanks!), so I never have to > > actually use the CD. > > Why do you need a subscription? You can go order the ones you are > missing (right now), and even save postage since a whole bunch fill > arrive at once. There is no need to setup the additional overhead of > managing subscriptions, for people like you. > > Wow, so many crazy suggstions. I never suggested a CD service. Somebody else suggested it and I thought--apparently erroneously--that it received a favorable comment from someone on the OpenBSD team. In any event I just discovered the monthly donation subscription on the Foundation website and have signed up for a $20 monthly donation. So the CD subscription is less of a useful idea than it initially appeared.
Re: Request for Funding our Electricity
I do not doubt that emulators can be useful for some things. Indeed, I use them myself when real hardware isn't available. but emulators have limits -- invariably they are written to emulate certain things accurately (albeit imperfectly, because all programmers make mistakes) while other things deemed less important are emulated less accurately, or simply substituted with ideal mathematical constructs. lately, I've been running a PDP-11 emulator that doesn't even bother to simulate memory errors -- every byte of memory in the simulated system is error-free, and therefore parity error traps are never generated (and the parity trap handler in the operating system is therefore never exercised). you are not going to track down a cache coherency bug using an emulator that doesn't attempt to emulate cache *incoherency*. really, in order to know whether emulation is going to be useful, you need to consult an expert in the particular part of the system you're trying to emulate. this means, if you're looking for bugs in an operating system, you need to talk to people who write operating systems, because they are the experts on the hardware behaviors that actually matter. some things that an emulator faithfully reproduces probably aren't that important to an operating system, while other things the emulator doesn't bother to accurately simulate may be critically important. how can we tell the difference? if only we had someone with years of experience doing this type of work who could tell us whether emulation is adequate in this situation or not. -ken
Re: Request for Funding our Electricity
Am 17.01.2014 22:14 schrieb Kevin Lyda: That's a bug to be filed against an emulator. And it's easier to do that *now* when the older hardware is around to test for bug compatibility. And how do you do that when the hardware has gone? And I must admit the resistance to this is weird. This all ends in places like NetBSD where cross-compiling is "good enough". Just to find out that a native build didnt work any longer. Stop dreaming in emulators.
Re: Request for Funding our Electricity
On Sat, Jan 18, 2014 at 7:53 AM, Brett Lymn wrote: > On Fri, Jan 17, 2014 at 07:33:01PM -0700, Theo de Raadt wrote: >> >> What other community has users who commonly run upstream software on >> 64-bit big-endian strict alignment platform with register windows >> adjusting the frames in odd ways, or 32-bit big-endian ones with mutex >> alignment requirements, or a pile of other requirements. >> > > NetBSD does but they also went down the path of making cross compilation > easy so you can build all of NetBSD for, say, arm in about 20 minutes on > a modern x86 machine. NetBSD doesn't test their system on all the machines they claim to support. OpenBSD does. If you have a very old or exotic machine, you're lucky if NetBSD boots at all, and if it does boot, you're lucky if it doesn't hardlock in the first minute of operation. OpenBSD is not like this, the hardware claimed supported is actually supported. All the people suggesting emulators remember this. -- Aram Hăvărneanu
Re: Request for Funding our Electricity
I notice a lot of people have suggested "use an emulator," as if that had never occurred to the OpenBSD developers before, but nobody has volunteered to verify that the available emulators are good enough to actually replace real hardware. Also, I don't understand why anyone thinks emulation would reduce the power bill. Even assuming the OpenBSD developers were interested in using emulators it's not like they're just going to install one and then power down the old machines. The old hardware would still run while they're validating the emulators, and that process would probably take a really long time. So there's no potential cost savings for a really long time, and in the meantime some of the devs are now distracted from actually working on OpenBSD because they're so busy verifying the accuracy of the emulators.
Re: Request for Funding our Electricity
On 18 Jan 2014, at 04.33, Theo de Raadt wrote: > > Why is there this effort to convince us to do less? > I do not propagate such a train of thought; only said that if you want corporate funding then be prepared to detail your costs and justify each and every one of them as well as satisfying said corporation’s business interest. Not trying to be condescending here at all, but that’s just Logic 101. The sad and really embarassing fact is that I am not in a position to make any sort of donation at this moment, but I promise you that I will do it just as soon as I can. And I hope it’s the thought that counts more than the amount. I appreciate your work, a lot - I really do. -mike
Re: Request for Funding our Electricity
> > The old hardware would still run while they're validating the emulators, > > and that process would probably take a really long time. > > > > If the tests are as good as this project claims them to be, the process > should take exactly one test cycle. If that's the case, then the test > regime suck big time. Logic brother. Logic. the OpenBSD project's purpose is not to test emulators. As a result, we make no claims about our ability to test emulators. thanks for the lesson in logic.
Re: Request for Funding our Electricity
On 18 Jan 2014, at 20.15, Jan Stary wrote: > On Jan 18 16:29:46, m...@sci.fi wrote: >> On 18 Jan 2014, at 04.33, Theo de Raadt wrote: >> And I hope it?s the thought that counts more than the amount. > > LOL, yes, especially when it comes to bills being paid. > You, too, sir, can also take an overdose of fugoff. 1 > 0, no matter how you look at it. I will do what I can. And do not private message me again without including the rest of the addresses included in the original context. Or are you simply seeking supply? -mike
Re: Request for Funding our Electricity
On 19 Jan 2014, at 01.36, Jan Stary wrote: > > So, the 1 is the thought, and the 0 is the amount? > > Sorry, but your comments were so ridiculous I couldn't help it. > Saying it's the thougth that counts to people who have > repeated explicitly they need MONEY. There you go again with your simple inability to understand what "Reply All" means. > >> I will do what I can. And do not private message me again without including >> the rest of the addresses included in the original context. Or are you >> simply seeking supply? > > ? > A "supply" of what? > No comment. —Mike
Re: Request for Funding our Electricity
On Jan 18, 2014, at 16:25, Sia Lang wrote: > If the tests are as good as this project claims them to be, the process > should take exactly one test cycle. If that's the case, then the test regime > suck big time. Logic brother. Logic. I don't know what tests you're referring to. OpenBSD builds & runs on real hardware. The process of doing that continuously on every arch is what exposes the bugs that are common across all archs but only easily triggered on some. Since you're well versed in logic you clearly understand the implications of moving this process from real hardware to emulators: if the emulators don't expose bugs you can't know if that's because of problems in the emulator itself; if the emulator does expose bugs then you can't know if that's because of bugs in the emulator itself. So, clearly there would have to be some period of first verifying the emulators themselves, which is not something the OpenBSD developers are doing at the moment. Those tests don't exist; that test cycle has never happened before. Brother.
Re: Request for Funding our Electricity
previously on this list Theo de Raadt contributed: > > > > If the tests are as good as this project claims them to be, the process > > should take exactly one test cycle. If that's the case, then the test > > regime suck big time. Logic brother. Logic. > > the OpenBSD project's purpose is not to test emulators. And this should be obvious to many that it is a time consuming task to prove or even have confidence of. Virtualbox without hardware virtualisation still crashes OpenBSD never mind being accurate because it's memory handling implementation is so far removed from x86 atleast. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
