3 ms·
I'd prefer my libraries be rock solid secure even if I lose some (or even a lot of) performance for it. Hardware is always getting cheaper. Losing data integr
by krschultz 17y ago
I'd prefer my libraries be rock solid secure even if I lose some (or even a lot of) performance for it.
Hardware is always getting cheaper.
Losing data integrity and the trust/confidence of your users is extremely expensive, and can be fatal for a startup.
Performance is not the most important metric for a lot of applications.
I'd prefer the safe but slow 5 star crash test rated sedan with a good alarm over the race car that is going to blow up after a few races, in library terms.
- pyre 17y ago> Hardware is always getting cheaper. This is a poor justification. A few years ago a house was a good investment because 'housing prices will always be going up.'
- bmj 17y agoThat, and not every program runs on ever-faster hardware.
- evgen 17y agoPlease provide even a single deluded fantasy in which the price/performance ratio for a particular piece of hardware or component in the hardware stack will not continue to trend in the direction of more bang for the buck.
- tow21 17y agoI don't know if this counts as "deluded", but how about: resource exhaustion of raw materials required in hardware manufacture. See, for example: http://blogs.wsj.com/informedreader/2007/05/25/a-metal-scare-to-rival-the-oil-scare/ http://blogs.wsj.com/informedreader/2007/05/25/a-metal-scare... which talks primarily about LCD displays (we're fast running out of Gallium/Hafnium/Indium), but points out that copper is likely to get significantly more expensive throughout this century. That's going to increase the price/performance ratio of practically everything.
- krschultz 17y agoSilicon makes up much more of the cost of a computer than copper, its not even close. Silicon is >50 cents a gram, copper is less than a cent per gram.
- tow21 17y agoThat's what the significantly was all about. We're not really going to run out of silicon any time soon, but we actually might with copper. At the moment, both those prices are strongly dominated by the cost of processing, I would imagine. At some point, it could well be the scarcity you're paying for with copper, though. Scarcity increases price, and two orders of magnitude is hardly inconceivable.
- billswift 17y agoYep, that's a deluded fantasy all right. See "Ultimate Resource 2", "The Resourceful Earth", or "State of Humanity" by Julian Simon or "Earth Report 2000" by Ronald Bailey.
- scott_s 17y agoRelying on single-thread (execution context/core) performance to increase is a mistake.
- evgen 17y agoYes, but I can't imagine any realistic scenario where this performance will start to backslide. The rate of performance increase will continue to slow down, and the number of cores that you get per unit will increase, but "the hardware" in the most general sense will keep getting faster and cheaper over time.
- scott_s 17y agoFirst, you said an upward trend - I submit that any meaningful upward trend in single core performance has ceased. Further, it has backslided in many cases. In order to increase the number of cores per processor, each core is getting simpler by reducing or eliminating single-threaded optimizations like branch prediction and out-of-order execution.
- pyre 17y ago"People always need a place to live so real estate/housing prices will always be going up. There is only a limited amount of land on the Earth, but the population continues to grow."
- ncarlson 17y ago> I'd prefer my libraries be rock solid secure even if I lose some (or even a lot of) performance for it. Then don't use C. People don't seem to understand that C is just a step up from Assembly Language. There are no "types" in the sense that they exist in higher level languages. And thus, there are no ways to check those types (unless you want to write a type checking system yourself). Lets not forget that most modern programming languages with type checking and "rock solid secure" libraries were, in fact, written in C.
- jrockway 17y agoWhich languages? SBCL is written in CL, GHC is written in Haskell, etc. Sure, there is some C to talk the C-based API of the OS it's running on, but all the important stuff is self-hosted. This is a rather common pattern, as nobody really wants to write important application code in C.