Open source confronts its midlife crisis - <AUTHOR> http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-crisis/ <comment><USER2> There's an assumption that an open source project should "belong" to a single company (Mongo, Elastic, Confluent, etc). I think that model may be more dangerous to OSS than large cloud providers.

If it's truly open source, one business shouldn't dominate the project's development. That's tantamount to the project becoming shared source that accepts community contributions, not community driven open source backed by many orgs. It reinforces a monopoly in that community. And these companies themselves are not tiny victims (many IPOd at multi billions). They also tend to compete with their customers and community in the same way as AWS, so I'm not sure they can cry foul when AWS does the same.

<comment><USER3> It's hard to drive non-incremental innovation without a benevolent dictator model.

For example, the Hadoop ecosystem moves very slowly, and most of the innovation happens in new projects that are added, not in core infrastructure. An example of moving slowly is the fact that even to this day, the HDFS high availability story for NameNodes is pretty wonky.

In a community model, if someone wants to do a large scale refactoring or rework parts of the architecture, these projects die of a thousand cuts with objections or change requests from many stakeholders. The decision-making then becomes "design by committee," instead of pushing towards a long term vision.

With a single benevolent dictator, since decision making is more centralized, it's significantly easier to do large reworks of the architecture to improve the product in non-incremental ways.

<comment><USER4> > It's hard to drive non-incremental innovation without a benevolent dictator > model.

Hmm, dunno that this is a universal truth. Most of the biggest improvements to Django came after Adrian and I stepped down and we moved to a more democratic leadership structure.

<comment><USER5> The key word is "improvement", which implies that there was something already there to improve.

So, a democratic structure can improve Django once it's already well-defined and widely used. But could it have created Django and made it successful in the first place? I think the answer is no, and that's what the gp meant by "non-incremental innovation".

<comment><USER2> Most of these projects reached that stage before or early in the life of these companies. So by that logic the companies were not necessary to support the projects.

<comment><USER5> I think "bdfl" and "exclusive corporate sponsor" are 2 distinct issues. I was addressing "bdfl vs. democratic leadership". I personally don't think it matters where the bdfl is employed in the early days of a project, there are examples of wildly successful projects with and without an exclusive corporate sponsor.

<comment><USER3> Good point, they are probably indeed distinct. In some cases the BDFL is employed by the corporate sponsor (eg. Confluent) which makes it hard to separate the influence of each.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> There is NO midlife crisis, only we have two things together:

\- for first we do not have decent universities anymore, they substantially evolve from the center of our collective knowledge to companies or servant of companies aiming to deliver various kind of Ford-model workers; => we do not have enough developer, mostly only code monkeys unable to think autonomously, tied to proprietary devs model, even when the code is open (see below).

\- for second we miss hardware. In the past hw was a bit various (different architectures nearly on-par, in concurrence) and reasonably open, now we have essentially arm for low power/mobile and x86 for the rest and they are more and more closed. On software side is even worse since we restore ancient mainframe model with the "mainframe" "outsourced to the cloud".

On "proprietary mental tie" in young people: simply new technicians do not think at scale because "the cloud" do that business and do not think in terms of local, desktop/user-centric computing. The "web" seems to be something like a local resource, always available. That's led to bad design for freedom. That's led to webUI instead of ml/news, dependency on someone's else services etc without thinking.

All the above crisis are not FOSS nor OpenSource, are social. They can be solved ONLY at social level.

</comment><comment><USER7> This seems to boil down to FAANG is taking your open source code and using it and no license jiggery pokery will stop them. The author seems to think that dual licenses are there to try and persuade Google to pay for your add-on extras.

I don't think that's right - the dual license is there to get Google to use the oss version and then snaggle the second tier of the Fortune 5000 into paying.

And it might, maybe, be working. (data needed, all i have is anecdata)

> business models like "support", "services" and "training" are entirely > viable

But that's the problem. They aren't really - at some point the effort in approvals and purchase orders gets so great that anything that is not "you can't use it" is not worth the candle

The thing is a license is a subscription - and subscriptions seem to be the only way to make money.

Everything else just pales.

<comment><USER8> When you say "everything else just pales" do you mean that licenses/subscriptions are the only viable options to make sure you don't go out of business, or are they the only option to justify multi-billion evaluations and multi-million investment rounds?

<comment><USER7> you can do good lifestyle businesses with just being an OSS developer and reasonable businesses doing support services. But at some point scale matters - stack it high and sell it cheap is the usual scale model IRL.

But support services almost always falls down on the first client that means every other client gets the solution for free and you lose the profit making side of selling the same thing multiple times.

OSS really does break most business assumptions.

I think it is good for society as a whole - i think for example Linux has added billions or maybe trillions to the world economy - but capturing that might reduce the benefits to society as a whole.

So long answer short - Inwoukdmlike to see evidence that long term OSS can support businesses of > 100 people > 50 million pa

I am hardly seeing it. i could be wrong

</comment></comment></comment><comment><USER9> > There are many business models that are complementary with respect to open > source, and some of the best open source software (and certainly the least > complicated from a licensing drama perspective!) comes from companies that > simply needed the software and open sourced it because they wanted to build > a community around it.

I've come to the conclusion that this is pretty much the only long term sustainable ethical way of developing (foss) software. That is to say that I don't believe anymore in pure software businesses.

<comment><USER10> > That is to say that I don't believe anymore in pure software businesses.

Does that mean you don't believe in company specialization?

Very few companies can afford to develop and maintain a cutting-edge database. Google, for example, can. But one rung down, and the answer is "no". For example, Kafka began at LinkedIn. The team that developed Kafka at LinkedIn ended up leaving to form Confluent, in order to build it out.

</comment></comment><comment><USER11> > Of these, the laughably named commons clause is the worst offender (it is > plainly designed to be confused with the purely virtuous creative commons)

Creative Commons has a "NonCommercial" variant[0], which is much more restrictive than the Commons Clause. To suggest the commons clause is piggybacking off the goodwill of the name of a more restrictive license is silly.

> they are almost certainly asserting rights that the copyright holder doesn't > in fact have

The author doesn't seem to understand how copyright works.

<comment><USER12> Having been around for the GPLv3 debate this sounds exactly like it. A lot of gut feelings with very little in the way of factual knowledge of what copyright law is, or what the current problems we are trying to deal with are.

</comment></comment><comment><USER13> Opensource, seems to be now defining how the overall professional programming develops, and how overall computing technology develops.

It is a very powerful phenomena that, may be more akin to development of a writing system(s).

There is simply no way to stop it, or reduce it to a 'island' of some sort.

So active creators of OSS value, definitely need to keep in mind how wide and long term the influence of their decisions might be. As the societies will continue to use their constructs not just in software but in other areas as well, for a long time.

\---

Just the other day, I was thinking how many programmers are there in the world (and i my definition -- these are people who had written software for 2+ years, and were paid for it).

Older estimates (eg [https://news.ycombinator.com/item?id=3555251](https://news.ycombinator.com/item?id=3555251) )

are off.

I think the number is closer to 50-70 mln.

But I also caught myself thinking, that programming in some scripting language to perform some task that by itself is _not creating a new program_ \-- is really a modern type of literacy (such as reading, writing, math).

<comment><USER14> Frankly, it's not real programming unless you made the chip

<comment><USER15> Chips? Hah!

It's not real programming unless you flip the bits in core memory by hand with a magnet.

</comment></comment></comment><comment><USER16> I wouldn't call this a midlife crisis. We have known and continue to know that this is a potential outcome when you sign a CLA.

If your company operates an open source project, you should know that if/when you are purchased, the centralized license on that project will inevitably be considered an asset.

</comment><comment><USER17> I can address some of the critiques that seemed aimed at the blog post I wrote announcing the Confluent license change:

1\. We aren't trying to get cloud providers to license our proprietary features. We run a cloud service of our software.

2\. The book analogy is not very accurate. We have an FAQ here the helps clarify interpretation. The limitations it places are extraordinarily small, 99.9999% of users are completely unimpacted, it really only impacts companies wanting to offer, say, KSQL-as-a-service. [https://www.confluent.io/confluent- community-license-faq](https://www.confluent.io/confluent-community-license- faq)

3\. We aren't trying to "co-opt" the community or open terminology. We actually tried super hard both in the license and in the blog post to be honest and upfront. Whatever else you think you have to agree that Confluent's license is _exceptionally_ permissive and the software has a pretty great community of users. How do you describe a license that let's you run, modify, fork, and redistribute the code and do virtually anything other than offer a competing SaaS offering of the product?

4\. Bryan Cantrill is an amazing engineer, but, well, as a lawyer, I think ours are probably better. We're quite confident in the enforceability, but it's a bit ironic because I remember this being the FUD around GPL that it was "totally unenforceable".

5\. The "open source companies are all failing"-meme isn't factually correct. Many open source companies are actually doing quite well. MongoDB has gone up in value about 3x over the last year, Elastic was the breakout IPO of the year. There are a handful of other really strong businesses a year or so behind, including Confluent. An open source project is not in-and-of-itself a business model, but it is, just empirically, a big part of some of the recent successes in the infrastructure space. Probably worth noting that the reverse is true too: if you look at some of the really cool up-and-coming open source platform data technologies, a lot of them have the support of a company behind them. Of course there are plenty of sucky open source companies, but that is true of every category of startup.

6\. I agree that it is silly to moralize about the behavior of the cloud providers. They are following their economic interest. The point is that this behavior does undermine the cycle of investment in some of the more promising hard tech open source projects and to try to change this dynamic.

7\. This article has a bit of a tone of "Son, new things aren't possible, trust me, I tried them and have the scars to prove it". I have huge respect for Bryan, and I know that to some extent that is his schtick as a public personality, but I'm not sure that attitude is most likely to lead to improvement. I don't think the current crop of licenses was handed down from the mountain on Stone Tablets by our elders to be revered and not questioned. I think CockroachDB, Elastic, MongoDB, and Confluent are building really innovating technology platforms and building pretty cool companies to help fund that. I don't think we need dogma. And I still don't say "GNU/Linux".

<comment><USER18> > How do you describe a license that let's you run, modify, fork, and > redistribute the code and do virtually anything other than offer a competing > SaaS offering of the product?

A proprietary software license. Let's not forget the infamous "don't be evil" clause.

> The "open source companies are all failing"-meme isn't factually correct.

Several of the companies you have mentioned (including yourselves) are no longer "open source companies" since you now develop proprietary software. You might not consider this a failure (maybe a "pivot"), but you are no longer an "open source company".

Don't get me wrong, I completely believe that there is a financial problem caused by cloud providers not paying you for your development work. And I understand the frustration and lack of fairness in such a dynamic. But that doesn't change that you now develop proprietary software.

> I don't think the current crop of licenses was handed down from the mountain > on Stone Tablets by our elders to be revered and not questioned.

Nobody is claiming that, and those licenses have changed over the years. But the changes have always come from the community. MPLv2 was written so that it could be integrated with GPL code. The GPLv3 was written to deal with concerns about locked-down hardware. The AGPLv3 was based on a community fork of GPLv2.

The new proprietary licenses are coming from companies that wish to protect their businesses. This is clearly a different dynamic, and I think it's quite unfair to paint your critics with the brush of being unquestioningly reverent of our elders -- when in fact we are seeing that the existing, gradual evolution of licenses by the community has been co-opted by companies wishing to protect their own interests.

<comment><USER19> you're creating a false dichotomy

neither open source nor proprietary represents a single thing and there's a continuum between the two extremes

this license is clearly somewhere near the middle

<comment><USER18> It would be more accurate to describe it as proprietary than it would be to describe it as free software or open source. Proprietary software is software which restricts your freedoms when it comes to the usage, modification, or distribution of said software. If you prefer, you can also use the term source-available to distinguish the degree of restrictions -- but the point is the same. There are restrictions on your freedom in the software and thus it is proprietary.

Not everything has a middle ground. Software is either proprietary (restricts your freedom) or it isn't -- and discussions about _how_ proprietary it is (how many restrictions it imposes on users) are secondary.

<comment><USER20> I could argue a completely different case. The only "restriction" it is placing on you is that you may not restrict anyone else from exercising the same rights that you yourself were granted by the license, which I believe is the original spirit of the 4 freedoms and the GPL family of licenses.

The software is "effectively free," because for every user who simply uses it for personal use, research, or even many forms of commercial use, they have all of the same abilities that they would have with any other free software license.

The restriction only comes in when you make a derived work of the software and do not pay forward that derived work under equivalent licensing terms as the work on which it was based.

And this is where the real disagreement is. What exactly is a "derived work", and where do you draw the line in the sand?

If I'm essentially selling access to somebody else's software, I have little doubt that access software constitutes as a derived work. I think it's fair that a license like the SSPL asks me to release the code which provides access to the free software as free software itself.

Suggesting that "My freedoms are being restricted" because a licensing term prevents you from restricting the freedom of others is the same argument that "permissive" license proponents argue against strong copyleft licenses.

If I release something as SSPL, it isn't because I'm trying to "restrict your freedoms". It's that I'm trying to prevent you from restricting other's freedoms by selling them proprietary work based on it.

<comment><USER18> The license being discussed here is not the SSPL. It's the Confluent Community License, which does not have any of the GPL-like aspects you refer to. Instead it simply denies the use of the software (freedom #0) for an "Excluded Purpose" (creating a competing product to Confluent). I'm sure you'll agree this is not in any way in the original spirit of the four freedoms.

> What exactly is a "derived work", and where do you draw the line in the > sand?

This is mostly determined by copyright law, since "derived work" is a legal term of art.

> If I release something as SSPL, it isn't because I'm trying to "restrict > your freedoms". It's that I'm trying to prevent you from restricting other's > freedoms by selling them proprietary work based on it.

This is the justification, but due to the design of the license it is de-facto impossible to actually comply with its requirements. Therefore it acts as a de-facto proprietary license. Many copyleft lawyers have stated that the license would likely require you to re-license Linux under the SSPL if you run SSPL code on a Linux server. This is not possible to do, and thus you are forced to pay MongoDB to get a business license.

Maybe there is a place for a license like the SSPL, but given how there would be effectively no company that could comply with it (even if it didn't require relicensing to SSPL, many companies have contracted code that they cannot relicense to a free software license) I fear it would have the same effect.

<comment><USER10> > Many copyleft lawyers have stated that the license would likely require you > to re-license Linux under the SSPL if you run SSPL code on a Linux server.

There's no such thing as a "copyleft lawyer". Even if there were, there wouldn't be many of us, even if you counted every one, worldwide.

I personally don't agree with the reading you referred to. But if Mongo's SSPLv2, which they've submitted to OSI, is any indication, it won't be tenable much longer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I agree that the naming of the non-open-source licenses is confusing, e.g. "commons clause" is not a great name.

However, I wonder if there is in fact a fundamental difference between some kinds of reuse and others (thinking aloud here).

If I want to use Debian to power my corporate desktops, that's one thing. Or if I want run Debian on cloud machines that provide a Redis service.

But if I actually expose the Redis API and protocol through a service to customers, and charge them for it, can that be considered another form of reuse that requires licensing?

This is in contrast to running Redis as a backend for say a for-profit Twitter clone.

Using Debian, the analogy would be providing a remote-desktop-as-a-service using Debian, as opposed to merely using Debian in a cloud service.

\-----

Although, I may have missed it -- why not make Redis AGPL? That would prevent proprietary forks, as I understand it. But they want something even stronger than that? They don't want just a level playing field, but an advantage?

I suppose I can understand that when you are faced with big cloud providers with tons of locked-in customers.

I'm surprised that Cantrill isn't more sympathetic to the business model problems and the lock-in effects of big cloud providers. He seems to take a pretty hard line that the "community" comes first. But what if there's no real community? Is there a community around CockroachDB? It seems to be mainly for for-profit companies to run cloud services.

\-----

In other words I think there could be another name for software where you have rights to view, modify, and distribute the source, but not to directly sell it as a service.

He is saying that nobody is ever going to license this software -- they will just reimplement it or use something else. But I think that is besides the point, which is that there are customers who WOULD pay for a hosted version of Redis or CockroachDB.

I guess where this falls down is that it only works for projects in which there have been essentially no external contributors. Although a few people may have contributed the lion's share of the code, it's not clear that you should reserve rights for author A's company but not author B's company, even author B only contributed 10 lines of code. It is hard to draw that line.

<comment><USER22> For me, it's hard to separate "Cloud provider selling a service" and "Cloud provider selling compute, and giving away the free service". On a scale of things that are ok to things that are not ok to open source companies: 1) end- user rents an ec2 server, installs redis themselves, 2) end-user rents an ec2 server, runs a redis AMI that a third party created, 3) same, except amazon created the AMI, 4) Amazon runs an ec2 instance on the user's behalf, puts a nice UI on top for "spin up a redis server", 5) Amazon runs an opaque multi- tenant redis system.

Where do you draw the line? Most steps are just Amazon streamlining letting the user run the service, except for the last one which decreases the cost for the end-user.

<comment><USER21> Yeah, that's a good way of putting it.

I agree there is no hard line. I would put it somewhere between #3 and #5.

On the other hand, there are plenty of legal/licensing issues that rely on fine distinctions. Just in the domain of software: is it OK to copy 1 line of code, 10 lines of code, or 100 lines of code? What about if you transliterate the code to a different language?

It's possible that the fuzzy distinctions are OK and they still roughly preserve the intent and business model.

</comment></comment></comment><comment><USER19> open source can certainly be profitable for some personalities and some projects, but there seems to be a large portion of the space that's hard to monetize

i've taken a cut at making a license that attempts to bridge the divide - capturing many of the freedoms of open source while still requiring a subscription

[https://github.com/db4j/pupl](https://github.com/db4j/pupl)

</comment><comment><USER23> > I cannot, however, tell you that you can't put the book on the same > bookshelf as that of my rival, or that you can't read the book while flying > a particular airline I dislike, or that you aren't allowed to read the book > and also work for a company that competes with mine.

Really?

<comment><USER24> Really.

Copyright is just that, _copy_ right. It's not _read_ right, _use_ right, _fly_ right or _workfor_ right.

The license for foo can say "by copying foo, you affirm your acceptance of the following conditions: …" and if you do copy foo and nothing else gives you the right to copy it, then those conditions are what you must've accepted, right? Of course you may argue the point, but that's the theory.

However, if what you do is use foo or fly with KLM, not copy foo, and don't affirm your acceptance by other means (such as signing a document), then _copy_ right doesn't apply.

EDIT: And even if it does apply, it's not clear to me that what it applies to is the non-copying bit. If copying and flying with KLM are incompatible, then it's not clear to me that copyright can ban the latter.

<comment><USER23> That's not about copyright actually. The license is a contract, and you decide to sign it or not - by deciding to use the software or not. The contract in theory may include any restrictions you can imagine. There are in practice some restrictions on that restrictions by some laws in some countries in some aspects, but rarely about KLM.

<comment><USER25> Copyright license and contract are not (necessary) the same thing. An important related fact is that contract breach is generally less penalised than copyright infringement.

See eg [https://perens.com/2017/05/28/understanding-the-gpl-is-a- con...](https://perens.com/2017/05/28/understanding-the-gpl-is-a-contract- court-case/) & [https://www.youtube.com/watch?v=6i9sngsv8G0](https://www.youtube.com/watch?v=6i9sngsv8G0)

(And keep in mind that per-license US case law doesn't have standing globally)

<comment><USER12> If you are using IP without a contract you are engaging in copyright infringement.

People we've been through this. This fud was deal with when the GPL was ruled valid a decade ago.

</comment></comment></comment></comment></comment><comment><USER26> All this talk about ethics, open, and free brings another angle to mind folks like Cantrill seem to be ignoring and therefore misrepresenting what they are achieving in at least U.S.. I used to push for OSS/FOSS in the past. Now I'm switching to hybrids. The reason is that encouraging people to play "give it all away" or "use low-revenue models" in a capitalist country where opponents of freedom make billions of dollars for their software shifted all the money (and therefore power) to the latter. They then paid off politicians and used pricey lawyers to win more power against OSS/FOSS in ways they couldn't fight against without piles of money. This includes ability to patent/copyright troll users of open/free software and especially Oracle's API ruling which jeopardizes OSS/FOSS, backwards-compatible implementations of anything that had a proprietary API.

From what I see, OSS/FOSS have done great things but are a fundamentally- flawed model in a capitalist country where money wins. As many as possible need to be charging by default both to support contributors and send money/power the other way. They and FOSS-using companies that don't depend on patent/copyright money need to pool money together to fight legal advances of patent/copyright-trolling companies that want lock-in. Otherwise, in a game where only one side is playing for keeps, the OSS/FOSS groups keep losing by default software freedoms and ability to enforce their licenses while preaching that they're maintaining them. Seems dishonest. Also, strange I almost never read about these issues in FOSS writers articles about business model and licensing recommendations.

Far as hybrids, I can't give you the answer yet since it's too soon. For FOSS, I'm looking at Open Core and Dual-Licensing with strongest copyleft available. For non-FOSS, Source-available from public-benefit companies and nonprofits chartered to implement most software freedoms for customers on top of free for non-commercial or under certain use. These freedoms and justifications would also be in licenses and contracts with huge penalties for non-compliance for extra layers of defense. Maybe expire into FOSS after certain time passes or revenue threshold. We need more experimentation that lets companies currently supplying or later releasing as FOSS to get millions to hundreds of millions in revenue collectively to fight this battle. Again, it's not optional: the other side is actively fighting to remove software freedom inch by inch. And mostly winning despite FOSS organizations' little victories.

Edit: Added a few specifics for hybrid model in this follow-up:

[https://lobste.rs/s/kbcjnx/open_source_confronts_its_midlife...](https://lobste.rs/s/kbcjnx/open_source_confronts_its_midlife_crisis#c_yokqtn)

</comment><comment><USER27> Very well written and timely.

</comment><comment><USER28> The answer lies in your context for programming. The bigger picture.

The invention of the microprocessor was a watershed moment in human history, more than that of fire, or even splitting the atom. Mechanical intelligence provides for a realistic Utopia. It's not guaranteed, but it's _unarguably possible._ "Let the robots do the work and we'll take their pay."

From this point of view, anything that restricts the free flow and use of software is regressive. (I'm not going to address the subtle point of whether "Free" or "Open" better foster free flow. On the ten-thousand-foot level that I'm dressing it just doesn't matter.)

Trying to make a living from charging for (copies of) software is foolish _compared to_ bringing about a techno-utopia as quickly and directly as possible.

The important question is, how do we marshal our resources to achieve a peaceful, ecologically harmonious, high-tech, post-historical world as quickly and painlessly as possible?

<comment><USER12> By charging for the software we produce and using the economic resources we gather to get the outcome we want through the acceptable channels in our society, e.g. the courts and the legislature.

<comment><USER28> Sell [copies of] software to make money and then lobby politicians. Is that what you're saying?

</comment></comment></comment><comment><USER29> Open source is booming by any metrics. My favourite example is Bitcoin, which is just getting started, but even its haters usually agree that it has a huge impact (even if they don't like the impact itself).

<comment><USER30> I would say Bitcoin is lagging compared to where many other open source projects were after 10 years.

<comment><USER20> Well, you can expect it might take some time to gain adoption for an idea which has such a profound and extensive impact on many areas of life, and not just software.

Bitcoin has changed the way the world thinks about money in just 10 years. I wouldn't call that lagging. It seems to me that it is _leading_.

<comment><USER30> > Bitcoin has changed the way the world thinks about money in just 10 years.

That's mostly limited to "true believers". For the 99%, Bitcoin the technology doesn't really mean anything, but they rather think of the speculative investment.

(for reference, I was mining BTC in 2011, and have made more than a few dollars in it over the years, I just like meat with my Koolaid)

<comment><USER20> It might only be a small minority of people who are true believers in Bitcoin, but many of them have taken it upon themselves to continue building new financial instruments and technologies around it.

The internet changed the way the world thought about communication in the 70s. This was a minority opinion all the way up to the naughties when it became impossible to continue ignoring reality.

Banks will need to innovate or they'll end up like the record labels and newspapers who failed to keep up with the geeks and entrepreneurs. The banks which embrace technology might survive.</comment></comment></comment></comment></comment>


Show HN: Vicilog – Open-source release notes generator - <AUTHOR> http://dn5.github.io/vicilog/ <comment><USER2> Hi there, I think tools like this are good. Changelogs are a helpful piece of information within a repo/project. It's not clear from the site whether this also generates a human readable form of the log, say in markdown, that would be really useful.

Beside that I think needing to call it with ruby makes it a little awkward, could you perhaps find an install route which offers you a file already +x'ed so it "just works"?

Keep up the good work!

<comment><AUTHOR> Hey dayjah, thanks for support! Vicilog does not have implemented option to revert changelog into readable form of the log but we are writing this on our TODO list.

Yes, I agree on that, although we just started working on this project so we will implement this feature in future. Keep up the good contribution! cheers.

</comment></comment><comment><USER3> wrap this (`ruby vicilog.rb`) to a single command maybe?</comment>


Pirates and Copyright Holders: Please Stop Making Stupid Arguments - <AUTHOR> http://www.dangerlibrary.com/2012/01/pirates-and-copyright-holders-stop-making-stupid-arguments/

<comment><USER2> The title is a bit rough, but the argument thoughtful, and to the point. The "Market Participants" part is particularly interesting. I would however argue that the "cheapskates" are much fewer that is commonly thought. It is true that few students would happily spend $20 on a CD, but if there were no other way of getting music, most of us would go ahead and spend these $20. We would just be more parsimonious in our music/media consumption if we had to pay for everything.

<comment><USER3> I think the point is a bit clearer if you imagine each song having its own market.

I am not a member of the market for dubstep. I am a cheapskate in the market for Taylor Swift songs - I'd never pay full price, but I could be tempted if they were twenty cents each. I am a paying customer in the market for old blues albums.

So any one consumer is not always a cheapskate or always a paying customer. Every consumer is a cheapskate in most markets.</comment></comment>


A change in attitude - Legacy code - <AUTHOR> http://craftedsw.blogspot.com/2011/06/change-in-attitude-legacy-code.html

<comment><USER2> I've never disliked legacy code for many of the same reasons. Sure, I've seen some gnarly stuff, but generally if it's still around then it's mostly working and usable. And sometimes it's rewarding to get a chunk of really slow code to run faster and be more efficient.

On rare occasions you get to experience completely different ways of thinking - such as some code I inherited a couple years back that was written by a team in North Africa. Seeing different ways of solving the same problem is never a bad thing.</comment>


From reddit to Hipmunk: if it ain't broke, don't fix it. - <AUTHOR> http://meetthefounders.com/meet-steve-huffman-cofounder-of-reddit-and-hi

<comment><USER2> This jumped out at me:

> With Hipmunk I've been more cognizant about having a life. I work daytime > hours, and I don't work quite as a late. But I also know a lot more, so we > get more done in less time.

This is my experience as well. I don't have the same energy I had even five years ago, but I still get a lot more done because I'm about an order of magnitude more productive than I was when I started out.

This suggests that the standard model of founders as young firebrands willing to pour three years of output into a year of development isn't the only model that can work.

The bigger challenge for older would-be founders is that it becomes harder to walk away from the steady income and job security that comes from several years working for established employers.

<comment><USER3> I can't help but wonder if his "having a life" is based on having cashed out with Conde Nast. Not that it's a bad thing (or that he hasn't become more productive, I'm sure he has), but I feel like part of the scrappy frenzy of being young is that you have no money to fall back on...every hour is precious. I just feel like this isn't necessarily transferable advice to a young guy who wants to follow in his footsteps.

<comment><USER4> If anything, it's the opposite. The first time around I felt I had nothing to lose, but this time there is a lot more pressure.

The main difference is I don't feel I have to force myself to work as much. If I'm going to be sitting in front of a computer but not actually getting much done, I may as well do something else. It's really just an acknowledgment that motivation comes and goes and there's not much to be gained by fighting it.

Of course, there is a big difference between procrastinating and being burned out for the day.

Everyone is different, of course, that's just me.

</comment></comment></comment><comment><USER5> "With Hipmunk I've been more cognizant about having a life. I work daytime hours, and I don't work quite as a late. But I also know a lot more, so we get more done in less time."

In another thread I got down voted much for saying work - life balance is needed. This quote brings to light that it's really a product of experience. That experience allows proper planning, a clear roadmap, and makes it easier to stay committed to a project/team/startup/X Inc.

Perhaps I should say that If you find your self working late hours, adding to an already 80 hour work week your probably missing some key knowledge and experience. If you can't plan at least a day or two in advance then try to look and find what knowledge your missing in order to plan and execute effectively.

A quickie on gaining exp: \- slaving away at some corp isn't so bad as long as you gain experience \- joining an existing startup is a good idea for learning the ins and outs without the pressure \- joining an incubator to boot camp these experiences

Obviously as the article stated working on something worth while is an absolute motivator.

I apologize for any grammar and spelling mistakes now because typing on the road from an iPhone is a pain.

</comment><comment><USER6> There's a great message in here: All the hustle in the world is wasted on a problem no one wants solved.

</comment><comment><USER7> That was an interesting read.

And thanks for not having a graphic-heavy or obscure blog theme.

</comment><comment><USER8> An insightful post about partnerships, hard work, sacrifices, and working smart. Thanks to Steve for being a candid subject and I'm glad that him and Katie ended up in the Bay Area, so that it's a little bit easier to support each other.

</comment><comment><USER9> "If it ain't broke, don't fix it' is the slogan of the complacent, the arrogant or the scared. It's an excuse for inaction, a call to non-arms." - Colin Powell.

</comment><comment><USER10> Coding in a vacuum! I was about to coin that term in a blog post! Dammit. I guess it's lucky I didn't do a blog post proclaiming how awesome my new turn of phrase was only to find out that every man and his dog has already heard of it.</comment>


Niagara Falls May Be Temporarily Dewatered - <AUTHOR> http://thesurge.net/niagara-falls-may-be-temporarily-dewatered/ <comment><USER2> ^---- from Western NY

How about they put some money into the surrounding area and build restaurants / hotels / gardens and attractions? Or - god forbid - a casino!

We went to the american side last year and it's amazing how night and day different it is from the Canadian side / Clifton Hill - I'm not saying Clifton Hill is great - it's very touristy - but theres a ton of stuff to do there from getting cheap pizza / ice cream to some nicer sit down restaurants / rides for kids, the casinos, etc...

The American side has always been neglected. Look what has been done with Canal Side downtown Buffalo - and it gets better by the year. Theres actually reason to go downtown by Sabres arena winter and summer. The wife and I took a bike ride there last year along the water front, stopped for lunch and a drink - we spent the day there - something we'd never do in years prior.

Takes just as long to get downtown as it would to Niagara Falls... and to stop and watch the falls / take pictures would be better then just looking at a lake.</comment>


Checked C from Microsoft Research - <AUTHOR> http://research.microsoft.com/en-us/projects/checkedc/ <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11899925](https://news.ycombinator.com/item?id=11899925).

</comment><comment><USER3> Github discussion: [https://news.ycombinator.com/item?id=11899925](https://news.ycombinator.com/item?id=11899925)

<comment><USER4> StackOverflowException. Call heap size exceeded.

<comment><USER5> Maybe the new checked C can protect against infinite loops too ;)

<comment><USER6> Why? Infinite loops in C are by design and have many uses: threads waiting for signals, polling, events processing etc.

<comment><USER7> It's a joke :)

[https://en.wikipedia.org/wiki/Halting_problem](https://en.wikipedia.org/wiki/Halting_problem)

<comment><USER8> Actually, Microsoft Research has another project to prove program termination: [http://research.microsoft.com/en- us/projects/t2/](http://research.microsoft.com/en-us/projects/t2/)

Obviously this cannot work on all programs, but it's nice that they tried to do their best.</comment></comment></comment></comment></comment></comment>


Don't rewrite Your Application - <AUTHOR> http://blog.schauderhaft.de/2011/02/20/dont-rewrite-your-application/

<comment><USER2> Very reminiscent of a Joel on Software article

<comment><USER3> Inflammatory and pragmatically useless?

<comment><USER2> That too, but more specifically: <http://www.joelonsoftware.com/articles/fog0000000069.html>

In that article, he talks about Netscape's biggest mistake being the decision to rebuild from scratch for version 5 (which went on to become the Mozilla suite).</comment></comment></comment>


Show HN: We actually built chat for GitHub - Kato.im - <AUTHOR> http://kato.quora.com/Free-Kato-For-Open-GitHub-Repos

<comment><USER2> Awesome job guys. Using Kato in our company and we love it.</comment>


Ask HN: Do you enjoy voice interactions with your devices? - <AUTHOR> When does it work for you?
Personally I use it to set a destination in maps and to set an alarm time but that's pretty much it...
Most of the type otherwise it feels pretty weird. Why is that?
Is it because the tech isn't well integrated yet to our apps?
What apps do you wish to see take advantage of voice more? <comment><USER2> I use it for the limited menu selections my car supports and usually have to repeat myself 3 or 4 times before it gets it right. I also use it for texts because it's less aggravating than the awful on screen keyboard. Enjoyment and pleasure don't enter into it, it's just barely better than the other available UIs.

</comment><comment><USER3> Ugh, no, never.

At home I like silence around me and not having to speak.

While commuting it's a privacy issue even if I liked it or could be heard clearly.

At the office it'd be rude and most things are faster with a keyboard anyway.

That said, I'm an outlier. My intuition is that voice interactions are for people who strongly prefer interacting with people rather than things.

I suppose they're also potentially useful for hands-free operation. If they actually work.

</comment><comment><USER4> I'm a little bit paranoid. All devices have voice interaction programs turned off. Microphones have tape on it...

</comment><comment><USER5> Mismatch...mismatch...no network...mismatch...well if I have to correct every word thrice, might as well type it.

</comment><comment><USER6> i set reminders with it. doing that through siri is actually faster than the manual way. all other tasks are easier/faster to do with a UI, that's why they feel weird .</comment>


[Book] Algorithmic Game Theory - <AUTHOR> http://www.cambridge.org/journals/nisan/downloads/Nisan_Non-printable.pdf

<comment><USER2> This is a really nice book, though the topics therein are complicated enough that each chapter needs thoughtful contemplation to both fully understand and to spell out some of the details.

A MUST for anyone who wants to run any sort of e-commerce site that does anything nontrivial, or anything else where you need to set up the incentives for various parties properly</comment>


Fruits as Beautiful in the Garden as They Are Delicious - <AUTHOR> http://www.nytimes.com/2009/05/21/garden/21garden.html?_r=1&ref=garden <comment><USER2> my late dad planted mango, star fruit, citrus, durian, guava. i have fond memories about it ^@^

now i'm thinking about it, fruit is nature's fast food -- just pick and eat it up. just dump the remains on ground (bio-degradable by default)

no fridge is needed (a living plant IS the nature's fridge)

even further, the water content can be quite pure (think plant as nano-bio- filter); i guess it's very hard to get fruit contaminated with heavy metals.

i like the 'bio sensor' ... if fruit looks bad and/or smells rotten, then it's probably not safe to eat

i wonder about the feeding-people efficiency of fruit farmden compared to corn field. for example, if i have a family of 2 and 100 m² land, what to plant for self-sustainable* garden? i do think gardening as 'depression-proof'

* self-sustainable in the sense that a garden is a close-system. it only needs water and sun. pest control by ducks/chickens. herb control by planting diverse plants (allelopathy). fert is provided by composting loop.</comment>


Security for the people - <AUTHOR> http://google-opensource.blogspot.com/2014/09/security-for-people.html <comment><USER2> The simplysecure.org domain uses Google Analytics which isn't disclosed on their privacy page (as required by Google Analytics' TOS). There is also a mixed-content warning because someone hard-coded an [http://](http://) link to the balloons image in the blog post on their https site. I went to email them and first looked for PGP keys (us pro-privacy & security people all use PGP, right?) and found none for the domain on any key servers.

I point all this out because it perfectly illustrates their point. Here are a group of smart people launching a great initiative with a beautiful and modern website, and they made some mistakes just like the rest of us do.

I've offered to help and recommended they switch to Piwik (and fix the http link). I hope others here on HN who care about security and privacy will also offer to help out. Some of this stuff is easy to fix and I think it's a great initiative.

<comment><USER3>
        I've offered to help and recommended they switch to Piwik (and fix the http link).

HN does tech satire so much better than the rest of the internet..

<comment><USER4> What do you exactly mean?

<comment><USER5> Telling the Google Open Source people to use Piwik instead of Google Analytics seems like satire.

<comment><USER2> I know the Piwik recommendation gave some a reason to chuckle but I was dead serious. This initiative was promoted by Dropbox (who recently brought Condoleeza Rice on board) and Google (an ad company currently removing privacy-enhancing apps from their mobile marketplace) and so this group will need to distinguish themselves to appear credible.

It's that or be dismissed as just another iteration of Microsoft's 'embrace, extend, extinguish' plays.

</comment></comment></comment></comment></comment><comment><USER6> _Researching and developing usability and security auditing practices. How do we measure the two in a single assessment?_

You don't. They're wildly different disciplines. Security auditing is fundamentally a systems programming problem. The least effective security "auditors" approach security as something different than software engineering. The most significant security issues arise from correctness issues; finding and fleshing them out involves discovering the degrees of freedom offered to an attacker by faulty assumptions made by blocks of code scattered throughout an entire system.

That's not to take anything away from the practice this team is trying to start! Someone should be doing security usability work, because I don't know anyone who does it well now.

Providing real software security for open source projects is a tricky problem. Talented software security people are in enormous demand. Bill rates are going up. One thing a project like this might want to tackle is onboarding more technical people into the discipline, to address the supply problem.

<comment><USER7> I'm not so sure. "User uses the system as designed" is a huge faulty assumption -- look at all the people who put SSH private keys (or Amazon AWS keys) on GitHub or who write a shared company-wide password on a sticky note taped to their monitor. A more usable system might prevent these sorts of failure modes, or at least inform the user of the risks that result from such decisions.

<comment><USER6> I'm probably being imprecise. There's a big and important discipline of assessing the usability of a system and the impact of all the affordances the interface of a system provides. I believe that also takes a special skillset, and it's a skillset I'm happy to see new initiatives like this taking on.

I am not suggesting that security usability (or, to keep it technical, security UX) is easy, or that software security practices are necessarily good at it.

</comment></comment></comment><comment><USER8> It's very odd that they lead off by focusing on unrelated FUD.

> _However, if people are indeed working to protect themselves, why are we > still seeing incidents, breaches, and confusion?_

That references a completely different security area, and as much as it's a juicy source of scare stories for mass media, it's unrelated to end user security with respect to government and corporate mass surveillance.

The former is basically insecure by design (based on the assumption that transactions are always reversible), with the duct tape occasionally failing. The latter will never manifest itself as a discrete problem for the sheer majority of people, but just an ever-growing set of annoyances and chilling effect on one's thoughts and actions.

They require completely different approaches. For the former simply having backup credit cards, being prepared to sue your banks for negligently giving away your money, and flagging the pop culture scare articles off Hacker News - that's about all you can do, because the deficient technology is _not yours_.

The latter requires _proactively_ analyzing the implications of one's technology choices and avoiding the attractive nuisances. Fixing these problems is not at all straightforward and is one of the great struggles of our time, which is why it is such a disservice to conflate the two.

<comment><USER9> But the former now leads to further erosion in the latter as well as reinforcing the misconceptions and fear tacticts that lead to greater and greater incursions on the privste sphere. Those "annoying" mass media articles have led Congres to enact laws, a court to seize the operations of a private company and hand it to a competitor, as well as forming tighter public-private partnerships that provide end-runs around due process.

These things can happen because the public is uninformed, disinterested, and subjected to carefully coordinated messaging by security companies selling solutions, "credit monitoring" companies that package insurance, and the mass media that doesn't have a deep commitment to getting the facys right when it comes to this topic.

</comment></comment><comment><USER10> And don't forget the end-to-end project[1], which is the javascript crypto library by google.

The significance of these types of project extend beyond browser privacy. As crypto-currency become more prominent, we NEED better, carefully auditted javascript crypto-libraries.

Right now, all the crypto-code are home baked. e.g.: [https://github.com/bitcoinjs/bitcoinjs- lib/blob/master/src/e...](https://github.com/bitcoinjs/bitcoinjs- lib/blob/master/src/ecdsa.js)

While, I think they are all doing a fine job. It is not settling to think that these mission critical, crypto-code is not vetted by cryptographers.

In fact, a few months ago, there was a bug where the nonce for each signature was not set properly that basically meant you were able to work out the private key for 2 different signatures. Some users lost funds due to the bug.

These open initiatives will lay an important foundation.

[1][https://code.google.com/p/end-to-end/](https://code.google.com/p/end-to- end/)

<comment><USER11> Holy crap, people are actually using javascript crypto for bitcoin‽

<comment><USER12> They also pretty commonly use in-browser JS SHA256 to derive private keys from human-generated passphrases: [https://brainwallet.github.io/](https://brainwallet.github.io/) There have been reports of pretty obscure, but still guessable, keys being cracked this way.

Bitcoin is fascinating just because it makes these sorts of things worth untraceable money, sometimes a lot of money, and puts it in the hands of people who have never had that sort of responsibility. Whatever else cryptocurrency does, maybe it will teach laypeople about these things, devise new ways to teach them and new technological measures to increase their safety.

</comment></comment></comment><comment><USER13> I wonder what the high level thinking at Google is these days around user privacy. They must be aware that the growing noise about it means it is going to be the stick they are going to be attacked with, and yet their business relies on people willingly giving some of it up.

While this particular announcement seems fluffy, I do somewhat applaud the intent. The question of how we expect to run the internet economy and preserve user privacy is becoming more pressing for everyone though.

<comment><USER14> I feel "willingly giving some [privacy] up" and "being incapable of even assessing one's level of privacy" are two very different conditions to be in.

</comment></comment><comment><USER15> [https://simplysecure.org/](https://simplysecure.org/) is the project that Google is supporting, which seems to be an open consultancy that works with OSS crypto/security/privacy projects to make them easier to use.

</comment><comment><USER16> On the topic of bringing better security to normal users, the project I'm most hopeful about is the FIDO alliance's U2F and UAF standards.[0] There's a new YubiKey that implements U2F, which is supposed to ship soon.[1]

I'm optimistic because these are open standards backed by many big organizations, and web browsers will be shipping with support built right in, no drivers, no plugins.

Tokens like that Yubikey work over USB HID (they look like keyboards to the OS, so they don't need dedicated drivers). They also work over NFC on mobile devices (ok, on Android devices. Still waiting on iOS.)

[0] [https://fidoalliance.org/specifications](https://fidoalliance.org/specifications) [1] [http://www.yubico.com/2014/09/yubikey- neo-u2f/](http://www.yubico.com/2014/09/yubikey-neo-u2f/)

</comment><comment><USER17> This sounds smart. And I'm pretty pragmatic. I don't think Google and Apple and Microsoft are really trying to ruin my privacy.

But something about this makes me uncomfortable. The fact that when this appeared on the front page of HN it was with posts from Google and Dropbox about how they support this.

Google that Assange is releasing a book about, and Dropbox that went a day where it didn't matter what password you entered and has former Secretary Rice on their board.

I have a feeling this organization might help keep things like the recent celebrity iCloud break happening, but as someone else said, real security is not easy. And false security is worse than no security.

</comment><comment><USER18> A PR announcement of an initiative to form a coalition to investigate making it easier to use security tools that most people don't care about. How thoughtful of you, Google. This wouldn't be an attempt at improving the public's negative view of you with regard to privacy issues, now would it?

Funny how Google doesn't offer a messaging service that's secured to a physical device the way Apple does, and these projects when combined would result in something like that.

<comment><USER19> You seem to imply that there is no real value in the initiative. I humbly suggest you ask the teams doing all the work (Guardian Project, Open Whisper Systems, F-Droid, etc.) how excited _they_ are about this. I suspect it's not as intangible or fuzzy as you imagine. They're expecting real resources and real funding, which will result in real progress for their already-strapped projects.

<comment><USER18> I'm sure they're very happy to get funding. The fact that they're excited to get money for their projects does not mean their projects have value, or that most people will be affected by them.

</comment></comment></comment><comment><USER20> I see the motivation behind it and appreciate the cause, however it is not just about the tools. Yes we need better tools but that alone wont help. 1-Click solutions often promise a lot but only end up giving a false sense of security. I belive that a certain amount of understanding of the underlying, general technology will always be required - both for users and developers.

Encrypting your e-mail does not help you if your machine is compromised.

Your super-secure 24 character password is useless if you use it on every single website.

Encrypting and salting your users credentials is useless if your SSH password is 6-digits.

What i'm saying is: REALLY staying secure is not easy and it never will be.

</comment><comment><USER21> I'd like to see Hangouts eventually implement some of Signal/TextSecure's crypto.

<comment><USER22> I'd like Hangouts to do a lot of things. It looks like they made the right choice in moving away from XMPP compliance in favor of usability. It certainly improved the apps' popularity but took a lot of back steps on security and openness. I'd like to at least see google include hangouts as part of their upcoming [end-to-end]([https://code.google.com/p/end-to- end/](https://code.google.com/p/end-to-end/)) extension.

</comment></comment><comment><USER19> I'm excited to see how the Guardian Project will use the resources. God love em, but their projects seem to have less UX polish compared to those of Open Whisper Systems, likely due to Twitter's positive post-acquisition influence on the latter.

</comment><comment><USER23> "We're excited for a future where people won't have to choose between ease and security, and where tools that allow people to secure their communications, content, and online activity are as easy as choosing to use them."

That future is now according to Apple.

In any case the real issue is protecting people from Google itself.

<comment><USER24> Apple's devotion to privacy ends at phone unlock; the easiest attack vector to social engineer or forensically determine. Today's announcement is not much more than a PR stunt to cover their ass and distract from their own repeated failings to secure their platform or networks.

<comment><USER23> "Apple's devotion to privacy ends at phone unlock."

If you had read either the privacy policy or security architecture, you would know that you have made a false statement here.

I think it's you who is trying to distract us from the fact that Google itself uses your private data for its own business purposes, and has a vested interest in not protecting you from itself.

<comment><USER24> I find it adorable how people buy into the rhetoric and trust that Apple doesn't leverage and track your data. They are a hardware _and_ content company, and they absolutely leverage all the data they can in order to better market _you_ the content they think _you_ might want. Its not just business, its personal. Even with the lions' share of their money coming from hardware sales, so what? Without deep, targeted tracking and mining of user data for market research their entire mobile platform would implode along with the business models of their content partners and app makers.

Meanwhile, I show nor imply any support for Google on the subject. They are no better, perhaps worse.

<comment><USER23> So you simply choose to believe they are lying with no evidence at all.

Not much point in discussing anything with you, I guess.

<comment><USER24> ... and we devolve into the same old debate over the definition of _metadata_

<comment><USER23> Nope. Thst's just you presenting more cynicism without a shred of evidence.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Hey google, you can start by phasing out RC4 on YT.

</comment><comment><USER26> Nitpicking:

They should use a SHA256 certificate :-)

And DANE and TLSA

<comment><USER6> Baffling that anyone could still be advocating for DANE after the NSA slides indicating that the USG has owned up CAs came out. Why exactly does anyone believe the DNS roots are harder to own up?

</comment></comment><comment><USER27> We merged the comments from [https://news.ycombinator.com/item?id=8335470](https://news.ycombinator.com/item?id=8335470) into this thread, since the stories are the same.

</comment><comment><USER28> The toolbox logo for simply secure is killing me. Whomever made the logo has never used any hand tools. The saw is part hacksaw part panel saw.

<comment><USER29> It's a back saw. Sure it has a weird handle and low tpi, but every woodworker knows what a back saw is.

<comment><USER28> And how many woodworkers have a back saw with a hack saw handle? I just went through a ton of clip-art toolboxes and cant find any where the designer decided to go with the extemporaneous saw design.

<comment><USER29> If you're nitpicking the handle design on some clip-art, then I think you should probably just step back a bit.

<comment><USER2> This thread has some great 'Shit HN says' lines. We are truly a tiny little bubble.</comment></comment></comment></comment></comment>


NASA Team Probes Peculiar Age-Defying Star - <AUTHOR> https://www.nasa.gov/feature/goddard/2016/nasa-team-probes-peculiar-age-defying-star <comment><USER2> It is incredible how much we know about objects mind bogglingly far away and also how much we don't know and have yet to discover.

</comment><comment><USER3> Just a theory but what do we know of dying stars getting a new breath of life due to nearby supernovae? Seems like the star died and material from nearby supernova seems to have drifted into it's neighborhood and jump started the star.

<comment><USER4> I can't imagine that the concentration of matter ejected, which diffuses impressively, would have been so concentrated so far away. Supernovae shockwaves are thought to be a candidate for touching of the process of dust cloud collapse and stellar formation, but an old star is usually a really dense core and a very wispy atmosphere, relatively speaking.

Maybe a shockwave could set off a nova event, or the addition of matter could trigger a collapse, but I'm not sure how it could jumpstart nuclear fusion again.

<comment><USER5> Do we have any idea what occurs if a young star and an old star merge? Of course my first thought on that line of thinking is that would cause some type of explosion or ejecta that would be noticeable, but maybe not.

<comment><USER4> I think that might be one of those seemingly straightforward questions that's actually very nuanced, because I suspect that the combined masses of the two stars will have a lot to say about the outcome. For a couple of Solar mass stars, I would expect... a big explosion. I can't imagine it really happening though, except in a one-in-a-<insert -illion of choice> "head-on" collision. In that case, whether it blew apart and re-settled into a star, or a nebula, or... just blew apart, would be a function of mass and momentum.

In the case of slowly decaying orbits, one star usually ends up stripping most of the atmosphere from its partner, before the core eventually passes its Roche limit, breaks apart, and is accreted. In that case you get a series of Novas (not to be confused with supernovas), and a somewhat larger star when all is finally said and done. Lots of debris, occasionally very bright.

It's hard to imagine a situation in which two stars "merge" without a slow process of cannibalization. Compact collapsed bodies like white dwarves, neutron stars and the rest definitely do merge, but they're _so_ much denser than a "living" star.</comment></comment></comment></comment>


Ask HN: Why using server session store? - <AUTHOR> HTTP is stateless, API for mobile app is stateless, so why does web application makes HTTP stateful by storing user data in its store ? <comment><USER2> Well HTTP is stateless but in that form it isn't much fun. So to get around this years ago web apps decided to store state from one request to the next and a whole new world opened up. The whole concept of having a user being logged in or not logged in comes from this. And the whole idea of when logged in as userA you see something different than userB logged in somewhere else.

You can think about it like a deli counter ticket number system. Each stateless HTTP request comes in and gets assigned a number. When that user makes their next request to the HTTP server, it sends along it's number. And this is all done behind the scenes with cookies. Your ticket number is a cookie, when you are given a cookie, u present that same cookie each time you come back. So the guy at the counter knows your ticket 45 and the other guy is ticket 98.

So once you have a system where the 1st http request without a cookie gets assigned a number and every request it makes in the future will contain that number, voila, HTTP is now stateful.</comment>


Plura, a SETI-like Distributed Grid - <AUTHOR> http://www.infoq.com/news/2009/12/Plura-Distributed-Grid

<comment><USER2> Also see this submission of the Wired article about using social networking to facilitate SETI@home style computing:

<http://news.ycombinator.com/item?id=746147></comment>


The AI-created humans in this video look disturbingly real - <AUTHOR> https://nypost.com/2019/05/06/the-ai-created-humans-in-this-video-look-disturbingly-real/ <comment><USER2> This is neat! I wish there was a simple way to use this tech. Is there any company providing SDKs to generate such characters, make models that are usable for videos, anything like that? All I've heard is people using it for deep fakes, rather than something useful.</comment>


Nimrod is being renamed to Nim - <AUTHOR> https://github.com/Araq/Nimrod <comment><USER2> [http://en.wikipedia.org/wiki/Nimrod#Idiom](http://en.wikipedia.org/wiki/Nimrod#Idiom)

"In 15th-century English, "Nimrod" had come to mean tyrant"

"In 20th-century American English, the term is now commonly used to mean a dimwitted or a stupid person."

I could see how you wouldn't want your programming language to be considered a tyrant or a dimwit.

Or a dimwitted tyrant. ;-)

<comment> fsck--off Nimrod was the great grandson of Noah, and he is mentioned in the book of Genesis as "a mighty hunter before the lord." So great hunters were sometimes called "Nimrod" as a compliment.

Bugs Bunny taunted Elmer Fudd, a stupid an incompetent hunter that failed to catch Bugs Bunny, by calling him a Nimrod. But the children who watched Loony Tunes didn't get the joke and so they assumed it was a synonym for "stupid and incompetent."

Imagine that in the future people think that that "Einstein" means "imbecile" because "you're a regular Einstein" was an ironic taunt. It's the same idea.

<comment><USER3> Well, except that Einstein was an actual person, and Nimrod was a mythological one.

<comment><USER4> Hardly an important distinction for these intents and purposes; particularly since those stories were widely taught as fact until fairly recently.

</comment></comment></comment></comment><comment><USER5> Honestly, smart move. I'm kind of embarrassed to say that I decided not to look into nimrod much, despite hearing great things about it from a few people, all because of the name. Figured that it would never gain any semblance of wide adoption under "nimrod" so why bother when there are other languages that are just as cool and _may_ be a marketable skill someday? Or maybe I'm just rationalizing my shallow knee jerk reaction after the fact.

Either way... nim sounds much better :)

<comment><USER6> Technically, `nimrod` means someone who is a good hunter; I don't know why it is viewed as a derogatory term.

<comment><USER7> You can blame Bugs Bunny. He was using it sarcastically when referring to Elmer Fudd (one of the more inept hunters in the history of film). Viewers who didn't understand the original reference began to think of it as just another word for 'moron'.

<comment><USER8> Second post in the thread that cites "Bugs Bunny". If that is now canon and required reading for educated people I have some work to do!

<comment><USER9> They got it from Wikipedia, which also cites Bugs Bunny as the source of "nimrod"'s modern meaning.

<comment><USER7> I had only encountered the term while watching the carton, which all my friend did too. I didn't learn about the word's origin until much later.

</comment></comment></comment></comment></comment></comment><comment><USER10> It's interesting to consider this in light of the opening quote on the language's homepage (which still refers to it as Nimrod):

      The most important thing in the programming language is the
      name. A language will not succeed without a good name. I
      have recently invented a very good name and now I am
      looking for a suitable language.
      -- D. E. Knuth

[http://nim-lang.org/](http://nim-lang.org/)

</comment><comment><USER11> And yet loads of us use "git" without an issue.

<comment><USER12> Just guessing, but I would say that's because "git" is only derogatory in British English, and wasn't popular (if even existent) in American English until it's use as the name of a DVCS.

<comment><USER13> I always thought that git was a form of got or get.

Get me the source code. I got the source code.

Git is almost like a slang word that means get or got.

Yeah in British English it means a stupid person, you useless git! Almost like Nimrod means stupid dimwitted person.

<comment><USER14> > Git is almost like a slang word that means get or got.

Perhaps more dialect than slang?

[http://en.wikipedia.org/wiki/Git_Along,_Little_Dogies](http://en.wikipedia.org/wiki/Git_Along,_Little_Dogies)

</comment></comment></comment></comment><comment><USER13> Nimrod was a King of Babylon, he was considered a hunter of panthers.

The Greek Orion was supposed to be based on him and shares the same star consolation. So was Osirus. His birthday was December 25th.

It was Arabic that gave the definition of a tyrant, as I suppose they saw him as one.

Bungs Bunny called Elmer Fudd a 'Nimrod' in a cartoon that made the connection of hunter to really dimwitted or stupid person. I guess that is where the second definition came in.

Always research the words you use to describe your project, there may be negative meanings to them. Even in a foreign language as well. Chevy Nova, in Spanish it meant the car doesn't run.

</comment><comment><USER15> I can only see this helping them... even by a little. Never understood the naming strategies of some folks.

<comment><USER16> The derogatory meaning of the word is US-specific. To the rest of the world, Nimrod is simply the mythical character. Nimrod's author is German. It's not surprising that he wasn't aware of the American slang usage.

<comment> aaron-lebo Is Nimrod mentioned in any historical texts outside of the Bible? It seems like Bible trivia that very few people would know, perhaps especially outside of the US.

<comment><USER17> He was kind of a big deal in the Old Testament as a Baddie and Wikipedia says his story was well-known, especially in Islam and Judaism.

> The story of Abraham's confrontation with Nimrod did not remain within the > confines of learned writings and religious treatises, but also conspicuously > influenced popular culture.

[http://en.wikipedia.org/wiki/Nimrod#The_evil_Nimrod_vs._the_...](http://en.wikipedia.org/wiki/Nimrod#The_evil_Nimrod_vs._the_righteous_Abraham)

</comment></comment></comment></comment><comment><USER18> Glad to see it. Sure, names don't really mean all that much in the final run; influential brands tend to cancel out pre-existing negative connotations (see: Git). But for nascent projects like Nim, a name with pre-existing connotations can be a burden, and a cool name can give a useful boost.

Of course, what _I_ think when I see Nim now is The Secret of NIMH: [http://www.imdb.com/title/tt0084649/reference](http://www.imdb.com/title/tt0084649/reference).

</comment><comment><USER19> In some important ways (clean code, performance, metaprogramming) the engineering is way ahead of the competition. I'm actually amazed how quickly this has gone from a little-known project to something that leading engineers are putting in their tool belt as an alternative to Python, C++ and other languages for a wide variety of tasks.

</comment><comment> vezzy-fnord The name change really only seems to be present in the repository description for now. Virtually everything else has been left unscathed.

I think it's a shame, personally. The name "Nimrod" is just so distinctive and it's going to be pretty hard (at least for me) to shake off the inertia.

</comment><comment><USER20> So, is he going to change the logo to a rat?(after the children's book Rats of NIMH) Seriously though the name was good for a chuckle but made the language slightly more memorable. Mostly I tend to think of the British spy plane when I hear the name, not the insult.

</comment><comment><USER21> People will get confused when people Google it and find the poset game Nim[1]. Unless of course that's what they were going for.

[1] [https://en.wikipedia.org/wiki/Nim](https://en.wikipedia.org/wiki/Nim)

<comment><USER22> If the programming language has any web presence at all, it will quickly bury the game. Also, it's not like people are going to overhear the word "nim" completely out of context and then google it. If you know it's a programming language, it will be easy to find resources.

<comment><USER14> Given the long mathematical heritage of the game (check out its Google presence: [https://www.google.com/search?q=Nim](https://www.google.com/search?q=Nim)), I'm not sure that I believe that it'll be so easily upset. On the other hand, the first page of results for [https://www.google.com/search?q=Ruby](https://www.google.com/search?q=Ruby) (except the image results) are all about the language, not the gem, so I could be wrong!

</comment></comment></comment><comment><USER23> why?

<comment><AUTHOR> I can't find any official statements about this renaming (there's a BigBreak branch which is supposed to take care of renaming as per a thread reply on the forum[1]) but I assume that people have been citing the name as a barrier to a widespread adoption of Nimrod [2][3].

[1] [http://forum.nimrod-lang.org/t/541](http://forum.nimrod-lang.org/t/541)

[2] [https://news.ycombinator.com/item?id=7076451](https://news.ycombinator.com/item?id=7076451)

[3] [https://news.ycombinator.com/item?id=7074774](https://news.ycombinator.com/item?id=7074774)</comment></comment>


Abstraction without overhead: traits in Rust - <AUTHOR> http://blog.rust-lang.org/2015/05/11/traits.html <comment><USER3> Great article. The main bit of new information for me was that while Rust supports dynamic dispatch, its implementation has a noticeable difference from C++. In C++, the vtable pointer is in the object itself. In Rust, it's stored inside what is essentially a "fat pointer." Pointers to traits ("trait objects") are actually two pointers: the pointer to the vtable and the pointer to the actual object.

This seems to have one major downside (pointers are twice as big), but lots of upsides:

        - allows traits to be implemented for existing types, as opposed
          to C++ where the type's declaration has to list all base classes.

        - allows a type to be used through dynamic dispatch while allowing users
          who don't need this to avoid the vtable overhead.

        - one less indirection in the call sequence for dynamic dispatch.

I like it a lot overall, though the idea of 16-byte pointers on 64-bit architectures does make me slightly queasy.

<comment><USER4> It also makes multiple inheritance (which Rust has, through Java-like interfaces) easy to implement, and fast at runtime. The virtual inheritance of C++ is a real mess, by contrast [1].

[1]: [http://www.phpcompiler.org/articles/virtualinheritance.html](http://www.phpcompiler.org/articles/virtualinheritance.html)

Edit: I don't mean to bash C++ here, BTW; the skinny-pointer approach has a lot of benefits when all you need is single inheritance (and there are early- stage proposals to add it to Rust too). But I don't think it works well for multiple inheritance.

<comment><USER5> I apologise in advance that this may not be most appropriate place to ask this question.

I am looking for a Rust tutorial. It looks like there was one, but it was deprecated in favour of 'the book'. But 'the book' doesn't seem to have a tutorial yet.

Are there any tutorial's running through how to build some small piece of working software.

I found the Golang tutorial, where you build a very basic blog extremely enjoyable. Does Rust have anything similar?

[https://golang.org/doc/articles/wiki/](https://golang.org/doc/articles/wiki/)

Thanks

<comment><AUTHOR> The book basically has two sets of tutorials: the "Syntax and Semantics" section is a bottom-up tutorial, and the "Learn Rust" section is a project- based, more top-down one. It's true that only one chapter of Learn Rust has landed at the moment. It's basically what I'm doing right now. Should have two or three more chapters over the next few days.

<comment><USER5> Great, thanks Steve.

</comment></comment></comment></comment></comment><comment><USER6> Typeclasses benefit from the same "zero runtime overhead" in Haskell (but not Scala). This is particularly important in non-strict languages where inlining is a more prominent aspect of making code performant. Fortunately, GHC is a lot easier to understand WRT optimizations than gcc.

You revert to the OOP-style vtables if existential quantification is introduced because you have to pack code with the data, rather than being able to inline the data from a statically known index of methods into the concrete call-sites.

As it stands, I'm more likely to want Clean-style uniqueness typing in Haskell for a non-GC'd life-cycle for memory than I am to use Rust, but it's nice to see what we can accomplish with linear types baked into the compiler. Wish regions hadn't been abandoned, but it seems like somebody wanted Rust pushed into becoming a product quickly.

<comment><USER7>
      > Wish regions hadn't been abandoned, but it seems like
      > somebody wanted Rust pushed into becoming a product quickly.

No idea what you're referring to here. Lifetimes are entirely based on the regions literature, and four frigging years of design iteration is hardly "pushed into becoming a product quickly". :P

<comment><USER6> Lifetimes aren't regions.

4 years when it is a recapitulation of existing technology and hasn't had time to push anything forward and we already have PLs with similar facilities? That's a product-oriented rather than research-oriented direction whether you think it's too fast or not. For comparison, Haskell dates to the early 90s, based on non-strict FP languages from the 80s. ML itself started in the 70s. Much of what makes Haskell nice today happened because it had a decade to gestate without the demands of industry coming first. Applicative wasn't discovered until _2008_. Those discoveries are a big part of why I happily use Haskell for work today.

This is emphatically _not_ a value judgment, I will likely not use Rust in anger so I'm not your customer anyway at least WRT the programming language. Representations of linear types embeddable in dependently typed languages (such as Brady is figuring out in Idris) will probably be the next step.

In my ideal universe, there's a language for people to experiment with theoretical models and practical applications of linear typing such as Idris provides for DTPLs. This is particularly appealing as it could enable programmers to define their own linearly typed models for the compiler to enforce.

<comment><USER8> I don't think Rust was ever intended to be primarily a research language. From what I gathered even from early docs (in Graydon's reign), it was intended to implement ideas previously introduced in research languages in a practical _systems_ language. They even made mention of adopting only _safe_ ideas* (and I'm too lazy to look for those quotes). I think they've had to innovate some but that wasn't the primary intent.

<comment><USER6> That would explain a lot. How do the goals contrast with C++ then? Smaller language?

<comment><USER7> For reasons of backwards-compatibility, it's basically impossible to design extensions to C++ that make the language memory-safe by default. C++11/14 are admirable best-effort approaches to doing so, but they provide only tools for helping to enforce memory safety without providing any actionable guarantees. Rust guarantees memory safety, with the only possibility of unsafety being relegated to blocks of code specifically denoted as `unsafe`.

In addition to memory safety, Rust's other goal was to improve the ability of programmers to reason about low-level concurrency, motivated by the enormous pain that both the Firefox and Chrome developers are currently experiencing by trying to adapt their browsers to a multicore world. The serendipitous discovery was that the same mechanism used to guarantee memory safety will also statically guarantee that your program is free of data races.

TL;DR: Rust's goals are guaranteed memory safety, guaranteed freedom from data races, and zero runtime overhead relative to C++.

<comment><USER9> kibwen, this whole reply should be an FAQ somewhere if it isn't already. Nice precision!

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> There is _always_ overhead when adding abstractions--the only question is whether you pay at runtime or at compile time. C++ (and presumably Rust) choose the latter, Python and Go choose the former.

<comment><AUTHOR> Yes, in these discussions, the overhead being referred to is runtime overhead.

There's also overhead in the sense of complexity for the programmer, which isn't really either of those two.

<comment><USER11> > There's also overhead in the sense of complexity for the programmer

Well, from the programmers' perspectives there are both read-time and write- time overheads. In C++-land, the discussion about the new (to C++) 'auto' keyword is about the trade-offs between the two.

</comment></comment></comment><comment><USER12> For being a lower level language, Rust's abstractions really make feel closer to a higher level language than to C. It will be even more so if HKT's land.

<comment><USER13> HKT = Higher-Kinded Polymorphism [1]

[1] [http://www.hydrocodedesign.com/2014/04/02/higher-kinded- type...](http://www.hydrocodedesign.com/2014/04/02/higher-kinded-types/)

</comment></comment><comment><USER14> > What you do use, you couldn't hand code any better.

... given you have no information about runtime behavior other than the static code.

How to achieve "zero-cost abstractions" is, as usual, a design tradeoff.

Rust -- like C++ -- lets you choose in your code whether you'd like to pay for an abstraction or not. This does produce good machine code, but has two costs: 1/ the language gets more complicated and the programmer needs to be aware of what she's paying for, and 2/ you might end up paying for stuff you end up not using (for example, all button listeners might end up being the same type, and a vtable adds unnecessary cost), so that the generated code is only optimal if you have no other information about runtime behavior.

There's another way to add zero-cost abstractions: have a single simple abstraction and a JIT to figure out at runtime -- based on observed behavior -- what the optimal machine code is. This is what the JVM does. All method calls are virtual from the programmer's perspective, and no choice needs to be made ahead of time. At runtime, the JIT views the class hierarchy and usage, and decides whether a specialized, inlined version of a function is produced or whether a vtable is actually necessary (HotSpot even makes a special case when there are exactly two implementations, replacing the vtable with an `if`). If runtime behavior changes (a new type of listener is added or even new code is loaded at runtime that adds another implementation), the JIT will notice, reconsider and recompile. So in Java, virtual or even interface method calls are also zero-cost, even though you have no choice about using them; the decision on how to implement the abstraction is done by the (JIT) compiler _at runtime_. This, too, is a tradeoff -- a simpler language and truly optimal code taking into consideration not only static consideration but actual runtime behavior -- at the cost of a possibly significant warmup time and possible non-optimal "mistakes" by the JIT.

<comment><USER15> I wouldn't call that zero-cost. It's more like variable-cost, which could be even worse than always doing virtual calls in some application types.

<comment><USER14> The average case is always as expensive or less than a virtual call. But yes, the JIT most certainly introduces unpredictability, which may be unsuitable for hard realtime applications (hard realtime Java programs employ AOT compilation for those classes that require absolute predictability).

<comment><USER16> It's a problem for more than just realtime applications. Requiring a JIT means requiring a runtime, and that makes it much harder to do thing like embed Rust libraries in scripting languages or expose a C interface.

<comment><USER14> JIT has little to do with interoperation. It's quite simple to generate C symbols pointing to stubs. What makes interoperation hard is usually a GC rather than a JIT (it's just that most JITted languages also employ a GC; but if you look at, say, Go, it's just as hard to embed or link against than as and it doesn't employ a JIT at all -- its runtime "just" performs scheduling and GC).

\---

BTW, Java can be embedded in scripting languages because those languages run on the platform itself and _share_ the runtime. Because of the JIT -- that optimizes across libraries and languages -- the interoperation is cheaper than with C. So much so, that you get the following story: As part of the work being done at Oracle on Graal, HotSpot's next-gen JIT, they've ported various scripting languages to the new JIT, among them Ruby. They've found[1] that if they interpret/JIT the _C code_ of the native Ruby extensions they get better performance than a "plain" Ruby runtime calling into statically compiled C, because the JIT is able to optimize across the language barrier.

[1]: [http://www.chrisseaton.com/rubytruffle/cext/](http://www.chrisseaton.com/rubytruffle/cext/)

<comment><USER16> Right, GC is hard to embed and inlining is a powerful optimization. But the runtime that both JIT and GC require makes things hard for JIT on its own.

</comment></comment></comment></comment></comment></comment><comment><USER17> > Traits are interfaces

So why not use "interface" keyword?

<comment><USER18> Probably for the same reason that they call their unions "enums" or their heap blocks "boxes". Standardization of jargon has never been a thing with rust, just roll with it.

<comment><AUTHOR> Well, enums aren't unions, they're tagged unions. And other languages call boxed values by that name too.

<comment><USER18> Stop it, they're unions. :) Among the target market, people are going to intimately familiar with the use of "enum" and "union" from the C language. Rust's concept of a single object that can store exactly one of several types of sub-objects matches one quite closely, and not the other. Having a runtime tag and affirmative checking doesn't change the nature of the thing. We don't call "cars" something different when we add cruise control or anti-lock brakes.

"Enumerate" in English is just a fancy word for "count" \-- it means to assign numbers to a bunch of things. Which is exactly what the C concept did. The Rust usage (to mean "something that can be in one of a few different states") is new, though Java has something fairly close too.

It was a poor choice, sorry. Likewise being deliberately difficult with "trait" vs. "interface" (picking Self's jargon instead of the term that literally everyone already knows from decades of OOP) didn't serve you well. Thus we have blog posts like this needing to tell us what we probably should have been able to figure out from context.

Finally, regarding "box" vs. "block". Other languages (C# is the only one that comes to mind off-hand) have used the idea of "boxing" to imply the allocation of space for and copying of pass-by-reference data. That's sort of a different notion than simple heap allocation, so it sort of gets its own jargon I guess. I didn't complain anyway. But with Rust, a "box" really is used to refer to a dynamic heap block in any context. We sort of already had a perfectly good word for that.

Pretentious jargon isn't the worst crime in the world, but I do think Rust seems needlessly complicated in the way it likes to play Shakespeare with existing concepts.

<comment><USER19> I'll have to admit enums are where I gave up the first time I read the Rust tutorial. They seem almost completely unrelated to enums in C and other languages.

<comment><USER18> Right, because they're unions. :)

Just go back to that tutorial with your C hat on and substitute the word "union" for "enum" and I promise it will all make sense. All your intuition about C unions will cross over just fine, and the new Rust rules (they're tagged at runtime and the compiler enforces that you can only ever use fields of a runtype-checked subtype) are straightforward extensions.

Likewise the linked blog post begins, comfortingly, with "Traits are interfaces". Once you get beyond the new jargon, you find it wraps a concept which is 95% compatible with something you've been using for years.

That the Rust team seems to find no value in this kind of naming, preferring the excess precision that comes with Create-Your-Own-Name, is what I was calling "pretentious jargon" in a previous post in the thread. It's really not that bad (I mean really, they're just names), but it doesn't speak well to where the designers heads were when they invented this stuff.

Really, that's what's starting to creep my out about Rust. Just like C++ 30 years ago, it seems like Rust has caught itself up in an internal rush (among its rock-star language nerd designers) for Masterpiece Status and sort of forgotten the goal of creating a practical tool for working programmers... At some point in the near future I have to wonder if we're going to start seeing blog posts about choosing a "sane subset" of Rust with which to develop software.

<comment><USER7>
      > it seems like Rust has caught itself up in an internal
      > rush (among its rock-star language nerd designers) for
      > Masterpiece Status and sort of forgotten the goal of
      > creating a practical tool for working programmers

This is complete hogwash. Just because you disagree with the chosen terminology doesn't justify attacks on the character of the Rust developers.

<comment><USER18> Sigh... it's an opinion. I even used "seems". I was around when we all watched C++ go from "exciting new tool we should all use" to "wait, does anyone else understand that new stuff because I don't anymore". This feels exactly the same.

I'm no dummy, yet Rust is just confusing as hell sometimes. And you guys _frankly don 't seem to care_ (again: note marker "seems" to indicate a personal opinion and not a "character attack"). That turns me off. It turns lots of people off. And I don't see any significant effort being made at making it an easy tool to learn and use.

<comment><USER4> > And I don't see any significant effort being made at making it an easy tool > to learn and use.

Just to name a few off the top of my head:

1\. Lots of focus on friendly compiler error messages, including typo correction, automatic lifetime suggestions, and error message explanations.

2\. A strong worse-is-better approach in many aspects of the language design, such as preventing reference-counted cycles (we don't try to), numeric overflow (we don't try except in debug mode), typeclass decidability (it's deliberately undecidable in corner cases to avoid complex rules), prevention of deadlocks (we don't try), userland threads (we don't implement them anymore), asynchronous I/O (it's out of the domain of libstd for now), etc.

3\. Blog posts like this one to introduce aspects of Rust, as well as the tutorial.

4\. The Cargo package manager, as well as crates.io.

5\. Naming conventions designed to fit well with C, for example choosing "enum" over "data"/"datatype" as in ML, "trait" over "class" as in Haskell (since the latter means something totally different), but modified in some cases to avoid leading programmers of C-like languages astray (for example, "interface" changing to "trait"). This naming process has taken time, but I think Rust is in a pretty good place now. There are obviously disagreements as to the naming, but we can't please everybody.

Certainly we weren't perfect, but there was a lot of effort put into making Rust as easy to use as possible.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> "new traits can be implemented for existing types (as with Hash above). That means abstractions can be created after-the-fact, and applied to existing libraries."

Sounds a bit like a Ruby monkey patch. What happens in case of conflict - <USER2> trait adds a .hash method, but there already was one?

<comment><USER21> Trait methods are only visible when the trait is in scope. So a conflict would only appear when both traits are imported and the method is called, in which case you'll have to disambiguate.

<comment><USER20> Cool, thanks for explaining. :) Would it be a compile-time or runtime error?

<comment><USER21> It would be a compile-time error saying (in essence) "multiple applicable methods in scope" and giving you a list of the available methods.

<comment><USER20> Awesome!</comment></comment></comment></comment></comment>


Facebook plans to let everyone retract delivery after Zuckerberg used feature - <AUTHOR> https://techcrunch.com/2018/04/06/facebook-unsend-messages/ <comment><USER2> A.K.A. Zuckerberg did something that was _supposed_ to be impossible and to explain how he did it they have now announced a new feature they just thought up as cover.</comment>


The North Face is the biggest brand yet to join Facebook ad boycott - <AUTHOR> https://edition.cnn.com/2020/06/19/tech/north-face-facebook-ads/ <comment><USER2> Good. Facebook is evil.</comment>


Facebook is No. 1 social network in 127 countries, study finds - <AUTHOR> http://www.latimes.com/business/technology/la-fi-tn-facebook-is-no-1-social-network-in-127-countries-study-finds-20130102,0,7705928.story

<comment><USER2> Not surprised at all!</comment>


An open letter from technology sector leaders on Donald Trump's candidacy - <AUTHOR> https://medium.com/@KatieS/an-open-letter-from-technology-sector-leaders-on-donald-trumps-candidacy-for-president-5bf734c159e4#.7cujhy9s7 <comment><USER2> Talk about being disconnected.

Good example of what happens when a random set of the tech elite sit amongst themselves and talk about their problems.

The average Trump supporter is afraid about their jobs/healthcare/housing being lost thanks to factory shutdowns and outsourcing. Trump exploits those fears.

And look how the "tech leaders" respond. Instead of addressing the fears of those people they want to talk about their own fears.

That is not leadership. Its how we end up with the likes of Trump.

<comment><USER3> So Steve Wozniak has to talk to the Average Joe supporter of Trump and address his fears about jobs/healthcare/housing???

In a world of super competitiveness and your-death-id-my-life it is quite rare (and refreshing) to see so many people unite behind a common fear.

I think we should all pay attention to what they say..

</comment></comment><comment><USER4> So a bunch of ceo's, co-founders, and elite types are against trump. This plays exactly into his hands.

</comment><comment><USER5> It's what these leaders are hiding that's more worrying to me. I think they made deals with the govt that would give away users privacy and are worried what if it falls into wrong hands.

</comment><comment><USER6> Trump is what the US needs (or deserves if you think he'll be bad). [EDIT] I am for more concerned about what these people want for society. I see several from facebook, twitter, and one from reddit. [EDIT2] What more is that many of these company names read like venture capitalists and hedge funds.</comment>


Run this NeXTStep dock on OSX alongside Dock.app (German, translate) - <AUTHOR> http://www.khwbn.de/NextDock/index.html

<comment><AUTHOR> can be used to switch to and launch apps but not hide them. builtin clock. I find the whole look, hidability, alignment and operation to be more power- user-friendly. Rearrange like tiles, adjust transparency.

There is also <http://www.khwbn.de/MultiCubeDock/index.html></comment>


Double your money again - <AUTHOR> http://vanillajava.blogspot.com/2011/08/double-your-money-again.html

<comment><USER2> Someone needs to read "What Every Computer Scientist Should Know About Floating-Point Arithmetic" [http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_go...](http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html) again.</comment>


A year with Twitter Developer Labs: What we've learned and changed - <AUTHOR> https://blog.twitter.com/developer/en_us/topics/tools/2020/a-year-with-twitter-developer-labs.html <comment><AUTHOR> Twitter has always gotten a bunch of crap for having a pretty hostile API (for example, token limits and API not being at feature parity with the main site with things like polls), but this seems to be concrete steps in the right direction. Jack has said this will get better, and I am hoping they actually follow through with the steps in this post.

I wonder if we will see a resurgence of 3rd party Twitter clients. I still use Tweetbot for the lack of ads and chronological sorting, but do miss things like polls and threads not working 100% of the time.

</comment><comment><USER2> Kudos to the folks in Twitter Dev. The new APIs look good and developer outreach has been great. As a long-time Twitter API developer, I'm positive and hoping the best for them in the upcoming new versions.</comment>