Hacker Newsnew | past | comments | ask | show | jobs | submit | thuffy's commentslogin

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.


Let's talk about the elephant in the room.

This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel.

They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux.

First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.


systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa.

Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.


I absolutely agree it is a mess for other reasons as well; but let us attack it on all angles, and I think security is the most important one these days.


Solved this without even a pencil and paper, just in my head, in under 60 seconds while being distracted by another person in the room asking me what to have for breakfast. There is only one possible answer as the others pointed out; you are definitely wrong that the answer is indeterminable.

The whole ruckus surrounding this problem seems to be more a reflection of the sad state of the intelligence in our population, rather than anything to do with Asia.


Contrast this (Chinese eugenics) with our dysgenic system of subsidizing defective genetics for the profit of the medical industry, and, well, the obvious result is that western civilization is in big trouble!

More info from this link that shiven shared below: https://edge.org/response-detail/23838


Python 3's asyncio / co-routines is the reason to write any new project in Python 3.

The API is tiny, and the result is beautiful.

If you haven't seriously tried using it to implement something that really benefits from such computer science innovation, then you have simply seen nothing of Python 3 yet. There are many types of logic that are vastly simplified with such a programming paradigm. Faster to code, and far simpler to debug. By orders of magnitude. One example you could try if you cannot envision one is to implement a high performance network protocol. I for instance implemented the SSH protocol from scratch (RFCs) in a matter of weeks. I though it would take months before I tried, especially since I had never programmed in Python before! As I said, the API is tiny. Learning it (Python and Asyncio at once) was so easy and ended up taking such an insignificant amount of time compared to the vast quantities of time and headache saved, that, well, I just had to write this post with all that extra time and energy!

Check it out! You will find that it is beyond worth just addressing whatever fears or problems you have with making the switch.


Im sure most people will start to use Python 3 for one of those large new features, but to me its all the small QoL changes for the standard library which I constantly see when searching for tricky problems and finding them in SO.


asyncio seems to me like it should be the biggest killer app for Python 3 - a universal replacement for the sprawling, confusing, and opposing async options out there for Python 2.x (Twisted, Tornado, gevent...).

I'm hoping that aiohttp, or a similar library, further matures and we start seeing apps built on it. Developing asynchronous HTTP code in Python 2.x is significantly harder than throwing together a Node app, where things are "asynchronous by default" (unlike, say, Flask or Django). Having a universal, built-in event loop removes a huge point of confusion and learning for async development in Python, and can hopefully bring interest from developers who would normally look to Node.


As a big fan (and user) of Twisted, I'd like to see a discussion of why I might want to use asyncio instead, besides the So-You-Can-Use-Py3 reason.


I 'll add my experience with asyncio and twisted:

1) debugging is way better in asyncio, with ipdb you can step in co-routine. In twisted, you will end up somewhere in internals.

2) asyncio is end of unhanded error in deferred :) (or you need to remember to add addErrback everywhere, even after addColbecks and addBoth)

3) with trial testing is frustrating, sometimes error raised in wrong test because of global event loop (for instance you forgot to mock external call). In asyncio world loop passed explicitly and this is good for testing.


Well here's a great blog post on how to use the @asyncio.coroutine decorator to do asynchronous/non-blocking I/O in this style, as opposed to JS-style callbacks. I think the control flow is a lot clearer with coroutines as opposed to callbacks. I've never used Twisted though so I'm not sure how asyncio compares to that library.

http://sahandsaba.com/understanding-asyncio-node-js-python-3...


Is there a thorough getting started guide for asyncio floating someplace on the web? I tried to pick up asyncio a few weeks ago. The official documentation assumes a lot of background that I don't possess, despite being a long-time Python user. Each method and class seems to be documented, but conceptual and end-to-end examples were much less common. Thanks in advance!


asyncio is just nice API for async programing and event loop management. You should start from something high level in order to obtain asyncio ideas, like scraping [1] or try web development with aiohttp [2]. And then if you want to write some library or port database driver, look for examples at aio-libs[3] github organization.

[1] http://compiletoi.net/fast-scraping-in-python-with-asyncio.h...

[2] https://github.com/KeepSafe/aiohttp

[3] https://github.com/aio-libs


Any interest in opening that SSH implementation up to the world. I wouldn't mind getting my hands on it and (maybe) even contributing.


Good news then!

I'll be releasing the greater project shortly as GPL, with the SSH implementation as LGPL! I'll announce on HN for sure then.

Guido, if you want to put it in Python itself, you can have it in whatever license you need for that.


I don't think so especially since it still uses bytes to output to a webserver, even go is way better for this kind of tiny library. For bigger projects i would still go the java route especially since there is karyon from netflix.


Not at all.

The court of the people have subpoenaed this corporate information. Anyone knows that the corporate veil will be pierced in discovery.


LOL, the new Godwin's Law: Edward Snowden.

(See my valid but then NSA downvoted answer to the question below regarding GO vs. Rust that no one else could answer and were forced to make jokes about -- if you are wondering what I mean.)

Sorry rust thread. :(

(now kicked off the front page)


One force having all knowledge and controlling it, even using their advantage of information asymmetry to control it, I would say, is different enough from EVERYONE KNOWING THE TRUTH, that yes, perhaps we can have this discussion.


When a super human entity such as a corporation gains such control over humans and thus politics as does a media conglomerate such as Sony, then YES, it becomes quite obviously VERY political!


Because there is a battle going on. The lines are being drawn. People who where fighting this battle will see this happening before those who were unaware to start with; however, the lines are now being drawn thanks to Edward Snowden, and this battle is becoming visible to all.

Meaning: GO was dead at birth from out of the sphincter of the NSA.


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

Search: