jb613

"Opening the code doesn't by itself eliminate the vulnerabilities. What it does do is fire the starting pistol on a race between black hats and white hats to find and either exploit or close the vulnerabilities."

The race is more dependent on motivation than whether the code is open or closed. Often, blackhats are financially motivated (whether they themselves monetize the vulnerabilities directly - or they are hired-by/paid-for a 3rd party) - they factor in their return on investment (ROI). Open source merely makes their job easier but given enough motivation, they can and will find vulnerabilities in binaries, remote services, etc almost as easily.

One problem is that many people believe in "many eyes makes all bugs shallow". Numerous examples prove that assumption false. Is it because there is more financial interest in closed systems? ...or is it because in open systems people automatically assume that because it's open that someone else must have vetted it? (e.g. "if I'm interested in it, and thousands/millions are too, then it's highly likely some expert better than me already looked at")

doesn't matter whether no goroutines or thousands - you either handle errors or pass upwards. Anyhoo, just pointing out that it has the flexibility to do either.

You are predicting the future (of Go) based on the past (of Java).

Non-idiomatic Go (or as you call it "bizarre hacks disguised as cleverness") is frowned upon. One example that comes to mind is the Martini web framework[1], which, once pointed out, resulted in a rewrite[2].

[1] https://github.com/go-martini/martini [2] https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...

"The problem with handling everything right away is that it lacks flexibility to handle things in what could be the optimal manner."

You can pass the error (or another) up the stack. The language is flexible.

by "hack on it" he/she means being able to 1) easily understand it by looking at it, 2) easily figure out how to modify it (to add functionality or change it). You are reading "hack" as a bad thing when really it's a good thing.

Anything that evolves over time requires changes. All of the examples you give (finance, healthcare, safety, money/lives matter) are better served with people being able to read and maintain that code.

the article is suggesting that when people say they don't want to debug or write in Go is because it challenges their previously formed beliefs in what they believe they need from a language. The fact that there may be another way or that projects are increasingly succeeding, challenges their identity.

One premise that I think the author is wrong about is #3 (people being deceived into liking Go). My experience is that a number of folks liking Go is due to past experiences and recognizing Go's completely different approach resolves at least some of those deficiencies or the problems those practices eventually led to.

But, I think the main point of the article is that Go's complete 180 on many things challenges the beliefs of some and hence their identity. We see it every time a discussion on Go pops up.

Yes totally subjective - different people work on different projects which eventually opinions are formed from.

I don't think Go was intended to improve upon any Lisp deficiency.

"Selling points are not facts"

except when talking about maintainability, you are not talking about facts. Show me the "fact" that Go is hard to maintain.

"The lack of exceptions makes writing correct code really tedious."

Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt.

Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid potential future costs.

"I dislike Go because I agree with the criticisms of it and I'm afraid I might end up having to maintain code written in it one day"

and:

"I also don't like Go much, but it's not because it challenges my identity"

You are EXACTLY who the article is talking about. One of Go's selling points is maintainability. Go's inherent bias towards maintainability challenges your identity.

"Hafner told me that in the middle of the development work for DriveCrypt, he discovered that Le Roux was still working on E4M and had incorporated some of his work for SecurStar into his personal project. Hafner was furious. Because E4M was an open-source product, the source code that Hafner had personally funded, he claimed, could now be used by anyone to develop an encryption product of their own."

I've seen this a few times now (employer doesn't want employee to take knowledge out).

apparently those corporations can find the people willing to work at those salaries. It's up to the tech workers to decide whether the location is worth the lower bank account.

> "A tech company that can't afford to pay an employee to rent a $1589/month apartment is not a tech company."

Tech companies don't have to be in Vancouver. The fundamental component that a tech company requires is talent. There's relatively little distinguishing talent in Vancouver that can't be found in several other comparable jurisdictions within Canada. A tech company that pays higher wages simply because the employee lives in a high-cost jurisdiction is a tech company that is less competitive.

That's the from the company view, now to address to your personal view:

> "I'm standing at my desk in my apartment that I pay $1589/month for."

and:

> "The single-family detached home is dead. Live in a condo. Everyone gets a view. Everyone gets sunshine. Everyone gets services. Everyone gets a park a block away. "

Yikes! That rent adds up to $381,000 over 20 years. You can easily find single-family detached homes for that price in places like Waterloo, Ottawa, or Montreal suburbs and in 20 years have it paid off and own an asset while Vancouver renter will have no asset and more rent to pay. Those 3 locations have comparable tech job prospects as Vancouver with a whole lot more sunshine in the winter.

> "Anything that benefits all of humanity is very difficult to recover the value of as a patent because engaging in licensing transactions"

"Anything that benefits all of humanity" should be recognized as inherently valuable to fund and therefore would be useful to look at reducing the costs of "engaging in licensing transactions". In other words, society may benefit by making it easier (or less costly) for the researcher or innovator to be rewarded - thereby increasing the incentive to create something to benefit humanity.

> "This is a curious point, however: it almost suggests that the proportion of innovators in a given population is (was) fixed, and they would innovate where the promise of rewards is highest."

True but I'll add that often for individuals to quit their jobs and focus on innovating requires more than just "the promise of rewards". Immediate funding often trumps the promise - and that funding comes from some kind of investor. Many investors view patents as: 1) a way to recoup at least some their investment dollars if the innovator can't monetize, 2) prevent competitors from simply copying the results of the R&D.

Moser references James Bessen who wrote a highly-cited paper that has been largely debunked [1][2][3]. Specifically, the paper claimed patents cost the economy $29B per year.

> "Actually it's good to have someone actually look into the data and challenge the dominant assumptions"

Challenging the dominant assumption would be to challenge Bessen's number and the numerous articles that automatically assume that value to be true.

[1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2117421 [2] http://www.iam-media.com/blog/Detail.aspx?g=454c1adc-52c3-4c... [3] https://gametimeip.wordpress.com/2012/07/30/patent-scholars-...

> Most innovations come from startups, academics, and volunteers in FOSS.

Not sure you can lump 3 very different types of entities into one group.

I agree with your 1st type (startups) but what about #2 (academics) and #3 (FOSS volunteers) - what are some examples that "most innovations" come from them?

THIS got downvoted?!? People were either too lazy or couldn't come up with a rebuttal

sure, there are numerous jurisdictions outside of the U.S. where patents have become stronger, but enforcing a U.S. patent is the weakest it's ever been.

what is:

1) http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=H...

2) www.google.ca/patents/US8396808

3) http://pat2pdf.org/patents/pat8396808.pdf

if not publicly disclosed?

your statement is contradictory - you claim large corps increased IP protection yet what we see today is that patents are the weakest they've ever been.

> What service did you render to Square to earn the payment you claim to deserve?

the service rendered was he made public the details of the invention. Whether Square read or did not choose to read the patent is beside the point.

> Did they get the idea for their product from your patent? Did they learn how to implement their process from patent?

You are assuming that Square did not read his patent - which if true suggests that Square inefficiently re-invented the wheel. You know, that whole standing on the shoulders of giants thing.

However, what we find happening lately is the concept of efficient infringement where large corporations have found it more cost effective to infringe and fight with their lawyer muscle than to pay inventors their due rights.

> Your patent did not inspire anyone at Square

question is how do we distinguish between patents that "inspired" and those which did not?

Or does inspiring even matter - anyone can see the "inspiration" on Android from the release of the 1st iPhone (e.g. before and after designs) - yet this fact plus all of Apple's $billions were unable to stop/prevent Android from their clearly inspired copying.

intercepting the win32 calls that make the syscall is often enough

who are these "companies don't want to disclose IP"?

Software startups disclose their IP whether through traditional IP protection (copyrights, trademarks, patents) - or open source. Those relying on trade secrets do not disclose their IP to investors.

"startup investing" depends on your definition of startup.

For example, a person that has applied for a patent - no VC would call that a startup, but perhaps those with intimate knowledge of what the patent will lead to may indeed call that a startup.

Another example are "stealth startups" - we explicitly refer to them as startups yet many are merely patents with maybe a partially working prototype but no product yet.

There are instances where both of those examples are combined (sole inventor + operating in stealth). Just because the entity doesn't fit the profile of "startup" for VC's doesn't mean there isn't room for that type of "startup investing".

"Are you arguing that it doesn't exist, that the one I suggested isn't the appropriate one, or that we can just ignore the problem? "

None. For any area, there will exist numerous levels of perspectives such that people will argue over which level matters.

"This is basically about framing issues"

People will move to arguing which frame is relevant.

Perhaps a lesson to learn here is consider who won. While AltaVista focused on physical details (number of servers, resource usage, etc...) they missed the boat on the bigger picture - how to significantly improve search engine results. Brin&Page did, filed a couple of patents, secured investment, registered google.com, scaled, etc and won.

Perhaps this is another example of what you measure is what you become. I realize it's just one email and we're missing all sorts of context, but to me, this email seems to boast at their technical prowess of being able to pull off the scaling aspects. Perhaps this email indicates measuring physical resources was a higher priority than DRASTICALLY improving search engine results.

The problem with "which license will lead to the largest and most viable ecosystem of free software" is that it's the wrong question to ask, because the perspective is too narrow. What matters most IMHO is which option will lead to longest and most viable ecosystem of satisfied engineers. If you take this perspective of satisfied people instead of an ...

IOW, I suggest such a system simply moves the problem from answering virtually the same question over and over to the problem of which level to ask a question at. Perhaps, in the name of progress, a step forward, or perhaps not.