HighwayHash: Strong hashing at 0.3 clock cycles per byte - <AUTHOR> https://github.com/google/highwayhash/ <comment><USER2> Are there any better instructions for how to build this? I'm interested in it, but not having any luck with Bazel. First I failed with a permissions issue ([https://github.com/bazelbuild/bazel/issues/739](https://github.com/bazelbuild/bazel/issues/739)), then because I didn't have a "WORKSPACE" file, and now it gives me an unhelpful error message:

      nate@skylake:~/git/highwayhash$ bazel build :all -c opt --copt=-mavx2
      .....
      ERROR: /home/nate/git/highwayhash/BUILD:3:1: unexpected
      keyword 'default_hdrs_check' in call to package(*,
      default_deprecation = ?, distribs = ?, licenses = ?,
      default_testonly = ?, default_visibility = ?, features = ?,
      default_compatible_with = ?, default_restricted_to = ?).
      ERROR: no such package '': Package '' contains errors.

<comment><USER3> I'm guessing it was built and tested internally at Google and no one tested it with bazel. It also depends on smasher, which I believe should be declared in the WORKSPACE file. So unless you want to manually build it you'll have to wait for someone to fix the build.

<comment><USER2> I went ahead and created a Makefile:

      CXXFLAGS := -g -std=c++11 -Wall -O3 -march=native -Wno-sign-compare
      OBJS := highway_tree_hash.o \
      	scalar_highway_tree_hash.o \
      	scalar_sip_tree_hash.o \
      	sip_hash.o \
      	sip_tree_hash.o
      MAIN := sip_hash_main
      all: $(OBJS)
      	$(CXX) $(CXXFLAGS) $(OBJS) $(MAIN).cc -o $(MAIN)
      clean:
      	rm -f $(OBJS) $(MAIN)

Then I commented out two lines in "sip_hash_main.cc":

       // #include "smhasher.h"
       // RunAllTests(argc, argv);

Then "make" and run:

      nate@skylake:~/git/highwayhash$ ./sip_hash_main
      ScalarSipTreeHash ...	    GBps=2.44  c/b=1.44
      ScalarHighwayTreeHash ... GBps=1.16  c/b=3.02
      SipHash ...               GBps=1.54  c/b=2.27
      SipTreeHash ...           GBps=4.56  c/b=0.77
      HighwayTreeHash ...       GBps=11.49 c/b=0.30
      ...

The inner loop for HighwayTreeHash looks like this:

       0.89 │ 60:┌─→vpor   %ymm5,%ymm0,%ymm0
       4.47 │    │  vpaddq (%rcx),%ymm1,%ymm1
       6.04 │    │  add    $0x4,%rax
       0.22 │    │  add    $0x20,%rcx
       2.24 │    │  cmp    %rax,%rdi
       3.13 │    │  vpsrlq $0x20,%ymm1,%ymm2
       3.36 │    │  vpmulu %ymm1,%ymm0,%ymm4
      13.20 │    │  vpshuf %ymm3,%ymm4,%ymm4
      11.19 │    │  vpmulu %ymm2,%ymm0,%ymm2
            │    │  vpaddq %ymm1,%ymm2,%ymm1
      31.32 │    │  vpaddq %ymm4,%ymm0,%ymm0
       7.61 │    └──ja     60

<comment><USER4> Do you know if there is a reference for a comparative number of collisions anywhere e.g. ([http://programmers.stackexchange.com/questions/49550/which-h...](http://programmers.stackexchange.com/questions/49550/which- hashing-algorithm-is-best-for-uniqueness-and-speed)) ?

<comment><USER5> With a 64-bit hash, you shouldn't be seeing collisions at all on small datasets. A test such as smhasher can verify this.

</comment></comment></comment></comment></comment><comment><USER6> Oh my, again the folks who think that a better hash function saves you from DDOS attacks on collision resolution with linked lists. This is pure nonsense! Get over it please. Hashes for hash tables need to be small and fast, that's all.

First, from any hash only a few bits are use for a hash table lookup, typically between 5-8. It depends on the size of the table. You can make your hash function long and strong, but only the last few bits count, and this does not help you at all against DDOS.

Second, against DDOS only uhash, or using no linked lists or arrays with O(n/2) lookup costs help. A random seed is good, but can be detected. E.g. a timeout as used by djb in his nameserver does help better than a stronger hash function. Or using a hash table as in glibc, gcc or the linux kernel. siphash or HighwayHash does not help at all. python and perl both fell into this trap.

But I appreciate the effort to create a fast metro like hash function, without resorting to the internal crc32 builtin. Will be included in smhasher soon.

Summary: [https://github.com/rurban/smhasher#summary](https://github.com/rurban/smhasher#summary)

<comment><USER7> > First, from any hash only a few bits are use for a hash table lookup, > typically between 5-8.

This is not my experience. Frequently, hash tables will have a size that is a power of 2, and the address into the table will be all of the low order bits. A table with 1 million slots will use 20 bits of hash.

> Second, against DDOS only uhash, or using no linked lists or arrays with > O(n/2) lookup costs help.

uhash is just one example of hash function designs based on almost-universal hashing. There are many others, including VHASH and Poly1305. Is HighwayHash almost universal?

<comment><USER8> > Frequently, hash tables will have a size that is a power of 2 ...

It looked like that was what rurban was arguing? Pull out the low 5-8 bits, get a table of size 32-256?

<comment><USER6> Exactly. You attack an existing table in an application via POST request of colliding keys. This table has mostly 10-100 elements, and you need to find a collision of say ~10.000-20.000 elements to have an effect. So it starts with ~5 bits on the avg. case and gets into 13-14 bits. This is all too trivial and doesn't need a "secure" hash function, which is not secure at all and can be precomputed. It's plain security theatre by rookies. The "security" may come from the collision resolution or from the seed if you insist on cache- unfriendly linked lists or better strategies, but never from a hash function per se. With 5-14 bits you have no chance at any "security", which starts at 256 bits.

And on top of that I guess nobody ever heard of "Cache-Conscious Collision Resolution in String Hash Tables" by Nikolas Askitis and Justin Zobel, who measured that a linear search in an array for collisions outperforms a linked lists by 2-4x, even if that can do move-to-front much easier.

People still do worry about the hash function, where they do should worry about their hash tables instead, which can easily be made 4x faster and not 2x slower.

<comment><USER7> > This is all too trivial and doesn't need a "secure" hash function, which is > not secure at all and can be precomputed. It's plain security theatre by > rookies. The "security" may come from the collision resolution or from the > seed

Hash "functions" like UHASH, Poly1305, and SipHash are actually families of hash functions, parameterized by seed.

> And on top of that I guess nobody ever heard of "Cache-Conscious Collision > Resolution in String Hash Tables" by Nikolas Askitis and Justin Zobel, who > measured that a linear search in an array for collisions outperforms a > linked lists by 2-4x, even if that can do move-to-front much easier.

If an implementation is vulnerable to hash-flooding attacks because it doesn't have a randomly-seeded almost-universal hash function, then changing the collision mechanism from linked lists to arrays isn't going to fix the problem.

Good collision resolution and good hash functions are both issues worth addressing.

</comment></comment></comment></comment></comment><comment><USER7> Where can I read what they mean by "Strong" hashing for HighwayHash? Also, is there a peer-reviewed paper on SipTreeHash? I am not a cryptographer, so I wouldn't trust my own instincts in terms of evaluating its strength compared to SipHash.

For non-cryptographic applications, CLHASH produces 64 bits of result and is 2.004/2^64 almost delta universal, at a cost of 0.16 cycles per byte on Haswell and 0.10 cycles per byte on Skylake.

[https://github.com/lemire/StronglyUniversalStringHashing](https://github.com/lemire/StronglyUniversalStringHashing)

[http://arxiv.org/abs/1503.03465](http://arxiv.org/abs/1503.03465)

<comment><USER5> I hadn't seen CLHASH yet, thank you for mentioning it. Looks even faster but only XOR universal (meaning XORed hashes are uniformly distributed, not the hashes themselves). In particular, it fails smhasher's avalanche test (because bit flips have predictable effects), and their proposed fix is more expensive than a HighwayTreeHash round.

<comment><USER7> > their proposed fix is more expensive than a HighwayTreeHash round.

For longish-strings, most of the cycles are in the preliminary rounds, so appending whatever you want onto the end should add negligible cost. This includes bitmixing (their proposed smhasher fix) or a HighwayTreeHash round.

<comment><USER5> Agreed :) We (and SipHash developers) do care about short strings, though. Scripting language hash table inputs are typically around 10 bytes, so we can't ignore finalization overhead.

</comment></comment></comment></comment><comment><USER9> I'm a newb at this, but how does this compare to SHA3/blake2 in term of applications? Is it more/less/same secure?

Or better: how can I educate myself better on the proper usage of certain hashing functions?

<comment><USER10> This is a hash function (as used in hash tables/Bloom filters and so forth), but it is not a cryptographic hash function. It is designed to be very fast for things like table lookups, but it is not designed to be strongly resistant to preimages, second-preimages, or collisions. Don't use it for security- relevant purposes.

I think BLAKE2 is probably the fastest and best cryptographic hash function you're likely to see for the foreseeable future?

<comment><USER9> Thanks, that's basically what I was looking for. I have apps that are bottlenecked by blake2, so finding a faster cryptographic hash function would be pretty interesting to me.

<comment><USER11> If BLAKE2 (I assume you're using blake2b) is your bottleneck, perhaps you should consider the blake2bp (four way parallelism) or the blake2sp (eight way parallelism) variants. If even those are too slow for you (lots of continuous data and you have multiple cores available), then you might be able to try using tree hashing on top of one of the mentioned BLAKE2 variants.

I'm curious though, what are you working on that saturates ~1 GiB/s/core?

<comment><USER9> A content addressable distributed cache, where the disk + network IO capacity is ~40Gb/s. A bit similar to IPFS.

<comment><USER5> Interesting. How big do you need the hashes to be?</comment></comment></comment></comment></comment></comment>


A clean point-of-interest icon set for web cartography - <AUTHOR> http://mapbox.com/maki/

<comment><USER2> So I quickly ran the icon set through <http://icomoon.io/app> and the icon font it produced seemed pretty good <http://dl.dropbox.com/u/138393/maki.zip>

<comment><USER3> Wow, that site is a better find than the OP, now I can easily use those raw icons designers post every so often.

</comment></comment><comment><USER4> Using scroll for zoom in web maps is a horrific UI choice. Nice enough icons, although I'm not a designer.

<comment><USER5> Really? That's what Google Maps and Bing Maps does...

<comment><USER6> Sure, but they are usually on a page with almost no other content (maps.google.com and whatever the Bing URL is). This page has content that I might want to scroll down to and the scroll zoom in the map makes that more difficult.

<comment><USER5> Good point. I guess I've grown accustomed to random things on the page stealing scrolling functionality (e.g. Flash/plugins, which I've disabled now) so I usually don't try to scroll unless the mouse is on the background somewhere.

<comment><USER6> Yes! Me too. Same with focus - I often find myself subconsciously clicking the background of a page to defocus whatever the page's developer or browser has decided should be focused. Flash is definitely (or at least used to be) the worst offender.

</comment></comment></comment></comment></comment><comment><USER7> Looks good! Except for the pharmacy symbol. That information is sometimes needed in emergencies, and what you currently have was totally unrecognizable. Make it the same as hospital, or very similar?

Some other things to improve: prison sign looks like railway crossing, college cap (?) would look stupid in many locales where there is no cap or different design, embassy and bank icons were difficult to figure out. Likewise for the minefield.

<comment><USER8> Yep, pharmacy symbol is unrecognisable to me too. Unfortunately, there isn't really an internationally recognised symbol. In some countries, the recipe symbol (℞) is used; in others, a green cross; in others still, the Bowl of Hygieia.

</comment></comment><comment><USER9> Inclusion of a landmine icon is interesting, but a generic skull and crossbones may help communicate the level of danger more universally. Otherwise very nice icons.

<comment><USER8> It looks like a crown to me.

</comment></comment><comment><USER10> Nice! Last time I looked, the set created for OpenStreetMap [1] was the only freely licensed icon set I could find, so it's nice to have more options. The OSM set is also not manually designed to be pixel-perfect at each size (the SVG form is canonical, and specific sizes rasterized from that).

[1] <http://www.sjjb.co.uk/mapicons/introduction>

<comment><USER11> As the main designer behind Maki, I'd love for it to be comprehensive enough to replace the standard OSM set someday. If not on the main OSM map, at least in the editors. I have a long way to go!

</comment></comment><comment><USER12> I've seen a lot about mapbox recently and I must say I'm very impressed, love the design of their websites in particular and of course their product seems to be pretty cool. Have any of you guys tried it? I might give it a go the next chance I get..

</comment><comment><USER13> This is the first I've seen of MapBox. I'm not sure of how much use I'll get out of these icons, but my mind is percolating with possibilities for creating useful embeddable maps...

</comment><comment><USER14> The "beer" glass is to generic (I think). Why not a standard beer glass?</comment>


Opening up Posterous to 3rd Party Developers  - <AUTHOR> http://blog.posterous.com/opening-up-posterous-to-3rd-party-developers <comment><USER2> The documentation website and inline testing of this api looks great, but here's hoping they keep the old api (as documented at apidocs.posterous.com) alive.

They were kind enough to re-add location data to posts coming through the api on request as our just-launched project (<http://innertubemap.com/>) is dependent on it.

</comment><comment><USER3> I've been working on a library for the Posterous API (in my free time), and this seems like it's a lot better than the old docs. They were wholly inconsistent. Some places would tell you what a response would look like, yet others wouldn't. A couple of the API calls would always give me a 500 error. The docs seemed to imply the once you had an api_token you didn't need to pass the user/pass in every request (just the api_token), but when I did that all of my requests came back authorization denied. So apparently you needed to send user/pass/api_token with every request. Ugh.

I never got around to trying to contact them about these issues though.

edit: The library, in case anyone was curious: <https://github.com/bsandrow/perl-posterous>

</comment><comment><USER4> This is awesome and a startup I co-founded on will be utilizing this asap.

Do you guys have anything that will allow in-site upload to posterous? ie: Uploading a video to Posterous through a form on my site?

<comment><USER5> You can use the rubygem to do just that: <https://github.com/posterous/posterous-gem></comment></comment>


Clean Energy Hoax? - <AUTHOR> http://www.steorn.com/

<comment><USER2> Enormously long and complicated, and very hard to figure out what's going on. Many technical terms, some explained, some not, it's all rather a mish-mash, and hence totally unconvincing. Too much time and space for hidden effects.

If people want to demonstrate a perpetual motion machine it's easy. Put it in a sealed box and get energy out. For a long time. When someone doesn't give a black box demonstration, be skeptical.

If someone does have a real perpetual motion device, I have ideas for how to convince people that it really works, avoiding this problem:

<http://xkcd.com/570/></comment>


Internet Advertising Bureau head comments on adblocking - <AUTHOR> http://www.iab.com/news/rothenberg-says-ad-blocking-is-a-war-against-diversity-and-freedom-of-expression/ <comment><USER2> Quote: _In all advanced societies around the world, advertising has been a central contributor to assuring such freedom and diversity of expression and economic action._

Ha ha ha ha ha! I almost wet myself. In what parallel universe has advertising been anything other than a homogenizing censor of unpleasant viewpoints? And sometimes a mechanism of censorship and control - I'm thinking here of the newspaper stories that got spiked because they might offend a big advertiser.

What a pompous, self-deluded fool.</comment>


Cosmos: Most contributor friendly project on GitHub at Hacktoberfest - <AUTHOR> https://github.com/OpenGenus/cosmos <comment><AUTHOR> I made my first ever OSS contribution at Cosmos. Great memory!</comment>


Russia's Use of Antivirus Software to Spy Shows Why We Need Strong Encryption - <AUTHOR> http://www.slate.com/blogs/future_tense/2017/10/12/russia_used_kaspersky_software_to_spy_on_the_u_s_that_s_why_we_need_encryption.html <comment><USER2> russia.... rofl.

Just leave that part out of the scentence already >.> like this it just reads as some narrow minded click bait.</comment>


Who Needs Ops Anyway? - <AUTHOR> http://joerussbowman.tumblr.com/post/51388938822/who-needs-ops-anyway

<comment><USER2> I'm _that guy_ whom the post is talking about. I decided against weighing in on the original thread on HN because I was still dealing with the downfall. A couple of things that I noticed:

* Our users were _very_ understanding of what happened. We have received nothing but encouragement to keep on working.

* Some comments on HN were nasty. I'm glad to be 33 and not 23. Otherwise, I could have been driven away from building my product because of my own incompetence.

* Many commented on devs vs ops. The way I see it, I can ask a dev to supervise the work of an ops contractor. I can't hire ops + dev at this stage.

Any start-up has three main constraints: time, money and talent. These are not set in stone, you can use time to produce money (consulting), you can use money to buy talent (hiring), and you can even convert time in talent (training).

So, when people say "let professionals handle it". Well, no, my particular set of constraints won't allow me to do this. My budget for this is around $100/mo. In an event where I completely run out of money I'd have to take down the site indefinitely, which causes the same effect as an HD loss.

It is clear now that I lack enough resources to run a complex app reliably. My focus in the next months is procuring those resources (money) so I can put it back into the product (ops and devs).

<comment><USER3> >So, when people say "let professionals handle it". Well, no, my particular set of constraints won't allow me to do this. My budget for this is around $100/mo. In an event where I completely run out of money I'd have to take down the site indefinitely, which causes the same effect as an HD loss.

well, drat. I was talking about launching a "tested backups" service, but it's just not really worth my time until you get to the $500/month level or so, and I'd probably want a setup fee on top of that.

(For that, I'd give you a full working replication of your production site, hosted on my stuff- something that, in case of emergency, you could cut over your dns and just run with. Something that you could go to at any time and check on by going to yourdomain.backups.prgmr.com or something. Obviously, this would take me setting up some sort of replication of your database. Obviously, this also means that I'd need to know your application well enough to figure out how to make the running backup not conflict with the primary, and how to cut over to the backup /as/ a primary and how to cut back.)

I mean, I can do basic backups really cheaply, but testing them? that... that takes effort. Effort and understanding the application. And untested backups, meh, there's no reason for you to pay me to do it (maybe you pay me for space, but that's the cheap part.) there are thousands of services that will cheaply give you a place to hold files.

Huh. Most of the work, on my end, would be up front. What if I charged you $100/month, but made you pre-pay a year in advance or something? that might be worth it for me. (assuming I had the option to back out and refund your money within the first X days should your application prove to be too difficult to replicate.)

<comment><USER4> If the production server is running as a VM to begin with, how hard is it to take a snapshot of the whole VM and replicate that? (It does sort of break down if you have a database that's continuously updated and you want to try to have a continuously updated copy of the database, though.)

<comment><USER5> How hard is it? Well, about as hard as writing bug free code is. You don't need testers, right, just don't put bugs in in the first place! Or is it not easy after all?

</comment></comment></comment></comment><comment><USER6> The problem is that admins provide somewhat less visible value.

A programmer can create in a afternoon a feature that can be sold for a 100K+ dollars. And get the credit, glory and chicks. Or at least part of the credit.

To value properly admin you have to have had your ass pulled out of the fire from a good one a couple of times. Which comes with experience.

<comment><USER7> The biggest problem is that when you have a good admin, things will run smoothly, but few will attribute that to his work.

<comment><USER8> The classic adage is: A CEO walks around the office floor and notices how wonderfully clean the place is. This CEO is all about efficiency, so he trots into his office and phones up the CFO. He asks how much is spent on cleaning, suprised at the cost decimates the cleaning budget.

In a brief email to the board, boasting of another hard day's work making the company leaner and faster he says: "The office is already squeaky clean, why would we need cleaners?"

<comment><USER3> Yeah, there's a common sysadmin joke about how if the CEO knows you exist, you aren't doing your job.

</comment></comment></comment></comment><comment><USER9> "I did some math and I found out that using a third party email delivery would be more expensive than the server"

The crux of the problem is the napkin math was wrong because he obviously forgot to a) include his billable time on learning such stuff and b) include the price of further staff to manage such things.

Personally I think there are tons of devs who can be good at ops, you just need to quickly come to the realisation that many of the aspects of ops are fairly essential non-optional functions of your job role, and should sit behind the writing of new code if your company has anything of value.

Once you come to these realisations you can quickly understand that despite a dedicated server being cheaper than paying for an email service, the time sink and required technical knowledge will quickly more than even the cost out, leading to this actually not being about ops for any other reason than an ops guy wrote it.

<comment><USER10> That line truly astounded me.

If "opening ports" is on the pain list, running your own mail server is going to feel like running a marathon while having a seizure.

<comment><USER2> You are nitpicking, opening ports was a google search away. It's just to give an idea of my experience doing ops at the time (nothing beyond shared hosting).

<comment><USER10> Substitute "opening ports" for "installing SSL certificates" or "tweaking config files" if you'd like; there's no nitpicking here. Don't feel insulted though, my point is that running a mail server is an awful experience even when you do ops for a living. It may look cheaper on paper to DIY, but in practice it can be better to save your sanity instead of the money.

</comment></comment></comment></comment><comment><USER11> I've found that there is a mindset out there that ops should be the sole responsibility of developers. They wrote the code, they should own the running of the service. This mindset falls down on two key reasons:

1) Not all developers are good at ops. Issues aren't always related to the code. Platform choices come into play and all the characteristics of a particular platform aren't necessarily known to developers.

2) In companies where developers are pushed hard -- It's a startup!, We must deliver! (the typical death march) -- after 60+ hour weeks, one's trouble shooting skills aren't the best.

In the last 3-4 startups I've been involved with, I've been one of a small handful of people who can do ops as well as code (across a myriad of technologies) and have pushed for engineering to provide as much logging, documentation, and guidance to ops when the company deems them relevant; when ops is considered part of dev, I pushed for getting some basic ops in house (the two instances I can think of were the 'weekends are in the schedule' type startups).

<comment><USER12> well said.. I'm an ops guy that likes working with small companies and I've come into a lot of startups where dev did the ops and it was a mess. No one knew if backups work, monitoring was a mess at best and the way things were setup, nothing would scale at all

</comment></comment><comment><USER13> As someone who deals with mainly dedicated servers at the high end and shared hosting at the low end, I've been curious as to what sort of things cloud hosting like EC2 makes easier to the point you don't have to think about it.

As I understand it, they sell VMs running some form of Linux that can have more RAM/storage/bandwidth dynamically allocated which takes out hardware related worries.

In terms of software though, there are still quite a few problems that need to be thought about.

For example:

* How do we backup files and databases? Where to, and how often? Are we just duplicating every so often or do we want snapshots at certain periods that we can revert to?

* How do we deal with software failures, like FS corruption?

* How do we update our software stack, when do we update it and how do we test that an update hasn't broken anything?

* What about if we want to concurrently run 2 versions of the same framework for different apps?

* How can we configure firewalling etc to allow trusted people to connect to the database, but block the people who spam the login form every 5 seconds?

* How do we make sure the software is configured correctly? Like charset encodings in the database, making sure that we have the correct modules installed into apache/php or the right gems installed etc?

* How do we manage background tasks, like cronjobs etc?

* How do we manage alerts when things fall over? Nagios etc.

A lot of the answers to these are going to depend on specific requirements for the project so are going to require some ops know-how to set up correctly. Or is it more the case that a cloud provider gives you a specific set up with limited options and you make everything fit around that?

Or is there some magic that goes on which I am missing?

<comment><USER14> Amazon certainly makes a lot of things easier. For example, you still have to manually back up your database and files, but the storage of those files are simplified (S3, which is arguably one of the safest places to store files in terms of durability).

Things like dealing with software failures, updating stack versions, configuring DB, are pretty much the same with EC2 as they are with dedicated hosting. There are Amazon products that help (Cloud Monitoring service) but mostly you will be doing it yourself the same way you would on your own hardware. Being a cloud VM hosts, some of these things are more convenient to handle than if you were on your own hardware. For example, everything can be done from the EC2 API, so you can programmically spin up/down instances (machines) as things go down to keep everything working. But of course you need to set up this failover/auto-scaling system yourself (the API just lets you control the infrastructure).

This is the case with IaaS services like EC2 and Rackspace (you only get bare VMs with some extras), but if you move to a more hand-holding PaaS service such as Heroku, where you get the entire deployment system and failure handling system, then your software stack management and failovers are mostly handled by the service provider. Of course these services cost a lot more for equivalent amount of compute power than IaaS services.

<comment><USER13> I see, sounds mostly similar to just renting a VPS from one of a variety of providers then in that it doesn't dispense with ops stuff.

I did evaluate S3 for backups for one project , but concluded that an rsync script would be simpler and more portable.

In the case of things like heroku, how are software updates handled? Do you contact them and say "I want to update to rails version x.x , do it and run these automated tests" or do they just do everything on a schedule?

In other words, if you want an extra feature that is only present in a newer version is this possible? Also what I would worry about it them doing a random upgrade at an inconvenient time (like during a launch of something) and it breaking something subtle.

<comment><USER14> Yeah EC2 is basically a VPS rental, but with a number of services surrounding it to help with ops. So it is more convenient than a pure VPS service, but by no means "takes care" of ops for you.

With Heroku you use files to specify your dyno configurations, and in the runtime file you can explicitly set the version of software to use. Heroku will read the file and take care of everything for you. Whether the version switch breaks your application code or not you have to test out on a dev dyno first, there is no way Heroku can help you with that. They will not touch installed software versions without your explicit consent. They might change the default runtime software versions though, so you should always explicitly state the version you want.

</comment></comment></comment></comment><comment><USER15> Good article, and I wrestle with this constantly. But the truth is, (Specialized) Knowledge and Curiosity are rabbit holes of unimaginable depth. They can unravel your ambitions for a product when not managed correctly.

The trend in software development has always been to abstract policy, process, and infrastructure into modular components when possible, and to allow experts to manage them. I think the demand for such services largely proves their efficacy in the marketplace.

The argument over whether a developer _should_ learn ops is interesting, as the answer differs depending on what she intends to get out of building the application.

Remember, most applications (though not all) are intended as business endeavors. I think you need to look in the mirror and ask yourself-- "Am I building this application to serve a consumer's need? Or to become a better programmer / operations / systems engineer?"

In the case you're building something for a customer, time is your biggest and most important resource. Don't squander it by prematurely optimizing things. While it is admirable (and sometimes scalable) to invest in expanding your knowledge sphere, this often isn't the smartest business decision. Truth is, no matter how good you get with AWS, there is probably almost always someone else out there who is better than you and is offering their knowledge and experience as a service. And I can almost guarantee you your time (as a founder) will always be worth more than what this service costs.

<comment><USER2> I am not sure these are rabbit holes. One can certainly get lost in the depth of a new discipline, but you can take a look around new ideas start sprouting.

I am an interaction designer, for example, but working with email got me thinking into ways of using it to support the interface. Instead of sending a reminder email for inactive users ("we miss you!"), you can send them a little interaction ("is this challenge good? yes or not). I doubt that insight would have come if I hadn't worked with email on the technical side.

</comment></comment><comment><USER16> I'm a sysadmin by profession but when I write code I don't want to have to worry about backups, scaling, etc. Those things get in the way of creating the product. What we deem as "cloud" infrastructure has gotten us partially there by eliminating the need to think about scaling the service and allowing that to dynamically occur on heroku or aws. There is obvious still some issues with availability within zones or regions but the layers of abstraction for hardware have come along way. Automated backups are definitely being explored by cloud providers but I don't think its a guaranteed service as of yet. In the next few years we wont even have to worry about that. We'll just be able to go back to versions of data in time because of the way in which data is already snapshotted in certain datastores.

Although I guess people still forget that anything can and will fail at some point in time. That automated backup wont work one day, it'll be corrupted or just wont run.

<comment><USER17> I think this is a common fallacy.

To randomly pick an example - sure, automatic filesystem snapshots are a cakewalk these days, and a decade ago they were rather expensive. It seems logical to assume that things that we needed admins to do and rig up somewhat delicate systems for a decade ago are so easy now, we don't need people to focus on that...

This overlooks the fact that the baseline has just moved ahead. Sure you don't need dedicated people for stuff you used to.. but there is new stuff out there that your competitors are hiring dedicated people to work on and push the envelope. if you're okay with doing what you could have done 10 years ago, just using reduced staff, that's great - but it's not going to win you much.

<comment><USER18> Is operations really going to be a competitive advantage for you? If my startup lets you hail cabs from your smartphone, is an extra 9 of uptime really going to help me beat Uber?

<comment><USER19> My company's space is pretty crowded with competitors, but we're beating them because our service returns results in 78ms, while our competitors doing devops and running in Azure, etc. return in 2500ms.

That's because we have a dedicated ops team who concentrate on performance and scaling, and leave the devs to write code instead of managing servers.

<comment><USER18> Surely the devs focus on performance and scaling as well, if not at the level of managing servers? Having a dedicated ops team is a necessity, but it's important to keep developers in the loop on operations as well.

<comment><USER19> As the architect of the systems, I focus the designs on scalability and performance and the devs implement it. So, whether it's a dev or its an architect, someone has to be thinking about it. But having an ops background helps with knowing how to scale.

</comment></comment></comment></comment></comment></comment><comment><USER20> I am a sysadmin and developer by day/night; I am currently putting together my initial videos for <http://makerops.com>, which I hope to be the railscasts for bridging the gap between dev and ops, for individuals/startups/people who don't have a lot of money to spend. I'll also be doing some stuff for large companies looking to transition their organizational structure to a "devops" shop, which I hope helps me launch a consultancy. There are a lot of things that developers can do to ensure they can scale, stay up, and not lose everything. Worst case scenario, use a platform as a service (heroku etc) and outsource all of the add ons, such as mail, logging etc. Best case scenario, write all your infrastructure as code, and be able to deploy to N number of clouds, or even bare metal, either way, I hope can learn how to produce a screencast quickly enough to get this damn thing launched.

</comment><comment><USER5> If you think devs should do ops, you probably also think devs should be writing their own compilers too.

<comment><USER14> In a startup you may not have the luxury of affording both devs and ops. Most of the time you end up having a devops guy who does a lot of both. Compilers are the same regardless of who's using them, but ops needs to be tailored for specific use-cases, which is very different.

<comment><USER19> Just like how a 3-in-one printer/scanner/fax machine does none of those jobs well in comparison to separate dedicated devices, you get what you pay for.

</comment></comment></comment><comment><USER21> If you've spent the hours learning to code, and even more time learning how to host your brand new app on a server... just spend that little bit of extra time to get those backups up and running - don't launch without it.

Your business could potentially be dead overnight without backups.

This doesn't just apply to the operations of your site, this also applies to every bit of data related to your business. Do you have backups of everything on your local machine? Do you also have backups in a remote location incase your local backup gets destroyed/stolen? If not then stop everything until you've put a plan in action.

Who needs backups anyway? Everyone does, unless you don't care about your data.

</comment><comment><USER22> While ops certainly has its place (and an important one at that), there has to be a line where it simply isnt reasonable to hire a dedicated ops person. For example, if you have no users you dont need to worry that servers never go down, that email isnt being routed, that user data is backed up, etc. Speaking as someone building a company with no dedicated ops, I think that the line is somewhere around: as soon as you can afford it. Before that, (i.e. pre- revenue) it seems like a pre-optimization. On the other hand, backups (especially of the software) are not inherently an ops issue. Developers deal with backups all the time (e.g. git, svn, cvs, dropbox, etc.).

<comment><USER23> > Developers deal with backups all the time (e.g. git, svn, cvs, dropbox, > etc.).

Those are not backups, they are merely information stores. I have seen time and time again that restoring a site from zero is extremely painful due to how poor most developer tools are. In fact, some tools that are designed to "make things easier" actually don't make them easier for ops folks when things break. A personal bugaboo is startup scripts that aren't "portable" between shells. That might sound overly annoying, but when you discover that your SW isn't starting due to differences in environment variables in a dev vs prod environment that should never have been there, it'll make more sense.

</comment></comment><comment><USER24> Thanks for writing this, I have been thinking the very same thing for a while now. This post inspired a post of my own ([http://russell.ballestrini.net/honey-i-just-deleted- linkpeek...](http://russell.ballestrini.net/honey-i-just-deleted-linkpeek- com/)) which talks about how I recovered from a catastrophic failure because I had backups.

</comment><comment><USER25> Whether or not you have a dedicated ops team, you may benefit from establishing Ops - here is a guideline - Tom Limoncelli's Ops Report Card <http://www.opsreportcard.com/></comment>


Ask HN: How do you see the future of computing ? - <AUTHOR>

How do you envision we will be programming computers 10 years from now ?<p>20 years from now ? <comment><USER4> I hate to say it but 10 years isn't that long a time. Keep in mind the HTML 4 spec was approved about 12 years ago and we're still using it. So I think a lot of the building blocks we'll be using in 10 years are probably already taking shape (HTML5 for example)

That said I think the improvements we will see in 10 years will be based around the maturation of frameworks. In just about every environment, be it Rails or .Net or whatever, you see programming in general moving to a higher level. People using mature algorithms to focus only on what they need to customize and in doing so making programs that are easier to use while being a lot more stable.

I think that leads to the 20 year question. As programs become more stable and a generation of kids grows up with computers they trust not to crash I think you'll see computing in general change. Add that to cheap, widespread touch screens and I think you'll see a lot of things that are currently "physical" become "virtual". You can already see this now with things like EC2 which turns physical computers into virtual constructs that can be manipulated through software.

Think about it. Other than your oven or refrigerator what else do you even have in your house that couldn't be made virtual? Your entertainment system, your computer, your alarm clock, etc... can all be moved "behind the screen". Even the oven and fridge can be made into components that interface with a virtual console.

That's when the fun really begins for programmers because that's when we get into the business of creating virtual worlds. I don't know how that will take shape exactly as far as programming is concerned but I assume you'll start to see hybrid functionality where physical interaction becomes a lot more important than back end functionality (which again will be largely covered by frameworks at that point). In many ways it will probably mirror how physical electronics are created now. Most electronics are built using pre-fab Integrate Circuits that do most of the work. The manufacturer just creates an appearance and a user interface.

Anyway, that's one man's opinion.

</comment><comment><USER5> I had to walk a bit to think this through. My mind works best when walking.

I think touch screens will be cool toys for the toddlers, but adults will use something different. Think about it, your fingers are blocking your view just when you need it the most.

I don't know what will happen, but I hope some technology would get the drones out of those cubicles. Something like chorded keyboards and holographic eye- wear combined with wireless network.

If some country would start to teach the use of chorded keyboard in elementary school, it might be a huge leap for the economics of that country.

If you work in small room, your ideas will be smaller too, if you work while sitting, your mind will be sitting too.

Nowadays programmers work to make software for other people. That will change. In future people will increasingly do their own software as programming is already taught in some schools as a basic skill. And programmers will increasingly make software for other programmers as the percentage of programmers/workforce constantly rises.

Both of these will shape programming towards "write what you want, and the machine will optimize it for you".

Actually some of the programming might not be writing at all. Some people are way better with images than words, and even today dudes draw pictures to help themselves to grasp what they are doing. Look at well formed C and the python, indentation was meant to help, now in python it's the way of doing things. Same might happen for other stuff originally just meant to display the info a bit clearer.

<comment><USER6> I have no idea about input devices, but this I agree completely with:

> In future people will increasingly do their own software as programming is > already taught in some schools as a basic skill.

Especially scripting-languages have evolved hugely, and I think we're pretty close to where "regular" office-people will be expected to put together small scripts to get things done. Instead of going through a complicated change management process to add a button to some in-house app to save some time, users will increasingly be empowered to script such a thing themselves.

Programming is increasingly de-mystified, and it's really no harder tying together a couple of objects in, say, Python, than to do a proper mail merge in Office.

<comment><USER7> I couldn't disagree more with this. Scripting is in many ways "glue" that ties to programs together. It's not perfect and it may not even be really necessary if the programs were designed to be extensible in the first place.

As soon as you go beyond "glue," you run straight into this <http://www.xkcd.com/568/> (second panel). No matter how high level your programming language, it doesn't read minds. When we write programs we trivially understand that a program is a precise description of what needs to be done. Sure we have more advanced primitives for doing stuff nowadays, but we still need to say exactly what we want. Remember, if your programming language is ambiguous, that's a flaw. I believe there always will be a clear distinction among programmers and non-programmers, as I don't believe that this will ever change. 90% of people want to say "make a cool game" and have it happen, regardless of whether or not that actually works.

</comment></comment></comment><comment><USER8> 10 years from now.. too short to tell, but 20/30 years from now, I have strange thoughts.

I do believe that in one day, Information Technology will invade each place, home, school, office, road... anything that exists in everyday life... I dream that everything in life will be connected and Internet will become more important than oxygene, something like cars, TV and cellphone now.

The IT world will be very promising, it'll be big and no one can control it. I think. In my opinion. The IT market will be so big that even giant companies like Google and Microsoft will be nothing rather than companies dominating a niche with a considerable market share.

I think in the future, the IT will grow strong, companies like msft will grow their sales but loose more market share, as the IT growth is stronger.

I think it's time for many "big" companies formed of 3 or 4 poeple. Look at startup now, it's just the begining, how was the web in 95? it was a few number of websites, they made good income and dominated the web (like yahoo.com and msn.com) now they still make money, but the web grow in a way they can't control it and the market is far big than their potentiel.

I think the future of IT will be so complicated that you can never, anyone, understand it... many new things everyday, startups launched each seconds... and many news, ideas and discoveries... It'll be fantastic, but we'll miss the days of the simple Hacker News interface.

meet you in 2040, hope this thread still exist...

</comment><comment><USER9> I think that Martin Fowler hits the nail on the head with Illustrative Programming: "When you look at a spreadsheet, the formulae of the spreadsheet are not immediately apparent, instead what you see is the calculated numbers - an illustration of what the program does. [...] Using examples as a first class element of a programming environment crops up in other places - <USER2> designers also have this. Providing a concrete illustration of the program output helps people understand what the program definition does, so they can more easily reason about behavior."[1]

Illustrative Programming will fit particularly well with, and benefit from, programs that collect, crunch, and display data - this being area that I agree will see a lot of growth and attention.[2] "The ability to take data—to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it—that's going to be a hugely important skill in the next decades,"[3]

Tools that are more suitable for large and complex data sets than Excel, and easier to use than R will become available. These will be used, as many current programming languages are, by people that are not trained in software development. Visualization will become much more important, so programming tool usability will improve. We'll see the influence of statisticians in our programming tools. Chasing down posts by others with similar problems and bugs will become easier. I'm not sure how much headway Illustrative Programming will make into the more hackerish areas of programming, though I hope it's a fair bit. For the best predictions on what languages will be like, just look critically at the languages that are at the start of their lifespans now (<http://mythryl.org/> ? Arc?) and also at current research.

I think, though, that the most interesting changes will come from the sort of programs we'll be writing, the sort of people we'll be working with, and the sort of tools we'll have available, rather than from some feature x or y of some future major language.

[1] <http://martinfowler.com/bliki/IllustrativeProgramming.html> [2] [http://flowingdata.com/2009/06/04/rise-of-the-data- scientist...](http://flowingdata.com/2009/06/04/rise-of-the-data-scientist/) [3] [http://flowingdata.com/2009/02/25/googles-chief-economist- ha...](http://flowingdata.com/2009/02/25/googles-chief-economist-hal-varian- on-statistics-and-data/)

<comment><USER10> I don't think there is any indication whatsoever that programming the equivalent of a Turing machine will become any more "illustrative" than it has ever been. 20 years back we had buzzwords like "query by example" and we (almost) had VisualBasic.

What has changed since then? Certainly not much in terms of programming productivity. What has changed is that we program the web now instead of a PC or a Mainframe. The architecture has changed. Esthetics have changed. Collaboration has changed. And we can crunch a lot more numbers now. Programming hasn't changed much.

And I think it won't change in the next 20 years unless some hard AI problems can be solved.

<comment><USER9> You might be agreeing with me, and perhaps are missing my point: more _people_ , especially statisticians, will be engaged in the programming and programming-like tasks that are required to work with ever-increasing data. Not structured-SQL data, but raw and ugly natural-language and legacy-format data. Many programming _tasks_ in the future will be about data, and excel- like "Illustrative" programs are very well adapted, even if not Turing- complete (Interesting discussions on the turing completeness/incompleteness of even something like Excel: <http://www.c2.com/cgi/wiki?ProductivityRant> <http://news.ycombinator.net/item?id=429477> ). Illustrative programming is just dynamic programming plus immediate feedback of program results - <USER3> the ability to click on a GUI element, and change its associated code in realtime, perhaps just the ability to change how a data-point is calculated. The _tools_ will be different.

Turing-completeness will always look like Turing-completeness, but this is hardly interesting or relevant. I think that your claim about productivity is entirely false (see something like <http://www.cs.umass.edu/~yannis/law.html> ), but that's beside the point of my post.

<comment><USER10> I do agree with you that data analysis is of growing importance (it's what I do after all). But I object to inventing a new fancy term for what you describe as "dynamic programming plus immediate feedback". We had that for ages.

"Illustrative programming" is just a classical case of a consultant inventing fancy marketable language. In Excel the illustrative parts are not the ones that involve programming in the sense of Turing completness. I think we need to use Turing completeness as a benchmark, or any interaction with computers can be called programming.

And I stand by my claim that programming something like KWIC has not become much more productive in the past 20 years. You could do it in Perl or in Lisp just as easily in 1989 as you could do it today. Even in C it's not that much less productive to flip and sort a few words than, say, in Java.

But productivity is admittedly a complex concept. Of course we have a much greater effect writing software today, but I think that has very little to do with the core techniques of programming. We may be more productive on average, simply because more people make use of techniques that fewer people were using in 1989.

</comment></comment></comment></comment><comment><USER11> Well, I expect that most programming language research in the next 10 years would focus on exploiting multicore programming. If we're lucky, we'll all be using something like Haskell or Erlang, and all apps will be multithreaded. Languages that choose to ignore multicore will slowly suffocate. Writing multithreaded apps will become much easier than it is now, if not trivial.

It's not wrong to dream, is it? :)

<comment><USER7> Not at all. I may note that our dream of parallelization (us systems people trying to implement it and the language designers trying to write it) is not easier or trivial multithreaded authoring, but implicit parallelization. Wouldn't it be unbelievably cool to just write your program and have it parallelized by the language semantics themselves? :) Come, join the dark side and take control of more power than you can possibly imagine! Muahahaha

</comment></comment><comment><USER12> Whatever we're using, there'll be plenty of tongue-in-cheek posts recalling the glory days of 'real programmers' implementing custom Hashtables in _pure Java,_ no less, in order to avoid the synchronisation issues in their company's Enterprise Framework, or whatever.

And they say the magic's gone out of programming!

<comment><USER13> Perhaps. But who's mourning for the good old time of Cobol today?

<comment><USER14> Cobol time is still in place and more important than ever, governments, banking, military, all rely on it. Problem is that 'good ol' Cobol programmers are hard to find nowadays.

<comment><AUTHOR> I can do it but you couldn't pay me enough to do it...

</comment></comment></comment></comment><comment><USER15> 20 years ago we wrote lisp on emacs, and we still do. The only thing that has changed is that the machines used for developing and running our programs have gotten faster. There haven't really been any gamechanging breakthroughs in software in that time. Chances are that there won't be in the next 20 years either.

<comment><USER16> There has been progress in SE though, the world is asking for more software and larger more complex systems to be written.

The progress in software engineering seems to be in finding good practices and giving them names, when they have names one can write papers about them where their usage in actual projects is analysed.

Example: there was a time when object orientation had not been coined as a term. Now that we have it we can move to the next step and explore variations on it. We can teach it, we can make languages adapted for it.

(I'm not holding up object orientation itself as an example of progress here (or the opposite), but the concept of giving a practice a name and exploring it.)

It's a great advantage if one can talk about 'unit tests' and a new hired person knows about it. People were writing what qualified as unit tests before the name existed, but now that we have a name we can write books about it, discuss problems in doing it, etc.

I'm sure bridge building and other engineering efforts have had much of the same development in their infancy. Clever individuals were doing successful things without thinking much about it they worked what they had, others needed to talk about it and books were written... and now we know arch bridges, suspension bridges.

<comment><USER15> Great points.

What I was trying to get through in the GP post was more that the changes we've seen in software are evolutionary and incremental. I can't really think of any revolutionary breakthroughs in software for the last 20 years.

As you point out that doesn't mean that progress hasn't been made, and we haven't been walking further down the road of enlightenment. It's just that we've been taking one step at a time down a straight road without many surprises.

</comment></comment></comment><comment><USER17> Ten years from now, will not be much more different. Essentially computing needs a breakthrough to move to the next level. What this breakthrough is nobody knows. A program written in the latest fashionable language of to-day is essentially not much more different from one written in Cobol or Fortran or Ada 30 years ago. We refining the tools but not discovering any new fundamentals.

I expect such a breakthrough to be achieved via two possible paths:

(a) By brute force : the effect of interconnecting the worlds information via the internet.

(b) Parallel processing to be stimulated further by breakthroughs in bio- informatics.

<comment><USER13> Programs written in say Prolog, Haskell or Curry are definitely different than Cobol or Fortran or Ada 30 years ago. And different from Lisps (and perhaps ML) of that time too.

<comment><USER17> Only on the 'surface'. For example write a program to add a+b! The 'language ' maybe different but not the concepts. I am arguing that we need a fundamental breakthrough.

<comment><USER7> Not gonna happen. Sorry, but this is like saying that we need a breakthrough in "base 3" because "base 2" is too limiting. The fundamental physics of our computing is unlikely to change (I'm sorry but I don't see quantum computing being practical in the next 50 years, if ever), therefore eventually we'll still be programming opcodes on processor dies. However, if you don't believe that the underlying architecture of computing hasn't changed in, hell, the past ten years, then I think you've been programming in high level languages a bit too much.

</comment></comment></comment></comment><comment><USER18> listen, people be asking me all the time, yo mos, whats gonna happen with hackin. i tell em, you know whats going to happen with hackin? whatevers happenin with us. if we smoked out, hackins gonna be smoked out. if we doin alright, hackins gonna be doin alright. people talk about hackin like it's some giant living on the hillside comin down and visitin' the towns people. we are hackers, we are systems hackers, we are life hackers, we are world hackers -- me, you, everybody. so -- hackins going where we going -- so... the next time that you ask yourself "where is hacking going?" ask yourself, "where am i going? how am i doing?" - and you get a clear idea.

speech is my hammer, bang the world into shape -- now let it fall! my restleness is my nemesis. it's hard to really chill and sit still, committed to projects, i write lines, sometimes won't finish for days. scrutinize my literature, from the large to the miniature. I mathematically add, minister, subtract the wack, selector, wheel it back, i'm feelin that. -- haha! from the core to the memory and back, you know the motto - stay fluid even in staccato.

\-- altered lyrics of Mos Def's Hip Hop

</comment><comment><USER19> Programs will write themselves using genetic algorithms and assorted machine learning techniques, and programmers will then become truly slaves of the machine. Then again, maybe I've been reading too much science-fiction...

</comment><comment><USER20> I think the biggest change coming to the computing world is iPhone-type devices. These will become our PCs. We'll have hand-held apps, but we'll also be able to plug them into real monitors and keyboards. So one of the biggest challenges will be making one device work in both kinds of environments. I think the other challenge will be how to create virtual systems within these devices, so that we can use the same device for personal and work uses, yet keep the 2 completely separate from each other.

</comment><comment><USER21> Easy, COLA: <http://www.youtube.com/watch?v=cn7kTPbW6QQ>

Any syntax you want, running on the same JIT compiler, but designed from scratch without marketing breathing down your neck.

<comment><USER22> Ian and the guys at VRP are amazing, but this (COLA) isn't the blue plane switch they're looking for.

<comment><USER21> It isn't? Why not?

<comment><USER22> I know what I said is cheeky because all of PLR is going in that direction, and for good reason. COLA and similar research really extol the best from each of the dominant architectures.

But I think that we need to move away from both object and lambda architectures rather than finding ways to marry them. In my humble opinion, the "blue plane shift" is in an entirely different ocean than the ones we've been swimming in.

I'll tell you a little about the research I'm working on: All software is created directly as key-value pairs which can self-assemble into labeled, directed graphs. These are understood directly by an OS which acts essentially as a simple layer over the hardware. No programs are compiled or interpreted. There's no assembly code. There's more to it; I'll email you.

<comment><AUTHOR> That is the kind of stuff that I hoped to hear when I posed my question! If you could elaborate on that then I'd be most interested and grateful...

<comment><USER22> Sure; I'll email you as well.

</comment></comment></comment></comment></comment></comment><comment><USER23> I predict that the future of computing (in business anyway) will have much less to do with technology that with what applications we write, who we write them for, and how we write them.

10 or 20 years from now, 100 million corporate drones will be sitting in cubicles looking at screens that look more like 37Signals or Wufoo than SAP or Oracle. Nimble web apps will steal the enterprise away from the monoliths just as surely as the PC stole it from the mainframe.

</comment><comment><USER24> At some point surely all computers will be quantum, so that would have an effect if that's the case.

Edit: maybe its further away, but still worth thinking about.

<comment><USER24> I don't mind the downvoting if I'm vastly wrong, but please could you explain why this would be wrong? A few people have upvoted me, so they might be interested in knowing why its wrong too.

</comment></comment><comment><USER25> I think 10 years from now we'll be dealing with the post-peak-oil world and will be worried more about how the garden is doing than what programming language we'll be using when the power is on. ;-)

<comment><USER8> This will be solved with green-renewable energy

<comment><USER25> Sure, sure, stick your head in the sand and assume it'll be solved "somehow" with some vague renewable energy.

And who's going to develop this magical new energy source that will replace petroleum, the most storable, efficient, easily-accessible energy source the world has ever (or will ever) seen? (Short of fusion.)

We need facts, not vague hopes.

<comment><USER8> it's time, it's all about time! petroleum will stand 50 years at least, during that time, countries and companies are doing researches... they'll find something.

look at the new electric cars and motos? aren't they the future? maybe!

</comment></comment></comment></comment><comment><USER22> I have nothing to publicly back this up, but I think in 10 years we'll be in a whole new world when it comes to creating software -- really, a whole new world. It won't be recognizable to those around today. It's exciting, and it's waiting for us.</comment>