Spark joy by running fewer tests - <AUTHOR> https://engineering.shopify.com/blogs/engineering/spark-joy-by-running-fewer-tests <comment><USER2> > Unfortunately, one can't fully eradicate intermittently failing tests,

Oh boy do I disagree with this. I have a zero tolerance policy for flaky tests. In code bases where I have the authority, I immediately remove flaky tests and notify the relevant teams. If you let flaky tests fester - or worse, hack together test re-runners and flaky reporters - they will erode trust in your test suite. "Just re-run the build" will become a common refrain, and hours are wasted performing re-runs instead of tracking down the actual problems causing the red tests.

<comment><USER3> I generally agree, but there's one thing that bothers me about the practice:

Before disabling the test, does anyone even consider the possibility that maybe it's not the test that's flaky, but that the software under test is itself buggy in a non-deterministic way?

I don't have a good answer for how to deal with this. It would be an enormous amount of effort to go through every flaky result and reason about whether the problem is with the test or the code under test, especially in larger codebases. Maybe the heuristic of assuming that it's the test's fault is good enough, and this is what I've done in every team I've worked in.

But it does bother me.

<comment><USER4> There's one particular domain where this question runs deep - tests that verify parts of distributed systems. Note: please do not extrapolate any problem described below outside of distributed systems.

For instance in Kubernetes we run lots of tests that verify parts of the system actually working together, not just mocked. A fair amount of the time, once tests are in and soaked, the test flake is actually the canary that says things like "no, the kernel regressed networking AGAIN" or "no, your retry failure means that etcd lost quorum - which shouldn't have happened, what on earth is going on, oh, someone suddenly started hotlooping and now the api server is performing 10k writes a second".

At some point, testing the system in isolation is not enough because all failures are interactions of multiple components. Your flakes are the evidence that the gigantic stack of software known as "modern computing run from HEAD lol" is full bugs.

It's definitely a culture change - once anyone anywhere thinks "oh it's just flaky" they stop treating it like signal. Once they treat it like noise, it's very hard to unwind.

Today, when I look at one of those test suites and see a flake, I assume that everything in open source is broken, again, and pull out the shovel, because 75% of the time it is.

<comment><USER4> Of course, to be able to see the signal, you have to be ruthless to noise. Deflake first, disable if you must, but never stop until it goes green and then be ruthless about keeping it that way.

</comment></comment></comment></comment><comment><USER5> As a long time DevOps engineer and now founder - my perspective on tests has really gone thru a rollercoaster. In the past life, I'd regularly be the guy rejecting deployments and asking for additional tests - barking at developers who ignored failures, lecturing on about the sanity saving features of a good integration test.

These days? Well the headlong rush to release features and fixes is a real thing. Ditching some tests in favor of manual verification is a good example of YC's advice "do things that don't scale". I add tests when the existential fear notches up - but not a whole lot before that.

Like with almost all topics in software development - the longer I'm in the field - the less intense my opinions become. The right answer: "eh, tests would be nice here! Let's get to that once the customer is happy!"

<comment><USER6> > Ditching some tests in favor of manual verification

I think that's the biggest problem with (unit) testing: there's too much "either test absolutely everything, or don't (unit) test anything at all" thinking. You can save yourself a lot of hassle if you just stick to writing tests for the things that are relatively straightforward to test: stay away from anything that requires an external system or anything that runs in parallel (multithreading, for example), and leave that stuff for manual testing.

A big benefit of having reasonable code coverage that I don't often see discussed is that if you have a unit test for each function in the system, you can also _run_ any function without recompiling and redeploying the entire app: when you've isolated the source of a problem, this capability can be a godsend in allowing you to iterate quickly to narrow down the cause. I invariably find myself stuck working with systems for which unit tests were never developed, so there's no way to test a change besides recompiling the whole thing, redeploying a whole environment, waiting for the whole thing to start up, firing up the UI, navigating to the problem spot, and finally testing what I was after in the first place.

<comment><USER7> > "You can save yourself a lot of hassle if you just stick to writing tests > for the things that are relatively straightforward to test"

Yup. Focus most of your effort on testing your pure functions. If you've followed functional core / imperative shell, typically what's left in the shell isn't very interesting from a testing perspective.

And if the majority of your codebase is still in the imperative shell, well, time to get to work :)

[https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

</comment></comment></comment><comment><USER8> I wonder if Marie Kondo-ing your tests is a good idea in general. This article reminded me a lot of "Write tests. Not too many. Mostly integration" [https://kentcdodds.com/blog/write-tests/](https://kentcdodds.com/blog/write- tests/) and other such articles for limiting testing, like this test diamond article [http://toddlittleweb.com/wordpress/2014/06/23/the-testing- di...](http://toddlittleweb.com/wordpress/2014/06/23/the-testing-diamond-and- the-pyramid-2/)

I've seen far too many unit tests at this point that just assumed too much to be meaningful, and conversations about unit testing quickly devolve into "no true scotsman" style arguments about what is truly a unit and what isn't.

<comment><USER9> Kent's article isn't so much about limiting the test coverage so much as preferring one kind (integration) over another (unit). He's right. Tons of unit testing in application codebases is a huge, stinking code smell in my experience. Usually it means the code is overly abstract (interfaces everywhere for "mockability") or unnecessarily complex (e.g. conditional expressions factored out into functions called in one site just so they can be tested separately) or both.

</comment></comment><comment><USER10> When it comes to testing, I now follow the advice of Gary Bernhardt's presentation, Functional Core, Imperative Shell: [https://www.destroyallsoftware.com/screencasts/catalog/funct...](https://www.destroyallsoftware.com/screencasts/catalog/functional- core-imperative-shell)

The idea is to move all the logic of your app into pure functions that can be tested on the order of milliseconds. When you refactor your code to allow for this, everything just makes more sense. Tests can be run more often and you are far more confident about the behaviour of your code.

<comment> 8192kjshad09- Maybe I just don't get it, but this design seems impractical for systems that use the network alot.

I work on an app whose basic structure is

1\. Receive data from a webhook (not controlled by me) 2\. Make some HTTP requests based on data from 1 3\. Send data to another HTTP API

The core of the logic is in step 2. How can I possibly have a functional core here? Step 2s behavior completely depends on the HTTP responses.

<comment><USER11> The idea is that your server handler mimics those steps and contains _all_ the IO you need (aka external depdendencies). The receiving and sending of the http requests + any other I/O you need should be immediately visible in the top level method (in a simple model). Everything below is functional and pure. Take a request, use pure functions to transform and reshape the data, pass that back up the call-stack to the top level method. Do some I/O operation against the database, go into functional land to shape it a bit, bring it back up, combine with other data in a pure way and then finally send the response.

</comment></comment></comment><comment><USER12> I wonder if they considered using something like ptrace to track which .rb files a given test suite loads? This would probably be orders of magnitude faster than Rotoscope or Tracepoint. You'd get a much "coarser" data set, since you wouldn't know which individual tests called which modules (unless you run each test case in it's own Ruby runtime). On the upside, you'd be able to watch JSON and YAML files.

<comment><USER13> > I wonder if they considered using something like ptrace to track which .rb > files a given test suite loads?

It's not really possible as we eager load the entire application on CI. And even if we didn't to trace depedencies like this we'd need to boot the application in lazy load mode for each test suite, that alone would be slower than running the entire test suite.

</comment></comment><comment><USER14> When it comes to browser automation tests, everywhere I've worked at suffered from intermittently failing tests. When I was at the Ministry of Justice (UK), I configured CircleCI to run tests hundreds of times [1] (over a number of days) through cron jobs. This allowed me to reflect on all test results, and find out what failed most often and eventually solve those root causes. This strategy worked well.

Interestingly enough, just today I posted a GitHub thread [2] and asked the community to 'thumbs up' the video course they'd like for me to create. "Learn Browser Automation" is currently the highest voted. If it's the one I end up making, a huge focus will absolutely be on: How to reduce test flakiness with headless browsers.

Words of advice, avoiding sleep() and other brittle bits of code will help. But in addition, run your tests frequently to catch out the flakiness early. Invest in tooling which helps you diagnose failing tests (screenshots, devtools trace dumps). Configure something like VNC so you can remotely connect to the machine running the test.

[1] [https://github.com/ministryofjustice/fb-automated- tests/blob...](https://github.com/ministryofjustice/fb-automated- tests/blob/7c9cee58db902419abf5449aaef6e91e575502d9/.circleci/config.yml#L52)

[2] [https://github.com/umaar/dev-tips- tracker/issues/33](https://github.com/umaar/dev-tips-tracker/issues/33)

</comment><comment><USER15> I think this shows how counting on horizontal scaling to handle inefficiency only works for a while, and will eventually introduce its own set of complexities - and dealing with those might be more trouble than coding things more efficiently in the first place. Then again, maybe it's worth it for a huge company like Shopify, because they save work for the feature devs by adding extra load on the test infrastructure devs, effectively increasing developer parallelism.

Finally I wonder if they could have done more to speed up their tests? I'm maintaining a Rails codebase too, and I cut test time down by two thirds by rewriting tests with efficiency in mind - e.g. by ignoring dogma like 'each test needs to run completely independently of previous ones' (if I verify the state between tests, do I really need to pay the performance penalty of a database wipe?) The test-prof gem has a great tool, let-it-be, that allows you to designate db state that should not get wiped between tests. That and focusing on more unit tests and fewer integration test has really gone a long way toward speeding things up again for me.

</comment><comment><USER16> > Before the feature was rolled out, many developers were skeptical that it > would work. Frankly, I was one of them.

Kudos for the Skepticism section. Every "how we fixed problem X at company Y" should have this section, and esp. written by someone who opposed the solution. The challenging and battle stories tend to be the most interesting part, at least for me.

</comment><comment><USER17> Interesting that they don't talk about Bazel. Isn't skipping tests like this one of its biggest selling points, particularly for monorepo users?

<comment><USER18> Exactly. The first thing they should dispense with is the idea that they should run _all_ the tests in the monorepo. That's what doesn't scale.

Run only the effected tests and the overhead is now more proportional the potential impact of the change.

<comment><USER17> That seemed to be what they were describing, but with dynamic dependency detection via introspection.

</comment></comment></comment><comment> Seb-C My experience is that most of the time, randomly failing tests are actually failing because they were made to be random.

Sure, adding Faker to your test/mock data may help you to find rare edge cases. The problem is that those edge cases will be triggered in the future, in another context and by another developer. So not only it probably won't be fixed, but it will be a waste of time and annoyance for someone. Same thing for some option like the `random` setting in Jasmine (runs your unit tests in a different random order each time).

So now I only have tests with static, predictable data.

Having tests that depends on the state of the previous one (or are affected by it) is quite common too. And not always easy to fix properly.

Once this is removed, the remaining random failures are usually authentic and helpful.

</comment><comment><USER19> And here's a makefile implementation with a statically typed language:

      #run test and output to a .testresult file when the test is modified
      %.testresult: %.test
        $< > $@ 2>&1

      #depends on a .testresult file for each test
      test: $(ALL_TEST_RESULTS)
        cat $(ALL_TEST_RESULTS)

Sure the dynamic typing introduces many problems, but surely you could have something a bit more half way like "%.testresult: %.test $(DEPENENDENCIES) $(METAPROGRAMMING_MAGIC_DEPENDENCIES)", then only hopefully rare changes to the core files require the full test suite to be rerun. Seems like dynamic typing is the core of their problem though and this is a crazy complicated solution to try and work around that.

<comment><USER20> > $< 2&1> $@

I'm not really well versed in Makefiles, but that seems to pass the argument "2" to the testing program, launching it in the background with "&", and then doing a redirection for the stdout of an empty command to the target file with "1>".

I think you meant

      $< > $@ 2>&1

which could also be

      $< &> $@

I can't see how your example relates to static or dynamic typing, though.

<comment><USER19> Fixed, the former is correct, the latter I think is a bashism that may not work. Unfortunately I plucked that from a project in a very broken state.

> I can't see how your example relates to static or dynamic typing, though.

Because with static typing you know the object/file graph at compile time and only affected tests need to be run. In that example the .test files will only be built when their dependencies change and .testresult will only be created if .test is built, everything is incremental and "make test" won't execute any tests if there are no changes that could affect them.

<comment><USER21> You know this in dynamic languages too, based on imports.

So if you have the build graph represented for your dynamic language, you get the same result.

This is just a poor (poor, poor) buggy implementation of Bazel.

</comment></comment></comment></comment><comment><USER22> The approach they use to apply this to a large Ruby project is interesting but this type of strategy has been in use since forever and at least to me, seems fairly obvious.

Running _all_ the tests with every build is always a bad idea. A better approach that doesn't require fancy dynamic analysis is to organize tests in a way that it's clear what's likely to break and to make sure you're constantly running your test suite in QA environments.

Making a change to a module should force you to run that module's test suite. Interactions between modules can be tested all day in a loop and monitored before deploying to production.

</comment><comment><USER23> I wonder if the tests are even serving a purpose at that point? If they can't reliably answer the question "did I accidentally break something" in a reasonable period of time what's the point?

</comment><comment><USER24> We just did pretty much the exact same thing with a large in-house ETL application. We can do great static analysis of the dependencies of different jobs and the coverage of various tests. Most PRs are now running a tiny fraction of the test suite (thousands of tests total) in minutes instead of an hour. Run all test cases before deployment of master just in case we missed something.

<comment><USER25> Was there internal resistance to this, and if so what was it?

</comment></comment><comment><USER26> > has over 150,000 tests

> takes about 30-40 min to run on hundreds of docker containers in parallel

This seems like it might be a signal that now could be the time to start splitting services out in an SOA fashion and having their own test suites and some contract driven tests? Having to run that many tests on each commit is definitely a smell that something architecturally fundamental is wrong...

</comment><comment><USER27> This sort of thing is why I always scoff at the idea of slow compile times for static strongly typed languages (eg. Scala, Haskell, OCaml, Rust, etc).

Sure, it definitely compiles slower than some other compiled language, and there is no compilation for an interpreted language. But if you factor in testing, the type systems of those languages can easily remove a massive amount of testing that other less rigorous languages would either a) not test at all, or b) test at a significant cost. I'd be willing to bet that if shopify were using a strongly typed language, 50-90% of their testing would be completely redundant, because the type system already takes care of it.

That isn't to say that there are not reasons to use dynamically typed languages...just that if you are building production systems in strongly typed languages, compile time is almost completely irrelevant as a factor in productivity, regardless of how much slower they compile in comparison to an alternative.

</comment><comment><USER28> Does anyone have thoughts on whether test suites suffer from Goodhart's law? Sometimes I feel like they only work well if people assume they don't exist and commit accordingly.

<comment><USER12> My dad was a huge proponent of this back when he was in software; don't tell you developers what tests failed, only what percentage of tests failed.

A software test is, in many ways, like an exam you might write in university; just like an exam can't possibly cover 100% of what you're supposed to know, a test (especially an integration test for a large and complex system) can't possibly cover 100% of the conditions the system is supposed to operate under. An exam is a good way to measure if you know a subject though, and similarly a test suite is a good way to check that the quality of a system meets a certain bar.

Once you write the exam, if I go back and say "Here are all the questions you got wrong. Go study up and write the same exam tomorrow," though, it very much ceases to be a good measure of whether or not you know the subject matter. You can now "cheat the system" by studying only the parts of the subject that the exam covers.

Similarly, once your integration tests are failing, if someone tells you which tests are failing and how, you're going to go back and fix only what you need to get the tests passing. At this point, the tests stop being a good indication of code quality - 100% of the tests are passing, but you can't say that 100% of the defects have been removed, so the tests are, in a sense, now kind of worthless. They might stop a limited number of future defects getting in, but they're not doing an arguably much more important job of telling you what your overall quality level is.

If instead, when you submit a commit, I say "5% of the tests are now failing" and nothing else, you have to go look for defects in your code, and you're probably going to find a lot of defects on your own before you even get to the 5% that the tests are complaining about.

<comment><USER2> This sounds like a fun game to play with a team of developers who have no time constraints. In every organisation I've worked with you would get a very stern talking to for behaving like this.

My tests are specifically designed to show you where the defect is, so you can solve the immediate problem and get back to work. I don't expect every developer who triggered a failing test to perform a full analysis of the code base and resolve every other defect. That would be nice, if we had the time.

<comment><USER12> I'll prefix by saying that this is exactly how I write my tests, too. But, let's do a little critical thinking here and ask "Why do we write integration tests?" If the goal is to improve software quality, I'm afraid I have some disappointing results for you.

Back when my dad was working at a huge software company (BigCorp, let's say), he looked at how much effort the manual test team spent over a two week period, and how many defects they found. Then he did the same over the next two week period. Now, logically, in that second period, some of the earlier defects had been found and fixed, so it should now be harder to find defects, so the total defect count per unit of test effort should be lower, right? Armed with two data points, he did a regression and worked out how many defects they'd find if they did an infinite amount of testing; effectively the undiscovered defect count left in the product. The number he got was astoundingly huge - no one believed this was possible. So, he went over to the plotter and plotted out a giant effort/defect count curve, and then every two weeks he'd put a pin in his plot to show reality vs. his prediction, and for months and months until he got tired of doing it, he was pretty dead on. And he didn't just do this for one project, he did it for lots of projects, across lots of different teams of various sizes.

On all of these projects, all the manual testing they could possibly hope to accomplish if they had their entire testing staff spend 100 years testing would have reduced the overall defect count by a tiny tiny fraction of a percent. So testing and then fixing bugs found in tests (at least in all the projects at BigCorp) didn't really have a huge impact on software quality.

And this should not really be a surprise; if you were manufacturing cars, you might test the power seats on every 100th car, and use this to figure out what the quality of power seats in your cars is. You might discovery only 95% of power seats are working, and you might think that's unacceptable. If you do, though, you're not going to "solve" the problem by fixing all the broken power seats you test; you're going to go figure out where in your manufacturing process/supply chain things are going wrong and fix the problem there, and improve your quality. The testing is a measure of your process.

Software is not so different - by the time it gets to integration testing, the code has been written. The level of quality of the code has largely already been set at this point - all the defects that are going to be introduced have already been introduced. The quality level is dependent upon your process and the skill level of your developers. So testing some arbitrary fraction of the lines-of-code is going to find problems in some percentage of those lines-of- code, but fixing those particular problems? Is this going to have a huge impact on quality?

<comment><USER29> > you're not going to "solve" the problem by fixing all the broken power seats > you test; you're going to go figure out where in your manufacturing > process/supply chain things are going wrong

I think the point is that examining the failing seats will lead you to the points in process that should be fixed. Therefore you can fix the issue more efficiently than going through the whole process. Similar as with knowing details about failing software tests.

Imagine I hide the information about seats and tell you 10% of the finished cars have "some" defect. Where would you even start looking in the factory?</comment></comment></comment></comment></comment>


The search for Betsy, bovine escape artist - <AUTHOR> https://story.californiasunday.com/escape-betsy-the-cow <comment><USER2> > If he were to get Betsy back, he's already planned to throw a barbecue for > the Fat Tire bike group and the rest of the public.

Oh no.

> He would corral Betsy and have her attend the party, too.

 _whew_</comment>


The Lost State of Jefferson  - <AUTHOR> http://strangemaps.wordpress.com/2010/04/20/458-the-lost-state-of-jefferson/

<comment><USER2> wow - crazy that this popped up tonight.

A friend and I just finished a project based on this. It's called "The Virtual State of Jefferson" - it's a router that alters pages to "claim" cities in that area. I just posted a tech description about how the project works: <http://ethanmiller.name/notes/virtual_state_jefferson_tech/>

</comment><comment><USER3> Beautiful area of the country... I sometimes think about moving to Southern Oregon, but there isn't a lot of tech work there.

That corner of California also has some extremely remote and isolated areas:

<http://en.wikipedia.org/wiki/Trinity_County,_California>

"Trinity County has no traffic lights, freeways, parking meters, or incorporated cities. Trinity County did not have a chain store or restaurant until 1999, when Burger King, Movie Gallery, Longs Drugs (now CVS/pharmacy), and Subway opened for business."

All in all, a large and fascinating area to explore.

<comment><USER3> Hrmph... this article got my all nostalgic! Now I feel like driving around in remote places this summer, but it's a bit of a stretch from here in Italy to there...

</comment></comment><comment><USER4> Cascadia!

[http://en.wikipedia.org/wiki/Cascadia_(independence_movement...](http://en.wikipedia.org/wiki/Cascadia_\(independence_movement\)#History)

Not to be confused with the Secession Cascadian Dark Ale from HUB, <http://beeradvocate.com/beer/profile/16353/51065>

<comment><USER5> Mmmmm, Hopworks Urban Brewery...

Their brew master is my neighbour, super nice guy.

</comment></comment><comment><USER6> We were in Ashland,OR for the Oregon Shakespeare Festival a few years ago. The public radio station repeatedly said they were located in "the mythical state of Jefferson".

</comment><comment><USER7> Let's also not forget the lost state of Franklin, and the Indian Stream Republic. US history is littered with similar examples.</comment>


Covid-19 crisis will wipe out demand for fossil fuels, says IEA - <AUTHOR> https://www.theguardian.com/business/2020/apr/30/covid-19-crisis-demand-fossil-fuels-iea-renewable-electricity <comment><USER2> that sounds like wishful thinking. modern sustainable energy sources are not yet sustainable really unfortunately. also the crisis will end much sooner than economy could possibly make a switch.</comment>


Fuck Microsoft - <AUTHOR> http://fuck.microsoft/

<comment><USER2>
      $ dig +short fuck.microsoft
      127.0.53.53
      $

It is part of the ICANN-mandated "controlled interruption" phase of launching a new TLD before production usage. [https://www.icann.org/resources/pages/name- collision-2013-12...](https://www.icann.org/resources/pages/name- collision-2013-12-06-en#127.0.53.53)

<comment><USER3>
        $ dig +short foo.meme
        127.0.53.53
        $

It's the same for .meme, which is owned by Google if I'm not mistaken.

</comment></comment><comment><AUTHOR> So, Microsoft registrated some top level domains, like MICROSOFT, XBOX, WINDOWS, AZURE, BING and HOTMAIL, as we can see here: [http://newgtlds.icann.org/en/program-status/delegated- string...](http://newgtlds.icann.org/en/program-status/delegated-strings)

But they didn't add any content yet. So, just a joke showing "Apache2 Ubuntu Default Page".

<comment><USER2> The Apache2 Ubuntu Default Page is presumably on your localhost?

<comment><USER4> Haha might want to turn that off...

</comment></comment></comment><comment><USER5> would be pretty awesome if they made it so if you have an xbox live account you get Username.xbox for your xbox profile page or something

BTW [http://nic.microsoft/](http://nic.microsoft/) Edit: You can use nic infront of pretty much all of microsofts ones</comment>


Internet.org - <AUTHOR> http://www.internet.org/

<comment><USER2> Really it feels good to know @google (Project Loon) and @facebook (Internet.org) are working towards making Internet available to everyone...</comment>


Wireshark 2.0.0 Released - <AUTHOR> https://www.wireshark.org/news/20151118.html <comment><USER2> This is the first version of Wireshark that's OS X native.</comment>


Tesla and other EVs will be overtaken by hydrogen cars by 2030 - <AUTHOR> https://www.teslarati.com/tesla-evs-will-be-killed-by-hydrogen-cars-continental-executive/ <comment><USER2> I had to double check when this article was released... to my surprise it was written in 2019.

I assumed it was from the early 2010s back when Toyota and Honda were pushing the fuel cell tech... Mainly so they could work with the existing energy (petroleum) industry to retrofit gas stations.

The good news is that it was all vaporware anyway. I think Honda's clarity was going for $350K or something... who knows though maybe people will prefer $350K to using a supercharger on trips ¯\\_(ツ)_/¯

</comment><comment><USER3> Unlikely. Hydrogen in this use is a pollution amplifier. Additionally it is very dangerous to store and transport. A hydrogen fire has no color. Hydrogen make metal brittle and likely to fracture.</comment>


OpenSSL 3 Strategic Architecture - <AUTHOR> https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html <comment><USER2> The OpenSSL strategy seems to be to try to leapfrog LibreSSL in terms of version numbers (which already has released a 2.x branch, hence their 3.x versioning), and revise their API, but still have considerable complexity.

The LibreSSL approach was to write a new library and API, libtls, which does away with the substantial configuration complexity in applications: [https://man.openbsd.org/tls_init.3](https://man.openbsd.org/tls_init.3)

I'd argue that LibreSSL's is the better approach.

<comment><USER3> It is supremely unlikely Akamai (via Rich Salz who is leading and has led a lot of post heartbleed fixup) take libressl seriously at all nor do any other large contributing company. People in the FreeBSD community knew libressl would be a flash in the pan given the personalities involved and FreeBSD has legitimate large scale commercial usage.

<comment><USER4> OpenVPN also disclaims any interoperability with LibreSSL.

"Please note that LibreSSL is not a supported crypto backend. We accept patches and we do test on OpenBSD 6.0 which comes with LibreSSL, but if newer versions of LIbreSSL break API compatibility we do not take responsibility to fix that."

</comment></comment></comment><comment><USER5> _The Core will implement a property based look-up feature for finding algorithms, e.g. it might allow you find an algorithm where "fips=true", or "keysize=128, constant_time=true"._

Why? What designer builds a system this way, without knowing precisely what algorithm they're using?

<comment><USER6> The fips example seems like a good one. _" Don't care how, tick this box so I'm compliant with my government contract"_.

Not arguing it's a good idea, just that it might be wanted.

<comment><USER7> Wanted the same way HIGH:MEDIUM:LOW was wanted, with a new recipe for late binding of noncomposable abstractions. Same outcome expected.

</comment></comment></comment><comment><USER8> Yikes. Backwards compatibility is tough.

Strange that with the bump to 3.0 they didn't at least announce the removal legacy primitives and TLS versions. Are they going to support DES and RC4 forever?

<comment><USER9> _Are they going to support DES and RC4 forever?_

It might not be the exact use-case for OpenSSL but there's plenty of existing content or protocols using those algorithms, which no one is going to bother changing ("encrypted" PDFs come to mind).

In any case not having RC4 isn't such a big deal; it's a tiny algorithm you could literally memorise and write into where it's needed (which I suspect is why it became so popular.) DES is a bit trickier though.

<comment><USER8> Let PDF readers find their own DES library. Or at lest make its non-default part of the build.

But even having it there as optional is risky and adds to an already huge maintenance burden. You know the distro packagers will enable every feature just like they did with DTLS support (which is what made Heartbleed pervasive).

Packagers don't want to deal with complaints and support tickets because their OpenSSL build doesn't do 3DES. So they turn on all the things.

</comment></comment></comment><comment><USER10> Still prefer libressl. A shame that openssl's history of failing at security is rewarded with donations and use, rather than shunned.

<comment><USER11> But libressl breaks ABI compatibility (see that BSD is taking a step backward).

OpenSSL is affected by what we can call "fame". It's the mostly wide used security library in the whole internet and it's the favourite target for hackers. For comparison, it's the same that happens to OS: windows and android are the preferred target platforms because of the large user base they have.

<comment><USER12> > But libressl breaks ABI compatibility

Who cares? Compatibility with insecurity is not a goal.

<comment><USER13> Are you volunteering to patch every program which uses OpenSSL? If not, you have the answer: it's been widespread for decades and so many things use it that compatibility is a big concern. Think about a distribution like Debian with thousands of packages, some of which update frequently and others which haven't been updated in years. If it's compatible, you can ship one shared library update but if it's not you're either not upgrading or maintaining a ton of patches.

<comment><USER14> Debian is a bad example; they compile everything from scratch, they don't need ABI compatibility.

</comment></comment></comment></comment></comment><comment><USER7> Neat. I look forward to better FIPS handling and the deprecation story.

And to vulnerabilities from the loadable module support. Getting the property based binding right looks tough!</comment>


HN Meetup - New Delhi(NCR) India - <AUTHOR>

Folks we are having a Hacker News Meetup in New Delhi on May 30th, 2010 - thats a Sunday. Exact time and place will be communicated later on email. If you are coming over drop me an email, so we can make the necessary arrangements.<p>kashif.razzaqui [at] gmail <comment><USER2> This is great! And it falls a few days after my exams, too :)

<comment><AUTHOR> Well lets hope more people sign-up.

<comment><USER2> I'll email this to a couple of people who might be interested.

<comment><AUTHOR> Yes lets spread the word. I will repost this in a couple of weeks to cover folks who didn't see it this time.

</comment></comment></comment></comment><comment><USER3> I'm in.

</comment><comment><USER4> any in hyderabad or bangalore?

<comment><USER5> Any such meetup in Bangalore? Could be made monthly or heck even twice a month to show off hacks or share ideas?

I'm in if you are in Bangalore!

<comment><USER4> I'm in the UK at the moment but will in Hyderabad soon and will be frequenting Bangalore. What is the hacker scene in Bangalore? Do you attend any other conferences/meetups?

<comment><USER5> Ya I used to be a BarCamp regular, but the last BarCamp was a year ago. Hackday was again was a year and half ago. But it would be nice if there were more hackdays. There are startup conf like Proto.in and HeadStart and StartupSaturdays etc, but they are mostly invite-only and the topics sound boring. I would vote for anything that's sort hacker-ish :)

(tried to find your email address on your profile). My email is on my profile. Mail me if you are interested in starting a hacker meetup in Bangalore or if you are attending one.

</comment></comment></comment></comment><comment><USER6> I just hope there could've been something like this in Ahmedabad, or that I could be in Delhi

<comment><USER6> Can I please request lots of videos and someone posting a complete account on a blog?</comment></comment>


Harvard Study Questions "Long Tail" Theory - <AUTHOR> http://harvardbusinessonline.hbsp.harvard.edu/hbsp/hbr/articles/article.jsp?OPERATION_TYPE=CHECK_COOKIE&referer=/hbsp/hbr/articles/article.jsp&productId=R0807H&TRUE=TRUE&reason=freeContent&FALSE=FALSE&ml_subscriber=true&_requestid=13055&ml_action=get-article&ml_issueid=BR0807&articleID=R0807H&pageNumber=1 <comment><USER2> I got to two pages: (1) asked me to login, and (2) "In order to access articles on HBR Online, you must agree to the terms and conditions that apply. Click 'Accept'"

I clicked Accept and was in but come on - I have agree to TOS to read?</comment>


Lessons from a Dell Executive who Joined a YC Startup - <AUTHOR> http://ownlocal.com/newspaper-support-group/interview-with-lamar-romero-ownlocals-vp-of-sales/

<comment><USER2> Congrats on jumping from sales at a large multi-national to a startup. I've move into progressively smaller companies (Now running a very small startup) and the smaller they are the more full of life they have seemed to be. This is the way it should be.

Although I cringed at reading a couple of the lines here, specifically the book on sales and clearly defining roles. I have tried something similar in my past and I consider it to be one of my mistakes. I like creating structure around chaos but I've found these methodologies to be the bane of a startup or small company's culture and ability to move forward. They're like poison. Do they work in larger corporations? _I think so. Maybe._ I've used some of them successfully (Also consider this to be among my many mistakes). But everyone you deal with is much more apathetic, they're willing to tolerate more and/or will just ignore it. In a startup everything is much more sensitive and I find that excessive structure and process kills, well, _everything_.

I have spent a fair bit of time in sales at different levels (Retail to long cycle million dollar B2B) and I cringe at these books and training seminars. Going on the road and selling with someone good in real-time is _far more_ valuable than any book or seminar. The good reps that I've seen already do the things they teach at some level naturally and few of them have read books or gone to a ton of seminars (I have witnessed one or two cases where a well performing rep followed these things religiously but seemed successful in spite of them not because of them).

Now that I've effectively ragged on your approach (Which I really can't tell exactly what it is from this simple blog post, I'm hinging it all on two things I read - I apologize if it's not an accurate representation of your approach), you may be right and I may be wrong. There doesn't seem to be one right way...

<comment><AUTHOR> I don't think Lamar would disagree that going into the field is more valuable than any book or seminar. In fact, that's pretty much where all of the sales strategies we use are battle-tested and refined. As a startup, in many cases we've opted to hire someone without the immediate skillset (out of college) but who has potential to succeed. We need a common vocabulary, a common set of expectations, and a knowledge base to work from.

Books like this one are the net, not the trapeze act.

</comment></comment><comment><USER3> I think a lot of the HN crowd will read this and cringe at what they see. Remember, this is sales. It's about "programming with humans". A developer does effectively the same thing with the systems they build. A VP of sales is trying to build a system as well.

The corporate culture is important no matter the department, but you have to remember that sales guys are very different animals. They'll do whatever it takes to make the sale. It's the burnout you need to manage.

<comment><USER4> By the same logic, you should be able to "program with programmers", and apply the same thinking to teams of developers. It's exactly this MBAness that HN rails against. I'm not saying one paradigm is superior to the other, but I would caution against the facile sort of thinking that places developers above other mere mortals. It's tempting to think that _we_ need to be able to spread our wings and realize our potential, while _they_ are best managed and regimented in a programatic fashion, but that sort of distinction requires an argument that seems to be lacking.

If we acknowledge that a sales force can benefit from this kind of regimentation, then we must either allow for the same to be true of developers, or offer a convincing argument as to why it can't be.

<comment><AUTHOR> Programming is an inherently creative act. Sales isn't always. The goal with most sales organizations is to replicate a process that works on a regular basis and at scale. Programmers are composers, most sales teams are like musicians in the orchestra. Both are really important to making the music happen. One is creating processes. One is executing on it.

</comment></comment></comment><comment><USER5> Sounds like he's going against all the things that make a startup fun. Reading a 'sales bible' sure isn't on my list of exciting things to do when I join/create a startup.

<comment><AUTHOR> We have lots of fun. In fact, in many ways, processes like these allow for our team to focus on innovating and doing cool things instead of just "winging it" every time.

<comment><USER6> Clearly Sandler Sales Tech and just winging it are not the only two options. Understandably, it's important to get your sales team up to speed, and using various sales systems might help, but the team itself should really be the focus in which to discover the speed. Mentoring, performance transparency, strategic incentives, and regular recognition of top performers will have more benefits that some 'off the shelf' system. What I found most revealing was that when the sales team was flying blind without a marketing plan, no matter what system they were using (hello cold calls?) they were spinning their wheels. Instead, building a comprehensive marketing / sales program resulted in better client outreach. This reinforces the basic fact that every product or service should have a marketing plan attached to it to lay the groundwork for the sales process that follows. And that question is simply answered by asking 'Who wants it, and how will we best let them know about it?'. To that answer, I doubt - cold calls 'brrr' - will ever be a top choice. Otherwise, thanks for sharing your team members stories.

ps. here are the 2 starred reviews from the 'you can't teach a kid to ride a bike at a seminar' book (what kind of title is that anyways? Surely you CAN teach a kid to ride a bike at a seminar. How better to teach a kid? By having them read a book? Maybe it should be called 'you can't teach a kid to ride a bike by reading a book'. Regardless, my point is that some of these concerns appear rather valid (though I've not read the book myself.)

[http://www.amazon.com/Cant-Teach-Ride-Bike- Seminar/product-r...](http://www.amazon.com/Cant-Teach-Ride-Bike- Seminar/product- reviews/0967179904/ref=cm_cr_pr_hist_2?ie=UTF8&showViewpoints=0&filterBy=addTwoStar)

</comment></comment></comment><comment><USER7> Minor nitpick: I cannot scroll the text using the page down key without missing half a line.</comment>


Piracy: The people vs the entertainment industry - <AUTHOR> http://www.newscientist.com/article/mg20427375.200-net-piracy-the-people-vs-the-entertainment-industry.html?DCMP=OTC-rss&nsref=tech <comment><USER2> Would it even work to monitor all the internet traffic? Couldn't the pirates just encrypt it?

<comment><USER3> Yes, but it's a step to put in place the technology and legal framework to casually snoop on the entire population. I don't feel this is about piracy in the long run, but about our governments fear that control of the internet - increasingly so important to the general populace - is running away from them. They have appeared equally desperate in trying to force the big players (Google, Facebook etc) to provide access to social information. The temptation is just too great.</comment></comment>


Facebook is building brain-computer interfaces for typing and skin-hearing - <AUTHOR> https://techcrunch.com/2017/04/19/facebook-brain-interface/ <comment><USER2> An advertising company wants mainline access to my brain and vital signs. What could go wrong?

(Note: You know you're getting old when you start to get concerned about the privacy of these things. If you'd told me when I started in tech that people would be voluntarily buying always-on microphones sold by advertising companies and putting them in their houses, I would've called you insane. Who knows, maybe this will work).

<comment><USER3> I look forward to the day when we start having to develop the Ghostery for preventing ads that track our identity via facial/gait recognition, and the brain and skin.

<comment><USER4> Why Ghostery? There are addons now that provide better functionality without the awful redesigned interface.

</comment></comment></comment><comment><USER5> What is unclear (at least to me) is how much of this tech actually exists, and how much FB is simply stating their aspirations.

There is such optimism in tech that we take claims like being able to "type at 100 words per minute" without invasive surgery at face value. And there is such cynicism that we are (or at least I am) terrified of the sort of society this would create. But can anyone actively researching this field comment on how feasible this is _with invasive surgery_ , never mind without?

<comment> yoz-y I have been working in BCI for 6 years and to me this is a total moonshot (the writing part). There is currently no affordable technology that can scan the brain at the necessary temporal and spatial resolution to even approach the precision of implants. The main problem is that bones and cerebrospinal fluid dilute the currents a lot. I suppose they want to make something like wearable IRM but that is impossible with our current tech. State of the art typing BCIs have speeds in letters per minute. What we need is a breakthrough in sensor technology, if Facebook can manage that then the field will be able to make a huge leap.

<comment><USER6> If you read through the article they don't seem to be talking about BCIs at all, just a camera that reads subvocalisations. I'm surprised they can be detected visually, but once you do that it's functionally audio processing.

Not to underplay the significance if it works, it'd be an enormous achievement if they could get it working outside of lab conditions, but a BCI it is not.

<comment> yoz-y In article they mention to use brain imaging to detect the speech patterns in the brain. I have limited knowledge of subvocalisation but would not that be detected on the throat? There were experiments with implants using phoneme detection and they worked but that gives you only vowels. I will post the article if I can find it.

</comment></comment></comment></comment><comment><USER7> "This isn't about decoding random thoughts. This is about decoding the words you've already decided to share by sending them to the speech center of your brain."

Somehow this still doesn't make me feel at ease.

<comment><USER8> A future skill may be not thinking verbally.

<comment><USER9> When I was younger I used to try not to subvocalise (?) my computer passwords, thinking that might stop someone reading my mind. Might start that again

<comment><USER10> Nasa had an article[0] back in 2004 where they could detect what you were saying with sub vocalization on the skin and were already working on technology to read it through cloths back then, so not to get too tinfoil hat but that might not be all that bad of an idea.

[0][https://www.nasa.gov/home/hqnews/2004/mar/HQ_04093_subvocal_...](https://www.nasa.gov/home/hqnews/2004/mar/HQ_04093_subvocal_speech.html)

</comment></comment></comment></comment><comment><USER11> I deal with OCD of the intrusive thought variety. Sometimes my brain gets stuck in a loop of my deepest fears coming true. In fact, sometimes just a single "trigger" word will get stuck repeating itself over and over in my head.

The idea of having a brain-computer interface recording this activity is an absolute non-starter for me.

But then again, maybe this would all normalize some of my own mental activity, if it was more public how strange everyone's minds can act at times.

<comment><USER12> Here's s technique I've found helpful for intrusive thoughts. It's like stack overflowing your imagination with a vivid internal ritual, which overwrites all the frames containing unpleasant thoughts.

I imagine writing the details of the unpleasant thought or image down in vim. This converts the thought to "something I am observing" vs "something i and xperiencing."

Then the ritual plays out, where inmagine the same sequence of events: saving the file in vim to disk. Copying the file to a USB memory stic. Putting that stick into a ziploc back. Putting that bag into a specific pocket in my backpack. Getting my backpack and getting on my bike. Biking from my old apartment (where I lived when I developed this technique) and bike down 101 to moffet Air Force base, where I throw the backpack into a conveyor chute to a rock, which launches the backpack into space.

Sometimes I had to repeat the ritual a few times, but afterward, the image or thought recedes in intensity.

<comment><USER13> You should consider using emacs instead of vim, because it can easily handle saving the file to disk, copying it to a USB memory stick, putting it into a ziploc bag, biking it down 101 to Moffet, throwing it onto a conveyer belt into a rocket, and launching it into space, all automatically, in one single keystroke!

</comment></comment></comment><comment><USER14> If there's one company I won't let into my brain, it's Facebook.

<comment><USER15> But they're changing* the world!

* for some negative value of "change"

</comment></comment><comment><USER16> I had the idea of using skin as input for sound and light a long time ago as a kid. I've since seen something using the tongue but not much else. It'll be interesting to see what comes out of it. How many nerve endings are connected to the brain through eyes and ears vs skin (and what the heck is 2 m2 supposed to mean)?

As for the brain interface, outside of helping people with severe disabilities, no thank you.

<comment><USER17> I worked on vibrotactile and electrotactile technologies (Mostly on the tongue, belly or chest...) for years. The most sensitive part of your body is the tongue, that's where you would get the best resolution. You could turn a b/w images, process it and lower the resolution, then turn the white into levels of stimulation. Unfortunately, the resolution on the tongue display is 20x20. It has its limitation, in a controlled environment we trained people to read 4-5 letter words in few seconds or distinguish shapes. For spatial orientation, it's better to use systems similar to a lidar and use a tactile vest to inform the user how close is the collision.

The best use of these systems were for training formula 1 drivers (clue for shifting, braking, timing...), force feedbacks for telesurgery or restauring proprioception for exoskeleton users.

[https://www.ihmc.us/research/multi-sensory-multi-modal- neura...](https://www.ihmc.us/research/multi-sensory-multi-modal-neural- interfaces/)

[https://www.sages.org/meetings/annual-meeting/abstracts- arch...](https://www.sages.org/meetings/annual-meeting/abstracts-archive/an- anthro-centric-multisensory-interface-for-sensory-augmentation-of-tele- surgery/)

[http://downloads.hindawi.com/journals/jr/2011/284352.pdf](http://downloads.hindawi.com/journals/jr/2011/284352.pdf)

</comment></comment><comment><USER18> I checked the date, but nope, it's not April Fool's today.

So apparently, yes, FaceBook is working on devices that will allow you to type with your brain.

In return, FaceBook will need from you only access to your thoughts, and maybe your moods and emotions too?

Rest assured, advertisers will happily pay for them.

<comment><USER19> The ability to use BCI != ability to access your thoughts. The technology doesn't, and probably won't for a long while yet, for the latter to start with. Facebook already has access to active user's thoughts, moods, and emotions anyway; they share them willingly and in a much more machine friendly fashion than brain waves.

Brain enabled typing is going to be the future of hands free devices, and you're better off trying to beat them to market than lamenting the "evil facebook boogieman".

<comment><USER18> Ah yes, except that (1) people who use such an interface will meld with it, and (2) we're talking about brain sensors on you.

<comment><USER19> Most input sensors are "brain sensors" in the most reductive sense.

There's nothing spooky about brain sensors. You can buy them today, as meditation tools. I have a long running personal project thread to to use mine as a typing interface. It's 100% possible with current technology and not in the least bit dystopian. Interested parties can read your thoughts much more reliably by just parsing these public posts than trying to build a model to get something more specific than "discrete input A" out of brain waves.

</comment></comment></comment></comment><comment><USER20> Brb, investing in tinfoil hat stocks....

On a serious note though, what's to stop Facebook from collecting more information than it claims? It may claim to only be scanning for verbal locomotion, but how can we be guaranteed that they aren't discretely monitoring our reactions to advertisements or whatnot?

<comment><USER21> When the time comes, it will be written there in the Terms & Conditions that they can record your reactions to advertisements and more, and billions will be clicking "I Agree."

</comment></comment><comment><USER22> Time for occlumency training...

</comment><comment><USER23> The next great frontier for hacking could be hacking brainwaves to get data as you think it--that's pretty scary.

</comment><comment><USER24> I fear where we are headed with AR and BCI funded by corporations.

Check out the future portrayed by Keiichi Matsuda in HYPER-REALITY: [https://vimeo.com/166807261](https://vimeo.com/166807261)

</comment><comment><USER25> If this works it would make torture useless right? Force implant this on someone's head. Ask a question, usually people answer it in their own head, realize they shouldn't say it and say that they don't know.

With Facebook's and Google's track record of privacy this seems like a weapon NSA will have a dancing field day. The ability to hear everyone's thoughts, it's the super power every dictator wants.

What next: ability to implant new thoughts and memory. An ad so fucking powerful you can't resist.

</comment><comment><USER26> I think for this to work, the service would need to train for a long time on each individual person, because our brain waves are different. In other words, my brain waves when I mentally think of the word "cat" are totally different from yours when you think of the word "cat."

Rather than "unsettling" (the word the article's author used), I think this would be awesome. I hate being bounded by the speed of my clumsy, ham-handed typing.

</comment><comment><USER27> This would be very interesting to see from a security stand point of view. We are introducing another attack vector. ex. Imagine if you could phish someone's brain.

<comment><USER28> You'd have to train yourself to "think privately" now... Most people don't even know how to text privately. This may truly be a dystopian nightmare.

<comment><USER29> This is already a dystopian nightmare ...

 _Technology is pervasive_

Smartphones are the most used technological objects (everywhere, always, repeatedly, compulsively, in the subway, on a bus, in a queue, by car, in a restaurant, in a break). VR is massive, augmented reality is not (think about Google Glass): it seems that this sector has picked up the witness by reaching in no time extraordinary results and a public success that increased reality has completely missed. It will be that we are tired of the often difficult and oppressive reality, and instead of increasing it, we want to forget it, evade it and slip completely into an increasingly credible and perfect virtual reality. If this is not a dystopian nightmare ... Drones, artificial intelligence, biotechnology prostheses, wearable computing, automation, sex- bots.

 _The urban layout has changed_

Vertical development with skyscrapers, horizontal developments with the sprawl and the hinterland. Increased air pollution, gap between rich and poor, extreme difference between some neighborhoods. Cities are becoming cyberpunk, and some have been around for some time.

 _Hacking, surveillance, cyber war_

NSA, Snowden, Prism, Anonymous, the US government hacking the network of my last university, the Golden Shield Project, leaks, whistleblowers, the power of the ad tech corporations.

 _The multinationals_

Large business conglomerates closely control the market by often enforcing laws, exploiting the underdeveloped work of innumerable employees by compelling them to work at the limits of slavery. All of this, of course, is aimed at the production of highly prestigious technology objects marketed at prices often overwhelmed by the iconographic presence of the brand, a new divinity created and powered by advertising and fetishically adored by conditioned masses.

"Think privately" is something most people are not able to do right here, right now. The possibility that Facebook might try (in a future) to exploit my brain is only the last drop in a dystopian sea.

<comment><USER30> It still requires consent. If it's really that bad, one can unplug and the problem goes away. Given you're still here and commenting on HN posts, the whole "we're in a dystopia already" schtick comes off as self-indulgent.

<comment><USER29> I'm sorry if it looks like a self-indulgence speech, it's not really my intention.

A complete opt-out from _...all that..._ would probably require moving to one of the Svalbard islands or joining a couple of bedouins in the Sahara desert.

One can sure avoid some of the most uncomfortable things in society, this may also give you the impression that "it still requires consent", an illusion of control.

But I was born and raised in a world made up of people inevitably related to each other. Even if I have personally exercised the ability to choose in what to be involved with or not, I am aware I don't have any ultimate control over the whole complex around me.

 _This doesn 't mean I am fine with x,y,z._

That's why the actual society is dystopian in the first place: because actually the best thing you can do is to speak out in order to raise awareness about the "we hoped for this, but ended up with that instead".

Disillusionment may be a first step, indulgence not. A BCI technology developed in the pubblic interest will be a game changer, but I simply don't see that (any deduction excluded).

<comment><USER30> Well said. I actually agree with you, apart from the semantics of "dystopia".

And you're totally right that we as members of society don't really have much choice but to either go all-in or off the grid. The all-or-nothing starkness is good for nobody but the monopolists.

> A BCI technology developed in the pubblic interest will be a game changer, > but I simply don't see that.

This seems to be the faustian bargain of capitalism. We get technological progress at exponential rates, and then the first purpose ends up to be selling ads.

</comment></comment></comment></comment></comment></comment><comment><USER31> A publication from 3 days ago:

"Success in recognizing ddigits and monosyllables with high accurary from brain activity measurement"

[1] [https://www.eurekalert.org/pub_releases/2017-04/tuot- sir0414...](https://www.eurekalert.org/pub_releases/2017-04/tuot- sir041417.php)

I have an openBCI at home, this is like a huge motivation to finally build the helmet and play often :)

</comment><comment><USER32> It's becoming boring, ladies, we have seen it all before in 1984: The government attempts to control not only the speech and actions, but also the thoughts of its subjects. To entertain unacceptable thoughts is known as crimethink. "Crimestop" is a way to avoid crimethink by immediately purging dangerous thoughts from the mind.

</comment><comment><USER33> Can anyone share more resources on how BCI works, specially non-invasive (no implants inside brain) BCI ? Papers, blogs etc

<comment> T-A A few links from recent years:

[http://www.autodidacts.io/neurotech-hardware-roundup-eeg- bci...](http://www.autodidacts.io/neurotech-hardware-roundup-eeg-bci-tdcs- neurofeedback/)

[http://gizmodo.com/the-best-brain-reader-your-money-cant- buy...](http://gizmodo.com/the-best-brain-reader-your-money-cant-buy- yet-1767234908)

[http://journals.plos.org/plosone/article?id=10.1371/journal....](http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0105225)

[http://journals.plos.org/plosone/article?id=10.1371/journal....](http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0137303)

[http://www.zdnet.com/article/ibm-and-xerox-predict-brain- con...](http://www.zdnet.com/article/ibm-and-xerox-predict-brain-controlled- apps-will-head-to-smartphones/)

[https://arxiv.org/abs/1509.01338](https://arxiv.org/abs/1509.01338)

[https://sccn.ucsd.edu/wiki/Introduction_To_Modern_Brain- Comp...](https://sccn.ucsd.edu/wiki/Introduction_To_Modern_Brain- Computer_Interface_Design)

</comment></comment><comment><USER34> I'm curious about the skin-hearing technology, in the article it mentions 'a system of actuators tuned to 16 frequency bands', does that mean say you'd have 16 actuators each using producing different frequencies? And would the actuators be used on any part of the body?

<comment><USER35> [https://www.thestar.com/life/health_wellness/2008/07/02/emot...](https://www.thestar.com/life/health_wellness/2008/07/02/emotichair_delivers_good_vibrations_to_deaf.html)

</comment></comment><comment><USER36> Not clear how they will make a non invasive optical brain interface...

</comment><comment><USER37> Aluminum foil headgear will soon be in fashion.

</comment><comment><USER38> The king of creepy wants another vector to harvest information?

What can possibly go wrong here?

</comment><comment><USER39> Good device to start a reality show, Brain Honesty.</comment>


Ask HN: What are your favourite tools that stood the test of time? - <AUTHOR> Nowadays most developers look for the newest shiny toys they can find. I understand this - usually I visit HN hoping to find something new to learn and use on my projects.
But as I grow older as a developer, I start to appreciate the "old school" tools. Some of them have been developed and improved for decades and the fact they are still here is a proof of their quality and adequacy. Here are a few of my favourites:

  PostgreSQL
  Emacs
  tmux
  regular expressions
 <comment><USER2> Pen and paper ;-)</comment>


Dimensions and Haskell: Singletons in Action - <AUTHOR> https://serokell.io/blog/dimensions-haskell-singletons <comment><USER2> Safety in the form of tightly-fitting types is great, but the signatures definitely suffer a bit in readability (otherwise, Haskell signatures are generally quite helpful when deciphering a functions purpose). I understand why it needs to be this way, but this signature is nasty looking:

        makePCATypeSafe
          :: forall d x y. (AllConstrained SingI '[d,x,y], d <= x ~ 'True)
          => Proxy (d :: Nat) -> DimMatrix D y x Double -> TypeSafePCA

In (pseudo code), dependent types would really help out a lot:

        makePCATypeSafe
          :: forall (d :: Natural) (x :: Natural) (y :: Natural). d <= x
          => Proxy d -> DimMatrix D y x Double -> TypeSafePCA

It sometimes feels like GHC is a kitchen sink for type-level extensions. I wish the bar for entry for new extensions of this sort was higher and the language a bit more cohesive.

<comment><USER3> There is a plan to add proper dependent types to GHC: [https://gitlab.haskell.org/ghc/ghc/wikis/dependent- haskell](https://gitlab.haskell.org/ghc/ghc/wikis/dependent-haskell). No exact timeline on when it will be ready though.

</comment></comment><comment><USER4> "singletons" in this context is apparently some mechanism applied here to type-check matrix dimensions... :

> we put dimensions of data types on the type level to avoid a large set of > errors that might arise at the runtime stage. During the compile stage, one > may check some properties of matrix dimensions expressed via type-level > natural numbers and find out the reason of that error as a type error.

> In this part, we describe our approach to the matrix data type that is > parameterised via its numbers of columns and rows

> In this approach, matrix dimensions are lifted to the type level with the > use of the Singletons library. At first glance, our solution looks a bit > sophisticated. Why? There remains a question about the way to make it less > devious and more idiomatic. In other words, we have to recognise the > restrictions of Haskell expressive opportunities. What about performance? > Also, our approach helps to remove only errors that affect the dimensions of > arrays. Can we track other array parameters to reduce a set of possible > runtime errors even more?

... not the horrible "singleton" design pattern [https://en.wikipedia.org/wiki/Singleton_pattern](https://en.wikipedia.org/wiki/Singleton_pattern)

Prior art for identifying errors due to mismatched array dimensions include:

* (Eigen, C++) support for compile-time static assertions in some situations: [https://eigen.tuxfamily.org/dox/TopicAssertions.html](https://eigen.tuxfamily.org/dox/TopicAssertions.html)

* (numpy, python) raising ValueErrors at runtime about shape misalignment

<comment><AUTHOR> [http://hackage.haskell.org/package/singletons](http://hackage.haskell.org/package/singletons)

Singletons is a Haskell library. In this context, it is used to emulate dependent types which Haskell does not yet have.

</comment></comment><comment><USER5> Singletons are one of the ugliest things in Haskell. They require lots of extensions, implemented in a complicated way, and leaks implementation detail. Which makes debugging compile-time errors using them quite hard. I'd rather debug a runtime error with proper HasCallstack constraints.

<comment> Haskell-mouse Hi! I am one the author of this post. I agree that Singletons are ugly. But:

1) Without them, creating a bridge between types and values became a real hell. 2) HasCallstack just gives you a place of an exception. It does not give you a cause. And part of errors even does not lead to exceptions at all.

Just want to say, that idea described in the post arose only after hard debugging. And using singletons was much easies and more reliable. And we tried to explain and analyse our personal experience.</comment></comment>


Russia's Covid Vaccine Shows Potential in Peer Review, Lancet Reports - <AUTHOR> https://www.bloomberg.com/news/articles/2020-09-04/russia-covid-vaccine-produces-immune-response-peer-review-shows <comment><USER2> >Between June 18 and Aug 3, 2020, 76 healthy adults were enrolled to the two studies from the volunteer register (figure 1).

>43 adults were selected at the beginning of each study from the volunteer registry; 38 participants were included in each study and five people were kept as backup volunteers in case of dropouts (two for phase 1 and three for phase 2).

>Nine participants in each study received rAd26-S in phase 1, nine received rAd5-S in phase 1, and 20 received sequential injections of rAd26-S (on day 0) and rAd5-S (on day 21) in phase 2. All volunteers in the main group were analysed and additional volunteers from the backup groups were not needed.

>Thus, in each study, 38 volunteers were vaccinated. More men than women took part in the study (table 1).

is it fair to note this is a pretty small sample?</comment>


Enough MEPs Say They Mistakenly Voted for Articles 11 and 13; EU Says Too Bad - <AUTHOR> https://www.techdirt.com/articles/20190326/15193241877/enough-meps-say-they-mistakenly-voted-articles-11-13-that-vote-should-have-flipped-eu-parliament-says-too-bad.shtml <comment><USER2> It's a lot harder to format nicely on HN, so see here [1] if you want the details, but it looks like the vote about amendments would have changed from:

Official vote: 312 for, 317 against, 24 abstained

Corrected votes: 320 for, 314 against, 20 abstained

It's very rare to have that many corrections, the only other vote with more was the actual vote on the directive afterwards (but the corrections couldn't have flipped that one).

[1]: [https://tildes.net/~tech/brp/europes_controversial_overhaul_...](https://tildes.net/~tech/brp/europes_controversial_overhaul_of_online_copyright_receives_final_approval#comment-2wxl)</comment>


"tl;dr; I see little benefit in using a CDN at this point." - <AUTHOR> https://www.peterbe.com/plog/to-cdn-assets-or-just-http2 <comment><USER2> The main benefit of a CDN is global acceleration via different networks. If you are just thinking about servicing one region a CDN usually won't matter.

<comment><AUTHOR> That's missing the point. The HTML document comes from a regular origin server, the rest of the stuff needs to be downloaded. That's a then down to a choice: Do you use a CDN or the existing HTTP/2 connection.</comment></comment>


My Startup Story: Lessons Learned from Ngame.tv - <AUTHOR> http://johncblandii.com/2011/09/my-startup-story-lessons-learned-from-ngame-tv.html

<comment><USER2> I think flat tv is the best bet apple could try, as well as a cell phone the tv will be the next personal computer in our home. So, with the astonishing image quality every apple device has in their hi def screen could easily beat the competence.

As everybody knows the price is not a problem for apple.

That's my humble opinion.</comment>


ReCAPTCHA Mailhide - <AUTHOR> http://www.google.com/recaptcha/mailhide/ <comment><USER2> ReCAPTHA has become such a huge pain to solve. Personally I wouldn't even bother solving their horrible captcha to get your email unless I REALLY REALLY need it.

</comment><comment><USER3> Is the benefit worth the inconvenience? I've had my email in plain text on my personal site for the last 2 years and haven't noticed an increase in spam (thanks to gmail, I suspect).

<comment><USER4> I've had mine on the Internet for well over a decade and run my own mail server. Plus it is a catch all domain - anything before the @ goes to me.

My mail server is configured to be deliberately slow - taking a few seconds extra here or there to respond to SMTP commands. This catches out the spammers who just spew traffic at you ignoring the protocol. Checking sender domains actually exist plus the Zen RBL gets almost everything else. The dribble that gets through all that then goes to spamassassin which does a sterling job. (I make it put messages scoring 5-7 points in a special folder I manually examine every now and then to double check its effectiveness.)

About the only problem I have had are bad recruiters who have made zero effort to ensure I am match for their client or vice versa. I even have a "Note to recruiters" prominently displayed on my resume, but of course the bad ones aren't going to bother reading that. I have to maintain a list of their domains to block since that appears to be the only way to stop them. (Currently 45 entries and counting ...)

<comment><USER5> Would you be willing to share your list of bad recruiters?

<comment><USER4> I've been threatening to do it for years, and I guess this is as good a time as any. Note of course that this is based on my experience.

<http://www.rogerbinns.com/blocked_recruiters.txt>

This is my "Note to recruiters"

<http://www.rogerbinns.com/recruiters.html>

<comment><USER5> "As any group of people gets larger, they get collectively slower and collectively stupider."

Amen!

My personal threshold is around 100 people. Pass 100, and you quickly dive into Dilbert territory.

<comment><USER4> > My personal threshold is around 100 people

That is probably highly correlated with Dunbar's number

<http://en.wikipedia.org/wiki/Dunbars_number>

<comment><USER5> Very enlightening article, thank you!

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Far more user-friendly is Dan Benjamin's Enkoder. <http://hivelogic.com/enkoder/>

It requires that JavaScript be enabled for users, but blocks a large number of spam bots.

</comment><comment><USER7> There's an older trick that still works for me: a passphrase in the subject line.

You can even include the passphrase in the mailto: uri. E-mail harvesters usually discard it, but a user who clicks the link (e.g. to compose a message in Thunderbird) will have their subject field populated.

Now set up procmail to redirect messages to /dev/null if the passphrase is not present. Now you can freely post the uri all over the web.

Real example:

mailto:firstname.lastname@example.com?subject=Don%22t+buy+this

(I'm confident that no spammer will send bulk messages with "Don't buy this" in the subject line, so that makes a good default passphrase.)

<comment><USER8> I know someone who always changes the subject line to reflect the content. He even changes the subject line when responding to other people's e-mails, which is quite annoying because it often breaks Gmail conversations.

So you'll have to take some measure to tell people not to delete that passphrase from the subject line. For example, "Don't change or delete this or it will go into my spam box." But that's verbose.

<comment><USER7> If I send a reply, it comes from a different address (which is not published and is unaffected by the procmail recipe)

</comment></comment></comment><comment><USER9> This is just another stupid hurdle that people are required to jump over if they want to use the internet.

If you offer products or services over the internet, stay clear of captcha. Unless, of course, you give a dam about your conversion rate.

Spam filters are effective enough to keep your inbox clean. There is no need to play hide and seek with email harvester bots.

</comment><comment><USER10> Example: show email@example.com in plain text on your site and let it pass Gmail's spam filter but send the reply from firstname.lastname@example.com if you get a non-spam message. Use Enkoder ( <http://hivelogic.com/enkoder/> ) if you're really spam sensitive.

</comment><comment><USER11> Although, if you are hosting your email with Google already, it seems kind of irrelevant. I happily post my email in `mailto:` form, and I get spam infrequently enough to happily read through it and laugh at the contents when I do (it's always the funny ones that make it through).

<comment><USER12> I'm curious why people bother with these posts anymore. It's like some sort of (self) identity validation. E.g. "Look! I sided with Google and I'm on the winning side!"

</comment></comment><comment><USER13> It seems the site's encoding is broken somehow. I see only question marks, instead of the å's, ä's and ö's it should display. (Trying to view the Swedish version)

<comment><USER14> Same on Russian page.

</comment></comment><comment><USER15> A horrible idea -- those who really want your email will just get it when there is a leak at some big site (ala slicehost forum) and the people you most want to get news from won't take the time to get your email (except if you are very famous).

If you are that concerned about spam, let Google handle it -- get your own domain if you want -- and you don't have to worry too much about it.

email@example.com.

</comment><comment><USER16> this has been around for years no? Also, in recent months I've started to move away from using reCaptcha everywhere on webform deployments because of increased difficulty from, shall we say, the less patient and computer literate, visitors of my sites.</comment>


Rocket Internet faces new setback with loss of senior managers - <AUTHOR> http://www.reuters.com/article/us-rocket-internet-management-idUSKCN0UQ0QY20160112 <comment><USER2> I think a lot of the recent events around Rocket Internet need to consider the very unique position of the company: they are both a Venture fund, and a very closely involved corporate holding. They provide technical support (including development, hosting and dev ops) and marketing assistance to their subsidiaries/investees. The CEO of their companie" have a relation to the head-office similar to what local GMs have with the Uber HQ. This means that financially-motivated decision can be confused with doubts over the management direction.

</comment><comment><USER3> There are two questions:

Will the current portfolio become profitable over time?

Are they able to continuously start successful companies?

At least for the 2nd they need excellent people in the headquarters. For the first one churn can also be an issue. If turnover is high one explanation could be that local management doesn't have enough long term incentives to build sustainable companies. As a consequence they optimize short term output to please the Samwers and jump ship to the next best offer.

</comment><comment><USER4> I would caution against reading too much in departures of Rocket managers.

First, Rocket managers come and go all the time. In my first two years at one of the Asian Rocket companies (I own no Rocket stock today and am not affiliated with anything Rocket anymore), I think I counted 4-5 CEOs. Since I left, it's been the same CEO, though. The key thing is that the Samwer brothers have designed their companies to be resilient to any departures; "people should be replaceable" which sucks a bit when you are "people" but is good corporate governance when you are a publicly traded company trusted with billions of dollars. I'm pretty sure from what I saw that this also applied to Berlin; and since we're shortly after the IPO (and maybe the start of the period where executives are allowed to liquidate their equity?) it might be that those who culturally were more comfortable in a privately owned conglomerate are not enjoying the public version. It's also common for senior executives to be poached for more money by smaller Rockets, CMOs are in particularly high demand and managing directors find it relatively easier to raise funding and start their own thing (e.g. Shopback in Singapore).

Second, there are a LOT of Rocket companies. Some are very successful, others are case studies in problems. Just look at the map: [https://www.rocket- internet.com/companies](https://www.rocket-internet.com/companies) and imagine that each of these countries will have at least three companies (one fashion retailer, one Amazon clone, and one of several of the smaller concepts like Birchbox or FoodPanda). There are hundreds of companies operating in vastly different countries, legal systems, business models. I'd be wary of extrapolating too much from one or two examples - it's like picking a few YC failures (and I am sure there are spectacular ones, just from the sheer number of companies funded - HomeJoy is the most prominent in my head right now) and saying YC as a whole has failed as an incubator.

Third, Rocket is relatively operationally decentralised. Yes, the Samwers visit often, but companies are ultimately left alone to figure things out, even if insights are occasionally emailed around, and even if Berlin has some R&D and obviously runs the financial and legal aspect. I would doubt that Berlin departures would significantly impact the operations of non-Berlin- based companies (which is to say most of them).

> The stock was down another 0.2 percent on Tuesday, to 23.33 euros at 1330 > GMT, valuing the company at about 3.9 billion euros ($4.2 billion).

I've always found these short term stock price tidbits fairly useless. What is more interesting is the long term trend (from a peak of 57 EUR down to 19 EUR) [1] which is strangely not mentioned in the article. Nevertheless, I used to be fairly critical of how the Samwers were running their conglomerate, but thinking back about it, I'm not sure I would do much better. How would you go about starting 200 companies in parallel in 40 countries? I do not know any other examples of even remotely successful attempts...

[1] [http://finance.yahoo.com/echarts?s=RKET.F+Interactive#{"rang...](http://finance.yahoo.com/echarts?s=RKET.F+Interactive#{"range":"max","allowChartStacking":true})

</comment><comment><USER5> Rocket Internet is the prime example of the pump and dumping scheme. The pumping is over, now comes the dumping.</comment>


Fertility rates in Flint, MI before and after switch to lead-poisoned water - <AUTHOR> https://twitter.com/_cingraham/status/910874785038471168 <comment><USER2> What's interesting is a reply challenging the assertion on the basis that families or potential-families left town: [https://twitter.com/MetroGram/status/910880679470215168](https://twitter.com/MetroGram/status/910880679470215168)

Quoting the paper: "Because the higher lead content of the new water supply was unknown at the time, this decrease in GFR is likely a reflection of an increase in fetal death and miscarriages and not a behavior change in sexual behavior related to conception..."

What's pleasant is that there wasn't a flamewar over it.

</comment><comment><USER3> I'm being a bit hyperbolic here, but doesn't this point towards Flint administration being directly responsible for the deaths of newborns ? All in order to save a few dollars. I would say this is horrifying, but realistically, how often do we management managing something they have near- zero understanding of?</comment>


STEM to STEAM - <AUTHOR> http://stemtosteam.org/ <comment><USER2> So, STEAM is Science, Technology, Engineering, Arts and Mathematics? One of these is not like the others.

<comment><USER3> I've heard a lot about this from people who do work at STEAM events. Arts are allegedly just as important as the rest of these, because creativity and artistic design are part of the manufacturing process.

I keep my mouth shut, because I don't want to hurt their feelings, because they do a lot of good work with helping kids into the STEM fields, and because they're genuinely nice people. (I can be kind of abrasive, and they're doing good work. So I hold off.)

But I fail to see how the color of the packaging affects how tough parts for the space shuttle are. Is it about promoting creativity and free-forming content into Engineering and Science, etc.? The webpage says a whole lot of nothing. I'd be willing to rethink my position if I understood the concept a little better (because I am clearly missing something).

Also: friend attends RISD right now. Will ask what he thinks of this.

<comment><USER4> Arts can create a sensibility for context, and can answer the "should" of "should we be doing this".

At least the hypothetical universe in my mind, a bunch of technocrats are a lot more likely to commit unethical behaviour than people who have a bit more sensibility for the human condition and history.

<comment><USER5> You can teach an engineer history a hell of a lot more easily than teaching an art historian how to do stochastic calculus.

<comment><USER6> Can and do are not the same. Just because different forms of knowledge are "easier" or "more difficult" to obtain does not mean that the easier knowledge is somehow devalued, except in the context of labor supply.

I would not say that, at this point, many engineers know or are interested much in history or art, regardless of its social value. This is a mild failure on the part of the free market.

</comment></comment></comment></comment></comment><comment><USER7> I'm looking at their list of objectives, trying to understand how any of it will benefit the advancement of STEM.

It doesn't. The objectives only seek to leverage the concrete validity of STEM as a stable platform for "arts & design," which are intuitive and incredibly debatable by nature.

<comment><USER8> If anything I would assume their objective is the exact opposite - draw people to STEM trough something popular/approachable like Art.

To be fair the site is very vague - I can't really see how this would be different from something like industrial design/architecture ?

<comment><USER9> I'm assuming - trying to plug themselves into the acronym to capitalize on the respect (and jobs) STEM has as "the real deal" as opposed to art fields, and framing that as initiative to bring more people into STEM. It's cynical, I know, but I've heard enough art/design people saying "art and design is important too!" and completely missing the point. No one is saying design or art is not important to humans. It's just STEM fields are different because they deal head-on with objective, observable reality as opposed to _incredibly_ complex internal life of humans.

</comment></comment></comment><comment><USER10> There is an implicit assumption that STEM does not have any artistic/design aspects to it. I imagine people who claim this have never had a long conversation with a mathematician about what their job is actually like.

</comment><comment><USER11> In Silicon Valley and on communities such as HN, when people talk about STEM, they seem to usually focus on CS/EE. Given that there doesn't seem to be as much focus here on, say, hydraulic engineering, or medicine, as there is focus on what is necessary to create tech startups, I'm surprised to see that people are objecting to Art. Doesn't this industry have a more pressing need for UI/UX designers, HCI specialists, web designers, and video game music composers, rather than astronomers or zoologists?

</comment><comment><USER12> This program misses the point by presenting a very narrow scope.

Adding the Arts to STEM is about much more than just "Art + Design" (though that is a piece). It's an important topic of discussion and should be priority in education.

Every child in America should leave school with a basic understanding of arts and culture - some knowledge of music, visual arts, literature, history.

Societal progress has consistently been tied to the greater appreciation of humanity found in these pursuits. Just as any musician or artist should have the opportunity to understand and appreciate the basic concepts of physics or computer science, so too should the scientist know sculpture. Creative thought sustains critical thinking, and many of the borders between them overlap.

If we truly wish to build our future nation to be our best, we must not discount the arts as a core pillar of any healthy society, and one worth supporting in any way possible.

</comment><comment><USER5> This is clearly some sort of spoof. Or someone has _completely_ missed the point of STEM, y'know, hard stuff where there are right and wrong answers...

</comment><comment><USER13> Does the U.S. have an art/design problem or shortage relative to other nations? (non-rhetorical question, please answer). It does seem clear that the U.S. is behind many other nations in STEM fields. Seems like promoting STEAM vs STEM would be somewhat mutually antagonistic.

<comment><USER14> How exactly is the US behind other nation in STEM fields?

<comment><USER13> I've seen various sources claim the US is behind other nations in STEM fields, particularly math, at the primary and secondary levels.

e.g. [https://www.nms.org/AboutNMSI/TheSTEMCrisis/STEMEducationSta...](https://www.nms.org/AboutNMSI/TheSTEMCrisis/STEMEducationStatistics.aspx)

<comment><USER15> These disparities disappear once you account for certain key demographic differences. In modern service-economy societies, _average_ educational attainment is unimportant. What matters is how many positive-marginal-product people you have, and the US still produces them in spades.

</comment></comment></comment></comment><comment><USER16> > "K–20 education"

I've never heard 8 years of college referred to like that. It's... strange.

<comment><USER17> Undergrad + PhD? :/

</comment></comment><comment><USER18> STEM is already too much about a gigantic T (apps! apps everywhere!) at the expense of S, E, and M. A would be even bigger. This is nothing but entryism.

<comment><USER19> What's entryism?

<comment><USER18> Essentially the same point made here: [https://news.ycombinator.com/item?id=10572766](https://news.ycombinator.com/item?id=10572766) Being associated with STEM is lucrative (money, respect, ability to effect change) and STEM explicitly leaves out the more numerous artists, lawyers, political theorists, english literaturers, gender studiers, etc. that are part of college-as-is. The benefits of STEM association are enough incentive for any groups within those left out to try and get themselves in and have a share. Hence, the Rhode Island School of Design (which ought to have no business in STEM: [http://www.risd.edu/academics/](http://www.risd.edu/academics/)) has been trying to steer things. Hey, at least if they win, there will be no gender representation problems in STEAM...

</comment></comment></comment><comment><USER20> The reason why artists aren't getting tech jobs isn't because there's a letter missing from an acronym...

</comment><comment><USER21> Great initiative!

A well rounded person is always better than a person that's really good at one or fewer things.

</comment><comment><USER22> any relation to this (also a RISD project)? [http://steamwith.us/](http://steamwith.us/)

(edit: why am I being downvoted?)

</comment><comment><USER23> This is not good for STEM, and this is not good for women. If the attention and effort to encourage women, children, underrepresented minorities, etc. in STEM gets diverted into "STEAM," then there is a high likelihood that many groups will tout increased enrollment of women but funnel the women right into the A in STEAM. (Not necessarily on purpose, but for the same complicated reasons that women are underrepresented in STEM right now.) And then we're in the same place we started, but with less visibility into the problem.

<comment><USER24> Hm. That's a good point. Try making it to the members of Congress behind the "Congressional STEM to STEAM Caucus".[1] . "Current members of the caucus include Reps. Jim Langevin (D-RI), Jared Polis (D-CO), David Cicilline (D-RI), Eleanor Holmes Norton (D-DC), Gerald Connolly (D-VA), Dave Loebsack (D-IA), Matt Cartwright (D-PA), Bobby Scott (D-VA), Louise Slaughter (D-NY), Tim Ryan (D-OH), and Carol Shea-Porter (D-NH)."

The Rhode Island School of Design seems to be the main force behind this. They're not really a design school, in the industrial design sense; they're a "fine arts" school. Teaching kids the rudiments of industrial design might be useful. It's not about self-expression; it's about what the user needs.

[1] [https://bonamici.house.gov/press-release/reps-bonamici- and-s...](https://bonamici.house.gov/press-release/reps-bonamici-and-schock- announce-bipartisan-congressional-steam-caucus)</comment></comment>


Helping the Poor in Education: The Power of a Simple Nudge - <AUTHOR> http://www.nytimes.com/2015/01/18/upshot/helping-the-poor-in-higher-education-the-power-of-a-simple-nudge.html?abt=0002&abg=1 <comment><USER2> Often you can get dramatic results for small amounts of money,or a small investment can pay off dramatically.

It consistently bothers me that people don't talk about low hanging fruit; easy simple ways to make the world better, and the educational ones that often pay for themselves in increased tax revenues and/or reductions in crime. Simple medical interventions often pay for themselves in reduced care costs.

The article suggests that because there is no constituency to support these changes, they don't get pushed. If that's true that's a shame.

Other examples:

HeadStart pays for itself 9 times over. [http://www.nhsa.org/files/static_page_files/399E0881-1D09-35...](http://www.nhsa.org/files/static_page_files/399E0881-1D09-3519-AD56452FC44941C3/BenefitsofHSandEHS.pdf)

Persistently lower arrests and crime rates if you give students a 6 week minimum wage job during the summer. [http://www.realclearscience.com/journal_club/2014/12/04/do_j...](http://www.realclearscience.com/journal_club/2014/12/04/do_jobs_reduce_crime_among_disadvantaged_youth.html)

A simple checklist significantly reduced death and serious complications in surgery. [http://content.time.com/time/health/article/0,8599,1871759,0...](http://content.time.com/time/health/article/0,8599,1871759,00.html)

A simpl stove that can be made of local materials in africa dramatically increases fuel efficiency, and reduces uncontrolled fires and smoke blindness [http://www.aidafrica.net/stoves/](http://www.aidafrica.net/stoves/)

A one liter bottle and water can provide light for the poor without electricity. [http://aliteroflight.org/index.php](http://aliteroflight.org/index.php)

<comment><USER3> It would be interesting if policy debates focused more on cost benefit ratios. Of course a big problem is that dollar values placed on benefits can be pretty debatable, but it should often be possible to at least establish the likely range.

I guess another big problem is that getting people in the feels is a much more effective persuasion technique than pointing out that something is a sound investment.</comment></comment>


How To Make Your iPhone App Launch Faster (by faking it) - <AUTHOR> http://www.dragthing.com/blog/?p=246

<comment><USER2> The really amazing thing here is that it should take a full four seconds to launch a calculator application on a mobile phone.

That should be instant, no delay at all.

A calculator application with such limited functionality should be well under 100 K and load in a split second.

<comment><USER3> I bet you could build it in a weekend, too?

<comment><USER2> errmm... does this count ?

A casio fx something or other clone.

The binary was 61107 bytes long (statically linked).

<http://ww.com/qwmcalc.txt>

Took about a week. I don't recall claiming it only took a weekend.

Apologies for the 'classic' style coding, it's pretty old code. The window manager this talks to was for the Qnx operating system.</comment></comment></comment>


Ask HN: Review my startup, Local Republic - <AUTHOR>

Check it out at http://localrepublic.com
The idea is for citizens to report issues they see happening around them (potholes, trash disposal issues, poor local government performance, etc. anything goes, really), discuss them and try to find solutions to these problems.
There's a blog post further explaining the idea behind Local Republic here: http://blog.localrepublic.com/we-are-live
We're really looking forward to your feedback :) <comment><USER2> Sounds like an interesting idea...especially at the neighborhood level. But I wonder if you've cast the net too wide. Maybe focusing on one or a few communities in the beginning might help create compelling and useful conversations that would then inspire other communities to jump onboard.</comment>