Github is my resume - <AUTHOR> http://pydanny.blogspot.com/2011/08/github-is-my-resume.html <comment><USER2> A fair bit of discussion here, perhaps much of which misses the point:

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.

<comment><USER3> I don't do the initial screening, but I do use resume's as an ethics test and guideline for interviews. If you list a lot of random crud on your resume and don't know much about it then you don't get in period. In the end every team has a different process, but I don't care what you have in GitHub and I do care what's on your resume so don't get to infatuated with what you hear random people say on HN or anywhere else.

<comment><USER2> The less fodder you, as a candidate, give an interviewer for structuring the interview, the better.

In most companies, interviewers are trained to "screen" candidates with a series of tech-out questions (and maybe some culture-fit stuff).

As a candidate, your interests are best served by (gracefully) taking as much control over the interview as possible. Turn the interview around on the interviewer. Ask the interviewer questions about tech problems they've run into, and then ask if you can talk about how you'd address them. Guide the interview to questions that push the interviewer's buttons.

If you sit back and passively accept the interview as it's offered to you by a screener, you put yourself on a level playing field with everyone else being interviewed for the role. Which is a bad thing.

<comment><USER4> I want to echo Thomas's sentiment here about asking questions of the interviewer.

It really is of tremendous benefit while interviewing to be the one driving (or at least steering) the interview. Even aside from any psychological power dynamic, it's a really good way to make sure you get to cover the things you want to cover.

If you've ever come out of an interview and said "Oh man, hopefully that went good; but I wish they'd asked me to talk more about area 'X'.", you know it can be nerve-wracking.

Being able to have an actual conversation, where there's interplay between the interviewer and interviewee will do wonders for your anxiety level (which considering how stressful interviewing can be for some people, can be a big deal).

</comment></comment></comment></comment><comment><USER5> One of the most frustrating things for me, I feel, is that hardly any of the code I have written is on Github for various reasons (NDA, proprietary code, etc). So when an employer asks me for my Github, what do I do? Do I send him my account showing off my code from 3 years ago containing only a script I didn't really care about?

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.

<comment><USER6> > One of the most frustrating things for me, I feel, is that hardly any of the > code I have written is on Github for various reasons (NDA, proprietary code, > etc). So when an employer asks me for my Github, what do I do? Do I send him > the my account showing off my code from 3 years ago containing only a script > I didn't really care about?

The not-so-easy answer is: find time to contribute to the open source community. This is difficult if your time is already spent though.

<comment><USER7> Weirdly, I find myself contributing to about 6 open source projects, and none are on github.

I imagine few large projects have moved their infrastructure to github. Therefore my github page is almost empty.

<comment><USER8> This is why I'm on Ohloh. You can just give them your Ohloh link instead and see a dashboard of your contributions across projects. And its free.

</comment></comment></comment></comment><comment><USER9> Yeah well it is not and never will be mine. This isn't to say that I wouldn't want to use it to host software (I won't but only because bitbucket is free with private repos) but because I know that appearances matter. As does the ability to selectively show what you have -- you wouldn't want anybody to look at the repositories for that porn scraper you wrote, or that half-finished stuff or what you play around with in other languages.

Finally you will want to be able to have something in PDF format or that you can print and show to your prospective employers.

</comment><comment><USER10> Apparently github is my de-facto resume, because I got emailed by a headhunter just the other day saying he found me on github, and my Java-related experience would be a real benefit to them.

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. :)

<comment><USER11> I've gotten two kinds of offers because of my Github account. The first is a genuine, honest-to-goodness message written by a human in HR that thought my skills were a good match for their company.

The second arrived late last night and appears to be an automated message from Githire[1], though a real name was used in the From field.

I think this is a new trend and while I don't mind it at all now it could easily get out of hand.

[1] <http://githire.com/>

<comment><USER12> I just got an email from them today for a "Senior Java Developer" position. I can't figure out what the deal is, because I have a) very little public Java code anywhere (I have the roughout of a Swing GUI in my github repos) and b) no mention of Java on my resume at all.

<comment><USER13> Yeah, the "GitHub jobs" aren't well targetted, but that's just like Dice, etc. Recruiters are the real source of the spam, not the job site. Fog Creek's job site Careers 2.0 is pretty quiet, but when I do get something, it is usually a direct company hire that is also mismatched. As someone else said, if you want a good match, you need connections, or an excellent or lucky recruiter.

</comment></comment></comment></comment><comment><USER14> github _complements_ your resume in providing evidence that you can write good code.

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.

<comment><USER11> Agreed. Things people write for fun are often quite different from what they write for work. I've written a few compilers and interpreters for fun but that doesn't mean I have the chops to do it for a living. I _could_ learn to do it, but toy languages differ greatly from SpiderMonkey, V8, or LLVM. It's the difference between Ruby <=1.8 and JRuby or Rubinius.

</comment></comment><comment><USER15> As somebody who doesn't use Github regularly, it's a horrible alternative to a resume. Looking at his profile[1] it's hard for me to figure out what he's actually done and it's a bigger time investment on my part. If somebody on my team forwarded me that link instead of a one page resume, I doubt I'd talk to him.

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] <https://github.com/pydanny>

<comment><USER16> Agreed. A large portion of "his" repos are forked from other people's. You can't tell what his level of contribution to any of them is at a glance. Also, he's got an absurd number of files for a project called "Hello World".

Perhaps a better alternative is to keep using GitHub to host your code, but then use your resume to highlight specific projects that you want to show to hiring managers. If they're really interested in you, they might look at some of your other stuff.

<comment><USER17> Actually you can tell, at a glance, how many commits are by the "owner" of a repo. They appear as dark blue in the timeline. If he has forked a project and made his own commits, his commits will show up as "owner" (e.g. for pydanny, he has made numerous commits to his fork of django-crispy-forms)

<comment><USER16> Ah, good call. I'm just used to only seeing dark blue, so I didn't look very closely.

</comment></comment></comment></comment><comment><USER18> That's is the idea behind Masterbranch (<https://masterbranch.com>). Masterbranch creates profiles based not only in information from GitHub but also other forges like BitBucket, GoogleCode, Sourceforge and almost any independent reachable repository out there (we support Hg, Git, SVN, and CVS).

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.

<comment><USER19> _we also have hooks to have information about private code without sharing the actual code_

I'm interested- how do you achieve that?

<comment><USER18> Right now we use the webhooks on Github and Bitbucket. Webhooks send to Masterbranch information about the commit, the message, the files and the date of the commit but never the code, in that way we protect the privacy of the code. This allows us to have a taste about what you are working on.

Due to the feedback right now we plan to release tools to upload full commit history and also hooks for the SCMs without having to host the private code on Github on Bitbucket. (already working on the git hook <https://github.com/masterbranch/Jolly-Roger>)

</comment></comment></comment><comment><USER20> I agree with Danny here. In fact, part of the reason we built Work for Pie is to address this issue.

I also agree with some of the other comments - Github certainly isn't the end all be all. But, we're all trending away from traditional education, and software developers are on the leading edge of this trend. There may be a fairly standard path for "finance guy," but great developers can (and often do) come from any background. Resourceful developers can learn all they need for free via sources outside of a CS degree someplace.

So the question for a company seeking great developers becomes "how do I evaluate these non-traditional folks?" Resumes don't get there, but open source work can work to fill that gap. It's certainly not key for everyone - there are plenty of folks who stand on their own without a public repo in site. But, increasingly, it replaces more traditional indicators of talent like CS degrees.

Just my 2 cents, and I'm admittedly a bit biased.

<comment><USER21> I haven't found CS degrees to be very well correlated with being able to program, so I think this need applies even to people who got an education in the normal way.

<comment><USER22> > _I haven't found CS degrees to be very well correlated with being able to > program,_

That's only true if you artificially restrict your population. It's like saying that music degrees aren't well correlated with being able to play an instrument or sing, because most people I meet at my local jazz joint (including customers) can play an instrument, though only a minority has a music degree.

<comment><USER21> Right, what I mean is that they are not very well correlated among people who are applying to make software for my employer. I'm sure that a more uniform sampling would produce a very high correlation in favor of people with CS degrees, but it would also be a lot less like anyone's hiring process.

</comment></comment></comment></comment><comment><USER23> From the comments it seems like there are three points of view:

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.

<comment><USER24> What GitHub (and others) are for the developer is leverage. There's nothing worse than going into a job interview that you know you are (over-) qualified for and being given fizzbuzz because the person interviewing you doesn't know if you are a rock star or a fraud.

Handing them your GitHub commit log lets you walk in on more equal terms. If they are interviewing you, they already think you're good enough for the position from a coding perspective.

<comment><USER25> The unfortunate truth is that there are fraudsters out there who will attempt to cheat or bullshit their way in. Fizzbuzz is so utterly trivial that you could bang it out in a few minutes. And yet it's amazing how well it weeds out non-programmers, no matter how much they bamboozled over the phone or built up a web of deceit online. You should treat fizzbuzz or the like as a secret handshake, where you write it and then everyone nods with a grin as a member of the fold is recognized, after which the real interview begins.

<comment><USER26> Totally agree.

A shockingly small number of candidates I've interviewed have heard of fizzbuzz. The first time I mentioned it to someone, I assumed they already knew it and would just chuckle and crank it out. However, that's actually kind of rare.

When I do talk to a candidate and get that "knowing grin", my estimation of them jumps up a couple of notches. It seems to actually mean something outside of coder forums.

The real downer is how dismaying it as that candidates clearly have never prepared. How could they have done any research ahead of time and NOT seen fizzbuzz?

<comment><USER25> Actually I don't consider lack of exposure to fizzbuzz a problem. The whole point of it is that it's trivial to implement, even if you've never heard of it before. But a non-programmer (or a "programmer" with no grasp of simple algorithms) will struggle with it.

It's basically a "secret handshake" that non-programmers simply cannot do, and competent programmers can figure out in less than a minute.

</comment></comment></comment></comment></comment><comment><USER27> Summarizing the main points I've picked out of these comments. Anything I'm missing?

A) Github does not cover a lot work that is done because developers are prohibited by NDAs (for their day job) and/or don't have time/inclination to contribute to open source; furthermore OSS is less hot outside of silicon valley

B)Github is an important piece of an overall portfolio; for most employers it is not stand-alone in screening a candidate

C) A code portfolio (github or otherwise) is a complement to the information found in a resume

D) Resume should be used to highlight the most significant code contributions (in github or otherwise)

E)Control is important - developers should be able to hide some projects in order to control the image they want to project; it is important to position oneself for the specific jobs one is targeting

F)For hiring, you need a summary (that's easily printable) of everything that you bring to the table

G) For employers, interviewing is a huge time-sink; there's huge value in only bringing the most relevant people into an interview

</comment><comment><USER28> I feel some of this discussion misses the point. To date the best predictor of the future is the past. And the best way to measure the past is by reviewing work done - not a self-declared history of yourself. If Github does not get you there, then creating some kind of show and tell for anyone to review is necessary. The other stuff you would assumed you can get out of a CV, ie cultural fit, etc you can only assess by meeting the person and working with him/her for a while. At the end of day Github is the best catch all for "show your work" for programmers

</comment><comment><USER29> Candidate's only "resume" was code would be a huge red flag for me [I hire Python engineers btw]. Outside of startup / few persons / open source projects, code is actually a small part of an engineers job. And not that rare/hard of a skill.

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.

</comment><comment><USER30> I think your resume and GitHub account can complement each other — which is why I keep my resume on GitHub :)

I had mixed feelings about making its history publicly available, but I've come to agree with the OP — how you've changed is at least as important as what you are right now.

</comment><comment><USER31> I tend to agree with this point of view: whiteboard interviews fail to predict how you will write real code once you are hired, your actual code is definitely a better indicator.

Asking candidates their github usernames is starting to seem a common trend, in my experience.

<comment><USER21> I have seen a lot of articles on HN that would suggest that someone somewhere is using github for hiring, but I have not heard of anyone actually doing it.

</comment></comment><comment><USER32> A corollary: Github is the first thing we look at when someone applies for a job and we do a cursory review of it before reaching out to an engineer.

The door swings both ways though: forking lots of projects / not understanding Git are red flags.

<comment><USER33> So what happens if someone is employed? Do you just not hire them? Do you expect your employees to spend lots of time coding random stuff outside of work? That's not generally a quality I would put a lot of weight on.

</comment></comment><comment><USER34> GitHub is the best resume. I've been saying that for years! <http://news.ycombinator.com/item?id=1472985></comment>


Bing advertisement URL exploit - <AUTHOR> I wanted to install Chrome on a new computer and used Bing to search for it (http://www.bing.com/search?q=chrome). The top link was an advertisement for a website which was reported as "google.com/chrome" by Bing, but when I clicked through I got redirected to http://www.googlechromedl.com/, a site which may or may not have a reputable download. It's also distributing (or claiming to distribute) an old version of Chrome.
http://archive.is/IBlU0 is an archive of the site, but it doesn't properly handle the advertisement link so you can't actually see where the link redirects to.
This seems like a pretty big security issue. I'd assume that Microsoft would verify that an entity owns a domain name before they allow said entity to register an ad claiming to link to that domain, but that seems like not the case.
I'm not sure how to get in touch with Microsoft. I couldn't find any information about reporting security issues online and I'm just a high school student so I don't have any connections or social media accounts like Twitter. I don't want to sign up for one either, so I'd appreciate it if someone here could get this information in the hands of someone who can fix it.
EDIT: Added a direct link to the Bing search.
The biggest issue is that there doesn't seem to be a simple way to report ad abuse. <comment><USER2> you can at least report the individual case here: [https://advertise.bingads.microsoft.com/en- us/resources/poli...](https://advertise.bingads.microsoft.com/en- us/resources/policies/report-spam-form)

AFAIK Google search does the same :/ Allowing advertisers to show a nice URL while redirecting you through strange lands of marketing services apparently is the more important feature.

<comment><AUTHOR> Okay, I reported it. I couldn't find that link at all when I googled for it. Perhaps I needed to use bing?

Thanks</comment></comment>


The Secret History of Credit Cards - <AUTHOR> http://blog.debteye.com/debt-articles/the-secret-history-of-credit-cards/

<comment><USER2> What is so secret about it?</comment>


Ask HN: Who are the other Elon Musk's? - <AUTHOR> He is not the only one, right? There must be other people who are doing extraordinary things on a same level. Or does he occupy all the space on this stage? <comment><USER2> I've studied Elon Musk pretty closely, and have tried to find others that are similar, but I'm not aware of anyone, at least English-speaking.

The thing that really sets him apart, in my opinion, and something that a lot of people don't fully appreciate - is that he is the lead engineer / chief designer at Tesla and SpaceX.

So, you basically have in one person, someone who is both able to grow a multi-billion dollar company, while also leading the design and engineering of the products. It's very rare to find an individual with this type of skill running such a large company. For example, the CEOs of SpaceX and Tesla's competitors cannot really delve too deep into the engineering details.

If that were it, Elon would still be impressive, but he goes way further than this.

He is not only running one multi-billion dollar company, but two simultaneously. (You can almost say he is running 4 multi-billion dollar companies simultaneously if you include Solar City, and if you see the Gigafactory as a separate entity, not to mention he also oversees Open AI, which is very impressive by itself (he says he spends one day a week on it).

If that were it, Elon would be in a league of his own already, but what makes it even more impressive is that the companies he runs are both in very complex industries, and he is revolutionizing both industries.

<comment><USER3> >he is revolutionizing both industries...

I would wait until that is achieved. I mean, with what he did with the hyperloop thing, I will take what ever thing he says with a huge grain of salt....

One thing is certain. Elon Musk knows his audience and knows them well and knows very well how to milk them. That way, I would say he is the Christopher Nolan of entrepreneurs...

<comment><USER4> Last I checked there are all electric vehicles on the road and space rockets that can land. Wait no further.

<comment><USER3> So where is the revolution?

</comment></comment></comment></comment><comment><USER4> Alphabet (Larry Page and Sergey Brin) is doing a lot of things. From what I understand they're the most advanced when it comes to ML and self driving technology. They tend not to ship so they don't get much credit.

Jeff Bezos is in many markets as well though he seems more focused on making money than directing the course of humanity.

All in all I'd say Google has had a much bigger impact on our lives than either Amazon or Tesla / SpaceX has had thus far.

</comment><comment><USER5> He has hard earned the resources to make it happen big time, there may be many others along the way having less or much less or using a comparable / even bigger pot for different goals.

<comment><USER4> He earned more from 'changing the world' itself than he ever did from PayPal or Zip2.

It's also important to note that his goals with x.com - the company he merged with PayPal - were to create online banking. The impact the company had might've been much greater had things gone differently.

</comment></comment><comment><USER6> Bill Gates.

</comment><comment><USER7> Richard Branson

</comment><comment><USER8> Craig Venter

</comment><comment><USER9> jeff bezos

<comment><USER10> Bezos definitely makes sense since he is also a pioneer in the private space industry, a major philanthropist, and Amazon is a very large and non- traditional company pursuing a wide variety of goals in hardware and software.

<comment><USER11> This. I'd say Amazon has had an insane impact on e-commerce as a whole and that Bezos doesnt get the 'genius/visionary' tag enough.

</comment></comment></comment><comment><USER12> Kanye West

<comment><USER13> Exactly! :D

</comment></comment><comment><USER14> Jack Ma and Wang Jianlin.

<comment><USER15> Care to explain why?

<comment><USER14> Jack Ma is Jeff Bezos and Wang Jianlin is Bill Gates.

<comment><USER16> That explains why I've never seen Wang and Gates in the same place at the same time.

</comment></comment></comment></comment><comment><USER17> Warren Buffett</comment>


Michael Seibel (Justin.tv) & Drew Houston (Dropbox) to speak at Startupcraft - <AUTHOR> http://www.startupcraftsf.com/1/post/2010/09/announcing-our-startupcraft-speaker-line-up.html

<comment><USER2> I'll be there -- if any HN'ers didn't sign up for the 2v2 tourney but want to enter with a Plat/Diamond Terran, let me know :) They're expecting some cancellations so maybe we could sneak in.

More on topic: I'm looking forward to Michael's talk; his testimony before congress a while back was well-prepared and professional. I can only assume a presentation in front of startup guys and gals would be easier than that.

<comment><AUTHOR> There have been cancellations -- we will email teams on the waitlist but your best bet to play is to come well before the start time of the first round and let us know you want to stand in for any no-shows.

</comment></comment><comment><USER3> the new startup interview: beat the ceo on random race selection</comment>


The decline of Stack Overflow - <AUTHOR> https://hackernoon.com/the-decline-of-stack-overflow-7cb69faa575d#.i8v6c3fdx <comment><USER2> I am not using it and reddit is more suitable than it.</comment>


Connecting Kubernetes services with linkerd - <AUTHOR> https://lwn.net/SubscriberLink/719282/d8444c95089cd014/ <comment><USER2> Great article, I've been able to learn more about why a cluster setup could utilize linkerd. However this statement confused me a little:

        However, Finagle is written in Scala, which Gould concedes is "not for everyone".

linkerd is written in Scala [1] and linkerd is written in Rust [2]. If he is optimizing for other people's contributions, is this really the best way to go?

[1] [https://github.com/linkerd/linkerd](https://github.com/linkerd/linkerd) [2] [https://github.com/linkerd/linkerd- tcp](https://github.com/linkerd/linkerd-tcp)

<comment><USER3> > linkerd is written in Scala [1] and linkerd is written in Rust [2]

Though your links are correct your statement isn't. Linkerd is written in Scala, but the Rust bit is linkerd-tcp, a TCP loadbalancer, which linkerd (the Scala one) doesn't handle as that covers HTTP and gRPC with optionally encrypting connections between linkers using TLS.

> If he is optimizing for other people's contributions, is this really the > best way to go?

But is he optimising for other people's contributions? Using a C/Rust for something like a TCP proxy makes a lot more sense to me than having a JVM do that. And if he perceives Scala as "not for everyone", maybe adding Rust means he might get more contributions to those components?

I think that statement actually refers to Finagle itself being written in Scala, so if you want to use it you have to at least hoist your own apps on the JVM and integrate Finagle in them. Finagle is essentially client-side and requires integration into your app tightly coupling the two. By spinning it out as a standalone component that acts as a proxy, like linkerd is doing, Scala doesn't get in the way and what Finagle offers can be used with a mesh of microservices written in a myriad of languages.

<comment><USER2> Sorry, not typing -tcp on linkerd-tcp was completely a typo on my end.

> I think that statement actually refers to Finagle itself being written in > Scala, so if you want to use it you have to at least hoist your own apps on > the JVM and integrate Finagle in them. Finagle is essentially client-side > and requires integration into your app tightly coupling the two.

Thanks, this is the answer I have been looking for.

</comment></comment></comment><comment><USER4> Lyft has a tech similar to linkerd called Envoy: [https://github.com/lyft/envoy](https://github.com/lyft/envoy). It is a bit lower level than linkerd (based on APIs rather than already integrated with common services) and written in C++.

I'm working on an adapter which should offer a better integration with Kubernetes. The end goal is to have envoy be able to replace our Ingress controllers. Not having to run the JVM on every machine is also nice.

<comment><USER5>
      > Not having to run the JVM on every machine is also nice.

Personally, Envoy compiling to a binary makes it much more likely that I would experiment with it than with linkerd. I have hesitated trying out linkerd because we don't run anything JVM based in any of our stack, and we aren't currently excited about introducing any.

I am definitely going to take a look at Envoy. Thanks for referencing it!

</comment></comment><comment><USER6> The content of the article does not have anything to do with the title. There is not mention of how linkerd and k8s work together.

</comment><comment><USER7> > Facilities that linkerd provides to assist with this include service > discovery, load balancing, encryption, tracing and logging, handling > retries, expiration and timeouts, back-offs, dynamic routing, and metrics.

Why not use SRV records and TLS? Retries, expiration, timeouts, and back-offs can all be placed into the networking library, and are, commonly.

Also, regarding [https://linkerd.io/](https://linkerd.io/), what's with landing pages having almost no useful information on them. "linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications" what's that even mean?

> Fast, lightweight, and performant > Handles tens of thousands of requests > per second per instance with minimal latency overhead. Scales horizontally > with ease.

Well, since you're calling yourself "transparent" I would hope it'd be fast!

> Any language, any environment > Runs as a transparent proxy alongside > existing applications, integrates with existing infrastructure.

So, it's just proxying and retrying things and doing tls for me? Why isn't this better handled in the library I'm using to make the call in the first place?

> Latency-aware load-balancing > Balances request traffic using real-time > performance, reducing tail latencies across your application.

Sounds like it requires a lot of cross-talk on my network, eating up bandwidth. That doesn't sound lightweight.

> Runtime traffic routing > Provides dynamic, scoped, logical routing rules, > enabling blue-green deployments, staging, canarying, failover, and more.

OK, some of that does sound useful, but some of it still feels like something the caller should handle.

> Drop-in service discovery > Integrates with most service discovery systems, > decoupling applications from specific implementations.

What's this mean? Why not just use SRV records?

> Production-tested and proven at scale > Powers the production infrastructure > of banks, artificial intelligence companies, social networks, government > labs, and more.

I know why this is here, but it feels like _everyone_ claims the same thing, so, to me, it just becomes noise.

> "linkerd allows you to drop in a transparent layer of application resilience > and provides the operational affordances critical for modern, cloud native > environments." > —Oliver Gould, CTO, Buoyant

This sounds doesn't make sense to me, you can't "drop in" resiliency. It needs to be built. The whole thing just feels like it's all marketing and doesn't tell me exactly what problems it's solving for me as a developer.

\</comment><comment></comment><comment>

Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving.

<comment><USER3> > > Latency-aware load-balancing > Balances request traffic using real-time > performance, reducing tail latencies across your application.

> Sounds like it requires a lot of cross-talk on my network, eating up > bandwidth. That doesn't sound lightweight.

Why does that require eating bandwidth? It's a proxy. It can derive statistics from past and current connections and make decisions based on that data for new ones without talking to anyone else.

> Maybe I'm just an old fogie, or being dense, but I still don't see how this > solves any problems I can't and aren't already solving.

So? If you're happy with your solution, keep it! But maybe others haven't solved all these problems, or don't like your approach to how you've solved them for other reasons or don't even want to spend time solving these problems in the first place. For many a component like this means it's 10 less things to deal with and more time to focus on building features that'll matter to their end users.

Besides, just because it can already be solved doesn't mean it's not worth trying out other approaches.

<comment><USER7> > Why does that require eating bandwidth? It's a proxy. It can derive > statistics from past and current connections and make decisions based on > that data for new ones without talking to anyone else.

Wouldn't those stats get out of date really quickly if you're not constantly talking to that machine?

> For many a component like this means it's 10 less things to deal with and > more time to focus on building features that'll matter to their end users.

But now you have a new component that you need to test and get to know. You didn't get rid of those 10 things, you just compartmentalized them in something else that needs to be maintained.

> Besides, just because it can already be solved doesn't mean it's not worth > trying out other approaches.

Very true, I just don't see the particular advantages to using more basic and well-known tools like DNS and TLS.

</comment></comment></comment><comment><USER8> I appreciate the sentiment behind linkerd et al but I think we are _really_ over-complicating things and tying ourselves into knots by going head-first into this world. I can't help but think we're going to regret it in a few years.

The complexity introduced not only by Docker, but also k8s and all of the other things competing for a spot in the middle of your cluster, is immense and _widely_ underestimated.

Your applications need to be aware and adapted to the k8s model of automatic pod termination, no hard storage, etc. Google has had over 10 years with the best computer scientists money can buy to perfect their stack. Most companies don't.

For most companies, k8s/linkerd/Docker deployments are a case of overengineering run _frighteningly_ amok.

There are many-a-snafu lying down this path. I'm very worried about how casually everyone is willing to jump aboard.

One particular worry: most Dockerfiles are built on opaque images registered with an image registry, and many of the publishers are not well-known. If you want Ruby, the habit is to go find someone's "pre-configured" alpine-ruby image (for instance). These are frequently distributed by complete strangers. Building "from scratch" off the base image distributed by the distro itself is considered "the old way", at least among those I've worked with.

My understanding is that most public image repositories are unmoderated. The moment a widely-used image gets pwned, there is going to be panic.

Source: been converting entire company to Docker/k8s

<comment><USER9> Yes, it's insane. I can only attribute it to that I don't work on problem of any scale (amount of apps, servers, deployments per day, etc.) and all of these people do. Who really wants to spend their time and effort running a Kubernetes master and nodes, 3+ Consul/etcd nodes, and now some fancy load balancers? The ratio of companies that would benefit from that to the number of companies working on products in the space is way out of wack.

<comment><USER8> I would not take the claims of scale at face value. People make this claim to boost their own egos, and the reality is that many of the people who do this would be more than fine on a handful of servers. They just want to feel important.

My frank take is that k8s was developed at Google by the seat of their pants (and yes, I know it's their third-gen orchestration platform), they talked about it with outsiders here and there, there was demand for it because there's demand for anything and everything with Google's name attached to it, regardless of applicability or propriety or any good sense (case in point: companies pretending to be smart by "integrating" TensorFlow), and they released k8s in response to the clamor for the mysterious Google-backed orchestration platform, much to the detriment of non-Googlers everywhere.

Maybe it's a coordinated plan to harm young startups that may challenge them. Or, alternate theory: perhaps it's a coordinated plan to get people to buy far more cloud instances than they actually need, since k8s literally cannot run on a single instance; to run it locally, you have to run virtual machines.

I understand that k8s has improved and that many people use it (myself among them), but it maintains that vibe of an internal tool; something so convoluted and complex and inside baseball that you'd only voluntarily undertake it if someone said your paycheck was at risk.

<comment><USER10> Just FYI, over 50% of contributions come from !Google, and that's part of the reason that so many people (CoreOS, Redhat, Apprenda, Deis, thousands of internal folks) have rebased on it.

I saw some of your other comments - I'd love to understand better what we could do to either a) make it feel like not an internal tool and b) if you didn't use Kubernetes or containers, how you'd prefer to run distributed workloads.

TBC, I totally agree with you - if you're running 1-2 nodes, and don't care about downtime, you should NEVER use Kubernetes or any orchestrator. Once you get to 3+, however, I can't imagine using anything else.

Disclosure: I work at Google on Kubernetes

<comment><USER8> So I actually answered this question for you when you asked it in December: [https://news.ycombinator.com/item?id=13241681](https://news.ycombinator.com/item?id=13241681) . ;)

Not to toot the same horn.

I have more experience with Kubernetes now than I did then, though I think a lot of those interface snafus, which is most of what the old post discussed, are still valid complaints.

You mentioned back then that if people aren't aware of some kube featureset, they end up reimplementing it. You mentioned logging. Can you tell me what you recommend for logging?

Right now, we have everything writing logs to stdout in the container, which gets recorded by kube in something like /var/log/kube/containers/ * . Then we have a fluentd container that reads the logs and uploads them to an external machine, which is running fluentd containers that receive the input stream, transform it according to rules, and pipe it out to a cloud-based log aggregator.

Is that how it's supposed to work? I know we used to do it somewhat differently, but had trouble with resource consumption that was disrupting our pods.

And here's a potentially legitimate Kubernetes issue: the scheduler is only reading the load _generated from containers administered by Kubernetes_ , so even though the box is being thrashed, k8s will not be aware of the problem and continues to report the node's resources as healthy. In our case, the dockerd process was using 4.5 cores. Kubernetes seemed unaware and it was affecting our performance because another busy pod was on the server and was not getting clamped by its quota (since it, technically, was not hitting the quota for itself). Shouldn't these be defined relative to overall system resources, and not just the containers that kube can see?

It's possible Kubernetes _was_ aware, but that we didn't know how to see it. A colleague told me the interface I was looking at for pod performance data reflects only the _quotas_ , not the actual utilization, so maybe k8s knew (why isn't there a `kubetop` that can be run on the host to supervise?). I also hear that automatic rescheduling is still in draft stage, so if k8s detects high load on a kubelet, instead of moving the pod, it will just not assign new pods to it.

About addressing. Right now, we have dev, stage, and prod. We have a container that takes all traffic targeting the kubelet on port 80 and proxies it out to the pod using servicelb. It's set up to forward from [http://app-label.env- name.example.com](http://app-label.env-name.example.com) to a pod matching that label. It's annoying that we have to run an external container for this in the first place and do extra configuration on it, but it's also annoying that since servicelb is not aware of the beta label attempting to simulate hostnames, we can't individually address instances of apps. Is that how this is supposed to work, or is there a ready-built solution that makes this much easier that we're overlooking?

\----

>I saw some of your other comments - I'd love to understand better what we could do to either a) make it feel like not an internal tool and b) if you didn't use Kubernetes or containers, how you'd prefer to run distributed workloads.

The best way to improve Kubernetes would be to:

a) simplify the terminology;

b) simplify the kubectl command, and particularly make it follow semi-standard Unix utility conventions (examples: -f should mean force or not be used (and yes, I know some other tools commit this sin too, but the association with "force" is nerve-wracking on a production environment), should probably be -r or -o; --from-file is ambiguous, and should be --read-literal or -r --raw or something like that);

c) simplify the configuration syntax and files;

d) provide simple ways to get real storage and real IPs (I haven't thoroughly investigated StatefulSets, so it may do this). I know that Google has long ago gone into a plane where these are irrelevant, but normal companies haven't, and IMO there's no reason they necessarily should;

e) provide simple backup and restoration methods (afaik, this involves multiple steps, including backing up the etcd cluster (not allowed to run on the master, or just conventionally doesn't?)).

My suggestion for distributed workloads is:

a) script your machine in Ansible or similar, and make a base image from that;

b) use your cloud provider of choice to deploy new instances under the circumstances considered necessary;

c) register the new node with haproxy or whatever sits at your front end (often a cloud-provided LB);

d) use conventional administrative and monitoring tooling to administer.

All of that is fully scriptable, in far less time than it takes to convert to Docker/k8s.

\-----

>TBC, I totally agree with you - if you're running 1-2 nodes, and don't care about downtime, you should NEVER use Kubernetes or any orchestrator. Once you get to 3+, however, I can't imagine using anything else.

Why is the above-recommended distributed systems strategy inadequate, even for people with more than 3 nodes who care about downtime? What's fundamentally wrong with it? What unique value does k8s bring to the table?

What's the k8s replacement for htop? tcpdump? df? and all the other utilities, and why are they better, and what benefit does k8s provide, that we didn't already have, that warrants giving up everything? I know it's not TRYING to replace all of that per se, but the practicalities make kubernetes the authority for such information, and you're not supposed to have to get onto the kubelet itself to diagnose these types of issues so you can't even use root on the Docker host to try and do some of this.

In our deployment, the main k8s jockey just kills pods if they're acting up and hopes that will magically fix it, because the devs don't want to get near the setup with a 10-foot pole. Before, they would SSH in and go over the issues. Now, since not only can't you SSH in but there's a convoluted process to get a shell, and then the container will not have any diagnosis tools in it anyway, it's very hard to have them collaboratively troubleshoot a problem we're seeing in the wild.

I can't tell you how many times I've had someone tell me "They _must_ have a better answer for that; Google uses it after all...". These people are under the mistaken impression that if Google is using it, it must be robust and stable, when in fact the opposite is usually true, and I don't think Google tries to pretend it's not. It's probably just misinterpreted the signal from the developer community as meaningful approbation, when it's really just blindly following the cool kid on the block.

It's not that k8s isn't a neat thing. It's just that it's solving a problem that pretty much only Google had, and now everyone else is plummeting down the rabbit hole.

We've spent probably 1.5 man-years getting our infrastructure containerized and kubed up. We're not at 100% in prod yet but getting pretty close. It's clear that I'm really dumb but I haven't even been the main one doing this, so can't blame it on me. That's a _huge_ project, and how does k8s/Docker justify the cost? It lets us cut down on AWS usage? Sure, but nowhere near the proportion of cost. It "makes it easier" to administer the cluster? Nope, not a chance. It's fun to kill pods but that's living on the edge, most apps written by non-Google can't take that. Solution? Write an "operator", which appears to be any random program that intercepts the k8s API and does stuff to support pods, etc. That sucks, why don't I just keep the init script that works fine?

One could argue that k8s is about resource utilization, which is sort-of-but- not-really-true. And that has a downside; we've essentially turned our environment into a shared host now, and despite k8s quotas, we still have pods that are bad neighbors; this is turning out to be quite difficult to control.

So I'm just really at a loss here. Google wanted it and they built it and it's working for them, that's great. That's an internal tool. How does this help anyone who wants to run a normal site this way? I haven't heard a single success story that had a moral or goal behind it other than "I'm cool like Google now too."

And on top of all of this, before k8s even comes into the picture, you have to make a Dockerfile and run your application in Docker, which is a PITA itself, in terms of stability, security, _and_ configuration (see above-mentioned dockerd hammering the box, dockerd hangs or breakages that render a box useless, having to deal with port forwards, name collisions, large Docker caches, docker's inability to remove old images or containers on its own, Dockerfile lameness, culture of importing unknown images, etc.).

I like the ideas of containers (and have liked them when they were called "jails" in past eras ;) ) and I like the idea of orchestrators like kubernetes. But I think it's very early days right now for both, and that they will need radically improved simplification and stability before they are appropriate for general use.</comment></comment></comment></comment></comment>


The Principia Discordia (classic hacker/60's counterculture) - <AUTHOR> http://www.principiadiscordia.com/book/9.php

<comment><USER2> Sweet. I haven't been to this site in a while, but I still have two dead tree copies - an IllumiNet Press 1991 printing and a Steve Jackson Games 1994 printing.

Hail Eris. All Hail Discordia.</comment>


Why not incorporate off-shore? Ireland's corporate tax is 12.5%; British Virgin Islands' is 0% - <AUTHOR> <comment><USER2> From what I read, the legal environment in your place of incorporation matters as much as, if not more than, the tax rate.

So many companies incorporate in Delaware because it has extremely detailed corporate case law history (and separate courts for corporate law), even though it is more expensive to incorporate there than most other states.

I would imagine for the average startup it's more an issue of overhead costs. Incorporating in Ireland, for instance, would require you to have a legal expert in Irish law on the payroll (most likely an Irish Lawyer) and deal with all the fancy tax forms I'm sure the IRS has for offshore companies doing business in the US.

I highly doubt either of those places is a hostile legal climate by any means (but IANAL!), but it seems like all that paperwork would be distracting from your business when you are that small.

</comment><comment><USER3> Don't bother, if you plan to ever raise money, get acquired, or go public.

I took the advice of an attorney in Texas and incorporated in Texas, with plans to switch to an LLC/Corporation holding company combo when it began making money--there's a well-known loophole in Texas tax law that allows the first 15 million to go untaxed (SBC LLC are the most famous beneficiaries of this loophole, and the most generous to politicians who keep it on the books). But when I began talking to folks in the rest of the business world it became apparent that those benefits were out-weighed by the negatives for a tech company that plans to be acquired or go IPO.

Just incorporate in Delaware, and don't worry about it.

</comment><comment><USER4> You won't save on taxes because you pay where you're doing business. So, if your office is in California, or you hire people in California, then you'll have to pay CA taxes. At lease that's how it is in CA, AFAIK.

</comment><comment><USER5> Ireland and London are good for gambling or related ventures. Not sure why you'd want to do it there otherwise.</comment>


Why I don't like "lab" companies. - <AUTHOR> http://sahillavingia.com/blog/why-i-dont-like-lab-companies/ <comment><USER2> _Every startup is already a "lab!"_

So you _do_ like "lab" companies - you just don't like calling them labs?

I'm on the "call it like it is" side of the equation.

I actually like what Milk is doing, and I like "lab" companies in the mobile space. I think, outside of Angry Birds" its going to be very difficult for an "iPhone App" company to exit based on a single app. I think the "Tapulous" model, where a single brand makes a whole bunch of Apps is much more attractive. I think these kinds of companies are going to have a much harder time getting early seed funding unless you're a Kevin Rose or Bill Nguyen (BTW I think Color _became_ a lab, I don't think it started that way). But on the flip side going to be much easier to bootstrap these companies.

<comment><USER3> _So you do like "lab" companies - you just don't like calling them labs?_

No, there's a distinction trying to be made here. A startup is a _temporary_ lab. The goal is: Do lots of experiments, but generally only a few at a time, and then when you find something that works even slightly _stop experimenting_ and start iterating.

It's true that the word _startup_ connotes experimentation, for the same reason that the word _baby_ connotes being small, helpless, and illiterate. But just as the purpose of a baby is to _stop being a baby as quickly as possible_ and grow up to be an adult, so the purpose of a startup is to find a repeatable business model and then _crank on it_.

Whereas a true "research" company doesn't do the cranking part. Their entire product is research reports, and their customers are the people who give them grant money.

Now, mobile-app companies with constantly-churning portfolios probably don't fit cleanly into this dichotomy, which seems to be what you're sensing as well. And it's also fair to ask if the "lab" metaphor really fits, e.g., Milk. Maybe the Milk folks have decided to label themselves a "lab" in the short run but will eventually pivot to being "the X company" once they find the value of X, just as Rovio used to be "a company with a portfolio of small games" but is now "the Angry Birds company".

<comment><USER4> I think the second part of your comment hits the nail on the head: labs might actually be _safer_ because of that lack of total commitment to a single idea. This lets them seek out value in areas that might be too risky, or with product/market fit that's hard to predict in advance. Essentially, it lowers the chance of failure for the startup.

<comment><USER3> The business model you're describing is YCombinator's business model: Invest in ten or twenty experimental businesses at a time, to hedge against each individual business's probability of failure.

The problem with this model was described by the OP: It's hard to sell "Product/Market Fit in a Box" because so much of product/market fit is tied to _specific_ products built by _specific_ teams. YCombinator finds product/market fits, but they don't just sell the ideas: They sell the _specific companies and products_ along with the ideas, because these things are not separable. Indeed, PG's explicit belief is that even a valuable idea like, say, Dropbox is less valuable than the specific team of people who built Dropbox.

Because the value is in the people and the brands and code they create – these things are your real product – your "labs business" will need a constant stream of fresh recruits to replace the veterans who graduate. You're basically running a school. (Incidentally, it's no coincidence that, even in actual laboratory science, so much funded research gets done at schools.) However, in case you haven't noticed, it's not that easy to find a constant stream of smart founders, each with the skills to find a product/market fit and grow it into a business.

And there's a big cash flow problem. Poor people do not get to be angel investors, no matter how good the angel-investing business model is. Perhaps funding ten startups at once is less risky than funding just one, but it also costs ten times as much up front, and it will take years to find out if you have a winner. Better have years worth of living expenses in the bank. Better have a lot of money you can afford to lose.

</comment></comment></comment></comment><comment><USER5> _PayPal had a clear vision_

This is actually not true. They started as a way to transfer money or IOUs between palm pilots. The web portion of the product got so much more traction that they pivoted.

</comment><comment><USER6> I agree with most of the points in your blog post and would also not recommend to take the 'labs' approach. My team and me have dropped our 'labs' company just recently. We have built extremely innovative algorithms to tackle a huge problem but completely failed to define and follow an actual product vision and strategy. Our motivation went down over time and our individual visions became more and more misaligned.

</comment><comment><USER7> I feel the word rubs you the wrong way and you are trying to come up with arguments to support your emotions.

</comment><comment><USER8> I view these lab companies as following the publishing model. A company like Milk produces say 12 apps a year hoping a few of them are hits.

</comment><comment><USER9> BTW: chrome 15/Windows-text zoom does not work in your blog. FF 8.0/IE 8.0 increase font size as expected

</comment><comment><USER10> What you are saying is right indeed, but most of the problems that you talked about are people problem rather than having to do something with the tag of "labs". Otherwise how different is the failure of two consecutive products by the same team under the same "labs" banner from the failure inside two entirely different banner!

</comment><comment><USER11> they have to call it a lab to pump up the valuation and attract investors.

Would you rather invest in a single iPhone app, a company that makes iPhone apps, or a lab?</comment>


Apple Retina iMac 5k Page 404's - <AUTHOR> http://store.apple.com/%20/shop/go/imac_retina

<comment><USER2> Try this link: [https://www.apple.com/imac-with- retina/](https://www.apple.com/imac-with-retina/)

</comment><comment><USER3> Yeah... that's because you have a space in your URL.</comment>


Exceptional Performance: Best Practices for Speeding Up Your Web Site - <AUTHOR> http://developer.yahoo.com/performance/ <comment><USER2> This is an awesome find. I had no idea Yahoo had a blog like this.

But just in general, I think people don't give Yahoo enough credit for what it's trying to accomplish. They have a lot of cool things in the pipeline and are big proponents of open source (ie. hadoop). This is just another example of how it's trying to reach out to startups and developers. Good for you Mr. Yang, keep on fighting the good fight.</comment>