Request for Funding our Electricity

classic Classic list List threaded Threaded
119 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Marcus MERIGHI
Am 01/16/14 18:05, schrieb Han Hwei Woo:
> Rather than raising prices on CD's/T-Shirts, how about allowing for
> subscriptions? I've bought CD's and shirts in the past, but don't do so
> regularly simply as it's not something I think/remember to do at every
> release. However, I'd gladly signup to purchase a CD and T-Shirt every
> release on an ongoing basis.

+1 for help on compensating my brain shortcomings.

Bye + OpenThanks(tm), Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Kevin Chadwick-2
In reply to this post by Dag Richards
previously on this list Dag Richards contributed:

> I have a suggestion for every one of us that has mailed in an idea in
> response to a solicitaion for money...
>
> Send money.

I also plan to open a ticket and will have to find time to send a short
letter to the management of my hosting providers asking if they donate
to Linux and if so do they donate to OpenBSD as OpenSSH is developed
primarily by OpenBSD devs and not Linux.

I can almost guarantee there are companies out there donating to Linux
thinking they are also supporting SSH by doing so.

--
_______________________________________________________________________

'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
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Request for Funding our Electricity

Jan Lambertz
In reply to this post by Marcus MERIGHI
Pushing the subscription idea and cd set selling a litte bit further, what
about a signed cd set or artwork from theo or a developer ( next hackathon
) . The time investment should be no problem and this could sell for ...
70$ or something.
This is cool, no time effort,  promotion easy possible ( undeadly etc)

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Charles RAPENNE-3
In reply to this post by Theo de Raadt
Le 2013-12-21 01:08, Theo de Raadt a écrit :

> 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.


Hello,

I think this could be great if OpenBSD had somewhere on their website a
goal/objectif about the money to rise, and the % of advancement of it.
The FreeBSD Foundation is doing this, I think this is very effective as
you know if they really lack some founds or if they are near their
objective.

I tried this method for one little project of mine involving some costs
(~ 400 € / year), after yelling every year "please give some money, this
doesn't run for free"... I put a visual show of my needs, then I got 40%
of my funds the day I put the advancement image of the fundraising.


Thank you everyone for doing what you do for OpenBSD :)

Kind Regards

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Lars Peter Cleary
I agree this is a very good idea, instant feedback and gratification.

Nevertheless, I've just now donated CAD 100.- and invite everybody
else to do the same.

Kind regards
Lars

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Stefan Wollny
Am Fri, 17 Jan 2014 16:08:07 +0100
schrieb Lars Peter Cleary <[hidden email]>:

> I agree this is a very good idea, instant feedback and gratification.
>
> Nevertheless, I've just now donated CAD 100.- and invite everybody
> else to do the same.
>
> Kind regards
> Lars
>


Yepp - let's face it: Until some bigger company decides to join in and
supports the project 'we the users' have to take responsibility and
donate some extra money right now! The developers already donate a lot
more - time, efforts and know-how.

Besides donating a little amount each month on a subscription basis I
just donated EUR 120,- additionally. It is a darn good investment!

Cheers,
STEFAN

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

LeviaComm Networks NOC
In reply to this post by Theo de Raadt
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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Kevin Lyda
On Fri, Jan 17, 2014 at 8:23 PM, Christopher Ahrens <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Bill Albertson-2
In reply to this post by LeviaComm Networks NOC
On Fri, Jan 17, 2014 at 12:23 PM, Christopher Ahrens <[hidden email]>wrote:

> 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.
>
>
>Please continue to do this.  Cash, code and correct docs help OpenBSD,
dreaming doesn't.

I've donated $20 a month in perpetuity via
http://www.openbsdfoundation.org/donations.html.  The community needs less
than 99 other donors willing to admit that OpenBSD is worth more than a
pizza.  This doesn't even begin to make up for the benefit I've received
from the project, but it is a start.

A small suggested change to the OpenBSD.org page header- put a donate
button and a small message under the header picture.  "We need X financial
maintainers @ $20 a month."  I completely forgot that I could donate until
I saw this thread come up on reddit.com/r/programming, and it didn't even
occur to me that I should be donating monthly until I read the thread.
 Sometimes, you just have to be that obvious to people, and it may be
easier to ask for a few new donors every so often than to be beholden to a
single large donor.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Chris Cappuccio
In reply to this post by Kevin Lyda
Kevin Lyda [[hidden email]] wrote:
>
> It's a lot easier to ask for $X/year if there's a plan for X to reduce.
>

Yeah, right. That's how things work, right? Your family spends less each year,
your work spends less each year, your government, they certainly spend less
each year. And OpenBSD, OpenBSD spends less each year. Just like everyone else!!!

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Theo de Raadt
In reply to this post by Theo de Raadt
>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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Miod Vallat
In reply to this post by Kevin Lyda
>                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

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Ed Ahlsen-Girard-2
In reply to this post by Theo de Raadt
Dear Misc,

In re electricity, please do one of the following:

1. Send money.
2. Convince OTHER PEOPLE to send money.
3. Stop summoning the Good Idea Fairy to the developers. I have
seen the suggestions, and it's not that none of them could
possibly work. It's that all of them *would have to be worked*, and
whichever developers are working them will not be employed in their best
and highest use.

Dear Developers,

Thanks.

--

Edward Ahlsen-Girard
Ft Walton Beach, FL

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

William Ahern-2
In reply to this post by Miod Vallat
On Fri, Jan 17, 2014 at 11:32:41PM +0000, 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.
<snip>

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Theo de Raadt
In reply to this post by Theo de Raadt
> > 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?

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Theo de Raadt
In reply to this post by Theo de Raadt
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

William Ahern-2
In reply to this post by Theo de Raadt
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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Theo de Raadt
In reply to this post by Theo de Raadt
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

William Ahern-2
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.

<snip>
> > 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.

Reply | Threaded
Open this post in threaded view
|

Re: Request for Funding our Electricity

Tobias Ulmer
On Fri, Jan 17, 2014 at 08:10:02PM -0800, William Ahern wrote:
[...]

Compared to your suggestions, Die Hard 2-5 didn't contain any plot holes
and made perfect sense.

You are not arguing, but obviously, emulators are so much better.

With just a couple of modern Xeon machines (these are free, obviously),
writing or patching up a couple of emulators (with performant JIT backends,
of course), we could easily halve(!) our power bill.

How to emulate a bunch of +-1GHz SMP RISC machines or even just a 200MHz
sparc at native speed is, of course, left as a finger exercise to the
developers, while they also improve OpenBSD as per usual.

Just stop, please.

123456