On Tue, Jan 07, 2020 at 02:47:02PM +0000, cho...@jtan.com wrote: > Hamd writes: > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > ... lists full of the uninteresting type of wine and that their > > twitterings -still- don't include any code. > > Yes. Yes it is. > > Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour.
Well, that's kind of ridiculous, that's not generally how threats are remediated in the real world. If you take a server down for 15 minutes to apply patches to Insecure- But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is performing lots faster during that 99.85%, but admittedly performs at zero during the patch process. Redundancy can cover that in many cases. A different argument could be that if you require a particular level of performance, and you have to deploy more compute resources to get it, that increases capex and opex, and the end result is a greater level of e-waste down the road, and perhaps a greater amount of pollution if the power is generated from "bad" sources. In reality, when you dig down, often you find that there's another reason for the issue. I was recently trying to substitute libressl into an openssl environment. Performance tanked. Some checking showed the speed of "speed -evp aes-256-gcm" was way off. It looked to me like it was an issue with not using AES-NI. I'm not going to blame libressl for that, I just lacked the time to do a deep dive on it to figure out what was (hopefully!) configured wrong. Probably something with ia32cap or whatever the libressl equivalent is. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
