FWIW I ran in a Core 2 Duo P9500 with W7 64, 4gb of ram.
1,315 karma · joined February 12, 2009
FWIW I ran in a Core 2 Duo P9500 with W7 64, 4gb of ram.
Lasted about half an hour - Google Reader doesn't seem to work right, and GMail also stopped responding after a while.
Probably someone that was sick of techcrunch on HN made it for himself and there's no major conspiracy of password stealing or SEO tricks.
Wine and WineLib are different things.
this.
Who writes all that? No one ever mentions the programmers that save the day.
I agree with the other poster that the bar on top with the battery/time is distracting. The menu fonts seemed a bit non-standard to me. The blocks seem a bit simple, could use some extra glow or something.
Keeping the high score on the top is a nice touch to encourage self-competition. The big combos are what make you want to come back for more.
It was kinda hard to figure out the "combo" mechanics at first (which blocks shrink when one disappears and a column falls down). There was nothing in the tutorial about this.
Regardless of the nitpicks, it's fun. I'll definitely play it again.
Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.
Again, not justifing it taking ages, just saying there's never an excuse to skip QA.
If the feature was really critical and important, QA should find a way to expedite the verification, but it should never be skipped in order to ship the fix faster.
Obviously without good and satisfied developers those benefits are moot. I'm certain the approval process needs to be [improved/changed/redesigned/removed], and maybe some kind of sanctioned jailbreak should exist where more advanced users can manually install third party apps, but I do believe the App Store itself is a good thing when you you look at it from a user perpective.
There's still the ever-increasing number of concurrent goroutines, but what just helped me accept that a bit is the fact is that each goroutine does not necessarily map to one thread (it actually does in one of their compilers - there's two - but that's an implementation detail).
When it runs, it is going to spawn a thread generating a sequence of numbers, then another one taking that sequence, start generating a new sequence based on that skipping multiples of a particular number, then start another one doing the same. Number of threads seems to always go up. Is that the right analysis of the code? Doesn't seem right to me.
I've been running the dev channel builds for a while now and never had any major issues, only the occasional minor issue.
[1] http://dev.chromium.org/getting-involved/dev-channel [2] http://dev.chromium.org/developers/design-documents/extensio...
http://en.wikipedia.org/wiki/Category:Esoteric_programming_l...
Maybe the issue isn't if it the tree makes a sound - does it fall at all if there's no one around?