Infosec's Jerk Problem (2013) - <AUTHOR> http://adversari.es/blog/2013/06/19/cant-we-all-just-get-along/ <comment><USER2> One of the root causes seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security. It's not as fun to be a developer that is really into security but only have that be part of your job. Even if it's all you do, if your days are just "analyze, document, harden, repeat," that's a lot less fun than getting paid to pop boxes. I know, because that's what I do.

That disinterest is the entire raison d'etre of I am The Cavalry. From their webpage:

        No one is rising to meet these challenges. The cavalry
        isn't coming. We are the domain experts and we are the
        adults in the room. It falls to us. We Are The Cavalry.

The less-charitable interpretation of this is "Hey dummies! If we all want to play red-team, who the fuck do we think is left over to fix things?"

I went to a two-hour presentation at $serious_security_conference on $my_product_domain. I was really excited to see what there was for us. We're not running webapps on racked pizza boxes, so there is a lot of topics in our systems that aren't really explored in public security literature. Instead all I got was some dummy thinking he's hot shit because he found some vulnerable systems on Shodan. I got angry enough to walk out, and then went back thinking there was probably some value to be had. 3 times.

<comment><USER3> >A root cause seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security.

To expand on this, I've also noticed that "security" in enterprise-size companies tends to be a dumping ground for helpdesk+ staff -- people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure"). It's been my experience that people in security teams can't implement the fixes to the things they complain about because if you're a security-minded dev, your career path will be in dev.

>It's not as fun to be a developer that is really into security but only have that be part of your job.

I think it would be ideal to have security as a parallel track to regular dev staff -- with their placement in the ecosystem being between dev and QA. Much like how "devops" was used as a hiring filter to have sysadmins that can at least read code, I think we should have a "devsec" group that bridges security-QA and dev.

<comment><USER4> > people that can read a CVE or parrot "best practice", but not really grok > the subject or think critically about it (e.g. jumping from one password to > another every 3 months isn't "more secure")

So much this.

One place I worked had a head of security that switched us to having passwords that auto-expired every 30 days, had annoying requirements (mix of upper, lower, numbers, and special characters) and not allowing reuse of a password for 1 year. The increase in people having problems was handled by having "security questions" and self-service password resets.

My insistence that "security questions" were just unexpiring, easy-to-guess passwords was met with "But this is the standard!". Pointing out that rapid turnover of hard-to-remember passwords led people to write them down generated a similar reaction.

</comment></comment></comment><comment><USER5> I carve up this problem differently. To me, the field can be divided into two basic categories of people:

1\. People who are into security to prosecute some immortal struggle between good and evil.

2\. People who are into security because of the engineering challenge.

It's the people in group (1) that I tend to have a problem with. Often, for the "good guys" security professionals, engineering facts are just a means to the end of winning the war on the "bad guys". These are the people who tell you your Scala serverside application is insecure because of some recently- released Java applet bug; they're the people who fought against DNS query randomization for a decade because we need to finally release DNSSEC; they're the ones shipping grievously broken cryptography to try to "stop the NSA".

There are jerks in both categories, and competition is a dimension orthogonal to this one, but I find I can handle jerkiness and competition between when I know it's from someone who truly cares about understanding what they're talking about.

<comment><USER6> One of the worst is the cyber-security political purist. The person who has drunk the kool-aid so badly and/or likes to use their knowledge to beat others round the head with it. The person who likes to talk about things like "risk/threat modelling" but actually doesn't:

a) Have a real understanding of the needs of the people they say they are trying to help

b) Have the courage to make tough calls related to ideal vs good security.

Working in the NGO security space we get these people all the time. Send them out in front of a bunch of African/Middle Eastern/Asian/Russian activists who have been risking their lives for years for democracy etc etc and all they do it spend three days showing off, berating people and then leaving. Telling everyone that TAILS/PGP/Linux/TrueCrypt etc etc is for everyone and that anything else "is gonna get people killed," so by extension shouldn't be done. There are people who have made entire careers around taking that attitude, which most of the time actually leads to demoralisation and a long-term decrease in security.

It's easy to recommend the hard "cover your ass" stuff because you don't like the NSA, it's harder to say "Hmm, ok we gotta assume some risk that the NSA doesn't care what we're looking at and use a solid Google two-factor here and see how we get on...now how do we stop the security guard from selling you out?"

<comment><USER7> This. If the Mossad/NSA/PLA thinks there is anything of value on our network, they either already have it or could trivially get it. It wouldn't be the end of the world if they had it, so I don't really care.

<comment><USER6> Yep, within reason - I don't buy into the "I have nothing to hide argument, so I have nothing to worry about." People like Trump or UKIP remind should remind us of the danger of that. Though we should remember, in a realpolitik world, the long-term interests of the NSA -> US Gov -> West etc is in supporting democracy activists for example. It's just a pity that the sensationalism of "counter-terrorism" interests in the short-term, actually damage the long game.

On a sidenote, as a digital and physical security training company for NGOs we manage to get a look at cases from both sides of the coin. Our very very rough guesstimate is that we see confirmed human penetration about 3 times more than we do digital penetration. Of course, this is very rough and has soooooo many other bias factors at play (numerical, cultural how many we see vs not see etc.). But I think it is a point that we keep having to reinforce. Too often powerful "infosec jerks" distort the the focus towards Western biases because of Snowden, Facebook, SnapChat, iPhone and this distracts time, money, energy, training and security measures from the human penetration aspect of things - which are very common in the developing world.

<comment><USER8> So I had to read that last paragraph twice. Could you explain what you mean by "human penetration"? And no, I'm not being dirty (though my mind did initially do a few mental flips when I first read that phrase, it's not my fault I never completely matured...) I'm genuinely asking what is meant by that. Do you mean that someone walks in and attaches a serial cable to a router and their laptop, or plugs in a USB stick into an unlocked workstation?

<comment><USER6> No, at it's most basic level I mean a spy or insider threat.

In the NGO contexts that I have seen that usually means someone who legitimately is works in an organisation but turns for the standard reasons. (More effective, faster and cheaper for an adversary that way)

To a slightly lessor extent, that means someone from the outside who has been placed on the inside. (Less effective, longer and more expensive for an adversary that way).

Sometimes both of these scenarios also include digital aspects, like stealing a USB drive or something but not always.

Before you ask, why do people do it in an NGO environment - fairly similar reasons as elsewhere (though I tend to order them differently based on experience):

US Method of Counter-Intelligence:

-Money

-Ideology

-Compromise or Coercion

-Ego or Extortion

or these days:

-Reciprocation

-Authority

-Scarcity

-Commitment

-Consistency

-Liking

-Social Proof

A good read for more info here: [https://www.cia.gov/library/center-for-the- study-of-intellig...](https://www.cia.gov/library/center-for-the-study-of- intelligence/csi-publications/csi- studies/studies/vol.-57-no.-1-a/vol.-57-no.-1-a-pdfs/Burkett- MICE%20to%20RASCALS.pdf)

<comment><USER8> Well that's scary as all fuck! I didn't realise NGOs were as susceptible to this sort of thing as commercial enterprises. I guess I was being naive and should have known better.

Thanks for the insights.

<comment><USER6> Honestly, in many cases NGOs actually have a far higher physical and digital security threat environment than corporations. Partly that's one of the things I love about my job.

I mean yeh, it's cool if you can get paid loads of money for a 9-5 job to throw a ton of resources and people at protecting your Pied Piper software company in suburban USA or Europe....But now take the exact same advisary (China gov for example) and try to think up ways to minimise their threats all while driving around with a hobbiest sysadmin (who the local gov may arrest, torture or disappear if exposed) with very little English in the middle of the night in darkest Africa/Middle East/Asia...The pay is crap or non-existent, it can be high stress but you get to make a real difference, which is rewarding.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Good article (although I thought it was going to have something to do with the grsecurity thing), but it doesn't mention the _other side_ of the problem:

" _To them, we're Chicken Little crossed with the IRS crossed with their least favorite elementary-school teacher: always yelling about the sky falling, demanding unquestioning obedience to a laundry list of arcane, seemingly arbitrary rules (password complexity requirements, anyone?) that seem of little consequence, and condescendingly remonstrating anyone who steps out of line._ "

That is often true.

It might help if security knew what the hell we did. The last three "Java is broken forever!!!" issues, when the problem was with _applets_ , nearly killed me. Or possibly if they knew _their job_. The last employer's security policy was defined by the latest vendor tool they bought, never mind that it couldn't possibly find any issues in the applications we were writing.

Of course there was the code review I did where I pointed out that it had a giant, monstrous hole in it. The other dev nodded and said, "yeah, that's a good point". But the app had to be in production now, so nothing happened. To escalate, I would have had to go to security, which would be like complaining about a hangnail to an axe murderer. So, nope.

</comment><comment><USER10> The (un)funny thing is, most developers would love to have the time to make sure their code is secure and well tested. Very often they lack a voice to product stakeholders, to get the time off feature development, and make sure their software is up to date with patches.

> _Practice active kindness. Go out of your way to do kind things for people, > especially people who may not deserve it. If you wait for them to make the > first move, you'll be waiting a while — but extend a hand to someone who > expects a kick in the teeth and watch as you gain a new friend. Smile._

I really like this quote. A security engineer and a developer teaming up together as colleagues, are more likely to being taken seriously by stakeholders. Both teams working together have a much better chance of being given the time needed to make sure their software is stable and secure.

<comment><USER11> Until companies start being held liable for their software deficiencies there won't be a change. This is also why I find "Software Engineering" a joke. The equivalent of what passes for Software Engineering, in any other engineering field, would put people in prison.

<comment><USER12> That's hardly the case. A lot of what passes for software engineering also passes for other engineering.

What we actually see is a lot of apologizing, recalls and class-action suit settlements, and nobody actually seems to go to jail.

Not all engineering is about bridges not collapsing; conversely, there is some software that is equally safety-critical and carefully developed.

There is also "everyday engineering", like in consumer products. That's a category that fails miserably. Put simply, shit breaks. Past the one year warranty? Too bad!

</comment></comment></comment><comment><USER8> If you think Infosec guys are jerks, I've met a group of even bigger jerks in some organizations: developers!

This isn't always the case, but in some software companies the developers capture the entire organization and run roughshod over everyone. I've seen developers tell support folks that because they are in support, they are utterly worthless and their opinions and views don't count and never will, right after they ask for their opinion. I've seen them obstruct QA people. Not arsehole, stick it to you QA folk, but quiet, unassuming QA guys doing manual test scripts and find a failure and send the case back to development.

Yup, having one-eyed folk around can really cause a toxic environment. Of course, I have to be careful, 6 years ago _I_ was often that toxic one-eyed person, and I learned this the hard way.

Don't do that. Don't be me. Be nice and be willing to concede that the other person has good intentions. You'll be less angry, more likeable and probably more productive.

</comment><comment><USER13> I've seen this happen way too often at various organizations. My take away is security is a function of the product, not some external process you bolt on top of it.

Organizations typically fail at security because they try to manage it as far away from the product as possible. That leads security and dev/ops teams to manage their goals in isolations: one cares about preventing incident, the other cares about shipping products.

If Agile & DevOps have taught us anything, it's that everyone in the organization should be focused on serving the customer, be it through features, reliable operations, or data security. The only good way to do infosec is to embed security with devs and ops and make everyone shares the goal of making the product better.

<comment><USER2> I don't think the problem is specialization, just that the incentives mean that the specialization doesn't always get applied where it's needed.

Presume a company with the budget to have a SOC, they're doing all the "regular" security jazz and them some. But are they auditing the network services they themselves run, or just applying patches? Auditing the products the company itself is producing, or just kicking the tyres? But they MITM all the outbound https connections, I'm sure that more than makes up for it.

</comment></comment><comment><USER14> I read the first lines and thought immediately of all those e-mails marked IMPORTANT coming from "my bank" that request I immediately enter my username and password somewhere for "security".

Teaching blind compliance with any (unauthenticated) request based on "security" is the one way we could make the situation even worse.

<comment><USER15> It's a pretty big deal. When everything starts at urgent and gets worse from there, people will just rescale the noise to be more understandable. It's just like the joke about sitting down and assigning points to a task and finding out everything is 100 or all bugs are critical or all tasks are top priority.

The meta joke here is that is some ways every security issue _is_ critical, but if everyone is immune to the fear then escalation will feel like the only choice. Either you slowly discharge that stress immunity by being sensibly mellow, or you start packing heat to 'convince' everyone to reboot _NOW_. (There's probably room for _some_ amount of finesse between these two extremes.)

EDIT: There's two terrible responses that seem to come out of this. Either no one gives a damn, or no one gives a damn and just does whatever you say. The first is bad because nothing gets fixed, and the second is bad for `red_admiral's reasons (users treat anything that looks like a security rant as a EULA and just do whatever it says).

<comment><USER16> > all tasks are top priority

I often joke with my boss that if all tasks are high priority, all tasks are therefore of average priority.

</comment></comment></comment><comment><USER17> After nearly 20 years in various kinds of infosec companies, there are companies where jerks are not common, and companies where the jerks are very common.

You cannot fix the jerks in the first kind of company. Learn from them, quietly, and look for your exit.

Some people think that there is a correlation between being really good and being a jerk. Only in the sense that the only way a jerk can survive is if they are very very good. Some other people try to pattern-match them. Mimicking the "jerk" part is easy. Mimicking the "very very good" part is not. (See also: making a name for yourself by being a jerk is a lot easier than making a name for yourself by being really good.)

There are good people who are not jerks. I've worked with a bunch of them.

<comment><USER18> I've worked with such a mimic. He did a security audit, then scrapped the whole system because there was a completely unfiltered network interface, and no matter what other security was in place that would never ever be good enough on a GNU/Linux system. "All interfaces must have strict filtration, only allowing traffic on previously approved ports as per system and application specifications."

The interface in question was called "lo".

I don't work there any more.

<comment><USER19> >The interface in question was called "lo".

Ok that cracked me up. Happy Friday.

</comment></comment></comment><comment><USER20> What is extremely frustrating is the rise of "cyber security" Masters degrees.

The vast majority of these people have never written a single line of code.

They don't understand security, because they can't understand the underlying logic in the code. They just write documentation to meet certain outside standards, and have no idea what I'm talking about when I talk about our security posture. They genuinely think that an online satellite campus degree qualifies them to manage security devs from top ten schools.

This coast's tech centers are starting to drive me batty.

For a data scientist, my normal trade, especially. So much red tape that it's a two month project to get myself a small server for test.

Anyone in need of a remote data scientist, Princeton University A.B., two years at a funded startup, four years work experience with a major firm, with specialties in machine learning, (real) cybersecurity, and big data experience?

<comment><USER21> Someone I know is getting one of those 'cyber security' Masters degrees at Mercyhurst in Erie. I respect the guy, he's really smart, he has an intuitive and pragmatic view of politics... but he hasn't written a line of code ever. He uses a Mac, but he's never opened Terminal.

And apparently the average graduation salary for these people at companies like Disney is around 120K. I want my friend to do well, but I also don't want the security industry to consist of people who have never used Linux.

<comment><USER20> I mean, I earn more than my boss, but he's still in charge. He gets the credit for the software projects I actually have to manage. So it's likely he'll rise up the ladder more quickly, and earn a multiple of my salary.

Yet, he's further up the chart and makes the final decisions, when he can't understand basic variables that go into what applications (especially early stage platforms) are even supposed to _do_.

I'm coming to the realization that I just need to bite the bullet, and get one of those "cybersecurity" degrees. The classes are remote, self-paced, easy to earn a 4.0 GPA, and so heavily subsidized by the company as to be nearly free, so I might as well.

I'm also making my way through the various certifications they seem to value (CISSP, PMP, CEH (Certified Ethical Hacker).)

They're very easy to pick up. I just took a CISSP practice exam for the first time and passed quite easily.

</comment></comment></comment><comment><USER22> I have 40 year experience in developer, systems and security. The real problem comes from the top. Upper management, CEO, CIO, CFO do understand risk and don't understand technology. To them, security wholes are just bugs in "the code" or product liabilities in products used.

More then once I showed management they had a life ending bug. (Little Johnny drop tables) and was fired for being the messenger.

</comment><comment><USER23> Good article, I can't help but think this is the real problem though:

> and Bob's demand that you explain the vulnerability is met with your > impatient demand to "just do it".

Maybe rather than say "Just do it" you could say "Any user can delete our entire database and steal all of our data". I think Bob would understand why this is a bit more important than his current tickets, and by not doing it when told about it any fallout would be his problem.

He might hate you for giving him the task but it would be done.

<comment><USER24> > you could say "Any user can delete our entire database and steal all of our > data".

See the problem is that all/most vulnerabilities wind up with this sort of description, which can lead to Bob building up an immunity to it.

<comment><USER23> Not really though, some do and they should be patched, but only a small subset of vulnerabilities end up with a complete backend compromise.

Things are fucked, but not _that_ fucked.

</comment></comment></comment><comment><USER25> My few brushes with Infosec folks makes me think there's a general socialization problem with the field, not really just a "jerk" problem.

For example (and I know it's still a fairly young field), but simple activities like cataloging and sharing knowledge learned so far seems to be something that just doesn't get done. So the wheel gets reinvented over and over and over again. I'm actually kind of amazed at how many half-assed log parsing/visualization/analysis tools there are. Doesn't anybody in infosec centralize knowledge other than adversaries?

The feel I get from infosec conferences is more of a dick waiving contest and tribal activity than an honest information sharing activity.

</comment><comment><USER26> As others have said, this is a good article.

I'd like to comment on a line that literally changed my life, from my favorite [https://en.wikipedia.org/wiki/Vorlon](https://en.wikipedia.org/wiki/Vorlon), Kosh:

"Understanding is a three-edged sword: our side, their side, and the truth."

I think about that every single day. Speaking for myself, a lot of the other suggestions in the article naturally flow out of embracing this perspective.

I could literally go on and on about this, but I'll leave it be.

</comment><comment><USER27> > Never attribute to incompetence that which can be explained by differing > incentive structures.

Oh, man, this is such a deeply, vitally true thing. It's something I've observed for a long time but never quite put it into words.

So often, when I see some person acting in a way that seems totally stupid to me, it turns out they were just operating with goals and constraints that weren't obvious and were different from mine.

</comment><comment><USER28> I was in IT security for many years and got out largely because of the sheer attitudes of many of the people I encountered. Some of them were genuinely very nice, very smart people, but these gentlemen were few and far between. Sadly.

I started off as an abuse investigator for a very large East Coast ISP, moved into firewalls, then penetration testing once I knew what I was doing. All along this path, the vast majority of guys I worked with, for, and around (on contracts) were sheer jerks of the highest order. Everyone seemed to be angry, upset, on edge. I can understand this. IT security--especially abuse investigations--necessitates seeing the seedy side of the Internet. Ditto IT security in general. You're not working for or with people who are "creatives". You're working for and with people whose sole job is to minimize threats and vulnerabilities.

The most stressful time was being a firewall engineer. Having to deal--on the fly--with impatient customers wanting a six-spoke VPN "right now!" and them being jerks about it was annoying.

I hated the calls that involved my placing a "tap" on some poor sod whose boss wanted an 8-hour tcpdump on him to see where he went when online. They wanted a gzipped log file placed on the server where they could SSH in and retrieve it.

I hated the double standards where executives were given static IP addresses on their machines and special rules created to allow them carte blanche access to the Internet at large--no filtering. They also avoided the proxy. These special executives were _&_ ^%#$@ and everyone knew it.

When you spend your life seeing nothing but evil, you take on a different view of life and the world around you. I saw this happening and I got out in favor of being a sysadmin. I'm much happier, and the IT security roles I do have are much smaller in scope and I know how to handle them quickly and quietly.

</comment><comment><USER29> If Bob gets in trouble with his manager for not prioritizing his features over security features and Alice gets in trouble with her manager for letting the security issues happen then it sounds like an issue with management not working together to set aside time for security related issues as part of the development cycle for the product.

</comment><comment><USER30> This is a big reason I stayed away from infosec, although it fascinates me in many aspects.

IMO, security orgs, especially within companies have this awful reputation because they borrowed the credentialing model of project managers and walk around like doctors with an alphabet soup of certifications. Talking to these folks is like crossing a circa-1998 MCSE with a lawyer.

The CPE requirements from CISSP and other certs encourage publishing and delivering talks, which is good -- if the authors/talkers are competent. The side effect within enterprises and some vendors is you develop a cadre of bullshit artists who are great at throwing spears, not so great at doing anything of value.

</comment><comment><USER31> Security professionals should try to practice avoiding the use of the word "no". Instead, help to explain what controls can be implemented to help reduce risk. Encourage a sense of camaraderie with system owners and develop powerful communication skills with everyone.

Help them to be excited to work with you, rather than to turn the other way when they see you in the hallway.

The mentioned topic of "Recalibrate 'urgent'" is a great message. We're rapidly approaching a desensitized feeling of security risk within organizations and in the general public. As breaches/incidents continue to rise we'll approach a "who cares?" level from the public.

What can they do? Steal my CC? Already been stolen. Steal my SSN? Already done.

What's left to fear when privacy is gone?

What really keeps me up at night is when security incidents are measured in lives. Scary...

</comment><comment><USER32> Yeah, they definitely are.

I reported a major issue of comcast to an indirect associate of mine I know who's huge into security. I wanted some contacts with folk who know how to disclose it properly, since I wasn't getting much help from comcast. He pretty much shrugged me off because I don't have a traditional "infosec personality". A day later, I got a hold of some pretty high ups in comcast who actually fixed it. Their engineers were completely blown away by the issue and it sounds like it might do pretty well for me in the end. He wasn't the only one who shrugged me off, but if I'd gotten help from any of them, it might've gone well for them, too. The exclusionary attitude is pretty ridiculous.

I think a lot of the problem is that their threat models tend to cause them to become pretty reclusive, so that they don't really want to trust "newbs". Problem is that it now feels like a paranoid echo chamber.

I commented here a while back about working with Northwestern's security to try and protect my own HIPAA data. NW's response to my disclosure was "We're already doing scans. Report back when you find something serious." It's fucking sad that security's treated this way on many fronts. If you're not on the "in", then you're considered a script kiddie, if you're on the "enterprise in", then you're useless and completely caught in red tape, and if you're in the "in crowd", then you're part of an echo chamber.

Just yesterday, I was explaining my reasoning for wanting to make a LAN party insecure as possible to promote openness rather than exclusion, since any measure to add extreme security would prevent further appearances. The not-so- fine print wold be, "Hey guys, your stuff is insecure. This is intentional. Please treat it as such." His recommendation that for each different game (of maybe 30), you disconnect and re-request from dhcp for the vlan which is hosting the game you want to play. Two games wouldn't be allowed. Silliness.

</comment><comment><USER33> Jerks are everywhere.

Quick read of article like, "Rise of the Cypherpunk" is a reminder of how many awesome people are in cyber security: [https://news.ycombinator.com/item?id=11465203](https://news.ycombinator.com/item?id=11465203)

</comment><comment><USER34> Tribalism is really hurting the progress that security folks could be making. Development and operations are starting to collaborate and make huge gains in productivity. Rebranding security as a component of quality can help.

Coming into meetings with other teams with a list of (often unfounded) assumptions does not help anyone. I wrote about this a bit last year: [https://blog.conjur.net/devops-and-security-the-five- monkeys](https://blog.conjur.net/devops-and-security-the-five-monkeys)

</comment><comment><USER35> Technical Infosec guys can fix vulnerable dependencies themselves and use the tests Bob writes (right?) to make sure they don't break anything. Only need to bug Bob when there is a breaking change and you prioritize it with Bobs PM.

Also passwords are dumb - Bob should use certs and or ssh keys and 2fa to access anything.

The point is that any security that hinges on hassling Bob is likely bad security.

</comment><comment><USER36> Article is fairly similar to my experience- infosec uses up all their goodwill by appearing inflexible on everything before we get to any important points. One of my (admittedly minor) examples: insisting that passwords dialogue boxes be obscured in all situations even in a private office and even if it breaks disabled input abilities and affordances.

</comment><comment><USER37> InfoSec: "There is a vulnerability."

me: "PR or GTFO."

The problem described is that ISOs are professional nags instead of software shippers.

<comment><USER13> That only works if your application is simple enough for the infosec folks to know how to write a patch for it.

If the organization has 200 of those apps, it's unlikely a transversal security team is able to write patches for each one of them.

<comment><USER38> Not patches, bug reports. With information in. So the problem can be reproduced and prioritized. As part of the normal development process.

</comment></comment></comment><comment><USER39> This is an excellent article.

> Hanlon's Razor says "Never attribute to malice that which can be adequately > explained by incompetence," but I would add, "Never attribute to > incompetence that which can be explained by differing incentive structures."

That's profound & pretty thought-provoking.

 _Ternus 's Razor_, anyone?

</comment><comment><USER40> Until a security incident occurs, the vast majority of people, be they developers, admins, management, senior management, etc. view security threats as something that only happens to other people. Why do we have to patch this, we are behind firewall x and y, we could NEVER be compromised.. yeah.

</comment><comment><USER41> "The Truth" is, it's probably not that big a deal. No matter how stringent you are, there are probably still vulnerabilities. And just like everything else, if there's a problem, you work through it. And likely remain unscathed.

</comment><comment><USER42> I don't know about infosec people, but computer security hackers are the biggest trolls and assholes I've ever encountered in tech. Their whole collective community is fueled by ego. (Source: 12 years in the hacker community)

</comment><comment><USER43> > Put bluntly: to others, we're jerks.

> If you don't think this is a problem, you can stop reading here.

Thanks for saving me the time

</comment><comment><USER44> >Put bluntly: to others, we're jerks. If you don't think this is a problem, you can stop reading here.

Well, that's a great way to have an honest dialogue.

> You fume for several minutes, cursing all developers everywhere, but no > response is forthcoming. Angrily, you stand up and march over to his cube, > ready to give him a piece of your mind.

At this point, all you've done in response to finding a serious security issue is to send an email with a very poorly worded and vague title. Why are you getting upset that nobody has reacted to it within a few minutes? I'm also curious as to why Bob would think this email to be unimportant, does InfoSec just use one email subject for everything?

If something's important, people generally turn to _synchronous_ communications, where we can verify that our audience has processed whatever it is we need to tell them. Async communication works just fine on smaller time slices, like chat/IM, but email overall tends to have relatively high latency, especially if you need to communicate a serious security issue.

> Many in the Infosec community are fond of casting the security world as "us > versus them,"...

Wait. Is this a joke? Isn't "us versus them" the canonical _wrong_ way to frame just about anything? At the very least, it's obviously the wrong way to approach InfoSec, in addition to virtually any other collaborative effort. This should be obvious if only because you need to work with other people. Conflict does not cooperation make.

> ...he gets lots of "urgent" security emails that turn out to be Windows > patches, admonitions to change his password, policy reminders and so on.

That right there is entirely on InfoSec. They're not only boy-who-cried- wolfing, they're doing so with vague subject titles. But that's okay, InfoSec is going to get very upset anyway, because they've failed to properly communicate the severity of the situation, and people are acting accordingly.

> ...and Bob's demand that you explain the vulnerability is met with your > impatient demand to "just do it."

Ouch. Why does InfoSec not want to share the wonders of 0days? Seriously, one of the most fun things to do is dissect, or read others' dissections of, an 0day. This is great knowledge to share, and I would applaud any developer who takes an interest in security by wishing to understand what security issues are, especially 0days.

Additionally, rejecting someone's request for additional information about a task you've given them is almost universally a bad thing to do. If it's not feasible to grant them the information they desire, it's on you to properly communicate that, don't just rebuff their request. Transparency is great for teamwork.

> Bob... can't deal with this now, he's too busy, it's not his problem (there > are other devs, right?) and you should take it up with his manager.

I actually thing this is valid. If a developer does honestly feel to busy, going to their manager (who should be in the loop for security issues anyway) seems like a reasonable escalation. If it's actually an urgent issue, it should be valid to disrupt the manager's day with it just as much as it is to disrupt the developers day.

It seems like it's the same response a developer would give to someone freaking out about a serious bug in their code. If it's a serious issue (developer, for whatever reasons, is unconvinced) then you should take it up with their manager. That's not to say the developer is correct in being unconvinced, but arguing that route is less timely and less likely to actually work.

> The jaundiced attitude among Infosec mentioned above...

When I first read the article, I thought the author was knowingly straw- manning, hence their opening warning about jerks. This seems to indicate otherwise, as the author is seriously referencing their story as something remotely realistic. Either the author's story was a terrible straw man, or I'm very ignorant of how unprofessional my professional compatriots are.

Regardless, the author lays out the solutions:

> Practice active kindness.

That's horoscope level advice. It is good to be nice, but it's not exactly feasible to do all the time to everyone or we'd have solved a great many problems in society a long time ago. Generally speaking, being nice requires some emotional effort, and not everybody has the same capacity for that as everyone else, and those that can afford to do it probably already do. Although I suppose I could believe that an adult capable of being nice all the time simply isn't doing so because nobody suggested to do so...

> Seek to understand and make this clear.

Always great advice, like being kind, but far more actionable and sadly, far more applicative. Yes, communication is critical when working with others, especially when attempting to delegate tasks to others. This _should_ be obvious, but I've found many people to not take this seriously. If you need something done, it's on you to ensure whoever you delegate the task to understands it at least as well as you. You can't fault them for your inability to properly communicate.

One of the saddest things to see is when two or more parties get upset at their own failures at communicating. For example: Bob shouts across the office "Hey Alice, do X" but Alice is listening to music and doesn't hear. Some time passes, then Bob gets upset that Alice has not done X, and Alice gets upset at Bob for being upset that Alice has not done X. Now we've got two parties, both upset over an unfortunate circumstance, with no resolution in sight. Had Bob attempted to confirm his communication, this whole situation could have been avoided. Alice could also do her part by not being upset by Bob's failure at communicating, but emotions are fickle and it's hard to defend yourself stoically when your attackers are fuming with emotions.

Additionally, had Bob confirmed his communication, in the event Alice had still not performed X, Bob can escalate to whatever authority is appropriate with the evidence of Alice's understanding of his request, increasing the odds for meaningful resolution (at least from Bob's perspective).

> Be flexible. Recalibrate "urgent."

The boy who cried wolf.

> Create stakeholders...

I'd be a little concerned with teams arbitrarily deciding their security goals. They should 100% be involved in the process, but leaving them entirely to their own devices would incentivize them to have terrible security, as that's generally the easiest thing to do.

>... and spread security knowledge.

This is good advice, and it's sad to think it is useful advice. If you're ever in a situation in your life where you need to communicate to another person a task to be performed, you should be more than willing to share information about said task in order to aid in the delegate's efforts. It's an obviously useful thing to do, and it's sad to imagine adults making it through life, surely having many tasks delegated to them by this point, and not understand how valuable additional information about the task can be.

I would be highly concerned if my coworkers did not already understand this. While we all can't have our dream jobs/offices/employers, compromising on communication abilities is pretty much always going to have both bad and unpredictable consequences (you can't easily predict how someone's going to react to (mis)information from poor communication).

> Fixing Infosec's jerk problem benefits everyone: us, the people we deal > with, and ultimately the security of the system — and since that's our long- > term goal, we should actively seek to fix the problem.

I think the easy solution here is to fire those jerks. Seriously. Talk to them about things, ask them why they're doing what they're doing, but this _isn 't_ a systemic issue. This is a personal issue. People being jerks can (and will) happen anywhere people are present, and the solution isn't to group everyone in a large category together and then proclaim it a categorical issue that they all must work to resolve. Find the bad apples, deal with them as you would in any other situation. Communicate to them that what they're doing is both technically (security issues are not being fixed in a timely manner) and personally (they're failing to communicate on multiple levels and upsetting people) ineffective. Ensure they understand that their actions are not desirable and are creating a hostile workplace (I never thought I'd say that non-sarcastically...). If they keep doing what they're doing, let them go. If they harbor animosity towards being repressed, let them go. There's a wealth of wonderful people in the world, seek them out instead. Be selective, it doesn't take a large security team to be effective, especially when developers are a part of the security effort (which they should be !!!!11).

</comment><comment><USER45> There is a fundamental conflict of interest between security people and developers/owners/the general public. Infosec isn't interested in curing fundamental IT insecurity by, say, using safe languages (like Rust or something JVM-based or maybe JavaScript which is also a safe GCed language) for application development and using safe OSes that aren't built around 70s state-of-art (ugh.. really no production ready examples here). Instead infosec community - both "blackhat" attackers and "whitehat" protectors - profits from business as usual: a never-ending stream of zero days, CVEs, buffer overflows, side-channel attacks. It's not in their true interest to kill their cash cow.

Remember: If we, developers, used modern safe programming technologies, such as safe languages and OSes built around capability-based security, 99% of security exploits wouldn't even exist.</comment>


US Rep. for Silicon Valley hosting online Q&A - <AUTHOR> http://crowdhall.com/h/53 House Representative Mike Honda (rep for Silicon Valley) is hosting a Q&A for a couple days online at this link: http://crowdhall.com/h/53. Could be interesting to ask him about issues that impact the startup ecosystem. <comment><AUTHOR> Might be cool to ask him about things affecting the startup ecosystem. Like privacy, taxes, etc.

</comment><comment><USER2> nice to see some transparency</comment>


Experimental browser built in HTML - <AUTHOR> https://github.com/mozilla/browser.html <comment><USER2> See also servo-shell, a stripped-down related project that runs in Servo today: [https://github.com/glennw/servo- shell](https://github.com/glennw/servo-shell)

The goal is to eventually grow Servo's functionality to be able to run all of browser.html.

</comment><comment><USER3> I believe that part of the idea here is that Mozilla is more-or-less fed up with XUL (the foundation of Firefox's UI), and rather than reimplementing it to serve as the basis for Servo's UI would rather just leverage the stock web technologies that Servo already supports.

<comment><USER4> I think they already threw away XUL for Firefox on Android.

<comment><USER5> Not so much because we're fed up with it as simply the performance characteristics of low end Android phones and the user expectations regarding mobile browsers not being compatible.

Startup time is just so darn important.

Not being able to rely on Gecko for stuff that must be accessible immediately means that Firefox for Android has to re-implement a load of things. That's not a choice that was made voluntarily.

<comment><USER4> Doesn't it still use Gecko though?

<comment><USER6> Yes, for web content, but not to render all of the UI as well.

</comment></comment></comment></comment></comment><comment><USER7> A similar effort: [http://breach.cc/](http://breach.cc/)

it uses nodeJS's webkit binding. You can open an inspector on any element of the UI

<comment><USER8> FWIW In Chrome you can already inspect the inspector.

<comment><USER9> Whaattt? Sure enough, I just hit `CTRL + Shift + I` a few times and ended up with an inspector of an inspector of an inspector. Inspectorception?

</comment></comment></comment><comment><USER10> Video posted in the reddit thread: [https://www.youtube.com/watch?v=U6fgWWQLWa8](https://www.youtube.com/watch?v=U6fgWWQLWa8)

</comment><comment><USER11> Commit: less offensive message in index.html (14 days ago)

[https://github.com/mozilla/browser.html/commit/b45df0941e2dd...](https://github.com/mozilla/browser.html/commit/b45df0941e2dd819f112210bb831eaa0c8ec3c2e)

Too bad about the line right above, though.

<comment><USER12> What? That's called "documentation". Its the "why" to complement code whose purpose is non-obvious.

How on earth do you find technical and accurate documentation to be offensive?

<comment><USER11> I'm not giving any opinion here. I don't find it offensive -- I find it funny. They just missed the line right above where the same remark is made sans the "wtf".

</comment></comment></comment><comment><USER13> Can't trust anything on April 1.

<comment><USER14> This has been around for a while; it was previously called Firefox.html and was discussed here:

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

</comment></comment><comment><USER15> Tired of these april fool's jokes: building an app using a document markup language? Who is going to believe that!

</comment><comment><USER16> Does anybody have prebuilt Servo for Windows 8.1 x64? I want to run this but I can't be bothered to build Servo just to test this.

<comment><USER17> We don't yet support Windows, though some awesome community members are slowly Windowsifying the deps. Any help would be much appreciated :)

</comment></comment><comment><USER12> Vivaldi, a browser made by ex-Opera employees, does this too: base the browser-UI on web technologies.

And honestly, it does make sense: any improvement you make to any part of your browser engine translates into improvements in the browser itself. It's the ultimate dogfooding.

[https://www.vivaldi.com/](https://www.vivaldi.com/)

<comment><USER18> It's too bad Vivaldi tracks all of its users with no opt out possibility, could have been interesting.

<comment><USER19> source?

</comment></comment></comment><comment><USER20> A browser running inside a browser!!!

<comment><USER21> Actually, a browser running in a web runtime ;)</comment></comment>


Godel's letter to Von Neumann: Computational Complexity years before its time - <AUTHOR> http://weblog.fortnow.com/2006/04/kurt-gdel-1906-1978.html

<comment><USER2> It's very interesting to see how Godel anticipates the major questions and goals in computational complexity, before the standard complexity paradigm was set.

It's also interesting to see how varied his interests were. I always feel very capricious when I mention a set of different concerns, ideas, or results in a letter to someone (indeed, I've been told to keep emails shorter), but I guess I'm in good company.</comment>


Why one of Leanplum's investors decided to become an employee - <AUTHOR> https://www.leanplum.com/c/blog/from-angel-investor-to-early-employee/

<comment><USER2> Customer empathy FTW!

</comment><comment><USER3> Great article !

</comment><comment><USER4> Nice move!</comment>


Mapping College Rapists with SHA2 & Tor - <AUTHOR> https://medium.com/praxis-journal/6b7ae80f3d72

<comment><USER2> It would be trivial to brute force the alleged perpetrator's names, simply by running SHA2 on all students. This is not helped by adding a unique salt, because then no matching can be done between incidents.

I applaud the ideas and ideals, and I believe this has the potential to be a Good Thing(tm). I'd really like to see clever and knowledgeable people get together to make this happen, and the ideas outlined here are at least a start.</comment>


Python vs. R: The battle for data scientist mind share - <AUTHOR> http://www.infoworld.com/article/3187550/data-science/python-vs-r-the-battle-for-data-scientist-mind-share.html <comment><USER2> Wow, people here are being pretty hard on this article. I'm sure everyone here on HN has read their share of programming language flamewars, and this one doesn't come close. It's pretty mild.

I also think it gets something right - it does feel different to use Python and R, and the reason may be rooted in how these languages arrived at data science. Python, as the article points out repeatedly, is a general programming language that scientists liked using for numerical computing, so slowly it acquired a billion libraries for data analysis, stats, machine learning, and so forth. R was created by scientists and statisticians specifically to do stats and analysis, but in order to be useful, it needed to acquire the full capabilities of a programming language.

What feels most natural to you often depends on what direction you come from. If you're a programmer taking on data science, you may gravitate toward python. If you're a statistician getting deeper into code R may feel more natural. It would behoove you to learn both.

What on earth is wrong with that? I suppose that for a few people on HN, this might be a bit repetitive. But otherwise, I'd recommend this article as a relatively non-combative bit on explaining the different languages, especially for someone getting started.

<comment><USER3> It's been a few years since I've done some real R work, but my general impression of things was that "core R" \- ie. the R that is explained in the R manual - is actually a bit deprecated. It's not the correct way to use R. The correct way is to use the Hadley tools (ggplot, dplyr, etc.)

These tools are grafted onto R - but seem to have a completely different design philosophy. I actually don't know why they're in R and not Python or C++ or whatever other language - but they form a set that is very easy to work with and produce results really quickly (especially in combination with RStudio).

So the design principles behind R (or I guess the S language) kinda becomes irrelevant.

<comment><USER4> R is explicitly designed around S-expressions and as such lends itself to domain-specific languages like these. The choice was not an accident either by the original Rs (Robert Gentleman and Ross Ihaka) nor by Hadley.

Guido has explicitly stated that he does not want Python to be "more lispy" e.g. in regards to lambdas (asterisk). Thus I've seen many people even at, say, Stanford, Harvard, and Cambridge going back to R from Python. Sometimes there does not exist a language that best suits a workflow, and a DSL works better. That is where lispy languages hold an advantage.

Use the right tool for the the job, imho, but I fucking hate people that mix the two within a project intended for wide public release. Worst of both worlds, again imho.

(Asterisk) apparently functional data structures such as iterators and generators are OK though. Wtf guido

</comment></comment></comment><comment><USER5> Ugh, not again.

R is good for tabular data and Python is good for text/image/nontabular data. _And there 's nothing wrong with knowing and using both languages._

Likewise, the world will not end if you use Python pandas for tabular manipulation or various bespoke R packages for nontabular manipulatition.

This isn't the battle that people should be fighting. It's not even a _religious_ argument like web development stacks where a language can eek out better benchmarks. And as others note, _this very article_ concludes that they both have their advantages.

<comment><USER6> >R is good for tabular data and Python is good for text/image/nontabular data.

Everyone I know who's used both prefers Pandas to R for tabular data.

<comment><USER5> More specifically, tidyverse/dplyr > pandas, in my opinion. Base R manipulation is not good.

<comment><USER7> It's a matter of taste. I prefer base R over tidyverse.

</comment></comment></comment></comment><comment><USER8> Hadley Wickham and Wes McKinney take issue with the gladiatorial angle of this article: [https://twitter.com/wesmckinn/status/850353331172249600](https://twitter.com/wesmckinn/status/850353331172249600)

<comment><USER4> Both are nice and pleasant guys to work with, unlike a lot of the drooling idiots that act like this "rivalry" is some sort of football game. Funny how master craftsmen don't often blame their tools, they sharpen them instead.

Any time someone blames their tools for their own inadequacies, show them this video of Kelly Slater surfing better on an overturned table than most of us can surf on a 7 foot three fin board: [https://m.youtube.com/watch?v=XQ4owd3yQ_4](https://m.youtube.com/watch?v=XQ4owd3yQ_4). Up your game instead!

Edit: hacker news doesn't use that part of markdown

<comment><USER8> I agree—it's about not blaming the tools, but also following Vonnegut's rule: Goddamnit, you've got to be kind.

Some of our other FOSS luminaries have chosen a different interaction model. Sometimes that other approach to technical project leadership is touted as necessary. I'm sure Hadley and Wes suffer their fair share of fools, and they generally seem to do so with kindness.

</comment></comment></comment><comment><USER9> > Yes, Python makes preprocessing easy, but that doesn't mean you can't use R > if you need to clean up your data. You can use any language. In fact, in > many cases, it's structurally unsound to mix up your data purification > routines with your analysis routines. It's better to separate them. And if > you're going to separate them, why not use any language you like? That may > indeed be Python, but it could be Java, C, or even assembly code. Or maybe > even you want to preprocess your data within the database or some other > storage layer. R doesn't care.

The hell does this even mean?

<comment><USER10> Yowza.

I'm guessing it means clean your data first; then process your cleaned data; and if you're doing that, why not try another language.

I think the author has a forest and trees issue here. He's definitely missing the point of Python for his use case.

</comment></comment><comment><USER11> All these articles always say that Python has better preprocessing compared with R. Where? I find tidyverse/data.table much more elegant than pandas, scipy et al. The only thing that I like more in Python it is how it handles streams/generators.

<comment><USER12> Ya, completely agree with this (having also used both extensively). dplyr can also connect to remote SQL server so data don't have to be local. Maybe pandas does this now too but in my experience SQL connections were generally more painful in python

<comment><USER13> This is what SQLAlchemy is for. It's one of the best ORMs out there and makes interacting with a SQL server a breeze.

</comment></comment></comment><comment><USER14> Having recently completed a data analysis project I'd say the biggest thing that made me choose R was its ability to make really pretty graphs easily.

I have a lot of experience with Python doing all sorts of programming. This was my first R program and I don't regret it. The libraries in R(ggplot2) for making pretty graphs are much better than anything I could find for Python.

<comment><USER15> Having spent lots of time recently looking at vis in both Python and R (I use both), I'm starting to think Vega lite may well be the future.

In Python, you can use Altair [0] and in R you can use the vegalite package [1]. Note also that R's ggvis uses vega under the hood.

[0] [https://github.com/altair-viz/altair](https://github.com/altair- viz/altair)

[1] [https://github.com/hrbrmstr/vegalite](https://github.com/hrbrmstr/vegalite)

</comment></comment><comment><USER16> "The first stage of data aggregation can be accomplished with Python. Then the data is fed into R, which applies the well-tested, optimized statistical analysis routines built into the language. It's as if R is a library for Python. Or maybe Python is a preprocessing library for R."

I really like this approach, actually. Taking advantage of the strengths of both languages.

<comment><USER17> We often take this approach at my company. The heavy lifting of feature extraction from raw data (wearables in our case) are done by python/numpy models. The population level stuff is then often handled in R by data scientists with more of a maths/stats background than an engineering one.

</comment></comment><comment><USER18> This is one of the worst articles I've ever read. It's literally (figurative literal here) creating a shitshow out of a mountain made of non-combative people who get along with each other mostly, but get a little pissy if you bone one of their wives, which is totally theoretical because none of them actually have wives.

But you get the point: this article has no point.

<comment><USER19> I agree. I also take issue with it's content, I think all the points made are very shallow and not necessarily correct.

<comment><USER20> its content

</comment></comment></comment><comment><USER21> In the "both of these are awesome, thx for your input infoworld" camp, does anyone know of an equivalent of purrr for pandas/ python? I've been digging the pandas/scikit/numpy/numba stack recently but a friend was showing me the most beautiful data manipulation R code the other day, written in purrr.

</comment><comment><USER22> Wise advice.

Use both because the real tool that you are using for data analysis is the computer, not the programming language. R and Python are both just parts of the toolset.

Nowadays there are lots of ways to combine the two from Rpy2 to Orange3 to Jupyter and the Beaker Notebook. Notably the last two let you use Groovy,Java,Scala and a host of other languages as well. Apache Taverna also plays in this space of integrating multiple tools with different strengths to do a job.

R will likely never be eclipsed by anything because it has such a broad and deep collection of statistical libraries. But Python won't go away because it is a great tool for general purpose computing and even hardcore stats heads have a lot of general purpose computing problems to deal with.

It is sad to read R code that copies files, gets data from S3 buckets, runs SQL queries, and so on. So much of it is crudely hacked together and even the libraries that support this are shoddily built. The best of both worlds is to use Python for pre and post processing, but R for the stats libraries (CRAN, BioConductor).

For lots of S3 wrangling the best tool is a Java library called Je tS3t, and using a language like Groovy or Scala makes it easy to tame. And Groovy is integrated deeply into Jenkins which has evolved beyond a CI tool into a general purpose dashboard for managing and running "jobs". Works great for big data stuff that is not purely Map/Reduce.

Beaker Notebook is leading the charge by integrating seamless conversion of data frames between languages so that you can write a script in two or three languages at the same time, building on the strengths of each one.

If you stick with just one language then expect the next generation of data scientists to leap far beyond you in a few years. A sea change is coming.

<comment><USER23> > the last two let you use Groovy,Java,Scala and a host of other languages as > well

Neither Python nor R run on the JVM, so if you end up using Java,Scala,Kotlin,etc then you've decided to open that JVM can of worms which is another huge pile of tradeoffs.

> Je tS3t, and using a language like Groovy or Scala makes it easy to tame. > And Groovy is integrated deeply into Jenkins which has evolved beyond a CI > tool into a general purpose dashboard

If you end up there, know that only a subset of Apache Groovy is used by Jenkins, e.g. Groovy collections methods aren't supported. Each step along the "native Python or R" -> "Java on JVM" -> "Scala or Groovy" -> "Jenkins as dashboard" decision process entails some cost-benefit tradeoffs which need to be assessed.

</comment></comment><comment><USER24> Future data scientists probably also should consider Julia.

<comment><USER25> Data Scientist here.

Only after they learn a boring language either R or Python.

Don't bet your money on Julia, it's only at 0.6 so the API ain't even stable yet.

Devs promise no changes to the language when it hits 1.0.

<comment><USER26> I've been using R intensively for almost two decades, and Python for about half that time. I enjoy using them both and think they're great languages. I don't think it's an either-or thing, because they both have something to offer.

At the same time, they also have a lot of weaknesses, most of which are summarized by the Julia benchmarks ([https://julialang.org/benchmarks/](https://julialang.org/benchmarks/)). You can criticize these particular benchmarks, but similar patterns emerge in lots of other benchmarks.

R was never meant to do the heavy lifting it's doing today. Ihaka sort of lamented this fact for a while, and then got ignored as people went on to use it anyway.

Sure, you can wrap things around low-level C/C++/Fortran in either language, but eventually if you find yourself getting into nitty-gritty stuff, the computation and/or memory use of R and Python becomes a problem. It also complicates a task to rely on juggling two platforms at the same time.

Julia is new, but it reminds me a _lot_ of R in its early stages. I started using R when it was in beta because it offered something new, and Julia has a similar feel at the moment. Maybe Julia will die away but it doesn't seem that way to me at the moment. I've seen lots of prospects come and go, and none of them had the same traction as Julia.

If anything will stem the growth of Julia, it probably will be Python. Javascript saw a lot of performance gains after Google and other players invested heavily into it as part of the mobile ecosystem. It seems like Python is getting similar investments now with ML/DL, and I wouldn't be surprised if Google, et al. started dumping tons of resources into PyPy or something in the same way you saw javascript implementations getting that investment. At the same time, if you look at benchmarks of PyPy, it seems like you might get to the same level as javascript, which isn't the same as Julia (or C++, which is maintaining its relevance, or Rust or Go, which are growing and relevant).

I guess my point is if a student asked me, sure, I'd recommend they prioritize R or Python first, but I would also explain Julia to them and recommend they become familiar with that as well.

</comment></comment></comment><comment><USER27> Maybe I am the only one, but I find numpy is like alcohol. You may feel exhilarated in writing numpy code, but the resulting code is often very difficult to read.

<comment><USER28> In my experience, this is just mathematical code in general.

</comment></comment><comment><USER29> I have not looked at the link. But would Sagemath not be both? Python AND R?

[http://doc.sagemath.org/html/en/reference/interfaces/sage/in...](http://doc.sagemath.org/html/en/reference/interfaces/sage/interfaces/r.html)

</comment><comment><USER30> Awful article. Badly researched and badly written. Just a journalist wanting to write about something he thinks people want to read

<comment><USER21> 7 ways to spice up your relationship... with data science!

</comment></comment><comment><USER31> Wow, I really liked the introductory paragraphs, gets the point accross very well for slightly non-technical people.

</comment><comment><USER32> Oh God the new age politically correct "battles" where in the end you all hug and sit down to sing the kumbaya and try to please all readers by claming everyone is actually a winner in this "battle"...

If you are too afraid to actually analyze a situation and give your opinion, then just don't write about it and spare us all the time it takes us to read it.

<comment><USER33> Perfectly put. See also [https://news.ycombinator.com/item?id=14067039](https://news.ycombinator.com/item?id=14067039)

</comment></comment><comment><USER25> > Indeed, it is a variant of S with lexical scoping to make large code bases > cleaner

I have no clue where he's getting this.

R have 3-4 ways to make a class btw. The code base isn't cleaner. Most packages that need speed is coded in faster languages. So R is gluey for packages.

The code base is decent overall but I think Python is much better.

> Python does everything any language can do

I want it to preemptively stop processes like Erlang but it can't. So this is wrong.

> The Python world has been trying to catch up lately by working with existing > IDEs like Eclipse or Visual Studio.

It have Rstudio equivalent, it's Rodeo.... this guy. He mentioned it later on for some reason which contradict his previous statement.

I think the article is unorganized brain dump. Maybe he just need to reorganize his thoughts.

<comment><USER34> > > Indeed, it is a variant of S with lexical scoping to make large code bases > cleaner

> I have no clue where he's getting this.

The original S language from the Bell Labs (and the commercial version S-PLUS) used dynamic scoping (like Emacs lisp).

[https://www.stat.auckland.ac.nz/~ihaka/downloads/lexical.pdf](https://www.stat.auckland.ac.nz/~ihaka/downloads/lexical.pdf)</comment></comment>


Ask HN: Review my web app Availablefordating.com - <AUTHOR>

The idea is to find a partner only when he or she is available for dating.
Basically you post when you're available for dating at a particular day so that others can see your profile and contact you. If you aren't available for dating then you won't be on the search results and won't receive messages from other users.
Any feedback or suggestion on how to improve the site would be appreciated. Thanks!
http://availablefordating.com <comment><USER2> you've got a good domain, and it speaks directly to your description of being available at a certain day/time.

Why isn't that description on your website anywhere?

Particularly in the very popular dating space, you need to set youself apart. you say 'no frills dating' which has absolutely no meaning.

If I've got what you are doing correctly you are doing a 'who else has a free night and wants to go on a date'? that has value. But you have to tell people.

From a design perspective, your orange highlighted items look like links, but they are just highlights, so I'd look into fixing that, and I think you should move the sign-up to another page to give yourself more room to explain why your site is better than the rest.

Also, the problem (if I understand it right) is that most dating sites when they are just starting out don't have enough people on them, so I think you need to make sure you have people looking for dates, or good ways to invite people. You need to make it look like the site has activity and that people are getting dates or looking at the available slots.

Also, that image of the perv grabbing that girl is really bad. I've always been surprised that dating sites use real people in the image rather than a silhouette where the person viewing the page can kinda see themselves in it.

Just my cents.

<comment><AUTHOR> Thanks for your feedback!

"Why isn't that description on your website anywhere?" Will try to add a description.

"you say 'no frills dating' which has absolutely no meaning." Will Reword/remove the "No frills dating". Need to come up with a good line.

"If I've got what you are doing correctly you are doing a 'who else has a free night and wants to go on a date'? that has value. But you have to tell people." Yes, it's basically that. Have a free night/day and put yourself available or look for others available at that time frame.

As for the site activity i'm finding this the hard part to fill in. Still haven't found a way to grab people's attention...

I think that most people want to relate with the ones in the images so dating sites tend to use real people...

Thanks again for your feedback.

</comment></comment><comment><USER3> Maybe it's just me, but I don't think the tag line "no frills dating" will appeal to women. I get what you're going for, but I would try to reword that.

I would also suggest to try a different design for the page as it looks like a template for a dating affiliate site, not an original project.

<comment><AUTHOR> I see what you mean with women... Will reword that so it can relate trust to women. As for the template, i tried to design something that was proven to work. Maybe that wasn't a good idea... Thanks.</comment></comment>


Great Programmers Write Debuggable Code - <AUTHOR> http://henrikwarne.com/2013/05/05/great-programmers-write-debuggable-code/ <comment><USER2> Logging is not a panacea.

It's easy to swamp useful messages in tons of noise, so just logging whatever is not necessarily an improvement. Logging means code, and more code means more work, less readability, and more bugs. In particular, logging somewhere, sometime means I/O, which opens up a whole new class of bugs you'd rather avoid. For instance, I've seen several systems go down simply because the disk space ran out.

Logging is also slow - his example of finding a cheapest path is a good example of this. These are well-studied algorithms that explore huge state spaces. Adding logging as he suggests can easily mean the application's running time is spent almost entirely logging. This might not be an issue: maybe you don't need this very often, or maybe the path's aren't very complex, so you can get away with huge overhead because systems are so fast anyhow. But often as not, you can't. And even when you can, you might be adding a trivial DoS vector for your app, or you might be needlessly limiting its applicablity.

If you have an error, it's nice to log whatever you can to help understand it. But the benefit of understanding the odd error more easily needs to be weighed against the non-trivial costs in time, readability, maintainability, disk space and runtime, particularly if you're pre-emptively logging before an error ever occors.

<comment><USER3> Logging does not mean I/O.

Logging _to disk_ means I/O.

<comment><USER4> Logging means a I/O operation in some way or another to observe the message. If it's not the disk, it's a buffered stream with a syscall and all kinds of slow. Any other magic (using another thread to do the slow stuff, etc) risks the log message getting lost during a crash and the whole thing being useless.

<comment><USER5> You can log to a shared memory segment. You'll need a mutex on it and a writeev call to log to it. And it will survive an application crash.

<comment><USER3> Hell - log to one shared buffer per cpu/thread, and then avoid the mutex.

Apparently when saying logging doesn't require I/O at runtime, you gotta talk it out a lot more before people get it.

</comment></comment></comment></comment></comment><comment><USER6> I'm curious about this whole "have to be contrarian deal." Guy writes blog post which is good advice in 99% of the situations and someone just _has_ to bring up that, yeah, somewhere, sometimes more logging is not necessarily better. Why always nitpick on things?

In my work, if people wrote more and better log messages I would be delighted. They almost never do and instead rely on the Visual Studio debugger to inspect program state. It works great when debugging your own code, but is pretty useless when debugging someone elses code (you dont know where to place the breakpoints) or when analyzing a crash on a production site.

<comment><USER7> The thing is, the article does not say "There are many circumstances where logging is a great tool." Who would object to that?

However, what the article says is "One of the differences between a great programmer and a bad programmer is that a great programmer adds logging and tools that make it easy to debug the program when things fail." In other words, he's more or less explicitly saying people who do not use logging are bad programmers. So it's not at all surprising that there is vocal disagreement.

</comment></comment><comment><USER8> One important aspect of logging is to include enough information when something fails. This sounds like it should be common sense, but I have seen this too many times:

java.net.ConnectionException: Connection refused ...

Why not include at least the hostname and port? And what connection is this exactly that failed? You might be able to find out what it was trying to connect to based on the stack trace, but that requires knowledge of the internal structure of the software.

This seems to be a common problem in software written in Java, I don't know why exactly. Maybe something to do with the way exceptions are handled, so that the relevant information is not available when printing the error?

<comment><AUTHOR> So true! One of my pet peeves! Truly pathetic to not include dynamic info like hostname, port and reason.

Who are these people writing code like that - they never had to debug a problem before? Include as much as you can! A stack trace is only part of the story.

<comment><USER9> Definitely, I often catch exceptions and wrap them just to add more information from the try-finally scope. It is so frequently useful to get a full story of what the app was attempting to do.

</comment></comment></comment><comment><USER10> Logging has its place, but I'd argue it's far more important that great programmers write code that fails _fast_. In his example, he didn't have instrumentation in production to determine why a module was returning null. If null isn't an expected return value, then an exception should be thrown to avoid the system moving forward in a crippled and unpredictable state. A well tested system that stops processing and fails fast with a descriptive exception greatly reduces the need for time-consuming and resource depleting logging systems.

<comment><USER11> Yes but no, in many cases you do not want to fail fast and loudly. If a corner case in a minor module crashes all the pages of your app, you better fail silently, and log.

<comment><AUTHOR> Or at least fail gracefully, by e.g. returning an error code to the caller. Simply crashing isn't always the best choice.

</comment></comment></comment><comment><USER12> 1\. Write code that you think is almost trivial. That way it is simple enough to debug. If you think your implementation gives you bragging rights down the pub, its waaaaay too complicated

2\. log everything, write tools to parse the logs. All this turning logging off / on / up / down. It's disk space, its cheap and trust me when you wanted -vvv debugging, the live server was set to -q

3\. testable code - oh yes, yes, yes. Functions that return common structures that are then sent on not wrapped up for that one specific use you had in mind(my most common crime) . But make it simple. If you cannot throw in a config file and run it there on the command line, then its hopeless. Stubs, dependancy injection - I get it, I just want to avoid it.

4\. Don't do as I do, do as I say :-)

<comment><USER13> _"1. Write code that you think is almost trivial. That way it is simple enough to debug. If you think your implementation gives you bragging rights down the pub, its waaaaay too complicated"_

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan

That said, sometimes cleverness is necessary, or actually serves the goals of making things testable and debuggable.

 _"2. log everything, write tools to parse the logs. All this turning logging off / on / up / down. It's disk space, its cheap and trust me when you wanted -vvv debugging, the live server was set to -q"_

While I tend to agree, it's _not_ (just) disk space - it's IO, which sometimes isn't cheap.

<comment><USER12> Yeah I could not remember who said the Kernighan quote. Should have remembered.

I am not against cleverness, just appropriate for the system - for example _some_ part of the system needs to be very clever else its a pretty mind- numbing project. However the rest of the project should be less clever.

<comment><USER13> Right, any cleverness should be buying you something worth it.

</comment></comment></comment></comment><comment><USER14> Misleading headline alert. All code is debuggable. Logging, mentioned in the article, is more similar to code tracing. It may or may not be useful, because the log might omit information crucial for debugging. There is no way someone can write logging code for every scenario that might break in production.

To me, easily debuggable code (whatever that means) is code written clearly with good documentation. Often well architected systems are modular (rather than a spaghetti mess) and problems are easy to isolate.

</comment><comment><USER15> Forget writing "debuggable code", whatever that is. Normally that's called "code that makes sense" or "code that a human can read", which I'll freely admit is a subset of the kind of code you'll encounter in the real world. It's still what you'd expect a competent programmer to produce.

Write _testable_ code. Each method should have a specific mandate, should specialize, and should delegate additional functions to other methods that follow the same pattern. It should be straightforward to verify that a particular method is working by exercising it according to the various branches it might take.

This is very hard to facilitate with huge methods that try to do too much, there are too many permutations.

</comment><comment><USER16> When speaking about reasons not to log, I have one: What about performance?

If your software is a computer game, for example, you might have dozens of items, characters, and particle effects being tracked by the game engine at a rate of ~60 Hz. That's ~2000 log lines per second, or 160 KB / sec. Steam says I've played 200 hours of Civ5. Where are we going to put 115 GB of logs?

Not to mention the string formatting and I/O of that much logging potentially leading to unacceptable lag.

</comment><comment><USER17> This article is says allot, but shows little.

Ok, write lots of logs everywhere, but how and where should those go? Wont all those messages get in the way? Will they obfuscate my code? Most of the codebases I've worked with didn't have judicious logging, so where should I look for examples?

Spring's source code doesn't look too bad. Is that a good standard?

Maybe other languages?

</comment><comment><USER18> Greater programmers write (unit) testable code? For example using dependency injection.

<comment><USER19> Greater programmers don't cargo cult on abstractions like dependency injection.

<comment><USER20> Greater programmers don't waste key clicks writing snide remarks on HN. They are too busy writing code. ;)

</comment></comment></comment><comment><USER21> It's very hard to think so,our IDE or gcc has already located where we can see the errors.And to write two versions of code is a very annoying thing.To great programmers,source code is enough.

<comment><USER22> This made me smile.

</comment></comment><comment><USER23> Even getting logs is luxury in many cases. I found it better to write 'fail fast' code. Module in that example should fail with reasonable error message, if it was used incorrectly.

<comment><USER11> If your codebase is a bit more complex than hello world, a single helpful error message is hard to do right, because if you have a crash it should mean something unknown happened that you cannot fix at coding time. So it is better, in error messages, to not try to guess what is the problem and just state the wrongful facts. But then only the log and the traceback will help.

No wonder most people just Google error messages.

</comment></comment><comment><USER24> Oh cmon. Why can't programming be just fun. Why this obsession with great programmer and expert coders and the likes. Just pick a problem and hack away. Most importantly, have fun.

Every week I come across at least 10 articles telling people about what makes a great programmer. Sometimes its test code, sometimes its some concoction of agile or xp etc, other times its about functional and oop.

Let it rest guys. Just go and hack.

</comment><comment><USER25> Logging everything != debuggable

</comment><comment><USER26> Logging is nice, but I'd say core dumps and panic screens trump it.</comment>


Guide to Personal Productivity Methods - <AUTHOR> https://blog.todoist.com/2015/11/30/ultimate-guide-personal-productivity-methods/ <comment><USER2> I have read this and several other articles about productivity, focus etc. to find ways out of my own procrastination. I have tried several things to some success and most often failures. I don't know if I will ever win battle against procrastination. I would like to know stories of people who never had this problem. Who can get work done whenever they like. How great would their life be?

PS. Never commented on HN before, so ignore my comment if it breaks rules/guidelines of the site.

<comment><USER3> GTD.

I can't understand why GTD is not anymore trendy (at least in HN) once it is the most efficient system I ever used. Since I implemented it, my life changed. If you ever get curious about GTD, besides reading the original book (Get Things Done by David Allen) you can have a look at my implementation (on my github), it might be a good starting point.

<comment><USER4> I've spent years applying GTD, but at some point I realized that 1) I failed at implementing it more often than not, and 2) it seems optimized for management-type situations, and doesn't work as well for, say, artists or even programmers.

If it works for you, of course that's great! And I think there are tons of individual elements in GTD that are valuable even if the whole system is not applied. But for me it didn't work as a whole, and it's significantly less useful if not applied completely (but also significantly more powerful when it is).

What seems to work best for me is a combination of two approaches:

1\. choosing up to three tasks to focus on per day, usually one major task, and two lesser tasks. 2\. using a simpler list of (usually) smaller or less important tasks for all the stuff that I can't dedicate a day or half-day to. I used Mark Forster's AutoFocus system for this for a while, and now I settled on the 'Final Version' that this evolved into: [http://markforster.squarespace.com/blog/2015/5/21/the- final-...](http://markforster.squarespace.com/blog/2015/5/21/the-final- version-perfected-fvp.html)

I think a crucial part for me is that I need a certain fluidity in my approach. The more complex, 'factory-checklist-like' the system is, the better. The lack of complexity keeps me from constantly fiddling with the system, and the lack of a 'factory-like' approach keeps me from feeling like I'm a robot working through a checklist.

</comment></comment></comment><comment><USER5> This is a really good list, I had not appreciated the subtle distinction been timeboxing and pomodoro before. Here are three more to consider

1\. Meditation - helps focus and mindfulness

2\. Review done list at end of day and make tomorrow's todo list then.

3\. Recognize and manage to constraints: 40 hours of prime work in a week, 8 hours of sleep, healthy diet and regular exercise.

</comment><comment><USER6> Personally I always use articles like this to yet again change my personal to- do-list strategy, select a new fancy app/tool, pay for a year long subscription, start entering all that is on my mind, open it the next day, look at it, and close it.

I know the strategy, I have plenty of apps with an active subscription, but really making it a daily habit is the struggle.

Any thoughts on that?

<comment><USER7> It's really easy (and sometimes fun) to get mired in the "planning" phase of thing. You need to keep that drive when the things get more abstract and you'll eventually find the same drive again.

For instance, choosing a method, that's easy. Doing a bunch of brainstorming and coming up with projects to apply that method too, that's easy (for me). It's that next step, where you're actually designing the infrastructure of the system that's difficult. Suddenly you're getting distracted by things like Operating Systems, web hosting, bandwidth requirements, APIs, etc. And it becomes this huge, abstract project.

It's then that you need to stay focused. Even if you only commit to 20 minutes a day, you'll be surprised how far you get. I find that really it doesn't take that long for me to take an abstract problem and reduce it down to a component I can get up and running now. This reduces the amount of mental overhead I'm juggling drastically and allows me to continue.

It's the same thing at work for me, have you ever had that experience where you finish a feature, and it's time to jump into the next one? And it's almost like you _can 't_ do it. You need to breathe, because you've just been so focused at such a low level on this one feature, and suddenly you have to open your brain up to imagine the _entire_ f#$@ing system again! And you need to connect end points, think about data structures, algorithms, libraries.

Another thing I recommend is trying to get some work done _before_ you go to work. Your mind is pretty refreshed after a good nights rest and a decent breakfast, but much less so after two commutes and a good 8 hours in the office.

Finally, in my area there are a ton of meetups. A lot of these are just hacker hours. You get a bit of social activity and they tend to keep my focused (since who's going to bust out Hulu and toss on Seinfeld at the monthly ViM meetup? There's someone talking about macros up there! MACROS!). I'd recommend finding some of those. The interchange of ideas, and being able to bounce ideas off other practiced programmers is another tangible benefit.

And a free beer and slice of pizza (well never is definitely the wrong word here...) never hurt anyone.

</comment></comment><comment><USER8> This is a good summary / refresher and worth a read, even if you're familiar with most of the productivity methodologies out there. I didn't know the Eisenhower Matrix had a specific name.

Not linked in the article (but worth a plug IMO) is the Mac app Vitamin-R [1]. I've started using it again lately and I'm finding it useful. It combines several of the methodologies in the article: Pomodoro, Time Boxing and Biological Prime Time. With the latter, after each pomodoro Vitamin-R asks whether you were in flow or felt distracted - over time it generates a graph of your peak productivity times & days of the week.

[1] [http://www.publicspace.net/Vitamin-R/](http://www.publicspace.net/Vitamin-R/)

</comment><comment><USER9> Why is every productivity/procrastination article so damn long? All I do is open it, see the length, add to Pocket, never read. The irony is strong.

<comment><USER10> Especially so when the answer should be a list, and simple lists are something almost everyone can use effectively to get things done.

If you're getting paid by the word and feel that a long article is more impressive, you won't write a short list!

Shame they're such a chore to read.

</comment></comment><comment><USER11> My biggest problem with these list making solutions are what I call the collateral tasks. For example, my list says "Buy a Christmas gift for Jen".

When I start shopping online, I realize that I don't know much about Jen, so I need to call a friend. Lots of discussion later, I finalize on something to buy then I need to think of a personal note to write.

At the checkout, my banking application tells me that my internet password needs to be changed. The whole process gets aborted!

Probably, I exaggerated a little but my point being that each task involves a million micro steps which may or may not be anticipated. No wonder there is a lot of procrastination!

<comment><USER12> Spot on. We see this a lot in coding activities. Many tasks are usually more complicated than for example "import this file into database, use the imported data to produce the histogram" ... there's bound to be plenty of "collateral" shyte en route. Non-programmers don't usually understand this.

So how to overcome this?

There's no other way than to cognitively "bring to front" the end goal every time you hit a task hurdle that threatens your concentration or that lets you succumb to distraction. But it takes practice to learn that you are in the process of beginning the "shirk move" ... watch out for this. Can you blame yourself when all you've done your whole life subconsciously toggle to other tasks when the going gets tough. Blame evolution for this.

So two things:

1\. Know upfront the discrete sub-task/destination you are hoping to achieve for a given finite stretch of time, achieve it and call it the day; and

2\. Kak on yourself solid! for being distracted during a tough spell ... speak it out to yourself by enunciating that you are being distracted, mofo. If someone else is doing the disturbing, find a quiet place next time. (Working with kids in the house can be painful).

That's why I am here!

</comment></comment><comment><USER13> This seems to be perpetuate the notion of learning styles (in the guise of "working style"), which has been debunked.

<comment><USER14> Really? Where/when was this debunked and in what way? Because anecdotally and subjectively, more visually-based approaches work better for me...

<comment><USER15> Google might help

<comment><USER14> All I can see that was debunked is "Learning styles" specifically in an educational environment, i.e. the goal being acquiring knowledge & skills. [https://en.wikipedia.org/wiki/Learning_styles](https://en.wikipedia.org/wiki/Learning_styles)

That surely is something totally different when it comes to productivity, isn't it? I am far more motivated to do things "my way", in my own preferred style of working than any other way.

</comment></comment></comment></comment><comment><USER16> The best productivity method is to just go do what you have to do and spend all the time doing it. Every thing else in the name of a productivity method is an excuse for your mind to stay off from what you really have to do.

</comment><comment><USER14> I like the distinction of more "visual" or more "tactile" minded people. I'm more a visual guy and the long lists in most todo solutions always felt overwhelming. So I went and wrote my own iPad app to help me keep a simple & fast personal Kanban, as well as for visual thinking & organizing. Turns out other people like it as well...

[https://itunes.apple.com/us/app/mindscope-mind-mapping- outli...](https://itunes.apple.com/us/app/mindscope-mind-mapping- outliner/id901513028?mt=8)

<comment><USER17> This looks like a good balance of usability and functionality. The minimalist tutorial videos were helpful.

I have used inShort, iThoughts and MagicalPad for mindmap-like issue tracking on iOS. Glad to see that arbitrary cross-branch links are possible, to supplement the tree hierarchy.

Do you plan to support iOS9 multi-tasking, web hyperlinks and iOS deep-linking into other apps and their extensions?

<comment><USER14> Thanks! Definitely plan on all of those at some point, but development has been slow since this is a weekends and evenings project and I'm currently swamped with the final stages of a house building project gone sideways... can't wait to get back to tinkering with it, especially since I've gotten tons of people telling me how useful it's become for them.

<comment><USER17> Looking forward to enhancements as your time permits. Four requests for your list:

\- An App Setting to disable animation (it can be disorienting)

\- After navigating a cross-link, provide either a back button, or multiple breadcrumb trails in the navbar, when there are multiple "parents" or inbound paths. On Android, NoteLynX Pro supports cross-references / multiple parents, [http://astrodean.blogspot.com](http://astrodean.blogspot.com). This is a valuable feature that few apps attempt, so thanks for including internal cross-ref links. With the new "Back to App" feature in iOS9, cross-app hyperlink support would enable use of Mindscope as a contextual launcher.

\- Keyboard support, e.g. Delete to go back (cross-link) or up one level in the navigation hierarchy, hotkeys (e.g. Cmd-H for home, Cmd-W to "close" a sub-task and go up one level in the navigation hierarchy), Cmd-N to create a new entry centered in available whitespace. Mobile Safari supports similar key combos. Especially useful on iPad Pro.

\- For sync, please consider open-standard CalDav

</comment></comment></comment></comment><comment><USER18> This is great. I have a huge problem with starting projects and just dropping them. I haven't been able to figure out why I simply stop working on them and jump to the next thing but maybe this will help me get back on track.

</comment><comment><USER19> Way to go todois ;-)</comment>


Could the Hyperloop Really Cost $6 Billion? Critics Say No - <AUTHOR> http://bits.blogs.nytimes.com/2013/08/15/could-the-hyperloop-really-cost-6-billion-critics-say-no/

<comment><USER2> _Michael L. Anderson, an associate professor of agricultural and resource economics at the University of California, Berkeley, predicted that the cost of the entire project would be closer to $100 billion._

Keeping the same assumptions as the paper [1], if the cost goes from $6 billion to $100 billion, the amortized cost per ticket goes from $20 to $333 (!). As pointed out elsewhere [2], the capacity is extremely low, less than 1/10th that of the high-speed rail proposal (7.4 million vs. 95 million riders annually).

[1] [http://www.spacex.com/sites/spacex/files/hyperloop_alpha-201...](http://www.spacex.com/sites/spacex/files/hyperloop_alpha-20130812.pdf)

[2] [http://pedestrianobservations.wordpress.com/2013/08/13/loopy...](http://pedestrianobservations.wordpress.com/2013/08/13/loopy- ideas-are-fine-if-youre-an-entrepreneur/)</comment>


Things Rust doesn't let you do - <AUTHOR> https://medium.com/@GolDDranks/things-rust-doesnt-let-you-do-draft-f596a3c740a5 <comment><AUTHOR> This is my (possibly a bit too) long form blog-post/survey on the current limitations of the Rust borrow checker and mutability system as I perceive them.

It might be a bit too detail-oriented for non-Rust specific audience, but as Rust is gaining traction fast and in the same time there is the perception that it's strict/unforgiving, this list of the "limitations" and workarounds might be an interesting read for some.

<comment><USER2> This post lets me understand Rust's quirks much better than all the documentation explaining what Rust _can_ do. Something as detailed like that should be added as a section/FAQ to the Rust Book.

<comment><AUTHOR> I intented it to read as something FAQ-like, but as it contains some information that is likely to be outdated soon-ish, I don't think it's suitable for the official docs as-is.

I'd love to see some similar kind of effort in documenting common struggles and workarounds in the offical docs though! I think that many people are having similar kind of struggles, and explaining properly and thoroughly "why X is hard to do with current Rust" might help some light bulbs go off.</comment></comment></comment>


Edbert, 10, Excels at Cursive. Should Other Students Follow His Lead? - <AUTHOR> https://www.nytimes.com/2019/12/17/nyregion/cursive-writing-nj.html <comment><USER2> Considering a fact that cursive doesnt have a monopoly on methods of unique identification, its an obvious no, literally no need to standardized a secondary form of penmanship and characters in 2020

<comment><AUTHOR> Here are some of the arguments for and against: [https://www.edutopia.org/article/what-we-lose-with- decline-c...](https://www.edutopia.org/article/what-we-lose-with-decline- cursive-tom-berger)</comment></comment>