skysight-inc/HackerNews huggingface dataset:
Nobody buys the Fed's story. It's clear that it was never about a specific phone and only about setting a precedent.

Which is all well and good, but it begs the question why did they back out now? Public opinion was divided from the start, and it didn't change dramatically from when the story broke to when they dropped the case. They got a lot of mainstream media exposure, but I would have thought that would have been expected at the least (and probably desired).

It's been reported that the other three letter agencies don't share the same view. Did Comey get too much unwanted heat? Is it just a temporary retreat to regroup and fight again another day? Something else? I can't believe that they just expected Apple to roll over.
For fuck sake, how can you have such a blatantly anti-European headline and pad the article with anti-European propaganda phrasings like "Europe’s attempts to get access to encrypted data" when the same fucking article itself states that major sovereign nations that are both on the European continent and founding members of the EU support encryption as a fundamental right?

The straw man evil "Europe" portrayed in this article quite obviously doesn't exist.
Also another good map: http://www.sigmaaldrich.com/technical-documents/articles/bio...
Cream: real time emotional speech effects
I see unit tests recommended all the time, but in practice I've found them significantly less helpful than integration and acceptance tests. Maybe its just a nomenclature thing? It's obvious if you change a "unit" of code, its tests are going to fail. That's not terribly helpful while refactoring. What's more useful is to find out what else breaks and that's where the other tests come in.

I'm not saying that unit tests aren't useful. They definitely help for example if you're using a dynamic programming language or if you're practicing TDD. I would just emphasize a higher priority for integration and acceptance tests.
Just because you can do it over USB doesn't mean you should. PCIe gets you more bandwidth and vastly better latency, and the peripherals that use PCIe tend to be higher quality and have better drivers than their USB competition. Just compare any USB NIC against Intel Ethernet or Atheros WiFi, or NVMe and AHCI devices against the mess that is UASP. You can't build a decent router or NAS around USB devices.

(And DisplayLink offers graphics over USB, but it's so bad that in almost any other context it should be regarded as not counting.)
I think it'll still need qualifying with "...in certain specific well-definable areas". They can certainly churn through data a lot quicker but that doesn't make them smart - e.g. even after 20 years of work, Google's search algorithm is still mostly dumb as a post for what's actually relevant to a query.
C# is an amazing language. The .NET framework is equally amazing and probably the most productive framework created so far.

In the next 12 months with the release of .NET Core, even the Windows requirement will go away. It should be at the top of the list for just about any project these days.
I was diagnosed 1994, and I do not live in the US. Back then I will say it was harder to find gluten-free stuff. But it progressed a lot long before the 'diet-thing' happened. Bread mix has always been around here, however more alternatives have popped up over time.

I happen to live in a country where we've always had a strong lobby group for celiacs though, and what I see mostly after the diet-thing came about is that there's a lot more almond flour and things like that.

I suppose it's different in other countries, I will agree with you that new products arise that would probably not have come otherwise, but what scares me is the threat of not being taken seriously when you mention you don't eat Glute.
> It works correctly either way

But the way you showed was not one in which anyone was interested, synchronous exceptions work in more or less every language, and you can't assume readers know your self-killing is actually implemented via asynchronous exceptions since they don't know the language.
I think when debate comes down to differences in ideology and idiosyncracy, it's at the end of debating because these differences are impossible to compromise (they are all legitimate).

And the world is at a point that everybody can believe in everything and all these beliefs are all grounded and justificable (using the available tools and knowledge we've accumulated).

To deal with the somewhat disturbing thought that the world doesn't need to be saved, I resort to the mantra that: eventually, the reason we read, the reason we write, the choice we make, everyday, is just because we feel like.
The bit that I don't get is how Ethereum will communicate with the outside world.

Example: I bet a friend that Hillary will be the next president. We create an Ethereum app/contract/whatever and fund it with $50 (worth of 'ether') each. When the election rolls around, we want to pay the winner automatically, but how can you do that?

You could have a rule to check some 'official' source on the internet but that data could easily be faked or unavailable. Then what?

If this kind of app is not suited to Etherium, then what are some good examples of Etherium's capabilities?
If possible, I'd use two flash drives, mirrored with soft-raid, for storage. One clearly visible in the dashcam, the other hidden somewhere deeeep inside the car with an USB extender.

Why? Because if a cop/other driver ever gets mad at you and forces you to hand over the flash drive, you still have a copy.

Also, I'd add two microphones to the project, one for exterior sound, one for interior (e.g. to prove what exactly has been said, or in case of a crash if other drivers have honked, or if an ambulance had its sirens on).

And, I wouldn't use a Pi, but rather something supporting SATA, because USB flash drives tend to have low lifecycles when constantly overwritten.
> I see it being used for system tools, to some degree, because it requires no runtime at all (static binary).

This is something I haven't seen discussed much recently.

Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)?

As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.".

As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found.

[1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein:

http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...
Maybe some stuff gets flagged to death? Not sure exactly.

I've seen other controversial topics drop off the front page that have recent submission times, and a decent number of points and comments, while others with similar stats remain on the front. ¯\_(ツ)_/¯
Traditionally (19th century British literature) any such technique was called "forcing" if it simulated an environment more favorable to growth. Techniques include light cycle variation (covering the plant with an opaque cover at specific time was the standard approach), thermal environment manipulation (using horse dung to generate heat from below, or glass cover to trap heat above), CO2 manipulation by breathing in the space the plants are, or using bacteria that produce CO2, varying the timing, location and temperature of water, etc etc etc
I try to keep my unit tests focused on the api of the unit I'm developing. If I'm refactoring and keeping the api the same, I shouldn't have to change any tests. Since I started writing my tests this way, I've felt I have to change my tests far less... Sometimes I add more tests, when a bug is found and needs fixing, but missed tests are better than wrong tests IMHO.
I find it noteworthy that crypto-currencies are treated as investments and 'bets' which would seems to imply instability or a design feature of fluctuating value.

Almost as if a primary motive behind designing crypto "currency" protocols is not a stable value exchange medium, but rather instead an investment system for early adopters to exploit late adopter buyers?

[0] https://www.youtube.com/watch?v=geSnkE4EOqs
It's a "3D printer for food"!
Sad to see things haven't changed much on the sql front. Many web apps don't care about performance for the language, since the cost of querying the db will be orders of magnitudes higher anyway. What they want is a simple one liner to persist object graphs into a DB, because 90% of the code will be glue code around insert from json, and select to json types of features ( i'm talking list & forms types of web apps, not the fancy video chat over webrtc demo).

The fact that this books advertize "build your own orm" solution, with the one given not even able to select 1-many objects makes me really wonder how in the world one could recommend go for web apps.

Ps: to get a benchmark on what is the current level of productivity expected today for enterprise-like web apps, just have a look at a loopback.io demo. Yes, it's node.js which sucks, but you have to admit that we're pretty far away from manually mapping result columns to struct properties.
Schrodinger's equation doesn't even include special relativistic effects. It's not exact (at least not if you mean it exactly describes nature in general). Neither is Dirac's equation; it includes special relativistic effects for a single particle, but not general relativistic effects or multi-particle interactions (at least as far as I understand it).
Love Me Like You Do – Ellie Goulding (cover) by Erik Santos
Did you not understand what I just said? Because "in this instance" doesn't address my point.
It's a transaction bound short lived one time token. Nothing you can replay.
I'd suggest people bake in an archival process during their deploys so you always have a zip/tarball of the entire source code and node_modules that you deploy, but still use npm install during development.
How long do we have to hear about this debacle?

Seriously, it's enough already. There's no new information to discuss.
I kind of wish this article had gotten into some details of how various compilers implement std::function; while it was nice to see some details of clang++'s 32-byte size of all std::function to remove the need for dynamic memory for many function objects, I'm still wishing I had more details on efficiency/cost of using std::function vs. plain lambdas or function pointers or other solutions.
In computer security I've often heard the saying there is no security without physical security. This means if somebody can access the hardware running your program you can't trust the outcome. That's why you have to lock your servers away and trust the people who have the key.

Ethereum solves this problem by creating truly virtual machine that does not have physical location. If somebody wants to tamper with the execution there is no address to drive to or datacenter to cut power from. Even service providers themselves can prove that they have locked themselves out. Without ethereum you just have to take their word for it.

This all comes with caveats.
Radical transparency, everyone can see your code and when it is running.
Cost, you need to pay for every instruction to keep the system running and to prevent spamming.
It's a shared resource, you need to wait for your turn and the computer is very slow.

Is there usecase for such contraption remains to be seen.
That's always been difficult for me if a unit test is written as purely as possible (i.e. isolating the unit from its dependencies). If I have to mock dependencies, create stubs and spies, I start to have to make assumptions about how the unit works beyond just its API, which makes the test itself more brittle. How do you approach this situation?
As is sometimes the case, people start with the wrong abstraction (thread pool) and then optimize it.

Java/Scala streams look like they would solve most of the problems in the post on their own.

e.g. Java streams

http://radar.oreilly.com/2015/02/java-8-streams-api-and-para...

private void runParallel() {
trades
.stream()
.parallel().forEach(t->doSomething(t) );
}

Java/Scala has a hierarchy of concurrency abstractions, from high level to low level:

Streams, Parallel collections, Futures, Actors, Fork/Join, ExecutionContext/ExecutorService, Threadpools, Threads, synchronized, Barriers, Atomic values and many more.
Healthy breakfasts in Dubai that you need to try
Thailand Expat Personal Records Posted to Govt Site
they leave out that Motorola was a spin of from RCA and Ericsson (? maybe Phillips?) to create that car-vitriola monstrosity
Everyone should seriously consider using Kotlin, it's here to stay.
One very lucky developer and gamer got the surprise of his life
Even if they can fix all of that, I still don't see the application here. It's tantalising but ... there's nothing new or interesting you can really do with Etherium.

Is there?
> The issue is did she break any laws or policies regarding the handling of classified information. That's for the courts to decide.

That's mentioned in the article around this point,

> Under Title 18, Section 2071, it is a misdemeanor to take federal records without authorization, something that is sometimes referred to as the “alienation” of records. The law is rarely enforced, but a conviction can carry a fine or imprisonment.

Agreed it is for the courts to decide. It would be quite a farce if this didn't see the light of a court room.

> But if there was any evidence I'd imagine they would have brought an indictment by now.

It takes time to build a proper case. Note that the guy who set up the email server was just given immunity in exchange for his cooperation earlier this month. I imagine the DOJ only gives immunity when they are working towards something.
the boss usually gets nabbed by things like tax evasion, so easy to get then on top of the list.
Unit-Tests can be helpful when working with Java as they can give you a semi REPL-like environment (especially if your IDE integrates well with JUnit).

I find both Integration and Acceptance Tests could potentially hide many bad internal designs (tight coupling, etc). I also find that not many places can speed up their full integration/acceptance tests suites; suddenly build becomes way too painful, be it local dev build or CI-triggered-through-commit builds.

Note: My experience with super-slow integration tests choking build is with a large JavaScript project with 100 developers (at least).

I implemented integration-tests for a Java-heavy based project before but limited only to test the database component of the project (e.g.: Repository, JPQL, JPA), the ability to test business logics that are tightly coupled with ORM quickly in isolated manner is a blessing.

I guess YMMV.
https://en.m.wikipedia.org/wiki/Bush_White_House_email_contr...
So your boss doesn’t believe in design research
Is Global Warming Real?
Gnosis is a prediction market platform that is live on Ethereum right now. http://groupgnosis.com/

There are a few ways to act as the oracle who indicates what the outcome of an event was. You can tell users to just trust you, which is what every centralized prediction market does with few problems. You can pick a few trusted oracles and require a majority vote. Or you can use any data that is served over a TLS connection so the outcome can be cryptographically verified, which is what Oraclize.it does. All of these approaches work for Gnosis markets.
Ethereum becomes useless as soon as it interacts with the real world. Its brave new world of digital contracts works fine for creating simple gambling games or 'provably fair' Ponzi schemes, but as soon as a piece of code on the blockchain has to rely on a real world piece of data, you lose all of the benefits of the system.

You want to write something related to (say) a share price, or property ownership? Then your code needs to trust an external system providing the data, and the users need to trust that other people will honour the 'facts' decided by your program on the blockchain.

You want to create even a simple system that opens a lock when someone pays money? (The much-hyped Slock.it startup selling 'smart' locks) The blockchain makes no promise that a physical lock will operate based on bits in the blockchain. You have to trust that someone isn't cheating you.

And why is this need for extra trust a problem? Because once you require trust, you are back into the real world where we already have real solutions to these Ethereum based problems, that rely on trust (e.g. Share dealing, property sales, etc). By moving onto the blockchain, you have gained nothing and only complicated matters.

It's like the IoT: putting a blockchain into an existing system is just as helpful as wiring your fridge up to the Internet. For anyone getting seriously involved in Ethereum, sorry for your loss.
> which helps me get more support, both financial and fellow makers who want to build with me

I noticed your project [0] on the site, and it looks as though there are zero backers and $0 financial support so far.

Is this a genuine review? If so, the financial support you have mention receiving is not visible on Baqqer.

0: https://baqqer.com/projects/raasta
Ethereum, a virtual currency, enables transactions that rival Bitcoins
This brings back memories. My first experience of a computer was using a PET 3016 at secondary school in the UK in 1979. Later I bought a Commodore 64 and built an RS232 interface for it - I still have the prototype on stripboard kicking around somewhere. I also wrote a VT100/220 terminal and file transfer program in assembler; it ran in graphics mode, using a custom bitmap font table to create an 80x25 display. Like this PET version, my C64 code had to bitbang the serial interface and because the 'serial port' shared an interrupt with the printer's, when you printed, serial comms was held up and so characters could be lost. I all-but cracked that problem with some clever buffering.
The charts at hnrankings.com can give you an idea of what happened to it: http://hnrankings.info/11372264/

Among the things that can cause big drops:

User flagging.
Administrative action.
Staleness (some number of hours on front page)
Flamewar detector (flurry of responses to responses)

It's difficult to distinguish between these from the outside, but a polite email to Dan (hn@ycombinator.com) will probably get you a specific answer if you are interested. Based on asking about similar stories, this one would be a tossup between "Flamewar" and "User flags".
No, he's been blocking all links from HN for a while.
The warrant would tend to be targeted at a specific person. "Tell us what you have on Bob Jones", and not a population "Tell us what you have on everybody named Jones"
Kuzzle: Open-source back end, self-hostable and ready to use
(cross-post from another HN discussion) The way i think about Ethereum is that it's a cloud computing platform upon which the whole world can see which program the server is running. The usefulness of this is that if you want to run a computing service that administers something of great value to others (such as a vote-counting service or a property registry), other people might be suspicious that you will use your administrative access to the server to corrupt the system. With Ethereum, the service provider doesn't have any admin access (and neither do the people upon whose hardware the program is ultimately running on); the cloud computer just runs the program you upload, and everyone can see what program that is.

In addition, it runs your service robustly, and preserves the entire history of the computation forever. The downside is that these transparency and robustness features make the service a lot more expensive than ordinary cloud computing, as well as more difficult to program on.

It doesn't really have much to do with Bitcoin or currency (except that (a) like Bitcoin, Ethereum uses blockchain technology to achieve these things; but that's an implementation detail (b) a Bitcoin clone is one of the many things you could build as an Ethereum application (c) for technical reasons you buy Ethereum server time via purchasing server-time-credits called "Ether").

As a project, Ethereum is very technically ambitious (they are not just working on a cloud computing platform, but also trying to advance blockchain technology in general, eg developing a new proof-of-stake algorithm, and eg developing a way to not have to replicate computations on every node on the network). They are trying to do a lot of new things at once, which is risky (but awesome).
Thanks. Yes, I should have included the "that had been written before" in my quote.

I didn't look too into the question of how to recover the contents of a hard disk with microscopy because I figured it would be possible, but expensive. Looking now, I quickly found a MS thesis at http://escholarship.org/uc/item/26g4p84b which recovered data from a disk using MFM. While the performance was poor, the author attributes that to the experimental setup.

Ahh, and http://www.dataclinic.it/magnetic-force-microscopy.htm appears to provide a commercial service to extra data from a hard disk using magnetic force microscopy.
This is why I refused to contribute to a medical study on a condition I had in the past and that would have required me to provide some DNA sample. These databases should not exist given the weak legal protection and the non existent protection against hackers.
That redirects to imgur.
Sunken Central Park: ‘Sidescraper’ Wraps Excavated Landscape Concept
The less they have the less potential for misbehaving. Where is the line? That depends on their previous behaviour.
It will hurt when your end-to-end tests (minus UI) must be run per check-in and as your code gets bigger.

Some companies invest in huge infrastructure to speed things up (paralleling until you can't...) but in that situation, suddenly Devs can no longer build locally without biting their tongue.

Setting up end-to-end test "per test-case" is also tedious (should user be logged-in in order for this test-case to run? what should be the state before the tests are run and what should be the state after the tests are run? what if the state of the system have the expected _and_ more e.g.: side-effect?)
Depends on how you author the unit tests.

They must be testing "behavior". If you are refactoring to clean up code, you'll want to verify the behavior and unit tests gives you that quick feedback.
In c++ if you pass something as reference there is nothing preventing the receiving function from keeping a pointer to that reference even after returning.

Right now the only way to enforce this is by convention: 1. move/unique/shared_ptr=receiver allowed to keep pointer, 2. raw ptr=totally banned, 3. reference=caller must outlive callee and called function is not allowed to keep pointer after returning. The last scenario here is not enforcable by the compiler.