Hacker News new | past | comments | ask | show | jobs | submit login

Moores Law works to make it eventually more than fast enough.

Moores Law does not help it get more secure.

How about we work on things that mater in this post-Snowden world, like increasing security -- and let Moore do the performance improvements! Seems a more reasonable and efficient approach, no? Adding more attackable surface area to the Kernel is not a good idea at all. It is an NSA wet dream.




Moore's law makes it faster, but Wirth's law compensates for that dearly. Let's also not forget that pesky Amdahl making our bottlenecks stay bottlenecks, as some things are just fundamentally wrong for performance.


Kinda good points; however: Wirth's law is more true for commercial software where profit is the motive. Amdahl's law only really makes sense in parallel computing. All that is beside the real point; which is that in this post-Snowden world, we should not be sacrificing security for performance.


Wirth's law is more true for commercial software where profit is the motive.

How I wish. Sure, for proprietary and commercial consumer-facing apps, it might be the case. There's a ton of proprietary/commercial development tools and infrastructure (hyper-optimized JVMs, k/kdb...) that are inverses of Wirth. FOSS has its opuses as well, but it's just as full of crap.

Amdahl's law only really makes sense in parallel computing.

Sure, but that doesn't mean one can just magic away blatant bottlenecks, and even if some speedup is possible, it does not retroactively make these decisions correct.


> Amdahl's law only really makes sense in parallel computing.

Contemporary computing is parallel computing. Even phones have multiple cores.


Nice job missing the point.


Security is usually correlated with efficiency, not inefficiency. Think djbware. If something is inefficient, it means nobody has bothered thinking through the design, and well...


So let us make the user space implementation more performant instead of going down the more inherently risky path in regards to security.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: