The login to get on the page is: level02 and the password is what you've found in level01. I.e. The challenge is not to crack that "Authorization required" dialog.
$ dsocks.sh ssh level01@ctf.stri.pe
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
74:67:32:4a:04:b8:9f:05:b6:e8:29:43:26:12:75:11.
Please contact your system administrator.
Add correct host key in /home/jcr/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/jcr/.ssh/known_hosts:8
RSA host key for ctf.stri.pe has changed and you have requested strict checking.
Host key verification failed.
EDIT: As confirmed by gdb and ab below, there's a good reason for the key change.
You certainly should be able to solve all of the levels without tons of brute force though.
level01@ctf:~$ pwd;ls -al
/home/level01
total 24
dr-x------ 2 level01 root 4096 2012-02-22 13:28 .
drwxr-xr-x 9 root root 4096 2012-02-22 13:28 ..
-rw-r--r-- 1 level01 level01 220 2010-04-19 02:15 .bash_logout
-rw-r--r-- 1 level01 level01 3103 2010-04-19 02:15 .bashrc
-rw------- 1 level01 root 11 2012-02-22 13:28 .password
-rw-r--r-- 1 level01 level01 675 2010-04-19 02:15 .profile level01@ctf:/tmp/tmp.c6PoABNv99$ ls
bash: fork: retry: Resource temporarily unavailableComparing himself to an air-traffic controller, Graham says much of his time is spend making introductions and helping the YC community solve problems within the network
Most of the large companies I've worked with are missing somebody in the "air-traffic controller" role. It can be very difficult for individual employees to understand all the resources that are available within the company, or who they should contact with a particular question. YC might actually have an advantage in this area.
(As transaction costs (search costs, costs to contract, costs to outsource, etc.) go down, optimal firm size goes down. In an efficient market for contracting, like IT, tiny startups turn into long-term profitable small-headcount companies (dropbox has, what, 70 people?). In inefficient markets, you end up with huge or state-owned companies, like in natural resource exploitation or the third world.)
How many YC companies have ever made a real profit before being bought? How is the YC model sustainable without existing large corporations like Google or Yahoo or Linkedin waiting to buy out the startups?
YC is about grooming startups ready to be bought out in talent acquisitions after a period of rapid growth, not about creating sustainable businesses with viable products.
In addition to trying to use each others' services, YC companies will probably often give each other feedback about what could be improved about each other's services.
Compare this to the alternative of trying to launch a new service, gain customers, and get feedback on your own.
What's more, the SF network extends to people who are not just in startups, but also established companies, universities, and even unrelated things (like the Because We Can people, who are making a business out of custom CNC products.)
Or do YC people collaborate more closely than that? Give up their time more freely to a fellow YC'er?
While I am really excited that these guys had an exit -- founders who make really great products deserve to get paid -- I hope that this doesn't mean that Rapporative will eventually be shut down or merged with LinkedIn in some horrible way that removes it from my inbox. I'm not sure if I can keep people straight without it.
I really liked when Conrad from the support them explained an issue I had regarding merged accounts by providing the following graph, I did mention that I was a CS Major (hope the spacing lines up):
email1@gmail.com (user, merged) <--.
| \
`-> email2@anotherdomain.tld (user, merged) \
| |
`-> email3@domainexample.tld (user, merged)
|
`-> email4@finaldomain.tld (user)
|
|`-> alias1@finaldomain.tld
|
|`-> alias2@finaldomain.tld
|
`-> alias3@finaldomain.tld$1 million raised, 2 years of work and $15 million cash exit. The founders have obviously done very well in this exit.
Great story. Great product. Well done!
edit: Admittedly, the tense of the headline was different.
I love getting older. I always tell people that I don't think of birthdays as getting a year older, I think of them as leveling up.
I'm level 41 now, and I hope to earn enough experience points to make it all the way to level 80, or even level 90 one day.
Sure, I can't run quite as fast, but I still try to run. What's best, though, is that I get all the increased abilities that come from leveling up. More wisdom, more knowledge, more credibility, and maybe even a bigger kingdom if I do things well.
When I was 21, everything was hard. Talking to new people was hard, getting a job was hard, even getting taken seriously was hard. I paid those dues already, I have no interest in going backwards. I'd rather keep leveling up.
so I'm 26, and on accident I've met one or two people "like me" plus 10 years. By active community participation, and deliberately doing things to stand out, i am gradually meeting a few more. They love to do lunch with people "like them", but they're inevitably busy, and they have other relationships as well, and I don't have a lot of value to them other than as an employee - so I don't get to interact on a regular basis unless I literally go and change employers. which is sort of like dumping the current mentor. It sucks.
I've never met someone "like me" but 20 years older, or 30, or 40. That would be incredible. The current strategy is to continue developing myself and meet people as life takes its course, like a leaf on the wind. I wish there was a way to accelerate this - who knows, by the time I've found a mentor who is 66, retired, who gives a shit about me in the midst of all the other people who want to interact with him - I'll be 56, not 26.
ideas?
Decrepitude I address by running regularly and trying to curb my over-eating. It's a cliche but I really am in better shape at 33 than I was in my 20's. This is mostly because I didn't take care of myself at all until I was 30, but most people can improve their eating and exercise habits.
Another problem is your mind and/or memory fading. Well it's been shown that this can be staved off by playing games and staying mentally challenged. As a developer this isn't a problem so far, I still play games every day.
What about social isolation, and losing friends and family until you're alone? I've always been a bit of a curmudgeon, so this is one I need to watch out for. I have to make sure to maintain a healthy group of friends as I get older. So far, so good. It helps that I have a lot of younger siblings, and it's unlikely they'll all die before me.
How about getting out of touch with modern society, arts and music? I don't like Lady Gaga or Nicki Minaj, but there's still new bands and new albums coming out that I do enjoy, and I stay aware of even the things I don't like and can understand why other people do. I may shake my fist and say "You kids today have no taste!" but at least I know why it is that I feel that way, and there's never been a time where I liked all new music anyway. Same goes for movies and TV.
It also goes for technology; I don't cling tightly to the tools I use today or used yesterday. I keep abreast of new technology and am ready to move to new platforms, languages, etc. when something better comes along. I'm not going to be caught with an obsolete skill-set because even for things I don't use every day at work (Ruby, Node.js), I stay at least familiar with them. And this is easier and easier to do the more disparate technologies you have under your belt.
So yeah, aging is a thing that can suck. But you can do what you can to minimize the bad parts.
And there's still more good than bad if you're doing what you want in an environment that rewards you.
I'm 27. Why? I personally just miss the feeling of having it all in front of you. Pft, a doctor? I can do that. A pro athlete? It's possible. Senator? I can do that. However unlikely those may have been from the beginning, they were at least possible. They definitely become less likely as you get older.
The only thing about growing old that makes me uneasy is seeing opportunities close. Sure, new ones open up, but seeing old ones close still hurts.
I guess also, certain things are experienced a certain way only the first time. The elation I felt the first time I was in live was absolutely crazy - I loved every bit of it.
Other than that, I agree with OP - it's very nice being less stupid. It does, however, rob life of suspense a bit as experience teaches you to expect a lot of things.
Millikan measured the charge on an electron by an experiment with falling oil drops, and got an answer which we now know not to be quite right. It's a little bit off because he had the incorrect value for the viscosity of air. It's interesting to look at the history of measurements of the charge of an electron, after Millikan. If you plot them as a function of time, you find that one is a little bit bigger than Millikan's, and the next one's a little bit bigger than that, and the next one's a little bit bigger than that, until finally they settle down to a number which is higher.
Why didn't they discover the new number was higher right away? It's a thing that scientists are ashamed of - this history - because it's apparent that people did things like this: When they got a number that was too high above Millikan's, they thought something must be wrong - and they would look for and find a reason why something might be wrong. When they got a number close to Millikan's value they didn't look so hard. And so they eliminated the numbers that were too far off, and did other things like that...
Compared to Wolfe-Simon et al (the group that claims to have found arsenic in the DNA of certain bacteria) they show exactly how science should be done.
(http://lhc-machine-outreach.web.cern.ch/lhc-machine-outreach...)
> The cables house 36 strands of superconducting wire, each strand being exactly 0.825 mm in diameter. Each strand houses 6300 superconducting filaments of Niobium-titanium (NbTi). Each filament is about 0.006 mm thick, i.e. 10 times thinner than a normal human hair.
> tolerances are only a few micrometers.
> Total superconducting cable required 1200 tonnes which translates to around 7600 km of cable (the cable is made up of strands which is made of filaments, total length of filaments is astronomical - 5 times to the sun and back with enough left over for a few trips to the moon).
Update: a spokesperson for CERN has confirmed "a problem with the GPS system." http://www.cbc.ca/news/technology/story/2012/02/22/technolog...
"The OPERA Collaboration, by continuing its campaign of verifications on the neutrino velocity measurement, has identified two issues that could significantly affect the reported result. The first one is linked to the oscillator used to produce the events time-stamps in between the GPS synchronizations. The second point is related to the connection of the optical fiber bringing the external GPS signal to the OPERA master clock.
These two issues can modify the neutrino time of flight in opposite directions."
http://blogs.nature.com/news/2012/02/faster-than-light-neutr...
jonhendry, you're a prophet :)
Alternatively you may find yourself more tired. Personally I like sleeping 8-9 hours a night. I find myself fairly alert a few minutes after I wake up and I can start my day. It certainly doesn't feel 'unnatural' to me.
I am also a big fan of sleeping when other people sleep so I can enjoy time with friends and family. Unusual sleep patterns typically mean missing out on some of this time.
Ironically, all of the industry's marketing makes people anxious about getting enough sleep--and makes it harder for them to get to sleep (thus propagating the need for more expensive mattresses and pillows.)
http://www.nytimes.com/2007/11/18/magazine/18sleep-t.html?pa...
His recommendation is that sleep cycles typically happen in 4 hour intervals so it's best to sleep 4 or 8 hours a night.
Getting up int he middle of a sleep cycle is often as bad as getting less than 4 hours of sleep.
And going to bed drunk is the worst for your sleep cycle.
If my wife and I split our sleep cycle into two 4 hour periods we can better spend my four hours of free time.
The waking period between my commute and first sleep could be spend eating dinner, playing with the kids, and exercise. After my first sleep I can spend time with my wife, and study with a rested mind. Theoretically it seems like a good idea. We'll see how I cope after a week or two of trying.
One lifelong problem I've got is sleeping. I have great trouble falling asleep, and my sleeping patterns are very uncommon: some days I sleep 12 hours, some 5, but I'm usually very tired because of this. However, I used to think I had a "gift" of being really creative and having my best ideas just before sleep, just waking up, and during insomnia episodes. However, I've discovered that many suffer from this phenomena (anyone here?). This article could explain a lot!
Unfortunately, contemporary economists have failed dramatically to appreciate the subtly of Coase's work.
Coase is famous for his work in showing that in the absence of transaction costs, and assuming an efficient market for a good, the market would equilibrate in a way where the good was allocated to its highest-value uses, regardless of the initial distribution of the good.
The theorem is very often used to justify deregulation and privatization in various areas, and modern economists almost uniformly give short-shrift to the assumptions underlying the theory. From the above-cited paper: "The fact that actions might have harmful effects on others has been shown to be no obstacle to the introduction of property rights. But it was possible to reach this unequivocal result because the conflicts of interest were between individuals. When large numbers of people are involved, the argument for the institution of property rights is weakened and that for general regulations becomes stronger." (Ronald Coase, the Federal Communications Commission at 29).
People may also find Yochai Benkler's 2002 followup applying this sort of analysis to open source software: http://www.benkler.org/CoasesPenguin.html
"So, the CAP Theorem says that you can only have one of C, A, and P. Which are you sacrificing?
HyperDex is designed to operate within a single datacenter. The CAP Theorem holds only for asynchronous environments, and well-administered datacenters enable us to sidestep this tradeoff entirely."
I'd like to see how they pull that off when a node goes down. I guess in "well-administered" data centers, nodes don't go down.
Sounds like they're sacrificing "A" to me because they're doing synchronous replication.
Their Python client seems to be using Cython for extra speed: https://github.com/rescrv/HyperDex/blob/master/hyperclient/p...
I am aware of a couple commercial distributed systems that use it (not this implementation but the underlying algorithm). Several organizations seem to have reinvented it over the last five years.
Organizing data in this way was studied in the 1980s but was poorly suited to the computing systems of the time. Relatively little was written about it because it was viewed as a dead end and modern literature has all but forgotten about it. Most of the research was done by companies rather than academics. Designs like this have fallen into the blackhole of "if it is not on the Internet then it doesn't exist". Back when I was studying these models I found more crusty old patents related to these types of models than relevant papers on the Internet. It will be valuable to have some modern literature pertaining to these designs.
If you were to swap this with your Cassandra cluster, you'd be losing multi-datacenter replication. Although partitions within a data center are pretty rare, you'd also lose some availability there as well. However, Cassandra is usually hash-partitioned so it needs to do broadcast for a scan (AFAICT, it even needs to do a broadcast for a lookup on a single secondary attribute), so you'd probably gain quite a bit of performance with HyperDex.
I can't tell if it's possible to dynamically change the set of secondary attributes being indexed without rebuilding the entire data set. Or how value-chaining works with missing attributes.
Also, apparently consistency has some... gaps... when you search via a secondary attribute:
"The searches are not strongly consistent with concurrently
modified objects because there is a small window of time
during which a client may observe inconsistency."
Also, is there a locking mechanism?
I'm the author of Torrus (torrus.org), and BerkeleyDB stability and non-network nature are quite painful. But I'm relying on its speed, concurrent locking, and some ways to acquire an exclusive lock on a table. It would be interesting to offer an alternative backend for torrus.
We need a unified nosql language.. Basically what SQL is.
A resume has just two purposes: first, to help you get an interview, and second, to get you past an HR hurdle.
It is not the job of your resume to go further than those objectives. In particular: it is not the job of your resume to establish a valuation for yourself. No one document can do that; in fact, no document can: you have to do it yourself, preferably face-to-face, by understanding in each interview what the "buttons" are, what the language of benefits that company speaks is, what things they find important, and how your prior experience can be phrased in ways that push those buttons and communicate those values.
More importantly: resumes, in any form, are bad at getting you interviews. A resume comes into play at the earliest part of the recruiting funnel, when the hiring team has the smallest number of cycles to spend on each candidate. Your primary strategy for dealing with recruiting funnels: jump the fucking line. It's never been easier to do this! Ten years ago, you'd have to track down someone who worked with someone who worked for someone at the same company as the hiring team. Today, in tech, you just go search Github for projects your hiring team contributes to and start sending pull requests.
Keep your resume simple. If Github does it for you, gets you in the door, great.
People spend a lot of time thinking about resumes. It's easy to see why. Resumes are the key ego document everyone in our field gets to work with. They are, admit it, fun to tinker with. That's fine. But don't obsess. The resume is literally the least important part of the search for your next role.
I don't mind a Github being used in conjunction with other resources (the projects I've worked on / Linkedin / etc), but god help me if it ever becomes the standard -- I'll be unemployable.
Now that I have left my current position and I am talking to companies, I find myself sending both a linked resume and link to my github account. The recruiters / HR folks never seem to understand why, but when I end up in the technical interview, the engineer / manager doing the interview is generally pleased and has reviewed a few projects on my github account.
However, I dont think there is some new trend to ditch your resume, I am glad to see companies wanting validation of professional criteria.
To all the folks who are restricted by NDA, I understand your concerns. When I have been held in an NDA over source code I would like to open source, I generally just ask the company if it's possible, offering exactly what code and why code will be released. To date, every company I have worked with has allowed at least some code to be released. Though, to be clear, you need to ask permission here. This isn't some suggestion to just start releasing private source code.
To that point, once a company gets some small benefit, like someone outside their team patching the OSS code, it's been my experience that company will allow even more code to be released.
Anyone who's been employed for a while will not be able to share the bulk of their source code, and source code doesn't typically give a high-level overview of career development and accomplishments.
Wait, Java-related experience? I'm pretty sure there's not a single line of Java in my entire github repo. Oh wait, that's not true - there's my trivial benchmark script that shows Java is slower than python in some cases. :)
Finally you will want to be able to have something in PDF format or that you can print and show to your prospective employers.
He has 58 public repos, but I can't see if he's had significant commits to them. Picking some commits at random from the activity doesn't help much either.
If you are going to restrict your job hunting to people who use GitHub and who contact you, it may be ideal, but why restrict your potential audience so dramatically?
1) Yeah this is dead on. Employers should only care about the code you've written.
2) No your always need a resume because your job history is more important.
3) GitHub complements your resume.
I'd say that this is totally situational. It is like a cover letter. You position yourself for the jobs you want. A lot of startups would probably put more emphasis on your GitHub account then on a resume. If you want to get into the enterprise world then they'd probably care more about your resume.
None of this is needed. It is simply your way of showcasing yourself to get the job you want.
Communication, being able to work on and contribute to a team (and not just a team of developers), understanding business, being able to estimate, being able to understand, articulate, and extract requirements from/to clients/non-technicals/management, etc, etc. Are all much more important and difficult to find.
Because not everyone has FOSS info we also have hooks to have information about private code without sharing the actual code so you don't have to worry about broken the IP, NDA, etc. And other stuff like StackOverflow reputation, etc. You can even give "free beers" to other developers as a thanks/kudos/good work
We are currently working on a new profile, less resume, more dashboard, you can take a look to it here https://masterbranch.com/drbrain/cool-new-stuff
So, the main idea is an identity (not just a resume) for the developers merging all their identities in one place and give them a tool (not only to find a new job) to stay connected to their peers, know what's hot on technology, discover interesting projects, etc.
I see three possible approaches, all with their advantages and disadvantages. (Of course people may fit between them with a mixture of attributes.)
1. Monolithic - Build it all yourself, purpose built and high performance. This is why mailinator and plenty-of-fish are able to produce high thruput on a surprisingly small number of machines.
2. Confederated - Completely distributed. Each machine is its own monolithic platform with everything from DNS to database, including web server on that node, but a cluster of nodes gives you scalability, and workload is distributed across the cluster. (I'm not aware of any examples of this, which is why I'm building Nirvana.)
3. COGS: You build your cluster of machines by architecting a system whereby you minimize (but not eliminate) single points of failure. You have N web server machines and X database machines and you seek out really high performance open source cogs to keep the number of machines low (e.g.: Redis, MongoDB, etc.)
The COGS approach is often taken with the idea that we need something really fast. MongoDB being fast (and "SQL") are the reasons its often chosen. Redis being fast is given as a key advantage (which is relevant for an in memory database, sure.) Node.js is often chosen for similar reasons.
But the ends result of the COGS approach is a brittle architecture. You may have multiple redundant web servers but the thing that distributes loads is a SPF. More specifically the architecture is complicated- each machine has a different configuration, etc.
With Monolithic, you get performance, and save hosting costs, and you can probably scale pretty well because you know your system really well, and you've squeezed out a lot of the inefficiencies that come from being generic (in the cogs approach) such that you can interoperate.
What I think we should see more of is confederated- no machine is a unique snowflake. Every machine is identical to every other machine. This way configuration becomes dead simple-- just replicate your model node, bring it up and data and load starts going to it.
This can be done with cogs- but they have to be fully distributed cogs. An example is Riak (Which hit 1.1 yesterday) which is open source and written in erlang and probably loses to nodeDB in every single single node benchmark you can come up with (not that the Basho people have designed it to be slow, quite the contrary.) But where's the fully distributed web platform for such an architecture? (If you have an answer, please make this question non-rhetorical. I'm putting a lot of time into building one because I couldn't find one.)
An interesting thing about the confederated approach is, because each machine is identical, it could be built in a monolithic fashion. Thus super optimized for its purpose. I'm using a sorta cogs approach because there are many good erlang cogs to use in my project.
But I think the big mistake is to focus on single node performance these days. Servers are relatively cheap, and you need more than one anyway for redundancy, so might as well have a cluster and no single points of failure.
It's true that, as a programmer, you should strive for simple, "correct by inspection" code when possible. And the better a programmer you are, the more you will see and take opportunities to write a bit of code instead of roping in a third-party library, to use a small library instead of a big library, or use a library instead of another process, thus avoiding large swaths of complexity, the bane of software development. On the flip side, poor engineers may make large errors of judgment in this area.
However, a bias against powerful, off-the-shelf tools or a disdain for the "familiar" over the "objectively simpler" is no better. The line between a one-man (or few-man) project and a bigger project is where this really starts to matter. News flash: You can't get that "my code feels correct" feeling (the one that's supposed to substitute for a formal proof your entire system works) when other people are writing it. When putting together a team, using technologies that are "familiar" doesn't seem so intellectually lazy -- and many popular technologies are actually very understandable and well-engineered. Finally, I'm taken by end-to-end testing and Eric Ries's "immune system" metaphor as a way to ensure correctness of a complicated system in practice.
If you're making something big, you might have to put down the microscope. If you're making a tapestry, you need to have multiple threads entwined and stay cool.
But I see another aspect to this whole "We Use Shiny Cogs" movement: high-level vs. low-level. As we make tools that abstract us away from the metal, we are able to spend less time thinking about the electrons flowing across silicon and more time thinking about building something John Q. Public will pay for.
We architect higher and higher abstractions for exactly this reason. And it comes with a price: at some point you stop running things as efficiently as possible and there's waste. If we were all studied CS students and could write kernels and compilers from scratch, we might spend five years building a very tight, efficient stack for Twitter that could run on a single box (maybe with a hot failover). But we're not. We're a collection of humans with differing levels of understanding and will power, many of whom just want to Get Shit Done and stop thinking about kernel task queues.
So lets turn his "rich man's problem" around a bit: you build your idea on top of a stack that you understand and keeps you happy, and when you bring in the capital (through revenue or investment - whatever) you put money into deeper, lower-level engineering. Until then, build your idea the way you know how.
1. Latency. Yes, going out-of-process, even to localhost, is very expensive, and the person the author was responding to should realize that. On the other hand, synchronization is also very expensive. How do they compare? I have no idea[0], and I'm not about to guess. The author shouldn't either.
2. Concurrency. Paul Tyma specifically talks about a "synchronized LinkedHashMap" as the implementation of a cache, so I'm going to take him at his word, understanding it might be a simplification. A synchronized Map is a poor implementation for a cache, because reads will block writes when they don't need to. A better implementation would be a ReentrantReadWriteLock protecting an unsynchronized LinkedHashMap. Redis gives you this behaviour for free (even if you don't know of the existence of ReadWriteLock).
3. Memory usage. Let's be honest--Java is a pig for memory[2] compared to C++, and this is nowhere more apparent than indexing and caching the guaranteed 8-bit strings you'd find in an email. If your whole purpose is to fit more lines into your cache it's genuinely worth considering breaking out of the JVM to exploit the smaller memory footprint of C++ strings (and this really only holds for caches).
Was using a LinkedHashMap a good idea for Mailinator? Probably, I definitely don't have any evidence or suspicion to the contrary. Is it sensible to say "COGS BAD! IN-PROCESS GOOD" for every use-case? Not really.
[0] If I had to guess I would imagine that going out-of-process is 1-2 orders of magnitude slower than contended synchronization. Anyone got any figures?
[1] http://docs.oracle.com/javase/6/docs/api/java/util/concurren...
[2] I would be very surprised if Redis was not more than twice as memory-efficient for this task as a LinkedHashMap. I'm pretty sure that one could implement a C++ solution that would be 3-4x as efficient. This is really only of paramount concern in a caching context, but in that context, it's paramount, because the cost of missing the cache is so phenomenal.
To me, the primary advantage of all this new-fangled web server technology is the improved developer experience, not the performance implications.
It then details and critiques the way a typical one-man, one-site 'startup' is using discrete 'cogs' to build his system, presumably whilst learning how to market, build customer relationships and develop a beautiful and compelling product that makes enough money to keep him afloat.
I think the author may be missing the point. An elegant and sustainable back-end does not directly correlate with an elegant and sustainable business.
Going with big data tool chains from the start is often a overkill for small experiments. But once you outgrow one machine, the pain of undoing all the nice (algorithmic) tricks is also quite severe.
Perhaps it is time to accept that we now produce data at a rate that distributed is going to be the way to process it. But this also means that some of the techniques available for scaling to larger data sets may need to be given up.
That is not strictly accurate. He's taking one aspect of performance - communication latency - and expanding that to be a universal truth of performance.
Pixar's render farms are good. Google data centers are good.
When you're CPU bound, more CPUs can make you faster. Note the specific use of the word "can," as in "sometimes."
Scalability and performance is complicated. Unless you KNOW your product will have a big splash, premature optimization will kill your productivity. And you will get it wrong. You will get the implementation wrong. You will optimize the wrong things and not really understand your bottlenecks. Especially if you've never scaled anything before and haven't been bitten twice by all the compromises you have to make.
Distributed systems are hard. Multi-threading is hard. Sharding is hard. CAP is a bitch. If you can scale vertically, do it. Avoid the demons of distributed work until you require them.
Most of the services/apps we build today would do just fine with setups like Mailinator or gasp ACID-compliant data stores.
At least that way, if you started to hit memory limits it would be relatively simple to scale out to more machines by moving Redis to its own box. It would be a configuration change rather than having to re-architect your custom LRU cache.
Another benefit would be that you could get disk persistence for free while still staying fast. If Mailinator needs to reboot all the emails are lost. That wouldn't necessarily have to happen if he was using Redis.
Hold on just a sec. SQLite? Isn't that essentially equivalent to saying "If you never have to concern yourself with database locking, you'll be winning massively?" How can we be talking about scalability and SQLite in the same article?
For mailinator, they were already popular, so it makes sense to do some one-off coding to make things faster/more efficient. Perhaps, were mailinator starting up today though, using Redis as a good first step would have beaten whatever they had before, and would have been 'good enough' for longer.
Once you've got to the point where you're getting popular, then worry about making stuff scale up.
Quips about premature optimization often make the assumption that any optimization is premature. If data or usage growth (or uptime guarantees, for that matter) is an inevitability, then its often worthwhile to have at least some plan to grow your system beyond a single machine.
so he's right (in the abstract).
but for the reality most of us operate in he's wrong because Done is Better than Perfect.
that said... the "New is Good" thing needs to die. We're not freaking magpies people.
Either way I love the idea of walking around with a full desktop in my pocket that doubles as an entertainment device, phone, gaming platform. The future is indeed bright.
Original video - http://www.youtube.com/watch?v=_--zcmqIyRI
Thankfully, there's this:
http://android.galoula.com/en/LinuxInstall/
Got it on my Transformer. ARM Debian tablet with a keyboard and all day battery life? YES PLZ
They have ramped up capacity recently and it is beneficial to them to fill that capacity rather than shut it down if they can add some revenue.
Later if they need that capacity for higher margin products like some x86 phone processor that none of us know about Intel can end their agreements with the fabless semiconductor companies and produce their own.
I'd go with that one (the first reason was pretty implausible). Get the third party suppliers used to doing test chips on their fab, then pick and choose silicon-proven blocks like the SoC builders on ARM &co are used to.
Possibly, it would be a good idea to have more than one buyer (Intel) in that market ...
Getting Apple's ARM processors moved to 22mm would be a spectacular coup for both Apple and Intel. You'd think that the volume and funds Apple brings would paper over any hard feelings about not using x86.
http://online.wsj.com/article/SB1000142405274870447790457558...
http://www.eetimes.com/electronics-news/4210263/Intel-to-fab...
Now, if you make the best programmable components, you'll sell most of the chips that use new processes, and thus financially strangle other chip manufacturers.
It should be noted that while increased "glycogen supercompensation" in the brain correlates with the much-hyped exercise-induced-cognition-enhancement (aka running makes you smarter/healthier/happier) the author's don't provide any behavioral or cognitive tests. They acknowledge this, and since it wasn't part of their study they just offer the correlation as an interesting hypothesis.
I imagine they'll be testing cognition/behavior in their next paper.
The articles they are referencing is:
I would like to see a study done seeing how 5 hour powers, caffeine, sugary treats, no-doz and other performance altering drugs affect this astrocyte supercompensation process.
1. Exercise without the proper "carbo-loading" can eliminate the cognitive benefits that astrocytes provide in restoring glycogen to neurons.
2. Exercising every now and then versus continuously will not provide these benefits. Intermittent exercise may just provide temporary (up to 24 hrs) cognitive benefits whereas continuous exercise may allow it to last longer (more than 24 hrs).
tl;dr Article should be renamed to: "Continuous Exercise with Proper Post-Workout Nutrition (Carbs) Fuels the Brain"
Google retains a complete history of your interactions with them, which is not subject to this Web History setting, not deletable, not removable, and will be shared across its properties.
Short reply: This doesn't remove Google's search history of your searches at all.
I'm still not sure why people are afraid of Google's new privacy policy. I understand that there are people who have specific privacy needs, but outside that scope I doubt you have anything to worry about.
It's doubtful at best that Google's "log" of you would become compromised (unless your personal account were compromised, but then this would have been a problem anyways!). It also isn't the case that some Google employee is reading row after row of Google's customer DB snooping on individuals.
Google isn't some unified entity; your data is being manipulated by advertising algorithms to tailor ads for you. Unless you care about a CPU "knowing" your secrets, or you have specific privacy needs/concerns, none of this is a problem.
Maybe someone can surprise me with some good reasons to be concerned, but until then I am trusting Google.
It seems like in every suit I hear about where the company was wrong, they lose the case but still try to say they did nothing wrong and refuse to apologize. I was impressed this company did.
https://supporters.eff.org/join, https://supporters.eff.org/donate or https://supporters.eff.org/shop