date:20140116

Re: Request for Funding our Electricity

2014-01-16 Thread Maximo Pech

 El 20/12/2013, a las 18:08, Theo de Raadt dera...@cvs.openbsd.org escribió:
 
 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.

Well, we know that energy prices will continue to increase, not decrease, so 
this will be harder in the future. 

Whit this in mind, why not look for a strategy to save up on energy costs. 
Something like this:

Through the history of openbsd there have been architectures in which more bugs 
have been found and some in which fewer bugs have appeared.

Then maybe the number of bugs for an architecture can be matched to the 
power-on-time for the machines for that architecture.

For example, if 1% of the total number of bugs in the history of openbsd have 
appeared on architecture x, then it's likely that it will continue to be so, 
then all the machines for that architecture should be powered on just 1% of the 
time.

Then perform that analysis on all architectures to make a more better use of 
energy. And that's it.

Re: Request for Funding our Electricity

2014-01-16 Thread Theo de Raadt

Through the history of openbsd there have been architectures in which more 
bugs have been found and some in which fewer bugs have appeared.

That is not true.

Then maybe the number of bugs for an architecture can be matched to the 
power-on-time for the machines for that architecture.

Maybe.  Probably need them on to prove or disprove the point.

For example, if 1% of the total number of bugs in the history of openbsd have 
appeared on architecture x, then it's likely that it will continue to be so, 
then all the machines for that architecture should be powered on just 1% of 
the time.

Another great advantage here is that all the pesky developers who love those 
machines will go away, and we'll only need to run on the best architectures 
(which of course, are big endian).

Then perform that analysis on all architectures to make a more better use of 
energy. And that's it.

It's so simple.  Why didn't I think of it.

Re: Request for Funding our Electricity

2014-01-16 Thread Sia Lang

Virtual machines/emus and canadian cross builds should be able to reduce
the amount of iron, no?


On Thu, Jan 16, 2014 at 12:53 PM, Theo de Raadt dera...@cvs.openbsd.orgwrote:

 Through the history of openbsd there have been architectures in which
 more bugs have been found and some in which fewer bugs have appeared.

 That is not true.

 Then maybe the number of bugs for an architecture can be matched to the
 power-on-time for the machines for that architecture.

 Maybe.  Probably need them on to prove or disprove the point.

 For example, if 1% of the total number of bugs in the history of openbsd
 have appeared on architecture x, then it's likely that it will continue to
 be so, then all the machines for that architecture should be powered on
 just 1% of the time.

 Another great advantage here is that all the pesky developers who love
 those machines will go away, and we'll only need to run on the best
 architectures (which of course, are big endian).

 Then perform that analysis on all architectures to make a more better use
 of energy. And that's it.

 It's so simple.  Why didn't I think of it.

Re: Request for Funding our Electricity

2014-01-16 Thread frantisek holop

hmm, on Wed, Jan 15, 2014 at 08:14:24PM +0100, Peter J. Philipp said that
 # pkg_add somepackage
 ...
 This package's buildtime was generously donated by Peter J. Philipp.
 #

ads in openbsd?  you must be out of your mind.
what next, adblock for openbsd?

-f
-- 
why do they call it a tv set when you only get one?

NIST-free crypto, autociphering, and libsodium (NaCl)

2014-01-16 Thread MJ

Hello,

I would like to inquire as to which OpenBSD RELEASE will offer the possibility
to avoid NIST crypto for everything in Base (isakmpd, openssh, openssl, https,
nginx being the key items in mind)?

BTW, looks like things are heading in the right direction
(http://www.slideshare.net/yandex/rubsd2013-mikeben)

As it stands, there is currently cipher-suite negotiation / configuration
coded into every single crypto-enabled tool / daemon and its a bit of a mess
and a headache to manage it all. Would it be good to start to think about
having a single, system-wide cipher-suite negotiation configuration and
socket? interface and removing all this mess from things like isakmpd,
openssh, openssl, httpd, nginx, etc? For example, one could specify a
preferred ordered list of cipher suites and ones that arent listed would be
completely avoided at the system level. This could, for example, eliminate
static algorithm configuration in ipsec.conf and instead start negotiation
traveling down the ordered list until either success or end of list. This
method would provide an abstract interface to avoid future version downgrade
attacks, i.e. no need to update anything other than the configuration file.

And, of course, the autocipher engine would be powered by libsodium (NaCl).

Thoughts, comments, insults, etc, are all welcome! The quantum computer is
coming soon to a theatre near you.


-mike

Re: Process monitoring

2014-01-16 Thread Giancarlo Razzolini

Em 16-01-2014 02:59, Cyrus escreveu:
 I am looking for ways to monitor processes on the system in the long
 term. It would be helpful to get a bigger picture about how the
 individual processes of users contribute to load averages. It would go a
 long way in diagnosing problems related to load.

Cyrus,

There are lots of ways to accomplish this. I personally use symon
and syweb. They are both in ports/packages and work nicely. There are
other options, like nagios with nagiosgraph, munin, etc. There are lots
of choices.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Request for Funding our Electricity

2014-01-16 Thread Luca Ferrari

On Thu, Jan 16, 2014 at 1:10 PM, Sia Lang silverlangu...@gmail.com wrote:
 Virtual machines/emus and canadian cross builds should be able to reduce
 the amount of iron, no?


I don't think virtual machines are the solution: I see them as another
buggy ecosystem on which developers will try to debug their code.
A lot of people on this thread are suggesting to remove/reduce
platforms OpenBSD supports, and it seems to me it is pretty clear the
project will not do that (and I appreciate the decision).
We have to deal with supporting OpenBSD, not trying to shrink the project.

Luca

Re: Request for Funding our Electricity

2014-01-16 Thread Gregor Best

On Wed, Jan 15, 2014 at 09:55:04PM +, Franchini Fabien wrote:
[...]
I suggest to write a letter to theses companies who are known to using OpenBSD
or other product-related like OpenSSH. In this letter we can explain (as the
first
post from Theo) our issue. I'm sure they can give us an hand if they know our
problem. And in my opinion, ONLY a company can give us a long-term solution.
[...]

Maybe to inject a further point into this discussion... One of these
companies is Apple. They replaced ipfw with pf in recent releases of
Darwin (see [0]).

Since, with Darwin being Open Source, they seem not entirely against
spending resources on Open Source Software, and they profit in no small
margin from the OpenBSD project and its satellites like OpenSSH, they
might be a good recipient for a polite letter in request of help. Not
the least because they could use their assistance in their marketing
(Look how cool we are, we are paying them their electricity!).

60 matches

Mail list logo