The Black Hole of Software Engineering Research - <AUTHOR> http://blogs.uw.edu/ajko/2015/10/05/the-black-hole-of-software-engineering-research/ <comment><USER2> The main problem is that "software engineering" is a code name for "software management".

If you major in "mechanical engineering", you will take courses in calculus, linear algebra, probability, computer programming, physics (thermodynamics, mechanics, electrodynamics, strength of materials, maybe aerodynamics and viscous flow), control theory (what used to be called "cybernetics"), manufacturing techniques, CAD, and maybe a management course or two.

The corresponding curriculum for software involves things like programming languages, algorithms, data structures, networking, operating systems, software architecture, and formal methods, and it is called "computer science". What is currently called "software engineering" is the software equivalent of "art appreciation". It's a desperate attempt by the cult of managerialism that dominated that 20th century to figure out how to run software projects without understanding software itself; it's an attempt to substitute credentials and command structures for intellectual mastery of the problems to be solved and understanding of the techniques for solving them.

The consequences, generally, are what you'd expect from a book publisher run by illiterates or a record label run by Deaf people. Experian and CGI Federal wasted hundreds of dollars building a "healthcare.gov" site that didn't work; SAIC wasted hundreds of millions of dollars on building a Virtual Case File system that was ultimately scrapped. These are the companies that represent the approach known as "software engineering", that get CMM certifications from the SEI.

By contrast, the companies that make software you actually use — companies like Canonical, Google, Facebook, and Apple — put a great deal of emphasis on _programming, motherfucker_ , and very little on things like SDLC, requirements engineering, and "formal" specifications.

This is not to say that the issues that "software engineering" attempts to tackle — like testing, requirements analysis, and software architecture — are unimportant. They are very important. But the field that identifies itself as "software engineering" is in fact failing to tackle those issues. It is not where the insights are coming from. They're coming from _programmers_ and _computer scientists_.

<comment><USER3> All good points. "software engineering" is how we take raw code and turn it into reliable systems.

The worst code you'll ever see written is by computer science PhDs who just have to _get something done_ for their research paper experiments. It'll be 6,000 lines of matlab with no loops, no functions, and entire 30 line sections just get copy/pasted when they need to repeat an action.

That's code without software engineering. That's "coding" and not "developing."

In a way, software engineering is a moving goalpost in the same way as "if a computer can do it now, it's not AI." Many of our standard practices these days used to be "must be considered separately" software engineering practices 10 years ago (revision control, proper documentation, creating libraries, etc).

Open Source projects run by communities with a focus towards testing, documentation, and maintainability are the best thing to happen to software engineering. But, there are still crazy people running around writing code just for themselves and refusing to realize software is more than _code code code_ these days.

We pretty much need two divisions here: "software engineering (social)" and "software engineering (technical)". Social software engineering is defined by well maintained, long-lived, multi-contributor software projects. Technical software engineering is the implementation of the testing systems and contribution systems behind those long lived sustainable projects (e.g. are you calculating the branch coverage of your unit tests? do you even have unit tests? (no, testing your live servers aren't "unit" tests, those are integration tests) are you testing all combinations of acceptable and invalid inputs (null, proper value, invalid value, out of range value positive, out of range value negative, ...)? are your systems even _testable_ and not bound to side-effect laden global states? do you have proper mock objects to compensate for your side-effect driven development? do you allow outside contributions so you don't have to maintain all 60 of these detailed testing and failure scenarios yourself?).

(there's also the entire other branch of "how to be a better software writer through requirements gathering and agile/lean/XP/monkeypants practices," but that's out of scope here.)

<comment><USER2> Revision control, proper documentation, creating libraries, use of high-level languages, were common practice at Bell Labs ("programming, motherfucker") in the 1970s, and alien to "software engineering"-driven groups like Computer Sciences Corporation (CMM Level 5!) and Harlan Mills's group at IBM. What we usually call "unit tests" these days, and certainly "mock objects", came from Extreme Programming, which is a _reaction against_ the "software engineering" managerialism cult.

I agree with you that those things are how you take raw code and turn it into reliable systems, and that you don't get there by copying and pasting code and writing 6000-line functions. But this article is not promoting those things. It's promoting formalized process engineering.

(However, in my book, using very-high-level languages like Matlab (or, better, Octave or Numpy), and high-level operations like matrix-multiply instead of explicit loops, are best practices.)

I do agree that social practices around effectively collaborating with other people are very important and require a lot of effort. You can have the world's most effective hackers on your project, but if they're wasting their time because you don't have a budget for a test server or because they're not allowed to fix the bugs they find, your productivity is still going to be low.

<comment><USER4> I totally agree about the process junkies ignoring good stuff and pushing their religion under banner of software engineering. They're the posers who weakened the term. The Bell Labs people were real, software engineers both experimenting and building on proven methods. Also...

"What we usually call "unit tests" these days, and certainly "mock objects""

That's not true. Like other assurance activities, Extreme Programming just did what was already done, gave it a new name, mixed it with bullshit (esp pair programming), and got it some needed attention. The Orange Book testing criteria, in 1983, required as much testing as resources allowed of primitives, their compositions, all interfaces, and common failure conditions. That's on top of specifications, covert channel analysis, pen testing, using only proven components, build system automation, etc that far exceed XP's quality regiment.

Funny you mention Cleanroom because it was first thing I thought of when I heard the "new" Agile approach. Iterative development, code reviews, usage- based testing for acceptance, verifying each module... Cleanroom had all that. At least they eventually figured it out and it seems competitors in Agile identified XP's problems as well. Although old, I'm glad the concepts are mainstreaming because it gave us something important: solid, well-maintained, constantly-updated TOOLS to support the efforts. :)

<comment><USER2> You're missing the point. XP testing isn't an assurance activity.

XP "unit testing" isn't what's called "unit testing" in the software engineering literature, and it isn't designed to reduce bugs; it's an executable functional spec, and the reason you write the tests first is so that you don't end up designing some monstrosity of an interface whose clumsiness becomes contagious to everything that calls it. "Mock objects" are a particular way of writing those tests in which your testing stub objects actively validate that they're being invoked the way you expect, rather than just passively simulating the subsystem being stubbed out.

Orange Book testing, by contrast, is aimed at reducing bugs.

XP-style test-first unit testing is not the best way to develop all software, but it works pretty well for some things. Similarly for pair programming: it can help a lot with intra-team communication, code reviewing, and not getting stuck, but I'm pretty sure there are projects where working alone and doing the code review later is a better practice.

Yes, Cleanroom has a lot in common with XP.

I think that a lot of the "competitors in Agile" actually suffer from the same disease I'm blasting here: they try to solve technical problems with management practices, and consequently you have a lot of Scrum teams with really shitty code who can't make much progress because they're beginning programmers, or experienced programmers who have fallen into bad practices.

<comment><USER4> Another I agreed with almost entirely. Hell yeah!

Yes, I read on unit testing and XP with its other goal. Most of what the crowd pushes it for is the benefit of catching defects usually with requirements, dependencies, or breaks from later changes. Old projects used testing for those reasons, too, although not as consistently.

I'd say the real difference are greater focus on mock-ups and documentation focus as you said. Other than that, the techniques are similar and more ad hoc than before. Just getting more attention and use. Still A Good Thing.

"I think that a lot of the "competitors in Agile" actually suffer from the same disease I'm blasting here: they try to solve technical problems with management practices, "

Totally agree. This is a bad sign any time we see it. The focus should always be on getting the right people in there, making sure they have good tools/methods, and letting them get shit done. That's development or engineering. Documentation, etc really just becomes evidence of what was done and an aid for further development/maintenance.

I'll add that I think there's a zealot kind of thing going on. They blasted me years ago with all of the stuff like it's better while not providing any empirical evidence showing it was. Some evidence appeared around testing, etc and Spiral already proved incremental approach would help. Much of it had nothing but some people's word to back it. Pair Programming even countered years of evidence about effects of interruptions on flow.

So, I think it would help if they or the next group focuses on controlled studies pitting methods against each other on similar projects with objective and subjective accounts of results. Then, we'll have a better handle on what works and where. Right now, I have to rely on little empirical data and mostly just take the word of the experienced people delivering best results for given domains. Gotta get programming a bit more scientific in industry.

</comment></comment></comment></comment></comment></comment><comment><USER5> I was always interested in Econ / Applied-Math research as an undergrad and would build toy models in those areas. When I graduated, I went to work at a financial company before coming back to study theory again 3 years later.

The immersion in industry was absolutely critical for me to see 1. what was actually needed in the real world, 2. what types of assumptions can be made about the predictability of large economic systems.

If I had gone to grad school right away, I think I would have followed several ill-advised models down way too deep. So, I'd say at least one year in a real role in the industry you hope to contribute is really essential for someone planning to do applied/translational research.

</comment><comment><USER6> > working as a [professional] for the past three years

That doesn't seem like a great deal of experience to me.

Off the top of my head I can only think of one or two professors with distinguished professional careers who are principally focused on engineering, rather than computer science. Maybe there's a list somewhere?

</comment><comment><USER7> One of the first things I noticed out of school was that most projects prefer not using formal methodologies for building software. A lot of the projects that do, tend to focus on applying methodologies more rigorously than the actual goal of the software. I've seen problems with both.

I think what some people miss about having a formal methodology is that a lot of time can end up being wasted addressing the same types of issues (design problems, bugs, re-implementing things, multiple requirements changes, etc...). The same can actually be true with applying methodologies too rigorously though.

The most effective software development I've seen tends to be where the culture values both quality and time spent. If something can improve quality and reduce the amount of time spent on boring tasks, it generally doesn't take much convincing there.

I think in a lot of ways, a lack of focus on software engineering isn't necessarily an academic problem. It can end in some fairly bad results though, like the Knight Capital incident ([https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...](https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption)), so obviously there can be a very tangible impact.

</comment><comment><USER8> One thing I wish he'd stressed more: there's almost always a big gap between the research that's published (and any software used to produce it) and being useful in a team's real-world environments. For software engineering tools, for example, researchers tend not to put a lot of time into instalability, integration into teams' toolchains and processes, usability, or clarity of error messages ... to say nothing of performance and scalability -- you don't need any of those things to publish the paper.

Of course there are exceptions, and I don't mean this as a criticism of the researchers. It's just that there's a lot of work involved in "tech transfer", and it's often hard to justify the investment -- especially for a relatively- small team. Microsoft and Google and Facebook all have plenty of people doing various forms of "applied research" to bridging that gap; but they've got the resources to do it.

</comment><comment><USER9> Sometimes I feel that software engineering is really three separate disciplines: ergonomics, type theory, and sociology.

<comment><USER10> And complexity management.

</comment></comment><comment><USER11> The very idea that computer science is called a "science" is a reason why software engineering is not taken seriously.

<comment><USER12> To my knowledge true computer science is essentially a very narrow focus of higher mathematics.

<comment><USER13> Not so narrow. I'd say it may contain all mathematics that is computable, which is a rather big subset. Essentially all constructive mathematics.

That's a lot of stuff. For example, probabilistic programming is concerned with all computable distributions. This is the most general class of sampleable distributions.

<comment><USER14> Narrow in a sense that it's one specific angle to view math problems. But the range of problems is indeed great; hell, parts of computer science have or may have direct relation to how we view reality itself.

<comment><USER15> It really isn't narrow. Mathematics, philosophy and computer science are just three different ways of viewing the same problems.

</comment></comment></comment></comment></comment><comment><USER16> I'm not sure I agree with what he's saying. I've been looking over the shoulder of my brother's CS degree at Columbia, and although there's a lot of theory, there's also a huge amount of practice.

They've been introduced a huge variety of tools: vim, Git, valgrind, tmux and so on. A variety of languages: HTML/CSS/js, C, Java, oCaml. Platforms: Linux, windows, Android.

A lot of the stuff seems incidental. If you're going to mess with the Linux kernel, you need to understand C, you need some Linux CLI commands, and you'll end up learning a bunch of other things as well. You end up spending a lot of time debugging, profiling, etc, basically what anyone does when they're programming.

They also seem to learn at least the basics of how to write programs as part of a team. Code merges, planning things together, bits of scrum.

<comment><USER2> I don't think the article is complaining that programmers don't know how to program or use version control; it's complaining that they don't know "software engineering", which is being used as a code word for "software management by managerialism".

</comment></comment><comment><USER17> What we call "Computer Science" is the discrete analogue of differential equations. It has absolutely nothing to do with software engineering. CS programs don't teach software engineering, which can be thought of as "how to design, build, grow, and maintain an effective software system in a team environment." Since most Universities prioritize research faculty over teaching faculty, software engineering skills are generally undeveloped in fresh college graduates, and tend to be passed along by mentors and senior engineers in software teams to junior engineers.

Shy of Universities hiring prominent open source software developers to serve as part-time teaching faculty, I don't know how we could push the transfer of these skills into the university setting and expose students to this knowledge at an earlier age.

</comment><comment><USER18> Can someone provide for me a path for keeping up with specifically software engineering research? As a guy whose title is literally "software engineer", I'd like to know what the PhDs in my field are up to.

<comment><AUTHOR> One suggestion would be to check what papers come out of the top-tier SE conferences each year (e.g., ICSE and FSE). However, this is time consuming since the topics range widely and each paper takes some effort to get into.

<comment><USER19> i easily read papers from journals on other fields. there is nothing for SE that is open and broad.

</comment></comment></comment><comment><USER4> Glad ajko is at least attempting something. This is one of the meme's I've been posting on for years. I think the problem is different, though. So much wisdom and so many capabilities are in papers, sometimes software, created in academia. However, nobody knows they exist. Coursework isn't the reason. The reason seems to be two-fold: (a) the main sources for all of it are pay-walled ACM and IEEE that professionals never use; (b) the non-paywalled links are scattered across the web in University sites instead of one or more central, organized sources for such information. These problems _must_ be solved somehow because the opportunity cost is gigantic.

I try to get this info to people by pulling batches of papers, skimming them, finding the worthwhile stuff, and mentioning it in online forums or to specific people in projects. I have over 10,000 papers in my collection from ACM/IEEE that were organized at some point (sighs). Anyway, when a topic comes up, I can just search them and (surprise!) many modern problems have already been solved. People just aren't applying the solutions when they know about them and more often just don't know about them.

So, the second one was my idea. A resource, crowd or taxpayer-funded, that's essentially an organized encyclopedia of papers and software developed in academia pertitent to aspects of software development. It would start as a manual effort that pulls in the links and paper that represent the best of most topics. As it got buy-in, the professors might have their students categorize and submit their own stuff. I thought an invite-only forum for serendipidous discussion among people that know their shit (esp researchers, professors, industry vets) could also get ideas across. Might be a fee for all of this charged to users, universities, someone that's way cheaper than ACM/IEEE. Basically, enough to cover the servers, bandwidth, and at least one employee.

Ran it by Epstein at NSF. He thought it was a nice idea but wisely warned it might not take off at all without buy-in ahead of time. The buy-in would have to come from a ton of places, too. So, bootstrapping that might be tricky. Even worse, many people I talked to in academia indicate the people and organizations on that side don't care about practical things at all. The ones that do are an exception and the norm actually filters out that stuff in favor of publishing/citations.

Well, we could hit it from the other side. Closest thing I've seen from industry was Dr Dobbs with articles on Cleanroom, Design-by-Contract, etc. Many professionals read that and could get exposed to cutting-edge via practical treatments from a trusted source. Additionally, the likes of Microsoft, IBM, Google, and Facebook do the cutting-edge academia and practical stuff simultaneously while publishing some and deploying others. This brings attention to it. Some results at these companies got widely deployed and are standard fare today.

So, I'd say the easiest route is a hybrid between companies and the nonprofit concept. Anyone wanting to try it can look at the kind of stuff companies are working on. Package up the cutting-edge stuff for those things to make it the first deliverable of the site. Add in plenty of IT and INFOSEC stuff on top of that which has immediate value for them. Get those companies as members to sponsor the initial development. Simultaneously, try to get University groups on the bandwagon who operate in key areas of IT or INFOSEC where the research results need attention. For big ones, maybe let them pay to have a dedicate person doing nothing but pulling in and curating their research as a brand boost for them. The site/service should grow in both usage and material as businesses pull on it for info while Universities push theirs into it.

Outside an effort like this, I'm not sure how else we're going to bridge the gap between academia and industry in a major way.

<comment><USER20> _(a) the main sources for all of it are pay-walled ACM and IEEE that professionals never use_

Balking at the $200/year ACM cost wouldn't signal to me that you're a professional (in the First World, then again, they have Developing World discounts). IEEE, though, is $40/month for 25 articles with a max of 10 unused carrying over to the next month, $17/month for a "Basic" level of only 3. Plus membership; that's prohibitive.

<comment><USER21> I was looking at renewing my IEEE membership yesterday to get article access... Naively I assumed the THREE articles per month level was included in regular membership dues. What a racket :/

<comment><USER4> I didn't even know about the limit until he said something. My University had no limit in their proxy: I pulled over 10,000 papers from it sometimes 50-100 a night. :O Wonder what they pay.

Anyway, might help to get affiliated with a University or enlist the help of a student. ;)

</comment></comment></comment></comment><comment><USER22> Every genius makes it more complicated.

It takes a super-genius to make is simpler.

<comment><USER4> What's complicated? There's all these problems in industry that allegedly need solving, improving, etc. There's all kinds of academic work that solved a lot of that, sometimes with industry, case studies. One doesn't make it to the other and often vice versa. Why is that? How to solve it?

Sounds like an inherently complicated situation given all the parties, differing incentives, and legalities involved. I made an attempt in another post but not sure what will work.

</comment></comment><comment><USER23> Software Engineering is an oxymoron. If it weren't, professionals in the field would be held accountable when projects go belly up, and they would be required to be licensed to practice. Since there is no real understanding of what that "engineering" is, there can't be a body of standards to which qualify and license. Software Engineering is the only profession I know of that requires no formal training, no license, and has pretty much zero liability.

<comment><USER24> There are areas of software development that do operate more like traditional engineering, such as in avionics software development.

For example, software developed for commercial avionics systems in the United States follows the guidelines in DO-178C:

[https://en.wikipedia.org/wiki/DO-178C](https://en.wikipedia.org/wiki/DO-178C)

Every stage of development from writing requirements to coding to verification to selection and usage of tools (including compilers and operating systems) is reviewed across a mixture of internal reviews and external audits. There's an extensive paper trail with each subsystem (i.e., software + hardware unit) being tested and enduring a certification process before being released to the public.

So while the _engineers_ on these projects aren't licensed, the development processes and the resulting software are examined and signed off on.

Does that count for software engineering? I think it does. The next interesting question, in my opinion, is, if that counts as software engineering, then what aspect could we take away or relax, and still have software engineering? Is there a graduated spectrum of software engineering? Or is there a hard cut-off point, where we can say, "yes, this is engineering, but that isn't"?

<comment><USER23> That seems to be the exception. Practically everywhere you look it is like someone else pointed out "mf* programming".

<comment><USER24> It is indeed an exception. But it demonstrates that software engineering does exist, and it suggests that more software could be "engineered", if we chose to do so.

I suspect that reason that such engineering process isn't applied to more software is that we don't really care that much. Are we willing to accept a 10x, or 100x, increase in development time and cost in order to have a more robust iPhone game? Word processor? To-do list?

Which is why I'm interested in the question, what can we take away or relax from avionics-style software development to bring better "engineering" practices to other areas of software? Maybe a 2x increase in time and cost would be acceptable...</comment></comment></comment></comment>


Ask HN: Why not build a library that scrapes Twitter's DOM into our own API? - <AUTHOR>

OK, so there are multiple things to consider here:
1) Users provide all content to Twitter. Without the users, Twitter is nothing.
2) If users cannot use their favorite clients, then what is Twitter if they're restricting the free-flow of content that generates this so-called "firehose"?
3) Twitter's content is not particularly challenging to analyze. The fact that it is 140 characters of text should make it fairly scrapable.
<comment></comment><comment>---
Strategies:
a] Depending on what the developer wants, there are multiple approaches. The first would be using cloud instances or even the third-party Twitter clients themselves to distributively spider or scrape Twitter constantly and provide a third-party "stream" or unofficial index.
b] If it's just the user's timeline the client wants to access, this can just be done through any HTTP connection as long as the library is up-to-date enough to properly decode the HTML and DOM elements into the previously readily available JSON elements.
Although the API is a convenience, it almost seems like a non-issue to access content that is publicly available or available when the user logs in if the user is willing to hand over their credentials. I agree it's a nuisance, but for read only access it shouldn't be terribly difficult to accomplish, and for write access it'd be even easier given it's HTTP POST and AJAX calls.
Why not build a replacement "API"? </comment><comment><USER2> > Why not build a replacement "API"?

Because what you're suggesting is entirely illegal, and playing with Twitter is not worth going to court and bankrupting yourself over.

It's not just civil either. Remember the woman that made a fake MySpace profile to instigate a girl to commit suicide? She was successfully convicted under the federal computer crimes laws; once you violate a site's terms, your use becomes unauthorized access to a computer system.</comment>


Tesla Employee #7 Has Built a $1B Business That Make Batteries Run Longer - <AUTHOR> https://www.forbes.com/sites/alejandrocremades/2019/07/28/he-was-employee-number-7-at-tesla-and-now-has-built-a-1-billion-business-that-makes-your-phone-or-car-run-longer/ <comment><USER2> TL;DR:

20% energy density increase by replacing the graphite powder.

(Rant excerpt: Holy shit, this article is fluffy)</comment>


Ask HN: I'm bored. What's something you wanted coded up? - <AUTHOR> Ask, and I may just make it real. <comment><USER2> Do something like this, but actually working:

      https://github.com/justinclift/EventsMap

So a person can see what events are happening in a specific area, in a given time range. It should be:

      * Visual, using a map service background like the above
      * Have time range slider (indicting start and stop of time range)
      * Use the public data sets of conference/events.  There are a few around that show
        up with simple searching:
          * O'Reillys has this: https://feeds.feedburner.com/oreilly/events
          * Red Hat has this: https://github.com/OSAS/rh-events
          * Eventbrite likely has relevant feeds too (lots of data)

For a revenue source, you could look at adding planning capabilities into it, direct booking, and reminders. Potentially also group bookings, and/or fees for usage.

For companies that want to send X number of devs to conferences over the next 6-12 months, having a good system to know which ones to go to, and accurately track/remind/etc people... is worth money.

Maybe not super rich quantities... but it's unlikely negligable either. :)

</comment><comment><USER3> Topic map engine that is usable in a database fashion and doesn't depend on some memory hog (no JVM, no MongoDB, no MySQL or PostgreSQL).

<comment><USER2> SQLite suitable?

<comment><USER3> This one yes, very suitable.

</comment></comment></comment><comment><USER2> Any chance this is your kind of thing?

      https://news.ycombinator.com/item?id=11093339

</comment><comment><USER4> create an app that allows me to find out what fun, interesting events are happening locally in the next few hours - days. Let me filter by my interests and distance. Make intelligent suggestions based upon artificial intelligence.</comment>


Ask HN: Is it too late to get into (invest in) Bitcoins? - <AUTHOR> I kind of get the concept behind bitcoins and I know it's been around for a long time.  Is it too late to get into it as an investment? <comment><USER2> I don't think it's too late, but crypto currencies are far too volatile in my opinion.

E.g when ethereum plummeted to 10 cents it was ideal to buy, but you have to have you ear to the ground.

What if the upcoming bitcoin fork will drive the price of 1 btc to 200k usd? what if to 5 cents? what if those values won't change for the next 2 years?

I won't be able to sleep at night knowing I have a lot of money invested in a volatile asset like this.</comment>


Post-Open Source - <AUTHOR> https://www.boringcactus.com/2020/08/13/post-open-source.html <comment><USER2> Don't even know where to start here. First of all, another fight about Free Software and Open Source. The licenses are the same. There's no point in arguing about why people put code under those licenses, whether because of freedom or practical reasons. For most people it's probably both.

Why is open source dead? Because mozilla layed of a bunch of people? If only their code where open source, so that everyone else could keep working on the projects they were working on. Because github makes money? And is closed source? The writing about that is particularly revealing. "if they believed open source was in principle better, they'd be open source themselves." See, there are two alternatives: Either they really believe in open source, or they see open source is something suckers do that they profit from. But in fact github open sourced plenty of important code, like the ruby git library. Thanks. Maybe it's not a dichotomy, not something that you "really believe in" or not?

It's possible today, both on desktop and on a smartphone, to run a fully open source OS. That's a huge victory by itself, and also makes those still using closed systems freer by putting a limit on what the corportaions running them can get away with.

The author dismisses any kind of open source that isn't on a sacred crusade against closed source software as corporate friendly, lacking idealism. But I think that even if there are several closed systems based on open source competing (like a lot of closed source browsers based on an open source rendering engine) that's much better then having just one closed source browser.

So yes, open source really does make people more free, partly by making it possible for dedicated people to run a fully open source system and browser, partly by increasing competition.

<comment><USER3> It is not possible to run an open source OS for a broader definition of OS on almost any hardware out there.

You can run parts of an open source kernel and maybe open source user space. But forget about fully open drivers (binary blobs rule), especially remember resident platform blobs like Intel ME. The remaining exceptions are librem and some hacked thinkpads or chromebooks equipped with coreboot.

And let's not ignore the fact that most cellphones are locked up or have hardware without sane drivers, only ones provided in binary form. Not to mention the kernel running on the DSP to handle modem. Or other things.

Even higher level, just Android, try running its applications without Google proprietary services. While there is a reverse engineered version, it always plays catch up...

<comment><USER4> Lineage OS works like a charm without google play services. I haven't used those services in years.

</comment></comment></comment><comment><USER5> > i'd say free software died a while ago, and open source went horribly right.

It's rather the opposite. It's a slow grind, but slowly more free software is at the basis of things, due to its license nature and it growing more mature. At the same time I think the failure of open source software (if you can call it that ) was predictable and predicted long ago.

I am not sure you can call it a failure of open source, if open source never made sure, that some ideals are followed when using open source software. Perhaps we can talk about ideals and ideas in people's heads and what they thought open source was.

<comment><USER6> I would go one step further and say that among the mentioned post-open source alternatives, free licenses are the most mature, legally sound and promising candidates to fight corporate exploitation of developers.

</comment></comment><comment><USER7> The article seems to gloss right past Free Software and copyleft licenses based on the claim that some copyleft licenses like GPLv3 aren't widespread because companies don't like and won't use them, then proceeds to opine on what license terms best annoy companies (profanity, ambiguity, lack of licensing, etc). And yet there's no consideration given to actually using copyleft licenses like GPLv3 or GPLv2, just the repeated assertion of the death of "Free Software".

If a copyleft license is sufficiently strong that some people don't want to use it under those terms, some subset of those people may be willing to pay for an alternate license. (The set of people who wouldn't pay for an alternative to a copyleft license seem even less likely to consider any completely non-standard incompatible-with-the-universe license.) If you want to use a license that may potentially lose you a few over-cautious corporate users, but which protects a community of users and the possibility of revenue, a copyleft license like GPLv3 or GPLv2 may make sense.

Many of the people using permissive licenses don't work for companies, or otherwise don't have anything that might block them from using a copyleft license. Many people seem to worry about using a copyleft license because it might mean some people can't or won't use the software. I've even seen companies who would actually benefit from a copyleft license just not-think about the possibility of using one because they have a vague impression that Apache or MIT is what they _should_ use. It wasn't that they considered and dismissed copyleft; they just didn't even think about the possibility and weigh it as a potential option.

(Also, last time I saw a survey of licenses on popular software repositories, GPLv3 was about as popular as GPLv2. LLVM vs GCC is a relevant and memorable problem, but those two projects hardly represent the whole landscape of software licensing. LLVM also gained popularity for reasons beyond just licensing, such as recognizing the value of extensibility and providing compiler framework libraries, much sooner than GCC did.)

I'm not going to say "use copyleft for everything!", and there _are_ good reasons to use permissive licenses (such as propagating standards or releasing tiny projects). But next time you're releasing a project, give it some actual consideration. If you _want_ to release something under a permissive license, and that's a deliberate decision, by all means do so; but don't just do so "by default" without thinking about it, and without thinking whether the permissive-by-default culture is actually in your best interests.

</comment><comment><USER3> I don't agree with characterization of Mozilla seeking profit over impact.

It's literally being destroyed by Chrome and Chromium derived browsers, with Google now in almost the same position as Microsoft used to be, and Firefox market share falling to single digits. They can barely fund operations because of that.

It seems that FOSS ran by a small foundation cannot compete with open source ran by one of the biggest corporations in the world. Which has nothing to do with it being free software or not.

</comment><comment><USER8> To me, the intent of open-source, free, whatever, is simply that " _my_ computer should do _my_ bidding, not someone else's".

In the last couple of weeks I've installed an OS X machine, and a couple of windows machines, both of which insisted I provide phone numbers, emails, or credit cards in order to install just the basic OS.

Linux is already a clear win for privacy and the principle that my computer is, my computer, not a client terminal to a corporate "ecosystem" (with "users" obviously being the plants, or at best, herbivores).

</comment><comment><USER9> > the linux kernel, along with a lot more stuff, declared it was sticking with > the GPLv2 and not moving to the GPLv3. when your movement says "here is the > new version of The Right Way To Do Things" and several of your largest > adherents say "nah fuck you we're going with the old version" that is not a > good sign.

Some public comments Linus has made about the choice to stick with GPLv2 over GPLv3: [https://youtu.be/PaKIZ7gJlRU](https://youtu.be/PaKIZ7gJlRU).

> and also most of the people using Linux right now are using it by accident, > distributed as ChromeOS or Android

Also, those kernels are now built with LLVM. [https://clangbuiltlinux.github.io/](https://clangbuiltlinux.github.io/) (not all devices in existence, but all new ones for the past few releases of both distros and many old chromebooks that received recent kernel upgrades).

<comment><USER10> Well, they've noticed how GPL is bad for their EEE strategy, so they've grasped the first occasion to fight it: can't do much with the code that is GPLv2, but can hinder the license update.

<comment><USER3> Not exactly. GPLv3 has serious problems with proprietary hardware. As stated, it would prevent current GPU drivers and many current network device drivers from being possible to use, due to irreplaceable closed source binary blobs and on device cryptographic authentication of said binary blobs.

Which is essentially the same as tivoization...

Immediately nvidia-driver and radeon drivers would be illegal.

<comment><USER11> Which is not actually a bad thing per se.

Those drivers do work better than their free/open-source counterpart but are hard to install (especially if secure boot is enabled) and do not play nice with the whole GNU/Linux ecosystem.

<comment><USER3> No, it would be illegal to install those drivers. Not hard at all.

Radeon drivers specifically play nice with the ecosystem, but they feature crypto firmware blobs.

Network drivers tends to be good neighbors too.

Nvidia drivers cause more of a problem, as do ugly smartphone GLES drivers. (Not to mention very custom network chipsets there.)

</comment></comment></comment></comment></comment><comment><USER12> Most attempts to "fix open-source funding" \- such as GitHub sponsors or OpenCollective are misguided. Bulk of the value of FOSS is being taken by corporates, not individuals. So expecting individuals to support the creation/maintenance of FOSS is futile. And corporates are RoI-driven. Charity will only go so far.

</comment><comment><USER13> Author made the fatal mistake of thinking "access to source code" is the specific, concerted goal of Free software, not you know... software freedom. In a world of forced software updates, elusive and feared "algorithms", etc, it doesn't seem like a particularly "esoteric" goal to me.

</comment><comment><USER14> The author added a human fart sound that plays when the visit comes from HN.

      // Hacker News is bad.
      if (document.referrer.startsWith("https://news.ycombinator.com")) {
          document.location = "https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav"
      }

If you don't want to have anything to do with the HN people, then who is your ally in tech?

<comment><USER15> people who aren't self-absorbed enough to think that their preferred newssite is the center of all activity in their industry?

</comment></comment><comment><USER14> Maybe you'll downvote, but I'll be that guy: It's very hard to read a text that is written in all lowercase. I don't understand why the author would choose to do that.

The topic of this article is very close to me but the style of writing makes it too hard to read.

</comment><comment><USER16> F/OSS isn't dead. Capitalism _does_ consume almost everything it touches, and you should have seen it coming.

The easy fix is to start using the F in F/OSS more (AGPL, etc), and force anyone who wants to use and extend your software for commercial use to pay up. Take that money, and invest it back in F/OSS software if you want -- use it to buy treats for your dog if you want. If you want wider reach and use for your software (which in a sense is even more "free" for some meaning of the word), then use the GPLv2/MIT license or other such permissive licenses.

The hard fix is trying to win over hearts and minds when it comes to OSS- washing and the marketing pushes/strategies companies employ these days to get people to write/maintain their software for them. The problem here is that some people are absolutely fine with the current situation -- many get absurdly cheap (essentially free) meaningfully complex software even if it's basically shareware from corporations, and are fine with that. Many also are fine creating software that is permissively licensed because people write software for all sorts of reasons, fame and recognition being one.

It does make me glad to see this narrative coming up on HN though -- the corporatization of OSS has been happening for a long time now and needs more attention drawn to it. Every company has a right to try to make money with software, but some are more well-intentioned than others (and they usually suffer from a harder route to market viability).

</comment><comment><USER17> I don't feel like extrapolating Mozilla's problems into a general problem with open source makes sense.

Mozilla is in an odd position, with most of their revenue coming from their largest competitor. I think that's pretty unique.

</comment><comment><USER18> [https://locusmag.com/2020/09/cory-doctorow- ip/](https://locusmag.com/2020/09/cory-doctorow-ip/)

<comment><USER19> Thanks for sharing this link!

</comment></comment><comment><USER20> I think the author made some good points worth thinking about, but I would somewhat disagree with the conclusion. Some of the bigger FOSS projects left out of the write-up would be Chromium which is BSD+others, and Java is GPL, so it shouldn't be surprising that corporations figured out which license would help them the most and went with that. Likewise, I think people should pick the right license for the job (Something along the lines of BSD/Apache for a system lib, and GPL for user-facing software), and experimentation in this area can only be good. License zero, ethical source, Tidelift, and some license/project proliferation with POSS all seem like they're going in different directions if anywhere, which might also make sense as there is more branching out of FOSS in general.

FWIW, I think the 4 freedoms reinforce what end users want, or maybe used to want: compatibility and interoperability. The big companies somehow managed to convince users against having those two things in the name of a few conveniences as the author himself pointed out. Gatekeepers can only be stopped if users reject them, and the GPL isn't so bad a tool for doing exactly that.

<comment><USER20> To add something else, POSS focusing on developers (Tidelift, L0) instead of just user freedoms, seems completely the right thing to be doing.

</comment></comment><comment><USER21> > only programmers care if they have access to the source code, and most > people aren't programmers. and i am a programmer, and i don't give a shit.

What a horribly short sighted view...

What happens when the company stops developing the software for your device?

<comment><USER22> Depends on the device...

Symbian^3 was moved to a free and open licence (Eclipse Public License) for some time. The ecosystem died anyway.

<comment><USER21> Yes, but as a programmer if you had the source code and the inclination you could still make modifications to suit your needs.

<comment><USER22> I was a programmer at that time and I was even reasonably well-versed in the rather arcane dialect of C++ that was used in Symbian programming.

Making a non-trivial change to an OS and deploying it successfully to a device on my own would be a challenge, though. Once Nokia stopped paying the internal developers and Symbian programming forum was closed, there were no gurus capable of answering questions.

And in case of a very complicated OS whose internal workings were very different from other OSes out there, having no vibrant community of experts = death, unfortunately.

</comment></comment></comment></comment><comment><USER23> > _" around the same time, free software organizations were starting to > successfully sue companies who were using free software but not complying > with the license. so big companies, like Apple, saw new restrictions coming > in at the same time as more aggressive enforcement, and said "well shit, we > want to base our software on these handy convenient tools like GCC but we > can't use GPLv3 software while keeping our hardware and software as locked > together as we'd like." so they started pouring money into a new C compiler, > LLVM, that was instead open source."_

This is only half the story.

The other half is that GCC is a monolithic app, built in a style that makes it hard to contribute to. GCC was (maybe it still is), ironically, defective by design in order to force companies to extend GCC, instead of building plugins that could be distributed as proprietary.

Either way, LLVM's license is still Free Software, still Open Source. And LLVM's permissive license is actually proof that you don't necessarily need a copyleft license to get companies to contribute. And we've got a whole ecosystem of such projects built with permissive licenses, hello BSD/OS.

Free Software and Open Source never meant just copyleft. That's a misconception.

\---

> " _what really killed free software? ... in a word, capitalism._ "

It's funny that the author says that, because it is capitalism that enabled Free Software to exist in the first place.

 _Copyleft_ wouldn't be possible without the existing copyright law.

Also the biggest contributors to FOSS projects have been companies. Not individuals in their spare time, not the state, but companies motivated by profit. Just like how technological innovations are often driven by companies motivated by profit. And yes, we could have a discussion about perverse incentives, and how we could avoid that.

But I was born in communism, I know how not living in capitalism is actually like, and unless people can suggest actual solutions, instead of a rant inspired by Marx & friends, we've got nothing to talk about. I wish articles with such bad takes would start with the conclusion, so I wouldn't waste my time.

<comment><USER15> >Either way, LLVM's license is still Free Software, still Open Source. And LLVM's permissive license is actually proof that you don't necessarily need a copyleft license to get companies to contribute. And we've got a whole ecosystem of such projects built with permissive licenses, hello BSD/OS.

It's also enables proprietary extensions, easily enabling companies to make compilers for their proprietary languages, see CUDA. That seems pretty contrary to the mission of free software.

Also, just curious, how many patches have FreeBSD and co. actually received back from Sony and Apple in the past few years? They still seem to be struggling to add features to the point of begging for 802.11ac support.

</comment></comment><comment><USER24> The hacker news crowd isn't too friendly to leftist content but I wanted to say I appreciate this article. It all makes sense to me and it gives me something to think about. I agree that licenses can not be used to force good behavior and we need to focus on changing norms. I choose licenses like CC0 for my work and focus on how to survive regardless of what big companies may do with the code. It's tough to navigate but I think successfully doing open source is worth the experimentation.

</comment><comment><USER25> Some very thoughtful points. Also echoed in "Working in Public" by Nadia Eghbal

</comment><comment><USER26> Ethics are only evolutionarily sound if cooperation among agents increases fitness. Since corporations seemingly do not need to cooperate, ethics indeed are harmful to their chances of proliferation.

</comment><comment><USER27> It's silly how the article idolizes Free Software and the 4 freedoms.

If only if they looked at OSI's open source definition, they would have realized the same 4 freedoms are held in it.

</comment><comment><USER28> Ironically Mozilla is rather more of the "corporate friendly open source" than anything else, making this look like pure clickbait.

</comment><comment><USER29> Perhaps limiting use by companies or individuals with income less than one million dollars directly or indirectly would help.

</comment><comment><USER30> What about Creative Commons Zero (CC0)?

Its intention is to be an internationally-recognized license equivalent to public domain

</comment><comment><USER31> Every time X has more users than Y, Y is declared dead, no matter if Y has as many or more users as always..

</comment><comment><USER32> The lack of capitals at the start of sentences....

<comment><USER33> Yes. I think I haven't noticed such a long form writing style before. I bet it's intentional.

What makes it really difficult for me is my eyes can't seem to anchor anywhere when I read. It's like reading a big phrase, or like speaking without taking a breath.

<comment><USER34> In addition you have to look closely to see if there's a . or , to know if it's a new sentence or not. Horrible UX.

</comment></comment></comment><comment><USER11> Very good points. Made me rethink about the whole GPL licensing model. It may be worth considering the WTFPL license and or the JSON license in the near future.

<comment><USER7> One of the few popular pieces of software affected by the JSON license _finally_ managed to eliminate it: [http://mikepennisi.com/blog/2020/jshint- watching-the-ship-si...](http://mikepennisi.com/blog/2020/jshint-watching-the- ship-sink/)

I sincerely hope no new project ever uses that license.

<comment><USER35> Thanks for the link. I'd not quite understood the nuanced rejection of JSON. That "The Software shall be used for Good, not Evil" equates to how...

> _Legally-conscious objectors aren't betraying their own dastardly > motivations; they're refusing to enter into an ambiguous contract. Put > differently: they're not saying, "I'm an evildoer," they're saying, "I don't > understand what you want."_

<comment><USER7> Right. Among other potential issues, such a license is effectively revocable based on someone declaring some particular action or entity "evil" (which is heavily subjective). A license that included the term "this license may be revoked by the author at any time" would also not be FOSS.

<comment><USER36> Open source licenses are revocable anyway under U.S. law because they are bare licenses, not contracts.

<comment><USER37> I'm not sure how to search for this to verify your claim, but I'm intrigued. Do you happen to have a citation to a ruling that you can share?

<comment><USER36> This has not been tested in court so far as I know.

(Please do not cite _Artifex v. Hancom_. Special conditions prevailed in that case that do not apply, in general, to all software under a nonexclusive open source license.)

Generally speaking, under common law, in order for an agreement to have the force of a contract, there must be an offer, acceptance, and consideration. Since most people acquire open source through a download, there is no consideration (monetary value) being remitted to the author of the software, and hence the license does not have the force of a contract binding on the author. The license is thus a bare license, and the author has the right to revoke it at any time. Unfortunately that's how contract law works in common- law jurisdictions, and we are in for some nasty surprises once this actually does get tested in court.

Civil-law jurisdictions, for example Germany, do not necessarily require consideration in order for a contract to be binding. Open source licenses such as the GPL can be binding contracts in Germany.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Open source is hosed because a bare license is revocable at any time by the licensor. If your business depends on an NPM library written by some schlub on the internet, and that schlub decides they don't like you, then they can revoke your license and sue for copyright infringement, not to mention preventing you from operating legally as long as you depend on their software.

It gets even worse if the "schlub" is an entity like Google -- and you appear on their radar and they decide you're a competitor.

<comment><USER38> > Open source is hosed because a bare license is revocable at any time by the > licensor.

I haven't the slightest clue what you're taking about. You can change your license on future versions, but you can't retroactively change the conditions of an offer that's already been accepted.

If you're talking about the ability to delete published packages from NPM, that's entirely unrelated to licensing.

<comment><USER39> This is what is being referred to. I have never seen an actual case of it occurring, only threats.

[https://lulz.com/linux-devs-threaten-killswitch-coc- controve...](https://lulz.com/linux-devs-threaten-killswitch-coc- controversy-1252/)

<comment><USER36> MikeeUSA may be an odious little prick, but he is 100% correct in his legal analysis, and cites actual legal experts to support his case.</comment></comment></comment></comment>


Ask HN: Password managers - <AUTHOR>

HN is a security savvy crowd that, I assume, does not like to reuse the same password on multiple sites of dubious security.  What software do you use to manage the proliferation of passwords, user id's, and email addresses you have to give out to register on so many websites?  Do you synchronize these across multiple browsers/boxes?<p>Is there market opportunity for a piece of new password management software?  What features aren't there that should be? <comment><USER2> For anything not ultra secure (bank/paypal/email/etc.), I remember a main password and then use a bookmarklet that creates different individual passwords that work for each website. The advantage of this is that I don't have to do any synchronization at all, and I can access any website on any computer.

I really can't believe this hasn't caught on as a password solution, even among the geeks I know; it has all the advantages of a password manager without the disadvantages.

<http://supergenpass.com/>

</comment><comment><USER3> I am a software security consultant and developer, and I've got to say my favorite is PasswordSafe, originally written by Bruce Schneier, it's now open source and available on sourceforge. It's secure, lightweight, easy to use and can be installed on a thumbdrive for portability. <http://passwordsafe.sourceforge.net/>

<comment><USER4> I've been using Roboform but I'll definitely be checking that one out - thanks.

</comment></comment><comment><USER5> Heh, I recently blogged about a system I came up with to manage this, using a ruby password generator that was linked on HN and storing the results in a dropbox directory. Super super insecure but kinda fun to think through. <http://digg.com/u19L9>

I don't actually use that system though, I generally use the same user id and generate the password using a formula based on the website I'm registering at and other mysterious factors.

</comment><comment><USER6> Gui (cross platform; thumb drive versions) <http://www.keepassx.org/>

CLI (old; via ssh) <http://freshmeat.net/projects/pwsafe/>

Library (looks promising although not done) <http://www.pwsafe.de/>

</comment><comment><USER7> I use plain text files encrypted via gpg.

There's a gpg plugin for vim. If you don't like vim, you can probably find one for your preferred editor.</comment>


How to Manually Detect If You're Infected With the OS X Flashback Trojan - <AUTHOR> http://www.f-secure.com/v-descs/trojan-downloader_osx_flashback_i.shtml

<comment><USER2> Title should be "How to manually detect if your infected".

tl;dr version:

In terminal run these:

defaults read /Applications/Safari.app/Contents/Info LSEnvironment

defaults read ~/.MacOSX/environment DYLD_INSERT_LIBRARIES

if both are not found you are clear. If found, read the f-secure article.

<comment><AUTHOR> Fair enough! I've updated the title of the post. Thanks for adding the quick detection routine.</comment></comment>


An App Helped Rescue 37,000 Hurricane Victims. It's Ready for Florence - <AUTHOR> https://www.king5.com/amp/article?section=news&subsection=nation-world&headline=an-app-helped-rescue-37000-hurricane-victims-its-ready-for-florence&contentId=507-593678047 <comment><USER2> An app that saves life rather than give you numerous updates. Hat's down to the gentleman. It really gives initiative to other people to help others during the time of need. Really great.</comment>


For Bonobos, it pays to have powerful allies - <AUTHOR> https://today.duke.edu/2018/01/bonobos-prefer-jerks <comment><USER2> "The results support the idea that a tendency to avoid individuals who mistreat others is one of the things that make humans different from other species."

The researchers desperately need to take a night out in town and observer other humans a bit. They've acquired a biased view from being cooped up with university people for far too long. I feel like I see directly contradictory behavior on a weekly basis.

<comment><USER3> 100%. One of the disadvantages of living the privileged, protected life as an academic is the inability to accurately draw conclusions about the majority of humanity.

<comment><USER4> This seems like a jump. Two, actually. First, that academics, who work in a charged political environment and with college students, are sheltered. Second that the majority of humans prefer jerks. I don't know that we can substantiate either of those claims.

It's true that jerks can be in positions of power, but it's hard to say that people prefer them. Indeed, it appears that many people strongly dislike them, but that they are protected by their power and other people with power (a distinct minority).

<comment><USER3> > First, that academics, who work in a charged political environment and with > college students, are sheltered.

It's exactly because they find themselves in such an environment that they're sheltered. You think the majority of humanity has access to safe-spaces, policed speech and diversity initiatives? US college campuses do not reflect reality.

<comment><USER4> The "real" world also has fewer fraternities, entitled college athletes and less binge drinking. Academic departments are also highly charged political atmospheres, more than any place I've ever worked since I left college. Perhaps I have just been lucky, but I wouldn't go into academia for much less than a boatload of money.

</comment></comment></comment></comment></comment><comment><USER5> As usual with science headlines, it's an oversimplification at best, and inaccurate at worst.

The results seemed to indicate that Bonobos preferred those who were at the top of the social hierarchy. The experiment would only be decisive if they could find a way to deconvolve jerkishness from dominance.

 _The researchers say there may be a good reason for these puzzling results. It could be that bonobos interpret rudeness as a sign of social status and are simply trying to keep dominant individuals on their side. In other words, it pays to have powerful allies._

 _To test the idea, the team showed 24 bonobos another set of animated videos in which one cartoon character repeatedly prevents another one from claiming a coveted spot. The apes generally preferred the character who hogged the spot over the one who yielded._

 _For bonobos, schmoozing with dominant individuals could mean better access to food, mates or other perks, or less chance of being bullied themselves, Krupenye said._

<comment><USER6> Got me very curious on what part of our brain evolved into spatial protection.

</comment></comment><comment><USER7> And chickens prefer attractive people:

[https://news.nationalgeographic.com/2018/01/animals- chickens...](https://news.nationalgeographic.com/2018/01/animals-chickens- evolution-eggs-food/)

Rough out there.

</comment><comment><USER8> > To test the idea, the team showed 24 bonobos another set of animated videos > in which one cartoon character repeatedly prevents another one from claiming > a coveted spot. The apes generally preferred the character who hogged the > spot over the one who yielded.

> they showed 24 bonobos animated videos of a Pac-Man-like shape as it > struggles to climb a hill. Then another cartoon shape enters the scene.

Nevermind the 'jerk' part, I'm impressed that researchers are interpreting ape preferences via cartoons

<comment><USER9> Me too. If you showed one group of humans Bugs Bunny and another group of humans Care Bears, they would show a marked preference for Bugs Bunny (who usually abuses poor Elmer Fudd) because it's _funnier_. Does that mean _humans_ prefer jerks, or just jerky cartoon characters?

<comment><USER10> Well to be fair to Bugs Bunny, he is a prey animal trying to avoid being killed. One might say that people just prefer underdogs winning.

</comment></comment></comment><comment> aaron-lebo _The results support the idea that a tendency to avoid individuals who mistreat others is one of the things that make humans different from other species._

What's the evidence for that? Humans love people who mistreat others. We'll die for them and canonize them, for similar reasons as bonobos: they exude power, confidence, strength, certainty. A cursory overview of history and a lot of relationships will support that.

Happy to be wrong. What studies are they referring to?

<comment><USER11> [https://www.nature.com/articles/nature06288](https://www.nature.com/articles/nature06288)

I believe this bonobo study is considered salient precisely because it is trying to be an analogue to studies of humans that have found the opposite result.

<comment><USER12> This is a study of preverbal infants. Maybe infants do also discriminate between dominant and less dominant individuals, but at their age, being very care dependent, have a much stronger preference for kind individuals. Maybe infant bonobo's react in the same manner. I am also getting the impression that with adult humans dominance often plays a strong role over kindness.

</comment></comment></comment><comment><USER13> Science confirms what we've known for a long time - humans are unique in their ability to act according to morality, instead of pure survival value. We have eaten from the tree of knowledge of good and evil and have free will. Animals don't.

<comment><USER14> And yet most people _still_ deny it (as evidenced by your being downvoted).

Our unique talents also include abstract reasoning and communication as well as advanced tool making, yet most human beings are still acting within the mammalian level of behavior which mostly comprises pack warfare and alpha- dominance seeking, and we are all witness to the disastrous effects those sub- human tendencies are having upon each other as well as the Earth itself (via our short-term profit-seeking over the long-term well-being of the Earth for our descendants benefit).

Love -- via selfless service to others' happiness -- is the most unique of human traits as it facilitates our rising above our mammalian tendencies (literally, from a brain structure standpoint) to segregate and wage war upon others of any perceived difference, be it physical (ethnic) or ideological (form of religion, neighborhood, country, sexual orientation or identity, etc.).

Only by accepting the primacy of our free wills upon this Earth and the necessity of our training our minds to differentiate good from evil and then choosing the former can we stop the devastation of the Earth and its less fortunate individuals.

Until then, the vast majority of human beings will remain, as Wisdom states, "like the animals, only worse".

<comment><USER15> I don't know that most people deny it, nor that down votes on this thread are evidence of anything...

It can't be modeled scientifically. People deny it because it's in effect a dogma. I don't say that as a slight, our society is built on the notion of free will.

It's simply that the notions exist in a level of abstraction, so the point is moot if you continue living your day to day life, except insofar as you let it affect your mental state.

<comment><USER13> Not everything has to be modeled scientifically in order to be true. Science is not the only source of truth.</comment></comment></comment></comment>


Why You Didn't Get The Interview, Part II - <AUTHOR> http://jobtipsforgeeks.com/2013/07/10/why-you-didnt-get-the-interview-part-ii/

<comment><USER2> The problem is that employers actually believe you can glean something useful from a resume. In my hiring experience, the quality of a resume is very rarely correlated with the quality of the candidate.

The majority of the time candidates look much better on paper than in person. I gave up the belief long ago that resumes can be filtered meaningfully.

<comment><AUTHOR> We are not announced publicly yet, but I'm working with a partner on a project called GeekRez ([http://geekrez.com](http://geekrez.com)) which is trying to solve the problem you mention. There is some info up and you can sign up for notices, and we're planning on a beta soon.

Resumes are not the future of search for devs. Hiring managers want to see other things beyond your self-assessed experience levels and a laundry list of buzzwords. GeekRez aggregates data from a handful of places like GitHub and/or BitBucket, Stack Overflow, Meetup, LinkedIn as well as other relevant links a job seeker would provide (publications, blogs, etc.).

This is all brought into a single page with collapsible tabs as a public profile for a potential employer (or even someone you might be doing a side project with) to review.

Devs can use it as a way to differentiate themselves from the competition and show off the strength of these accounts - obviously there would be no advantage for devs that have weak associated accounts to use the service.

It is also set up so a manager could view several profiles side-by-side, to compare say 5 candidate profiles at once. Instead of looking at 5 PDFs and clicking on a handful of URLs in each PDF to get the full picture, it's all brought together on one screen.

Feel free to check it out now, whether you are a dev or someone who will be hiring them. I'll post about it here on HN when we launch officially.

</comment></comment><comment><USER3> The skills required to get a job: resume writing, professional networking, interviewing, are often not the same skills that actually qualify you for the job. One could be a very good resume-writer and interviewer (dare I say B.S.er?) but not be the right match for the day-to-day job duties. On the other hand, one may be technically qualified, but just not good at resume- writing or smooth talking during the interview.

It reminds me of back in high school, where there were always those really smart kids who were just bad at standardize testing. They risked falling through the cracks because the testing was the only method used to judge one's scholastic ability.

Perhaps the standard "personal reference -> resume -> phone screen -> interview" pattern could use some disruption. Is there a way to match candidates with jobs that's better than keyword-matching resumes and sitting in a conference room talking about a time in the past when you learned from a mistake? Given that there are simultaneously tons of companies saying they can't find talent and tons of unemployed (and under-employed) talent looking for work, you could conclude that something about the current job matching system most companies use is not working.

<comment><AUTHOR> The current system isn't entirely broken, but it needs works, and the work needs to come from both sides. Candidates need to do a better job of how they market themselves to employers, and employers need to improve how they select and evaluate talent both on paper and in interviews.

The news a couple weeks ago about Google and their alleged use of trick questions and such hopefully raised awareness of the problems surrounding tech interviews, the value of GPAs and majors, etc., for all the other companies. Google is one of a handful of shops that shape how others think they should do things.

As I mentioned in another comment, managers today are more keen on seeing code. A resume can make whatever unverified claims you want to make. I mentioned a project I'm working on ([http://geekrez.com](http://geekrez.com)) that is hoping to change how talent represents themselves to hiring entities and somewhat trying to replace the resume submission process with items managers want to see.

A Stack Overflow reputation score is not a self-assessed expertise in a specific technology, but rather something that is assessed by others. Saying you write good code is one thing, but let's see what you have in your GitHub or Bitbucket to prove what you are saying. These are the types of things that will get devs hired in the years to come.

Personal references are a whole other story. If someone can't find 3 people to say something nice about their work, they shouldn't be in the industry. The only thing that is valuable about references is when a handful (3-5 usually) of people provide very consistent information - to be more specific, consistent with both positive and negative items. I know when I hear a few people share the same strengths and weaknesses about a candidate that I'm probably getting a pretty good and honest assessment (or they have all been superbly prepped).

</comment></comment><comment><USER4> A lot of times I see a resume with a laundry list of skills at the top like languages, app servers, CMS systems etc. First I thing I do is check the experience and make sure the skills are actually mentioned as having been used on a project. Otherwise, I assume you are padding to meet the req.

<comment><USER5> I'd name the law after the guy who told me this but I don't have explicit permission (he'd probably be OK with it, but I don't see him often and he's a well-known CS person) so let's just call it Smith's Nineteenth Rule: the quality of a candidate is inversely proportionate to the number or technologies listed on the resume.

One startup idea I've had is a scarce resume system where people are limited to 7 technologies and allocate 10 points in each for skill and interest (3-5 points means you're really good or really interested). It's like building a character sheet. More information in that than a typical resume.

<comment><USER6> Doesn't that just encourage those who do have a range of technologies at least somewhat under their belt to tweak their skill-weights on each application to bring it closer to a presumed "perfect skill vector" for that job?

(...or is that the whole point...?)

<comment><USER5> Also listed would be years of experience, in the first iteration. In a later one, I'd want to replace that with some way of evaluating directly a person's general skill level on a scale like this: [http://michaelochurch.wordpress.com/2013/04/22/gervais- macle...](http://michaelochurch.wordpress.com/2013/04/22/gervais- macleod-23-the-shodan-programmer/) That would take a long time to figure out, though: how to evaluate programmers in the general case.

3 points of Machine Learning with 20+ years of experience (or 2.0 level skill) is different from 3 points from a fresh college student. The first means he's probably an expert; the second means he specialized in it while in school.

Resumes have two purposes. One is to give a list of topics one is willing to discuss in the interview. The second is to project social status (i.e. lie). So you have a mix of self-evaluations and lies on a resume. The latter don't have signal, but the former do. The reason for the 10-point allocation is that self-evaluation has a great deal of signal _if_ a person is expected to trade off one claim against another ("i.e. I know Java but I'm really good at Python" vs. "yeah, I'm an expert in all languages").

<comment><USER7> This can never work. Resume's have only one purpose - they are marketting materials for folks looking for work. Everything else has to be considered within that frame reference.

<comment><AUTHOR> To some extent what Michael is saying is already true, but since resumes don't have a character limit candidates aren't held to it. If you were given a finite amount of space, such as one page, what would you choose to describe? What Michael is proposing is essentially limiting what you can say. If you had an online application that said to list 3 technologies that you use, that would probably be quite different than the list of 30 you may have on your resume, and it would send a strong message about how you truly value certain skills.

</comment></comment></comment></comment></comment></comment><comment><USER5> Here's what I think is unsaid about the pre-interview stage. Most resumes are junk (recruiter spam, unqualified candidates, perennial candidates who continually punch above their weight class). Your job, pre-interview, is to prove that you're not one of them. Another way to look at it is to establish that your job searching doesn't reflect negatively on you. (Being employed at the time helps.) Everyone job searches, but the bad candidates spend a lot more time doing it.

For example, someone who applies to 5 unrelated positions isn't looking for a career upgrade or new challenges, but just looking for a job in general. That's not attractive.

Once you're in the interview process, you don't have to answer for the mere fact of looking for a job. You've cleared that stigma.

<comment><USER8> > Everyone job searches, but the bad candidates spend a lot more time doing > it.

This sums up what my experience seems to be hiring. I've never really thought of it that way, but there's a clear selection bias. The good ones get snatched up quickly; the bad ones spam out to every damn listing they see.

<comment><AUTHOR> Good candidates are rarely on the market for an extended period of time, and are often much easier for experienced recruiters and hiring managers to identify than mediocre or below average candidates. When I have a candidate that I know is in the top tier, I'll advise clients that they need to move quickly or lose their chance to even see them, because other companies will be relatively quick and aggressive to hire.

It's not much different than real estate, where if you see a house that has been on the market for a long time you may be less inclined to give it a look. Thankfully, job seekers don't have listing dates unless they choose to post a resume publicly.

</comment></comment></comment><comment><USER9> I've dealt with Dave a couple of times. I trust his advice.</comment>


Ask HN: Will dominance in a particular ephemeral activity always be short-lived? - <AUTHOR> I often wonder if businesses based entirely on ephemeral activities (e.g. Software, Internet advertising, social media platforms, etc) will ever have a solid footing. <comment><USER2> They're in the business of change.

</comment><comment><USER3> Microsoft was the first microcomputer software company. They are still around today.</comment>


MurmurHash 2.0 - <AUTHOR> http://murmurhash.googlepages.com/ <comment><USER2> I VERY much dislike such webpages where there is no information what it is. Stop assuming some knowledge and start of the webpage with a two line description of what the project is.

<comment><USER3> The name of the project tells you what it does. If you don't understand from the name of the project, you'll certainly have no use for it.

<comment><USER4> It's a hash container, right? I do have a use for it, but it took some serious investigation to find out anything about it. The poster you replied to was spot on.

</comment></comment></comment><comment><USER5> If someone manages to port the 64-bit version to Java (which probably requires some JNI or JNA work), I would be very happy.

<comment><USER6> I just ported it to Java. It took me five minutes.

It's 40 lines of C++, most of which are of the `k *= m;` variety. You literally paste in the C++, fix the type declarations, and replace the point increment looping with standard indexed array iteration. Remember to replace `const` with `final` and you're done.

Using JNI for a high-speed hash function makes only slightly more sense than putting a SOAP interface on it.

<comment><USER5> Yes, and those "k _= m" lines are the problem! Those assume_ unsigned* types! And 64-bit integers! Those multiplications and other operations are all wrong!

You didn't port this to Java, you ported a broken algorithm to Java. Way to go, though.

<comment><USER5> Sorry, not 64-bit _integers_ but you get my drift.

</comment></comment></comment></comment><comment><USER7> What puzzled me here was that it took so many years for someone to optimize this. I looked at the code and dug around for 'barrel shifters'.

Funnily enough, this page <http://answers.google.com/answers/threadview?id=388350> says that in 1986 both the i386 and 68030 came with one, but it was missing from the Pentium 4.

<comment><USER8> I doubt the Pentium 4 had no barrel shifter, as its shift instructions have single-cycle latency. It does seem, however, that the Prescott can do rotate instructions in one cycle while the Northwood took 4 (thanks, Mubench!).</comment></comment>


Isn't brain hack the ultimate hack? - <AUTHOR> http://www.mindfulogy.com/

<comment><USER2> Be careful for what you wish... The long term effects are unknown. Try meditation first. The mind is buddha, the way is nowhere.</comment>


Ask HN: Elm vs. React vs. Vue.js in 2018? - <AUTHOR> <comment><USER2> It doesn't matter. The only thing that matters is choosing whatever compiler, framework or library you want to use. React is a very safe bet in my opinion, it has entrenched itself into many facets of the industry (both corporate and non-corporate). However, don't underestimate the growing popularity of Vue. I've worked with both React and Vue, and I think React needs to up its game because Vue is growing rapidly, has some great ideas (single file components) and more people are becoming aware of it.

The most dangerous thing that any developer can do is choose to work with only one framework or library. Don't put all of your eggs into one basket.

<comment><USER3> > The most dangerous thing that any developer can do is choose to work with > only one framework or library

100% agree, still I found better results choosing a "main" framework/library to learn and then having a set of alternatives.

[https://stateofjs.com/2017/front- end/results](https://stateofjs.com/2017/front-end/results) will give you an idea of where things are by December 2017. React is taking the lead, but Vue has great potential.

I personally worked with both and have VueDevTools and ReactDevTools extensions installed, and I am impressed by the number of websites React icon turns on compared to Vue. Which would mean is has a huge chance of becoming a standard for the next few years.

</comment></comment><comment><USER4> Used Mithril (think React but smaller API and much simpler) in my first developer gig and I love it. It's my go to for quick prototyping and development.

In my last gig I used Vue and even though I would much prefer writing my views in hyperscript, using a popular framework has its advantages in terms of tutorials, libraries, established practices etc.

<comment><USER5> What about JSX? Hyperscript's bracket closing is quite tedious to me.

<comment><USER4> I'm yet to try JSX with Mithril but I've used it with React. I prefer hyperscript when it comes to Mithril. The bracket closing has grown on me.

</comment></comment></comment><comment><USER6> Personally I love Vue and the ideas behind it. React has managed to break into the industry with a bang and some (bad) PR with the licensing issues they hit last year and has now become very widely used.

They are the same language but require different ways of thinking which both have their uses.

</comment><comment><USER7> Elm for maximum joy, if you can. Maybe purescrpt plus library is even better?

</comment><comment><USER8> Use all three.

I lean more towards vue for personal reasons, but in the technology world you will always run across all flavors. So always be knowledgeable in as many areas as possible.

Think of it as traveling Europe. Would you want to only speak one language?

</comment><comment><USER9> Vue is rocking my boat right now. Love it!

</comment><comment><USER10> If you understand ReactJS well enough, those skills are quite transferable to React Native.

</comment><comment><USER11> If you are inclined towards Elm you might also want to consider GHCJS (via Miso or Reflex):

\- Miso: [https://haskell-miso.org](https://haskell-miso.org)

\- Reflex: [http://docs.reflex-frp.org/](http://docs.reflex-frp.org/)

Reflex is known to be already in production.</comment>


Touchdroid - Android for the HP Touchpad - <AUTHOR> http://rootzwiki.com/showthread.php?t=3327

<comment><USER2> It should be noted that the TouchDroid team is largely composed of, and led by young teenagers with not a lot of systems programming experience, and no history (that I know of) of "cooking" ROMs.

That's not saying young teenagers can't accomplish anything. They just spent too much time on their website and getting on the front page of every news site and too little (a little poking around) time looking into the feasibility of it, or getting any work done on the port.

Don't buy a TouchPad if you're thinking you'll be running TouchDroid on it any time soon.

<comment><USER3> 1\. The development team comes from the Nookdev team, and multiple other android porting/ROM projects 2\. The website was done by a friend of the team that is not doing any of the actually porting work 3\. For $99, the TouchPad is sort of an impulse buy... and even though we do not have an ETA for release, we do plan on getting this working and released at some point. Do you see the CyanogenMod Team ever commenting on the next release date?

<comment><USER2> It's good to hear that from you. I wish you guys the best of luck.

</comment></comment></comment><comment><USER4> More power to them, but why would I want to replace the best part about this device?

<comment><USER5> just picked up one this weekend, some reasons are:

1\. WebOS international support is terrible. This is a huge reason to get Android on it. They've completely ignored it.

2\. The browser while good, the card system is slow when trying to use it as a tabbed browser. Opening a new link in a new card is quite slow. I don't care for app support because their browser is good, but if you are going to rely on the browser at least have a decent tabbed browser. Look at Dolphin browser on Android to see how a mobile browser should be done. Also another limitation seems to be I can't download files from the browser ex. dropbox.

3\. Overall the system feels sluggish. Android has multitasking right, WebOS doesn't. After the Android team optimizes and overclocks this hardware, I imagine its going to be pretty good.

4\. Lack of Customization, I can't even make a picture fullscreen wallpaper on the background. And since you can't place anything on the desktop/wall area.. a nice big picture would look good.

Overall its solid and feels polished, but WebOS is overall really lacking and compared to Honeycomb I don't see it as better. The best thing is flash support works great, and I can watch all the media I want from streaming flash sites. The biggest benefit is getting honeycomb/Ice cream sandwich on a solid tablet for $100. *posted in another thread

Also check out <http://www.touch-droid.com/>

<comment><USER6> system feels sluggish because of logging. this is a 5 minute fix with some patches.

<comment><USER7> Where can I find the logging patches? I have a TouchPad and would like to test this. :)

<comment><USER8> I'll provide some quick steps on how I made mine snappy.

      1. [Install Preware with WebOS Quick Install][1]
      2. In Preware on the Touchpad,
        a. install [UberKernel][2] (Kernel > Stable)
        b. install [Govnah][3] (Application > System Utilities) and choose
           the OnDemandTcl 1512 profile. This overclocks the device to
           1.5 GHz (up from 1.2 GHz) and underclocks it to 192 MHz when
           idle (down from 500 Mhz).
        c. install the following patches
          i. Faster Card Animation HYPER Version (Patch > Mojo)
          ii. Increase Touch Sensitivity And Smoothness 10 (Patch > Misc)
          iii. Muffle System Logging (Patch > System; primarily what
               you're looking for if you don't want to use the custom kernel)
          iv. Remove Dropped Packet Logging (Patch > Misc)
          v. Unthrottle Download Manager (Patch > Misc)

[1]: [http://www.webos- internals.org/wiki/Application:Preware#Inst...](http://www.webos- internals.org/wiki/Application:Preware#Installing_Preware_with_WebOS_Quick_Install)

[2]: <http://www.webos-internals.org/wiki/Application:UberKernel>

[3]: <http://www.webos-internals.org/wiki/Govnah>

<comment><USER5> thanks for this , i just tried these and its a significant difference. What about OTA updates ? have you tried with these patches.

<comment><USER8> It works totally fine with 3.0.2 (the only OTA update as far as I know), but I can't give a comparison, sorry. I updated the same day I got the device so I'm not sure how 3.0 was.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> We've had this already: <http://news.ycombinator.com/item?id=2907664>

</comment><comment><USER10> Was wondering when this would happen, took about 24 hours after they went on clearance for $100.</comment>


The Unbelievable Story of a Facebook Impostor - <AUTHOR> http://the-ken.com/the-unbelievable-story-of-a-facebook-impostor/?t=2317a310-7348-11e6-8807-3d27b63a55b2-db643261-252a-4e7e-95a6-f89a72c14fcc&utm_campaign=The%20Ken&utm_source=Email&utm_medium=Newsletter# <comment><USER2> If I have to sign up just to read it, it's not worth it. Even bothering with a mailinator address is not worth it.

</comment><comment><AUTHOR> Chilling account of how one Facebook impostor is wrecking havoc on lives of one Mumbai couple.</comment>


Why Do You Do What You Do? - <AUTHOR> http://www.fortworthstartups.com/2009/08/14/why-do-you-do-what-you-do/ <comment><USER2> That's easy for Apple to say ("Apple's goal isn't to make money. Our goal is to design and develop and bring to market good products"), because they are already a very successful company. Anything they sell will make money. As a struggling startup looking for investors, you don't have that luxury. You have to convince people that there is at least a possibility of profit down the line.</comment>


Complete e-mail sent by Levenson(Atlanta Hawks owner) - <AUTHOR> http://www.ajc.com/news/sports/basketball/complete-e-mail-sent-by-levenson/nhHbD/

<comment><USER2> Pardon my white male patriarchal cishet privilege here, but... what's so "racist" about this email? If anything his criticism is on white fans for being afraid of being in a majority-black crowd. It all appears to me to be as neutral of an observation as one could have in an inherently volatile subject.

</comment><comment><AUTHOR> Where is the line between targeted marketing and racism?</comment>


Ask HN: CoffeeScript used in open-source JavaScript libraries? - <AUTHOR>

There is a high likelihood that this question my erupt in a flamewar, but it's not intended to, so if you do choose to participate, please try to keep it civil.
So far, we've seen several arguments for and against CoffeeScript:
https://github.com/raganwald/homoiconic/blob/master/2011/12/jargon.md#readme
http://www.codethinked.com/a-case-for-using-coffeescript
http://userinexperience.com/?p=732
etc.
From my experience and all the arguments presented by both sides, CS appears to be an excellent tool when put in the right hands and used in a well set up development environment that has been tailored for coding in CoffeeScript.
The choice to use CoffeeScript or not appears to be as much a religious war as Emacs vs. Vim. Most arguments boil down to taste, and in some cases the social contract regarding tools that you've established with your team.
The question I have is if CoffeeScript in open-source
Javascript libraries is a net positive or net negative for Javascript. I can see arguments for both sides, but if the stakes aren't discussed I can see a potential tragedy of the commons where there are increasingly two versions of every javascript library, the one written in Javascript that receives few contributions from those who spend most of their time in CoffeeScript and those written in CoffeeScript that receive few contributions from those who don't use CoffeeScript and haven't tooled their environment to work effectively with it.
Despite the contentiousness of this issue, I'm curious to hear what others think.
Please leave your personal preferences at home (your dev env) and try to only discuss the pros and cons of CoffeeScript being used in open-source libraries and the impact is has on our community.
Social issues, community issues and language evolutions are fair game. Discussions of syntax preference should be avoided. <comment><USER2> I haven't used CS, but I expect its JS output to be more verbose than if someone had written the JS themself. This means the people trying to contribute with CS-JS will be adding longer code that doesn't fit with the coding style of the project, and will be much longer. It may be possible to change CS to output less verbosely, or to ignore the difference. I think the library's main writers will ask for contributions to be in JS, so it can be written to their coding style.

<comment><AUTHOR> There's another problem. I can't contribute to a CS project by modifying the JS, because as soon as the CS is compiled it will overwrite any changes I made to the JS. In a CS project, the JS technically shouldn't even be committed to the repository except maybe as a precompiled lib/ directory.</comment></comment>