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

where was the file stored on the beagle? that could explain a good part of the difference in results you're getting.


time dd if=linux-3.4.tar.bz2 of=/dev/null

is 0.7 seconds on the beagleboard and slicehost is more variable but comes to down to 0.5 seconds after a few goes from (1 second). I'd expect it to be read from the page cache anyway.

However, I remembered that the beagleboard is using busybox and really the systems are very different from each other, different distribution for example.

Update: busybox md5sum is about 20% slower than regular md5sum.


My thoughts exactly... Reddit is a misfit in the overall organization and with the current exponential growth it's experiencing, it's the best and most leveraged time to sell it off. Would be a strategically good decision IMO.. I'm surprised this comment isn't voted higher..


Keep it moving people.. there's no bubble here...


Motivation has two dimensions: goal attractiveness, goal expectancy.

Goal attractiveness is basically how much do you want it and goal expectancy is how much you believe you can attain the goal.

As you can see they are two perpendicular forces which directly affect the direction your motivation/dedication towards attaining goals are pointing.

I don't know you, but a common problem many people face is that they look at the world around them and focus on other people's achievements and wish for the same. The only problem is on the motivation dimensions their scales get way tipped over..

As an example, you may look at what is happening on HN and wish for what Andrew Mason is doing with Groupon or Zuckerberg has achieved with FB. The issue is that while that goal is extremely attractive the expectancy of you achieving it is very negative and so the motivation vector ends up pointing in the negative direction.

Developing this argument as I go along, I would therefore say that the correct approach is to take stock of what your current strengths are, what your challenges are and strategize a plan. Namely one that sets you up with small bite sized goals which are positively geared for your current situation and continually update the goal statuses. Maybe have daily, weekly, monthly, quarterly and half yearly goals and work on them.

THEREFORE, you can definitely change, you just need to have realistic goals and discipline to tough it out.


swapping is a fundamental part of a multi-tasking o/s and unfortunately unless a program starts writing into memory addresses that have not been allocated to it the o/s would not be able to know if the program is crashing or not (segmentation faulting)...

to the o/s this bug would just look like a memory hungry program so it just keeps on allocating more memory... once all physical memory has been used up, the o/s has to swap out old data to disk and re-use addresses for this program that just doesn't stop asking for more memory... i.e the program doesn't know it's doing stupid shit and the o/s doesn't know it is hosting a stupid program..

it's kinda like a house party where everyone starts the night normal, then as the night goes on some idiot doesn't recognize their own limits and they keep drinking more and more and the host doesn't know what this guy is doing and before he knows it he has to clean up vomit in the morning...

hope this makes sense..


You are conflating virtual memory and swapping. A disk-backed page cache is not necessary for memory protection.


Is it me or is this not a really fair comparison since the erlang frameworks would be utilizing both cpu's while node and tornado wouldn't be?

In real life a load balancer in front of tornado or node would be a far better solution than going down the erlang road in production.. support and maintenance wise + more programmers out there knowing the language would win hands down IMO...


If you read the article closely you will notice that the Erlang VMs were started without SMP support enabled; everything was single-core. If you turned on Erlang SMP support then the comparison would be even more lop-sided than the example presented in the OP. In real life a hardware load balancer in front of a pool of Erlang servers would be even better :)


I agree that the article does seem a little tabloid, but I think speculating on what will happen to G as a complete outsider is to a very high degree a gamble..

There would be so many issues at play here.. How well can Larry get buy-in from various levels of the organisation? How well will the Google culture evolve around his proposed changes? What will they do to ensure Quality of service goes up?

At the end of the day, Google right now is a one trick pony. General consensus in this thread is that Android is successful within Google right now. I don't buy into that though primarily because it's a business unit that does not make any money...

I think there's a long way to go and a lot of forces at play


Organizational culture is one of the toughest things to change! Larry has his hands full


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

Search: