Channels Are Not Enough - <AUTHOR> https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 <comment><USER2> Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck.

What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them.

I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem with CoffeeScript (conflation of declaration and assignment + scope rules) and the authors' refusal to admit that there is a problem also made me dismiss it entirely.

Every language/platform has problems. But not every language is in denial of them. We should all avoid those that refuse to acknowledge their problems - because that points to a much deeper, much more serious problem - a problem that cannot be eradicated with technical means.

<comment><USER3> Lack of generics != lack of abstractions.

The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience.

Rob Pike has outlined the tradeoffs inherent with generics here: [http://research.swtch.com/2009/12/generic- dilemma.html](http://research.swtch.com/2009/12/generic-dilemma.html)

The bottom line is it's not a feature that comes for free, and if most of the time you don't really need it, maybe the costs aren't worth it. That's a bold statement for a programming language these days, since generics is a central feature of every popular, modern, statically typed language. Whether they are right or wrong I won't attempt to say. The language may well get generics one day, but it's early days still and the team is rightly focusing on more important features for the moment.

<comment><USER4> Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

<comment><USER5> It reminds me of the wonderful fun days of Java 1.2 - anybody remember how proud Sun was of how everything derived from object so you could use the untyped containers for everything?

<comment><USER6> The main difference with casting to Object is that you can use type switches or safe casts which return an additional success boolean, to restore type safety quickly after taking the item out of its container. Yes, you can type- test in Java before you type-cast, but it isn't idiomatic, and it isn't syntax.

<comment><USER7> "It's fine in Go to do the wrong thing, because they added syntax to make it even easier to do the wrong thing."

</comment></comment></comment></comment></comment></comment><comment><USER8> This is a really great read, and goes beyond just channels and concurrency. It seems to me that Go is designed to discourage developing higher-level abstractions. That was my sense using it in the past, and it's only gotten stronger over time.

Remember that one of Go's primary stated goals is "speed of compilation"[1]. Simplicity and ease of learning are paramount, and it's easier to learn a language where any chunk of code basically follows the same rules as any other.

[1]: [http://golang.org/doc/faq#Why_doesnt_Go_have_feature_X](http://golang.org/doc/faq#Why_doesnt_Go_have_feature_X)

<comment><USER9> "Go is designed to discourage developing higher-level abstractions."

Yes, that does seem to be the distinctive thing about Go. It's almost like someone read Paul Graham's "blub" essay[1] and thought, "what would it mean to take seriously the idea that blub _is_ the best language?"

Everyone knows that building abstractions has a cost - the cost of building the abstractions themselves, the cost of figuring out the particular abstractions employed in a given project, and the cost of comprehending a language flexible enough to support these abstractions. The hope is that the cost of abstraction is an investment: the time you put in will be rewarded in faster development when you put the abstractions to use. But at some point increased abstraction is going to give diminishing returns.

Now, most programs written today don't involve that much more abstraction than would have been possible with programs written in ALGOL; that is, we haven't seen a huge widespread increase in the power of abstraction used by most programmers in about 50 years. People like Alan Kay and Brett Victor[2] decry this stagnation, and maybe they're right to. But maybe the current low level of abstraction is so durable because it's a sweet spot between the benefits you get from abstraction and the costs involved in coming to grips with that abstraction.

Most people, particularly most people who develop programming languages, assume that we're nowhere near the point of diminishing returns for increasing abstraction. Go seems like an experiment to test the possibility that the maximum efficiency occurs at a much lower level of abstraction than we usually think. It will be interesting to see whether (or in what domains) that hypothesis turns out to be true.

[1] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html) [2] [http://worrydream.com/dbx/](http://worrydream.com/dbx/)

<comment><USER10> I think what you are missing is that people do use abstraction if you offer it. Java or C# generics or even when C++ added templates. C++ templates where abused but it was done so often that is now standard.

If you look at code from the newer fancy languages people do use these fancy features.

</comment></comment></comment><comment><USER11> It's funny that OP uses Twitter as the case study at the end. I wrote what was then the first (and think still the only) Go Twitter client library that works with v1.1 of Twitter's API[0]. It implements automatic rate- limiting/throttling behind the scenes, and it returns values of concrete types (not interfaces) ready for immediate use.

Keep in mind that, were I to write this again today from scratch, there are a number of things I would do differently (since I started it as a relative beginner expanded on it as my familiarity with Go developed, it's grown to be a bit over-engineered in places). But I still think it's a worthwhile example in this discussion.

For concurrency, I wouldn't say that what OP is trying to do is going to be easy in _any_ language, because OAuth in general kind of sucks[1] the Twitter API itself has a number of quirks that make it cumbersome in general, irrespective of language[2]. That said, Go was by far the easiest to work with here, because channels allowed me to abstract the pagination and the rate- limiting in a way that it would be invisible to all callers, but "magically" handled behind the scenes.

Without going into too much detail, I can see that the way OP has designed his code looks a bit cumbersome. That said, while it's a reasonable way of approaching it, I don't think it's actually the best approach in Go given the language's idioms.

One other thing I want to draw attention to is the use of the general-purpose function for issuing a GET request to Twitter, and how that is shared among the various functions that use it to return values of varying, but known, types.

I don't want to use the word "generic" here because people expect a certain thing when they hear that word, but I will say that this function is (A) general-purpose, and (B) type-safe - it involves _no_ type assertions, and the functions all return concrete types instead if interface{}.

[0] [https://github.com/ChimeraCoder/anaconda/](https://github.com/ChimeraCoder/anaconda/)

[1] Don't get me started on this

[2] I've written client libraries for Twitter in a few different languages, so I actually have a reasonable point of reference on this - at one point, it was my personal "hello world" for testing out a new language.

<comment><USER12> I'm curious to see this general purpose function of yours. You are also addressing a different point than the article. The main point is that patterns like parallel map are impossible to implement in Go in a type-safe manner. This is a valid complaint depending on what is meant by type-safe and at this point the arguments for/against Go usually devolve into name calling and matters of culture. If you could factor out all that general purpose functionality from your code base, e.g. the rate-limiting and other things, and turn it into a re-usable library then that would be an entirely different matter. Whether that would qualify according to the author's definition of type-safe is another matter.

<comment><USER13> It looks like this is the function: [https://github.com/ChimeraCoder/anaconda/blob/master/twitter...](https://github.com/ChimeraCoder/anaconda/blob/master/twitter.go#L162)

This looks like a good example of interface{} used correctly - the consumer of the apiGet function passes in their strongly typed object, which then is handed in to json.Decode. No type safety is lost from the perspective of the consumer, while the json.Decode can operate on any struct type.

Sure this addresses a different issue, but for all the complaints about interface{} I think this is a good use-case.

</comment></comment></comment><comment><USER14> Rather than arguing about generics in Go again, I'd be interested in reading about how experienced Go developers solve the problems posed in this article. (He may be wrong that there's no elegant solution.)

Also, if it can't be solved elegantly, perhaps adding merge() and a few other important functions to the language would be good enough? After all, Go already has the magic append() function for slices and we get quite a lot of use out of it.

<comment><USER15> There's no generalized solution to every generic problem. The "cast to interface{}" is the closest to a linear mapping of generics, but if you're reaching for that all the time, you're doing it wrong. So the only sane answer is, "it depends".

The only use case that I have encountered that is essentially impossible in Go is the "generic data structure". Mind you, that's a bit of a big deal, even if it covered over by "generic" arrays and maps (which, further, _does_ cover over a lot of the cases), but it is also the only case where it is actually a problem. Despite the fact Go is not functional, like, _at all_ , I still find myself using my functional training in minimizing the surface area of an "object" as much as possible incredibly useful when programming in Go. I think if I were only an OO programmer trying to come over to Go I'd have a much harder time of it.

Most of the rest of the time you can solve your problem by asking what the code is _really_ trying to do, pull that up into an interface, and carry on. A substantial portion of the rest of the use case can be covered by providing wrapper objects that compose in another object, probably using an interface as the composition point.

I think in practice, about 80% of the problems that people trying to jam generics into Go are encountering are because they are trying to program C++, Java, or C# in Go. Despite their substantial superficial similarities, Go is not any of them, and idiomatic answers differ substantially. Let me rhetorically underline that... Go _really_ looks like a Java or C# clone if you just read down the bullet points, but there are enough important differences that it's a substantially different experience to program in it. Trying to program Go as C# is only slightly less frustrating than trying to port FP idioms into Go (which is a complete waste of time). The remaining 20% are real problems that Go hasn't got a good answer for beyond duplicating code.

Now. All that said, despite the fact that people not used to idiomatic Go are significantly overstating the problem that is the lack of generics, it _is_ a problem and were I in charge, I'd be trying to work something out on this front. (I actually have a proposal I've probably put about 4 or 5 hours of thought into. In defense of the Go developers, this _is_ a nontrivial problem when you stop just waving the word "generic" around and start trying to seriously create an implementable suggestion, accounting for all the use cases, grammar interactions, semantics, etc.) My best argument is that for a language as mature as Go, this is embarrassing: [http://golang.org/pkg/container/](http://golang.org/pkg/container/) Those are the "generic" containers in the standard library that ship with the language.... all three of them as of this writing, plus array and map. At this point that ought to be significantly richer.

(So, that ought to just about piss everybody off...)

Oh, I ought to add for context that I'm actually pretty fluent in Haskell, and my primary work programming language up to this point have been dynamic languages (Perl, Python, etc). So it's not like I'm not comfortable with generics or incapable of understanding how to use them or anything. If anything, I dare say my openness to other answers and then finding ways to express them in Go may be part of why this doesn't bother me too much. There _are_ other options, most of the time, and they are not generally "compromises", either... they are often perfectly sensible options, or even _better_ options than are available in other languages on a bang/buck basis, such as the trade for making composition very easy and inheritance something fairly difficult.

<comment><USER14> Talking about how to implement generics generically isn't really responding to my question. The original post had questions about how to implement specific concurrent constructs like pipelines, futures, and so on. So the question is how do you handle _concurrency_ in Go? Are we missing important features that should be part of the language or standard libraries?

Some of these may be one-off generic functions like append() that could be added to the language without adding full-blown generics.

<comment><USER15> I know this is going to sound like an evasion, but the answer is that idiomatic Go doesn't involve pulling in patterns from other languages, but using ones native to the language.

Futures I can be specific about, though. You simply don't use "futures" in Go. Futures (as the term is used by most languages) are a hack around missing concurrency constructs, and in Go, they aren't missing. Use channels instead. This covers rather a lot of patterns from Javascript and the weaker languages, actually... you don't port them, you simply _don 't use them_. They aren't that appealing once you learn the native idioms, which are, generally, quite a bit better.

Putting a "future" library up on /r/golang is a pretty common occurrence... but they're so trivial they're worthless. It's harder to "use" a future than it is to just do thing the future library is doing.

For pipelines, you just "do" them... you don't set up some declarative pipeline, you just... program them. Sort of like how in the Python world they prefer the for loops to map statements? Same thing, really... if you want a pipeline, just hook things together manually. They may miss out on some abstraction, but, honestly, in most imperative languages I'm underwhelmed by the concept of really generic pipelines. Haskell's making some progress on that front and I've actually got an "in the wild" five-stager, but in the imperative world I'm not sure I've ever encountered _in the wild_ some sort of 6-stage pipeline that was better written other ways.

If any major concurrency pattern is missing from Go, it's an explicitly asynchronous concurrency pattern. However, this can be fixed by library code: [https://github.com/thejerf/reign](https://github.com/thejerf/reign)

</comment></comment></comment></comment><comment><USER16> "I want all this <-done synchronizations and select sacramentals to be entire hidden"

Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic".

This is, IMO, a feature and not a bug, but YMMV.

<comment><USER8> Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own.

This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

<comment><USER17> > but it's unsurprisingly frustrating for people used to more expressive > languages

Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust.

There are things in _all_ languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with _near_ perfect orthogonality in the language.

Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.

<comment><USER18> I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.

People _de facto_ speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.

<comment><USER7> > I find your response condescending and hostile, actually.

Welcome to the Go community.

<comment><USER19> A snarky comment, but I experienced the same on the golang-nuts mailing list. If you dare to question conventional wisdom be prepared to be shot down rather unceremoniously.

At least by now, they updated their docs a little bit.

I still think the "How to Write Go Code" article, which most beginners will encounter, is absolutely misleading by its advocacy of 'go get' \- I cannot envision a universe where 'go get' makes sense. You absolutely have to vendor your dependencies if you want any kind of stability with your project.

<comment><USER17> > You absolutely have to vendor your dependencies if you want any kind of > stability with your project.

I have several open source Go projects and I have been maintaining them for years by just using `go get`. I've never once had a stability problem because of it.

Of course, your point is absolutely correct. But I'm pointing out that `go get` can absolutely be useful in some universes. In fact, it's one of the things I love most of the Go toolchain.

So, umm, can we stop presupposing that everyone else's opinion and experience is just wrong?

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Yeah it seem channels are basic primitives. Kind of a like a class in OO programming.

Just like Erlang has explicit processes and message sending primitives So it is pretty simple and concise at that level. In order to build large systems there is OTP (or e2) that embodies and abstracts away some common patterns/behaviours: gen_event, gen_server, gen_fsm, supervisors, logging, distribution between nodes etc.

I imagine over time go will acquire those kind of libraries (maybe it already has them?).

There is also an interesting duality between Erlang and Go. In one case there are explicit processes (identified by PIDs) + an anonymous (implicit) mailbox. Where go has anonymous goroutines but explicitly identifiably channels. It seems they are duals. You can simulate one with another. And you can build concurrency patterns on top of them.

I personally prefer Erlang's model to think about concurrency. There is an active entity -- a client request, a server, a socket handler, it has a an id/name, it can be monitored for liveliness, it can be halted, upgraded, killed, can send messages to it. Somehow to me that makes it easier to map to concurrent problem domains. Channels can ultimately do the same things but it is harder for me to design using goroutines.

<comment><USER21> The problem (which the article touches on) is that you have to resort to interface{} to make things reusable since Go doesn't have generics. So you have to pick between using a library (which will handle edge cases better) or compile time type checking.

<comment><USER22> You don't have to resort to an empty interface, in fact, mrust experiences go programmers cringe when they see anyone using empty interfaces. The fact of the matter that much code can reused without being "generic" and often your code never gets reused. YAGNI and all that.

<comment><USER23> The point of generic code is not purely that it's easier to re-use. The almost more important fact is that generic code has less information about its inputs and outputs—this leads to a smaller design space and, consequently, an easier time designing the implementation and an easier time avoiding bugs.

<comment><USER22> I think a _lot_ more bugs are introduced from people trying to make their code too generic rather than too specific. The complexity of the code goes way up when you stop being able to rely on certain values being certain types. If I "hardcode" my ID to be an int64, there are a lot of assumptions that become safe to make, like the fact that it's a relatively small value, that I can bit shift it, that the keyspace is of a particular size.... if you then take the same code and decide that the ID should be genericized so it can be anything, now I have to account for the fact that the keyspace could be unbounded (as in the case of a string ID), I can't assume it's safe to copy around the value (it might not be thread safe and/or it might be a really large value).

Saying having less information about the data makes for easier coding is almost always not true.

<comment><USER23> > _decide that the ID should be genericized so it can be anything_

You say that, but you probably don't actually do it. If it truly could "be anything" then you would not be able to do _anything_ to it. This is the nature of polymorphism.

So instead, your algorithm constrains the polymorphism based on what you need. If you make use of the properties {small, bit-shiftable, sized, bounded, copy- safe} then you must prove (exactly and only) that whatever the generic variable gets instantiated to satisfies {small, bit-shiftable, sized, bounded, copy-safe}.

Indeed, this is part of how such a system prevents bugs---it forces you to express exactly how much information about the types involved is needed. You can thus reflect better on the kinds of contracts/laws things must uphold and are prevented from accidentally making use of a property of your concrete type which you do not demarcate.

In a truly expressive language you might write

        foo : forall id n .
              (Bits id, Size id = n, n <= 1024)
              => id -> {Copy id} id

to indicate all of those properties needed (bounded being subsumed by constraining the size)

Today, you can get promises very similar to the above by using a language like Cryptol[0].

[0] [https://galois.com/project/cryptol/](https://galois.com/project/cryptol/)

</comment></comment></comment></comment></comment></comment><comment><USER24> The interesting thing about Go, that can help make sense of all its oddities, is that it was not created to assist the developer.

Go was created for businesses, not developers. The holy grail of a corporate programming language is that all individual developer personality is restricted, such that _you cannot tell from reading code who wrote it_. This is all about long-term, large-scale maintainability for massive code bases at massive corporations.

Disclaimer: I work at Google, I do not represent Google, and this is just my opinion after spending time "on the inside".

<comment><USER25> I understand not having any fancy features in a "corporate programming language", but wouldn't language features aimed at reducing code duplication (like generics) help with maintainability?

<comment><USER24> I think the extra flexibility gained would be perceived as a negative. The ideal (from their perspective) is that there is only one way to do a particular thing, no matter how verbose it is. Google has recently been mostly Java (Guice, dependency injection everywhere), and has long preferred incredibly verbose code at the cost of occasional duplication.

<comment><USER25> Agreed, it's likely what you say is the perception. But the thing is:

> _The ideal (from their perspective) is that there is only one way to do a > particular thing_

The lack of useful tools like generics (and others) means there is no single way to do a particular thing: things must be duplicated everywhere (or ugly workarounds to avoid doing so must be employed, like casting from Object or using interface{} or whatever). Surely the benefits of better tools outweigh their inconveniences, even in a corporate environment? This is not a nerdy programmer's whim, but a major software engineering principle of direct consequences for any business.

Taken to an absurd extreme, you can simply copy & paste code everywhere -- that's the simplest programming model there is, and even the most junior of programmers can handle it without having their learning skills taxed in any way. It just leads to maintenance hell, which is why it's frowned upon even in corporate environments.

</comment></comment></comment></comment><comment><USER26> I think the author could use a technique like this to build the higher level abstractions they want: [http://commandcenter.blogspot.nl/2014/01/self- referential-fu...](http://commandcenter.blogspot.nl/2014/01/self-referential- functions-and-design.html?m=1)

<comment><USER4> I remember seeing that post a while ago on Reddit. The impression I got from the discussion is that the whole "self-referential" thing was unnecessary and that the code would be much simpler in a language with generics.

[http://www.reddit.com/r/programming/comments/1w2y01/rob_pike...](http://www.reddit.com/r/programming/comments/1w2y01/rob_pike_selfreferential_functions_and_the_design/)

</comment></comment><comment><USER27> Wouldn't a library like zeromq address the complications/shortcomings the OP highlights in his article, when working with Go channels on a regular basis? Using the 'inproc' for message transport with zeromq should give similar performance to pure go channels no?

This Go client implementation [https://github.com/pebbe/zmq4](https://github.com/pebbe/zmq4) by Peter Kleiweg also includes all the examples from the online zeromq guide which is great.

I know it's not a pure ago solution but the OP does mention that

 _' 99% of time I don't really care if the response is delivered with a channel or a magical unicorn brought it on its horn.'_

I don't know, maybe I'm missing the point of the article.

<comment><USER12> Sure, but at that point what is the point of using Go? You might as well use some other language like D if all the parallelism and message passing patterns are going to be handled by a library like zeromq.

</comment></comment><comment><USER28> Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics, which completely drowns the discussions about Go. As a result, the material on the web about Go has a very high noise/signal ratio, which is unfortunate.

Hopefully, the Go team will see this as one more reason to add generics to their language, but until they do that, Go will remain a niche language with a severely crippled potential.

<comment><USER29> I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go.

(Personally, I don't mind the ongoing discussions about generics in Go, I just wish they were less repetitive. It's very easy to say "add generics to Go!" It's a little bit harder to actually do it well.)

<comment><USER28> Yeah I was trying to insufflate new life in this tired debate, glad someone noticed :)

</comment></comment></comment><comment><USER30> In an essay titled "Why Pascal is Not My Favorite Programming Language" Brian W. Kernighan wrote:

<quote> The size of an array is part of its type

If one declares

         var     arr10 : array [1..10] of integer;
                 arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. </quote>

Kernighan was one of the early C/Unix developers from Bell Labs. It is amusing to note that Go, whose authors come from the same background, getting criticized for something very similar.

[1]: [http://www.lysator.liu.se/c/bwk-on- pascal.html](http://www.lysator.liu.se/c/bwk-on-pascal.html)

</comment><comment><USER31> I stopped reading. The further I got the more the article seemed to be complaining not about channels but that Go isn't a functional language. That's right, it isn't.</comment>


Ask HN: How to "defend" against Transaction malleability? - <AUTHOR>

After reading https://news.ycombinator.com/item?id=7244191 I think my website got affect by this. What's the best way to defend against it?
freedomsponsors.org is a crowdfunding service for open source software where "sponsors" can send Bitcoins to programmers for solving issues.
As soon as we confirm we received bitcoins from a sponsor,
we keep a 3% fee send the rest to the programmer, using a Python API.
Sending through the API returns a transaction hash that we store in our database.
Later FS receives a notification with transaction details. If that notification contains a transaction hash that doesn't match anything on the database, freedomsponsors.org sends me an email that basically says: "HEADS UP: Blockchain is telling me there is an outgoing transaction that I don't know about, here is the transaction details...".
freedomsponsors.org is open source on Github, and the related code is here http://bit.ly/1bA2eiQ
Today, I got two of those emails and boy did that freak me out!
I thought someone was stealing my coins. Only later I could investigate and understand what happened:
Transaction created by FS (hash returned by the API):
hash = 18311e095c3d8426025ab87fae87e988e1fbad09ba01db32586d066fc28ba87d
amount = 0.01570000
from = 14LkZoYgcheQCkj1mk6oEKqDsxcKHNAT7q
to = 1LSrAt3Ee1BZrRM2YLxrPaBxSTEqcr8SxW
That hash cannot be found in the blockchain anymore. Instead there's
hash = a76f239a327e8b61f7c3f942d52066696c58ad13fb19e4ec7f523a342a12db59
amount = 0.01569999
from/to = the same
So... I can't trust transaction hashes anymore, is that it? Should I verify transactions based on "from" and "to" then? Or is there any more reliable way of telling whether money I sent has reached the wallet on the other side?
Thanks! <comment><USER2> I'm not sure what is going on here, but it's not malleability, since malleability can't change the amount.

In addition, the transaction in the blockchain hasn't been modified by the malleability attack, since the script starts with 47 not 4d (i.e. regular push not modified OP_PUSHDATA2): [https://blockchain.info/rawtx/a76f239a327e8b61f7c3f942d52066...](https://blockchain.info/rawtx/a76f239a327e8b61f7c3f942d52066696c58ad13fb19e4ec7f523a342a12db59?scripts=true)

It looks to me like a floating point rounding error somewhere in the FS API changed the amount and thus the hash between the transaction that was sent to you and the transaction sent into the Bitcoin network. The difference is too small to be explained by fees.

Do you have any evidence that the first transaction ever existed at all? I'd expect it to show up as unconfirmed on blockchain.info or blockexplorer.com for a while if it ever went out to the network.</comment>


TheLikestream, Digg For Facebook "Likes" - <AUTHOR> http://techcrunch.com/2010/09/23/thelikestream-digg-for-facebook-likes/

<comment><USER2> Long live TheLikeStream! congrats Ed :)

</comment><comment><USER3> Cool -- and best of luck to Ed.</comment>


Ask HN: What Are Your Hobbies? - <AUTHOR> I am tired of very boring day job (programming) and looking for something to lose myself again. (the feeling I used to have in early days of programming). So Friends, would you care to share you hobbies ? <comment><USER2> Overwatch (and a few other games) its also kind of a social thing as i regularly play with my brother and sister in law who live at the other end of the country, its probably the closest ive ever come to enjoying a "sport"

Electronics, i just enjoy repairing broken things, it doesnt really matter what the thing or issue is, i just enjoy solving the puzzle if you will

Music, i dont play an instrument or anything but unlike many people i spend time just listening to music, not as a background to other tasks but actually sitting and enjoying it or looking for new stuff

Travel, i tend to spend a good amount of that time we all spend idly browsing the net to look for info on places i plan to travel to. In recent years i go to japan once a year so i spend time looking for things to do/see when im there, it may sound excessive but anyone whos been on holiday with me will tell you that it pays off

</comment><comment><USER3> Video games, learning new programming languages, watching TV and movies, and, most importantly of all, reading.

I should strive for more "active" hobbies. I have friends who go to the rock- climbing gym fairly often.

</comment><comment><USER4> sure :) all of these work pretty good for the "lose yourself" thing for me personally:

\- Hardware tinkering, picked that up while I was in a similar situation years ago. It can be fun to just solder along and program non-work things with low- level abstractions sometimes.

\- Sewing, honestly not sure why I started that but it's a nice indoor hobby away from the PC.

\- Hiking and the gym (weight lifting and crossfit mostly), for obvious reasons (nature and movement, especially after those debugging days). Both took some getting used to and integrate timewise but I couldn't live without anymore.

</comment><comment><USER5> DnD, Hill walking, (indoor)Climbing, Cooking, homebrewing and amateur photography

</comment><comment><USER6> Gardening, child caring, playing games, listen to music, woodworking, reading books are good hobbies</comment>


Ask HN: CAD design for beginners - <AUTHOR> I am a developer who has recently become interested in fabrication and metal work. I think it's awesome to make stuff. I want to do more complicated things, f.ex. I want to build a special gate for my  garden that folds in a specific way and requires me to build custom latches. I want to play with my ideas for the hinging and latching components in some sort of CAD software but the only two free pieces of CAD software I've been able to find (opencad and freecad) seem to be extremely complicated. Is there any sort of CAD software for beginners or a free online course that I could take? <comment><USER2> I started with making 3d models of objects and weapons for games 15 years ago. Usually based of existing pictures or blueprints. Copy existing stuff is easy, even without measurements because good pictures with good camera can still be used for scaling stuff. I used to have about 100GB picture archive of all sort of stuff to be replicated into 3d models for game us.

Getting to know the tooling before you make something new really is the way to go. I currently use Freecad and Openscad. Freecad really has a way to work, sometimes going at something from a certain direction really helps you curb the complexity and pitfalls you can get yourself into. I can suggest most of the videos made by [https://www.youtube.com/user/cad1919/videos](https://www.youtube.com/user/cad1919/videos) on youtube. Usually videos without audio just doing the modeling. Often I am surprised at his route to completion, usually fairly efficient and direct. For the item you want to make I would suggest following his example.

You should draw it out on paper in maybe 2 or 3 perspectives and do all the hard calculation and then just replicate it in 3d.

Freecad is really as user friendly as it gets for actual good small tolerance Free CAD. There are however some usability and or nagging issues. Like how you break your model and can't continue the route you had because the chamfer or join brakes your mesh :).

On a side note are you sure your idea is novel and new, I assume someone has made it before and you can copy ;) a few months ago there was a N mechanical mechanisms link on hackernews, it might be in there :).

Edit: don't look at the videos you find on youtube and just copy the thing their making. Make your own stuff just steal their workflow.

Also do everything using coordinates and measurements not drag and drop. Might help you visualise it better.

</comment><comment><USER3> FreeCAD has some advanced capabilities but is not a great package to start on. I've created some weird shapes in it but would never have been able to do it if it were not for a fair amount of SolidWorks experience. You might try using OnShape, where everything is stored in the cloud. I haven't tried it yet but it seems to be made by the same people who did SolidWorks. They probably have good tutorials. If you get over a learning curve there you might be better prepared to do things on FreeCad offline.

</comment><comment><USER4> There is Tinkercad, but that might be to basic, depending what you exactly want to do.</comment>


Why Microsoft Needed Facebook & Google Didn't - <AUTHOR> http://www.marketingpilgrim.com/2007/10/why-microsoft-needed-facebook-google-didnt.html <comment><USER2> I'm of the opinion that, if we can all agree that social software is important, Google would get a ton more out of Facebook than Microsoft would. Google doesn't seem to _get_ social software at all.</comment>


Where Book Selling is Headed - <AUTHOR> http://techcrunch.com/2011/12/02/whats-so-funny-about-a-tablets-love-and-a-bookless-world/

<comment><USER3> So, physical bookstores are going to completely disappear? Just as physical computer stores completely disappeared?

Except, come to think of it, my last three computers were picked up at a physical computer store.

It feels impossible for brick-and-mortar stores like B&N to survive on their current scale (though never say never – it always seemed like a miracle that those stores could have existed at such scale in the first place, fifteen years and more after the invention of the web). But I suspect that _something_ made of bricks and mortar is going to take their place. It might look more like a public library or a coffeeshop or a student union, because most of the actual books will be sold electronically, but people are going to continue to have a place to go which has the parts of bookstores that they like: The browsing, the occasional chair, the librarian/bookseller/knowledgeable person, the cafe, the company of other readers. And, yes, perhaps even displays of books.

Because sitting alone in your apartment in front of a screen gets old. And because a shelf full of physical books and magazines still makes an impressive, and fairly inexpensive, _display ad_ for books and magazines.

Even the aforementioned Apple store, as well as the office-supply store down the street, still has a few boxes of software sitting on a shelf – even though software doesn't come in boxes anymore, to the extent that many of those software boxes have _nothing inside them_ but a thin paper slip with a URL and a code on it, and even though boxed software, unlike a physical book, is not browseable, which destroys most of the value of having it on a shelf. Software boxes are merely well-designed shiny props. And, yet, some of them are still there. Props are useful things. Humans have more senses than one, and we like to engage them all when we shop.

Of course, the structure of the bookselling business is going to change, and some sections really will just disappear. For example, the softening of the college textbook market seems like a harbinger: College textbooks are incredibly expensive relative to other books, most buyers really only want to rent them, they don't rely on bookstore displays to market them (because most of them are sold to a captive audience), and the people who buy them already have perfectly good places to hang out with other college-textbook readers (we call them _colleges_ ).

<comment><USER4> Why is the decline of the bookstore any different than the decline of record stores?

<comment><USER5> Record stores make poor promotional vehicles for records; people don't often go into record stores hoping for serendipity. Partly because it's hard to browse music, even when you can actually listen to it. Partly because people tend to have something specific in mind when they go to a record store, at least more often than when they go to book stores.

<comment><USER6> _people don't often go into record stores hoping for serendipity._

That's pretty much the main reason I go into record stores.

If I have something specific in mind I go to Amazon.

<comment><USER5> Yeah, because now there's Amazon. If you could own a record store before or after Amazon...?

<comment><USER6> I've little doubt record stores are now a poor investment, at least as currently managed.

Like book stores, they need a way to exploit having physical items in immediate proximity, and the prospect of there being other people around as your browse or shop. Perhaps only carry items that have distinct packaging, while providing high-end listening facilities for digital purchases.

<comment><USER5> I knew when I wrote my first comment on this thread that someone was going to tell me about how they love flipping through albums at record stores. I used to, too! The issue is, _most people_ probably don't browse record stores that much. You can take a bunch of books at B&N and sit down with them in the coffee shop. You can't do that at a record store.

This is all not to mention the fact that the era of buying music on physical media is pretty much over.

<comment><USER6> _The issue is, most people probably don't browse record stores that much._

On what do you base this? I don't have anything other than my own anecdotal data, so I offered up my own personal preference.

Thing is, as I recall, whenever I went into record stores there seemed to be a fair number of people in there. Gut feeling tells me people were browsing in the stores but buying online.

No, you can't take a stack of CDs to listen too, though some places will play something for you if you ask (but that's hardly as frictionless as grabbing books on your own). There still are some opportunities for listening previews, though.

 _This is all not to mention the fact that the era of buying music on physical media is pretty much over._

Define "pretty much over."

[http://blog.nielsen.com/nielsenwire/consumer/cue-the- music-d...](http://blog.nielsen.com/nielsenwire/consumer/cue-the-music-driven- by-digital-music-sales-up-in-2011/)

Vinyl is certainly a much _smaller_ market than CDs, but custom packaging still has its appeal.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> From a person who loves to read, this article is barely coherent. It lists three things that will "kill" bookstores then says Barnes is "only good at two of them". Wha? Only good at two ways of killing yourself?

And one of those things that will kill bookstores is apparently LOVE for paper books. Ok, sure.

</comment><comment><USER8>
      >> easy for a professor to write his or her own book, made up of class notes

Writing a good textbook is quite a lot of work. This seems very unlikely.

What will happen is a few professors will write books, and self-publish or distribute free electronic versions.

Perhaps crowd sourcing will become a popular way to write textbooks, based on a wikipedia or github collaboration model.

</comment><comment><USER9> As a parent, I can't imagine giving my 1 year-old a kindle to play with - <USER2> think board books will be very hard to replace with digital alternatives, unless it's something that looks and feels like a board book, but has several different stories you can choose from.

</comment><comment><USER10> And in the end, there won't be a trace of the next generation, since there won't be any physical records left...

<comment><USER3> That's an important question, but a different one. Surely we could preserve the collected works of Steig Larsson or J.K. Rowling without asking _every reader on Earth_ to buy and retain a physical copy.

(If nothing else, if in three hundred years the works of Steig Larsson are somehow lost, our descendents can just have the archaeologists dig down a few feet, where they will discover a stratum consisting of nothing but remaindered Steig Larsson paperbacks.)

More seriously: It's likely that books will continue to have print runs, but the question is the size of those print runs. You can preserve a novel by having twenty librarians in twenty countries run off twenty printed copies and stash each of them in a storage vault. But that market won't support a physical infrastructure of printed-book sellers.

</comment></comment><comment><USER11> TechCrunch link, didn't read.</comment>


Anatomy of a Seed Round During Covid-19 - <AUTHOR> https://www.freshpaint.io/blog/anatomy-of-a-seed-round-during-covid-19 <comment><USER2> The visual map of where the money came from is incredibly helpful. Thank you!

Direct link for the lazy: [https://uploads- ssl.webflow.com/5dad2b1e508f04886d0245c3/5f3...](https://uploads- ssl.webflow.com/5dad2b1e508f04886d0245c3/5f3b0a0cc95ca033b5715bb2_image.png)

</comment><comment><USER3> >>Record your calls and self-assess<<

I'm assuming that the other party was informed the call was being recorded. I'm not sure I'd be too comfortable dealing with an entity which recorded my calls without my consent, an act which in certain jurisdictions may not even be legal.

<comment><USER4> I'm the author of the post - yes, of course. best i can remember, a handful of people asked to not record. almost all were fine with it.

</comment></comment><comment><USER5> Thanks for writing this. Is this tree of 38 small checks what most seed round looks like? Needing to manage the chemistry of that many people gives huge meaning to when funded founders say, if they could do it again they would bootstrap.

<comment><USER6> I think some seed rounds work this way. Some seed rounds have a small number of large checks that fill up the entire round.

For managing chemistry, the extent of our interaction with most of the investors is they are on our investor mailing list. Besides that, we ask them when we need help with something.

</comment></comment><comment><USER7> What did you guys get diluted to? :( I hope this was a good stable valuation across all investors.

What's the value in raising really low amounts like 5k? would it not have made sense to keep a minimum amount e.g. > 50k/100k?

<comment><USER4> Hey! I wrote the post.

SAFEs make it easy these days to add someone to the round (for any amount). The issue becomes time management (is it really worth hours of calls, responding to questions over email, etc) trying to close such a small check.

There's a secondary issue of wrangling each investor in subsequent rounds or an acquisition (which that can just gets kicked down the road). Some investors provide value beyond their money, mostly with their connections to other investors, connections to potential customers, and skills in certain areas, or just generally someone you can call for advice.

One thing I've learned having gone thru this process: it's common for angel investors to write small checks, though not common knowledge. I always thought you needed to write a $25-50k check to be able to invest in a startup. It's common for people in the industry to invest smaller amounts like $5k-$10k, sometimes even less than $5k. I've even now started doing it myself.

</comment></comment><comment><USER8> > Freshpaint collects behavioral customer data from your website and app, and > sends that data to hundreds of analytics and marketing tools in one click.

Oof. I'm sure there are many people who want this thing, but I really of wish our economy weren't structured so that pouring over a million bucks into the N+1th surveillance ad-tech thing seemed like a good investment.

</comment><comment><USER9> It's always interesting to me to see a platform like this that puts so much focus on raising money while their first tier product is free. In fact it says FREE FOREVER! Their other pricing is custom in which I'd have to contact them. I always have a hard time understanding what the appeal is to a seed investor in a product that is going to be free for the vast majority of users.

Anyone smarter than I am have any insights into this? Does a company like this miss out on product development because they are spending so much time raising money?

<comment><USER10> As a paying customer of Freshpaint, my perspective is they are building a great product with a clear value proposition.

The steady stream of product improvements tells me they are still very focused on product development.</comment></comment>


Secret language - <AUTHOR> http://www.joelonsoftware.com/items/2009/12/30.html <comment><USER2> The hiring manager probably meant for it to be an internal only posting but failed at posting. The training you get very early on as a manager-of-managers covers how to write good job postings, and avoiding ridiculous acronyms is part of it.

Fear of IP taint has traditionally kept most MSFT teams away from direct external contact, except through legal-approved intermediaries. Maybe Joel has forgotten that after fifteen years away? I'd stake money he didn't "talk to anyone outside the company" when working on VBA :-)

</comment><comment><USER3> Joel's not really contributing anything here, and as I've said elsewhere, this is marketing-speak, not Microsoft-speak. At least, I never heard anyone talk like this when I was there over the summer. I learned some new words ("dogfooding") and people do call Ballmer "SteveB" (just as they often refer to coworkers by their email aliases), but I can assure you this posting is as incomprehensible to most Microsoft engineers as it is to you.

<comment><USER4> DogFooding is such a universally well known phrase in the technical industry, that I was utterly shocked when I ran into someone for whom it was new. It may be an insular phrase, but it's at least insular to a _very_ broad community.

<comment><USER3> Fair enough. I've been a student my whole life, and had never worked for a software company before, which is why it was new to me. If you met someone 10 years into his career, then sure, that could be surprising - but everyone has to hear the term for the first time at some point.

</comment></comment></comment><comment><USER5> Microsoft is certainly not the only guilty party in this respect. Overuse of jargon and, more egregiously, failure to appropriately define all but the most universally well-known abbreviations at the point where the abbreviated form is first used in the text is a pervasive problem in the field. For example, the first few responses to this article use a total of four domain-specific abbreviations (IP, MSFT, VBA, and DSL), none of which were defined by the authors. Worse, within the field, the meaning of one of the abbreviations (DSL) is context-sensitive and the author's intended meaning is the lesser known one. The appropriate convention, used in virtually every other technical domain, is to explicitly state what the abbreviation or acronym stands for when it is first used in the text and then use it as much as you like in the rest of the text. Only a very small subset of abbreviations that are certain to be recognized by _everyone_ in the field, regardless of their subspecialty, may be used without defining the term.

<comment><USER6> Somehow I find it difficult to believe that anyone who even knows about Hacker News, much less anyone who actually reads it would have interpreted the one comment to have said "any model complicated enough is best expressed in terms of a Digital Subscriber Line".

Unless there is some other computer-related meaning for the abbreviation DSL (besides Domain-Specific Language, of course) that I'm not aware of. :-D

<comment><USER5> The point is not that anyone would mistakenly believe that Digital Subscriber Line was the correct interpretation of DSL in that context. The point is that the nature of human cognition is such that Digital Subscriber Line is the term most likely to pop into consciousness first and it will be the _wrong_ answer. The abbreviation DSL is _not_ widely recognized as meaning Domain-Specific Language, or at least not so widely known that one may reasonably assume that _any_ practitioner in the field will immediately know what you are talking about. They'll know that Digital Subscriber Line doesn't fit into context, but they won't necessarily know what meaning the author _was_ trying to convey.

<comment><USER7> Not to disagree, but when I see DSL (and other acronyms of its ilk) I treat it the same as any other homonym.

In fact, when I read in general I read the whole sentence and parse it all together and not on a word by word basis. I thought most people read this way so that they are more resilient to typos and other small errors.

So if they simply do not recognize the term DSL->Domain Specific Language acronym, readers simply mentally flag it as a possible typo/other error instead of confusing the telecom notion with the um.. trendy ruby-world? term.

</comment></comment></comment></comment><comment><USER8> We'll connect offline about when I have some free cycles to get that on my radar.

</comment><comment><USER9> Judging from their performance in the marketplace, it sounds like their internal jargon describes a model of the competitive landscape that's pretty successful. Just like in programming, any model complicated enough is best expressed in terms of a DSL.

</comment><comment><USER10> Already noted at <http://news.ycombinator.com/item?id=1022403>

</comment><comment><USER11> I find the similarity between the style of jargon in that job posting and the jargon used by the Church of Scientology ('sea-org', 'OT', 'out-ethics' etc.) a little creepy.

</comment><comment><USER12> There's no reason for a job posting to be jargon-free, but the jargon used should be understandable by anyone who might be qualified for the role. I find it hard to believe that detailed knowledge of MSFT culture would be required to work in a group whose goal is to help the company compete with open source stuff. If anything, this knowledge is a detriment. Had the poster used acronyms like FOSS, I would have no issue.

</comment><comment><USER13> Jargon arises because it is useful for compressing information exchanged within a given culture. If this really was an internal posting which was accidentally exposed, what is the problem with using the jargon of Microsoft's culture?

</comment><comment><USER14> What's a v-team?

<comment><USER15> "They are not supposed to work on campus (although they may attend meetings, etc.) and should not have an office or telephone assigned to them. These contractors are called "v dashes" because the first two characters of their alias/userID are v-. There are no restrictions on how long a "v dash" can work for Microsoft." <http://www.edsguild.org/contracting.htm>

<comment><USER16> This is not how it works in practice. In reality a "v-team" is made up of "vendors" who are not full-time employees but unlike agency temps they don't have a limit on how long they can work at Microsoft without a break. They do very much work on campus, though often they tend not to have their own offices (instead they work in bays or are doubled up with others).

</comment></comment></comment><comment><USER17> IBM say DASD when they mean "hard disk"...

</comment><comment><USER18> OK, but to be fair to MS, this appears to have been written by a nonnative English speaker. Indian, I think. So there's another factor at work.

<comment><USER19> What points that out to you?

<comment><USER18> "Top of mind" doesn't quite sound native to me. The use of the ampersand like that seems Indian too. Finally the exclamation point is slight evidence.</comment></comment></comment>


The Birth of Prolog (1992) [pdf] - <AUTHOR> https://web.stanford.edu/class/linguist289/p37-colmerauer.pdf <comment><USER2> I've noticed prolog being mentioned here and a bunch of other places, but haven't really found any good introductory books on the language.

Does anyone have any recommendations?

<comment><USER3> Clocksin & Mellish has the benefit of being a slim volume, which makes it approachable.

Sterling & Shapiro (Art of Prolog) has much more depth. Not sure I'd recommend to a beginner. (It has a beautiful cover, though and is almost worth getting just for that.)

My favorite Prolog book is Pereira & Sheiber's "Prolog and Natural-Language Analysis". It's slanted toward NLP but the coverage of Prolog itself is top notch.

[https://www.amazon.com/Natural-Language-Analysis- Information...](https://www.amazon.com/Natural-Language-Analysis-Information- Publication-1987-07-30/dp/B01FJ1DIH6)

<comment><USER4> Uh, the cover did not move me. Especially at $150

<comment><USER5> [https://mitpress.mit.edu/books/art-prolog-second- edition](https://mitpress.mit.edu/books/art-prolog-second-edition)

That's the book they meant (referred to as having a "beautiful cover").

<comment><USER6> ...and it's Open Access, i.e. free download.

<comment><USER7> Holy Cow, I had no idea. I have a physical copy, but now I can suggest this to everyone.

</comment></comment></comment></comment></comment></comment><comment><USER8> It's a fun language to play around with and everything. Just have never seen anyone us it at scale in the industry other than folks doing research/academia.

<comment><USER9> "Datalog is a declarative logic programming language that syntactically is a subset of Prolog." [1]

"Datomic is a distributed database and implementation of Datalog.". Datomic seems to be quite succesful [2].

Related to datomic, I'm trying to learn Datascript these days ("An immutable in-memory database and Datalog query engine in Clojure and ClojureScript.") [3].

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

2: [https://www.datomic.com/customers.html](https://www.datomic.com/customers.html)

3: [https://github.com/tonsky/datascript](https://github.com/tonsky/datascript)

<comment> cgrand-net Datalog is a subset of Prolog syntax and logical semantics, but not of its operational semantics, so in practice the link is tenuous.

I like the honest words of Serge Abiteboul (co-author of Foundations of Databases [http://webdam.inria.fr/Alice/](http://webdam.inria.fr/Alice/)) on this topic:

 _This is back to the advantages of "declarative programming". The first scam was Prolog: The language is not really declarative. The second scam was Datalog: It is declarative, but there is not much you can do with it._

 _Datalog is simple and beautiful – Horn clauses. We theory guys had a ball with it. There were beautiful results to obtain even at the cost of further simplifications (e.g., monadic to be able to decide containment). But the scam is that if you want to do anything serious beyond your stupid positive first- order queries, you need more._

 _There was no fix that I know of for Prolog. There were fixes for Datalog. Extend the language. And this was done during the last 30 years_

([http://abiteboul.blogspot.com/2012/08/datalog-revival-for- da...](http://abiteboul.blogspot.com/2012/08/datalog-revival-for-database- geeks-only.html))

<comment><USER10> >> The first scam was Prolog: The language is not really declarative.

The language is not _fully_ declarative. It's something like 90% declarative, but that is not enough to satisfy the purists, who demand 100% purity, or else!

... or else they will stick to their C++'s and their Javas and SQLs, that are, oh, about 0.01% declarative. Because that makes sense, right? If you can't have a perfectly, purely declarative language, throw out the baby with the bathwater and go back to your purely imperative languages.

That kind of criticism has never made any sense and it doesn't make sense now.

>> But the scam is that if you want to do anything serious beyond your stupid positive first-order queries, you need more.

You can't do anything serious with Datalog? Sure you can- you can do _machine learning_ with Datalog:

[https://github.com/metagol/metagol](https://github.com/metagol/metagol)

<comment> cgrand-net >> Sure you can

The author spent decades on Datalog and when he says Datalog he talks about the core Datalog not even Datalog¬, he is just stating that the core Datalog is a wonderful seed for building actual applications by extending it.

</comment></comment></comment></comment></comment><comment><USER11> I found Ivan Bratko's Prolog Programming for Artificial Intelligence excellent (I've read the previous two editions, but not the current 4th).

<comment><USER12> I enjoyed it. I didn't read other prolog books since so I can't compare but I'd still suggest it.

</comment></comment><comment><USER13> I wish there was a way to electrify such paper scans into some roff or TeX format for perfect reproduction and scalability. Anyone up for an ML project doing that?

</comment><comment><USER14> I emailed Dr Colmerauer about this once and asked about the Fortran source, but his recollection is that it has been lost. :-/

</comment><comment><USER15> What is the relation of Prolog constraint programming and "Google OR-Tools" ?</comment>


SSL is not about encryption - <AUTHOR> http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html <comment><USER2> Something needs to change drastically, or I can see these problems getting worse over time. Those little "secure" images in the address bar mean nothing to 95% of the population. A lot of people don't even know the difference between a Google search bar and the address bar. Pop-ups appear that are fake OS message boxes warning about viruses and people fall for these left and right.

The only way to solve these problems is to educate people. Perhaps a little tutorial pops up after you've downloaded your web browser -- "If you want to keep your information from getting stolen, follow this little instructional guide on how to safely browse the web. It will only take 5 minutes of your time". I think a lot of people would do it.

</comment><comment><USER3> SSL is about encryption. Don't tell bullshit to people just to make a point. Because they believe it at the first degree.

In fact, SSL (and others) are about:

\- confidentiality (encryption!!)

\- integrity

\- authenticity (trust!!)

and in a lesser but important nonetheless fashion:

\- availability

\- non-repudiation

</comment><comment><USER4> He is both right and wrong IMO. Ssl is about encrypted communication to and from the server, but the cerrificate also means that you are sending your data to a trusted authority, and the people are who they say they are. I think the real issue is that the switch from http -> https can be a security hole and the safest bet is to use ssl before you ever start entering credentials.

<comment><USER5> It's always good practice to type in the https. It's not to difficult to stop the redirect from http => https.

<comment><USER6> If the server redirects from HTTP to HTTPS, how is it possible to stop it?

<comment><USER5> MITM attack. If your on the same networking and the router isn't configured to block ARPing. You can proxy the traffic that filters out the redirect. Your proxy keeps the https connection open and passes back unsecured content. Public wifi can be a bad idea sometimes...

</comment></comment></comment></comment><comment><USER7> What a weird semantic game. It is about encryption. Without it you wouldn't be able to "[establish] a degree of trust in a site's legitimacy that's sufficient for you to confidently transmit and receive data with the knowledge that it's reaching its intended destination without being intercepted or manipulated in the process"

<comment><USER6> I've learned to completely ignore the title of any article I see on HN. A disproportionate number of them simply use titles as a way to grab attention. This article is typical of the pattern - the title is used only as part of a few sentences at the start of the text, then its completely ignored and the real article begins.

I've noticed that ignoring the title often helps me to really evaluate what an article is saying independent of the bias (and frustration) that a bad title creates.</comment></comment>


Show Me What's Wrong - a tool for helping with "computer issues" - <AUTHOR> http://showmewhatswrong.com/

<comment><USER2> This is really nice. We are going to try it for hard-to-reproduce browser issues in one of our apps.

Feature request: Could you add some meta-data to the notification email with user-agent info? Would be nice to get browser, OS, screen res, js and flash support, and anything you can get about network properties (DSL, dial-up, hostname and location, etc).

</comment><comment><USER3> Fog Creek Copilot (<http://copilot.com/>) one-ups this by allowing you to just _fix_ the broken machine--and it's free on weekends. No, it's not perfect, and yes, Show Me What's Wrong and its ilk definitely have their place, but if it's just family and friends, why not cut out the frustrating reinterpretation of the screencast?

</comment><comment><USER4> I'm not sure how you process a video "102%", seems like that might be a bug. Other than that seems like it could be pretty useful.

</comment><comment><USER5> Really easy to use. I love it. Would be nice if you could choose custom URLs (instead of <http://showmewhatswrong.com/submit/c6VbeeTi> I could have <http://showmewhatswrong.com/submit/reedlaw>)

<comment><USER6> Would also be nice if you could white label it. So I could have showmewhatswrong.xyz.com

</comment></comment><comment><USER6> This counts as something that is so obvious that everyone is going to think "why didn't I make that?"

I just sent it to my team and we're going to try it. My only worry is that I have no data about the java install base size.

Otherwise, think of all the issues this solves!

Customer: I can't get on the site.

Me: What are you trying to do?

Customer: I want to get the log on!?

Me: OK. Did you go the the home page and click signup?

Customer: What?

Me: OK. Type in www.xyz.com

Customer: Oh, yeah, I did that.

Me: OK. What are you trying to do?

Customer: Etc

 __continue for 20 more e-mail exchanges __

Me: OK. This looks like a new IE6 issue that we havne't run into before. Joy. We'll take a look and try to have it fixed within the next week.

This app would solve the above problem.

</comment><comment><USER7> <http://imgs.xkcd.com/comics/tech_support_cheat_sheet.png>

</comment><comment><USER8> This could easily be used to share development/design feedback with a team. One of the more frustrating limitations of working from home is the difficulty in showing a few someones a quick screen share. We've used iChat for this in the past, but it proved to be buggy and crash prone. This looks like it might fit the bill.

</comment><comment><USER9> Nice. How about live streaming ? Often my "friends & family" simply get confused by some gui and the best way to help them starts by asking them to click on the 'tightvnc server' icon on their desktop.

<comment><USER10> www.copilot.com does this

</comment></comment><comment><USER11> Nice, but I didn't get: what software is used to record the screen?

<comment><USER5> Seems like a java app.

<comment><USER12> This is awesome! Does it work on Linux too?

<comment><USER13> Nope. Blew up my KDE4 session.

</comment></comment></comment></comment><comment><USER14> Looks good.

The only thing is that I find I'm often solving "the internet is broken" issues these days, so there might be a circular problem there.

</comment><comment><USER15> What about security implications? Can anyone view the uploaded recordings? Maybe an optional password protection will be cool.

</comment><comment><USER16> How is it better than using zolved.com?

<comment><USER17> seems to me that you need to install some software to share your screen. that is much more complicated than what was showed in this screencast. since most people that need help with fixing a problem on their computer probably also would have trouble installing and using the zolved.com screen share utility this site is a vast improvement.</comment></comment>


Common Ways a Site Can Get Hacked - <AUTHOR> http://blog.nerdery.com/2013/10/building-secure-website/

<comment><USER2> I believe one additional way to mitigate Risk #2 "Broken Authentication and Session Management" should become best practice:

The ability to sign out of all other sessions.

Without this a user who forgot to logout from a library would be out of luck until the session expired.</comment>


Security Analysis of a Full-Body Scanner - <AUTHOR> https://radsec.org/ <comment><USER2> From the paper:

"To a degree that surprised us, our attacks benefited from testing on the device itself. Our first attempts at implementing a new attack strategy were often visible to the scanner, and reliable concealment was made possible only by iteration and refinement.

[...]

The effectiveness of such a strategy depends critically on the difficulty of obtaining access to the machine. In addition to the device we purchased, at least one other Secure 1000 was available for sale on eBay for months after we obtained ours. We do not know whether it sold, or to whom."

<comment><USER3> If the attack you are worried about is terrorism (which I imagine it must be, since that's the thing these things purport to stop, I suppose), then I don't think this is a big problem. Terrorists get about as much bang for their buck whether or not they get caught, so they can presumably just try out their strategies a few times and see if they get caught.

</comment></comment><comment><USER4> These machines are such a blatant violation of our Constitutional rights. We shouldn't be searched like this without probable cause or a search warrant. Whether they are effective or not is irrelevant.

<comment><USER5> We don't have a constitution.

(Not everyone on the internet is American, and of those who are, none can do anything about erosion of your rights. Complain to your local political representative, who potentially can).

<comment><USER4> Sorry for the US-centric comment. All people are created equal with unalienable rights, so we shouldn't be trampling the human rights of foreigners either. It's just easier to point out the abuses when we have governing documents that explicitly say we shouldn't be doing the thing that we're doing.

<comment><USER6> > It's just easier to point out the abuses when we have governing documents > that explicitly say we shouldn't be doing the thing that we're doing.

Can you explain what part of it is unconstitutional? Because while I'm totally against it, I think it is pretty much entirely constitutional because airlines are a private business that no one is being forced to go through. But I clearly don't know much about this and would welcome an education.

<comment><USER7> Earlier this year, the ACLU won a case regarding the constitutionally of the no-fly list[1]. Basically, their argument was that you can't give up your Fifth Amendment rights (due process) when you travel internationally. Since this argument won, it implies that Fourth Amendment rights (probable cause searches) also cannot be forfeited.

Relevant quote:

"Accordingly, the Court concludes on this record that Plaintiffs have a constitutionally-protected liberty interest in traveling internationally by air, which is affected by being placed on the No Fly List." [2]

[1] - [https://www.aclu.org/national-security/latif-et-al-v- holder-...](https://www.aclu.org/national-security/latif-et-al-v-holder-et-al- aclu-challenge-government-no-fly-list)

[2] - [https://www.aclu.org/sites/default/files/assets/latif_v_hold...](https://www.aclu.org/sites/default/files/assets/latif_v_holder_opinion_and_order.pdf)

<comment><USER8> The Fourth Amendment only protects against unreasonable searches without probable cause. The Supreme Court could well decide that airport scanners are reasonable and therefore do not require probable cause.

</comment></comment></comment></comment></comment></comment><comment><USER9> Hi! Lead author here.

We'll be giving a talk on this work tomorrow at the USENIX Security, but I'm happy to answer any questions you have here before then.

<comment><USER2> Theoretically, how many of these (or similar) techniques would work against the millimeter wave scanners currently deployed in US airports?

<comment><USER10> Don't the millimeter wave machines perform a 360 degree scan? That would at least eliminate the really facepalm-inducing "put your gun on the side of your body" attack.

<comment><USER11> Doesn't seem that way. The sensor revolves around the subject being scanned, but the images that have always been shown as coming from the machine are just front and back images.

From L3's sales site for the ProVision MMW machine, sample images:

[http://storage.pardot.com/16582/23361/product_provision_L_3_...](http://storage.pardot.com/16582/23361/product_provision_L_3_composite_300dpi.jpg)

Their "ATD" model that includes image analysis to automatically flag "anomalies" only seems to show front and back, too.

[http://storage.pardot.com/16582/23381/products_ait_ProVision...](http://storage.pardot.com/16582/23381/products_ait_ProVision_ATD_Mannequin_300.jpg)

In 2012, the "TSA Out Of Our Pants" guy previously documented the "conceal a metal object on the side of your body" attack, and did so against the MMW machines with the ATD software on them:

[http://tsaoutofourpants.wordpress.com/2012/03/06/1b-of- nude-...](http://tsaoutofourpants.wordpress.com/2012/03/06/1b-of-nude-body- scanners-made-worthless-by-blog-how-anyone-can-get-anything-past-the-tsas- nude-body-scanners/)

<comment><USER10> Interesting. I always assumed it was doing a 360 scan. The sample images do seem to hint at a 2D scan, though the ATD front & back cartoon should be enough to highlight anomalies anywhere on the traveler's body.

It's too bad the "TSA Out Of Our Pants" guy didn't have a hidden camera accomplice to film his entire trip through security.

</comment></comment></comment></comment></comment><comment><USER12> As everyone knows, they aren't there for security.

They are there for theater.

Meanwhile the number of TSA "officers" arrested continues to grow each month [http://tsascandals.wordpress.com/](http://tsascandals.wordpress.com/)

<comment><USER13> I always opt out for this reason, even when I'm risking missing my plane. Paying contractors a lot of taxpayer money for a public placebo is offensive, and this makes me feel true to myself, but I wish I knew a more effective method of protesting. Currently no one really wonders about the odd out-out.

</comment></comment><comment><USER14> They removed these machines from airports in 2013 but are still using them elsewhere - prisons, gov't offices. So while you may not be able to bomb a plane, you can still take a gun into court. Lovely!

<comment><USER15> The airports I frequent (in particular San Jose International) are very much still using full-body scanners.

Edit: Do you mean this particular model is no longer in use? If so, are newer models not susceptible to these attacks?

<comment><USER16> Backscatter x-ray technology was removed from airports. [1]

All airports now use millimeter wave technology. [2]

[1] [https://en.wikipedia.org/wiki/Backscatter_X- ray](https://en.wikipedia.org/wiki/Backscatter_X-ray)

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

<comment><USER17> Millimeter wave scanners still subject the body to radiation, even though they don't have the work "X-Ray" in the name. Radiation damage to your body is cumulative throughout your life, so if you care about your longevity, you'd be wise to opt-out of subjecting your body to this radiation whenever possible.

<comment><USER18> So you've got a bunch of responses, but as a guy with a Master's in applied physics I wanted to chime in with a bit more of a long explanation.

The word "radiation" just means that something _radiates_ \-- it travels off to infinity. In this case we're talking about electromagnetic radiation, which spans a vast continuum from radio waves through microwaves to infrared and red, across the visible spectrum to deep blue, then on into ultraviolet, X-ray, and gamma light. It turns out that this radiation is _quantized_ \-- meaning it comes in lumps of a certain energy E = hf where h is a fundamental constant and f is the frequency of the light (equivalently, f = c / L where L is the wavelength). Light also comes with a certain "kick" or momentum p = E / c. We knew the latter formula from classical electromagnetism but the former formula was awarded two Nobel prizes, one to Max Planck and one three years later to Albert Einstein.

It is presently thought that the blue side of the non-visible electromagnetic radiation spectrum (UV, X-rays, Gamma rays) is cancer-causing, while the visible and red-side of nonvisible is not. This comports with the Planck/Einstein law for the energy of the photons, which approaches the bond energies for several common atomic bonds in the visible spectrum and exceeds it as we go into the ultraviolet. (We essentially see light by having the light excite these bonds, but not so much that it tears them apart, so as they "relax" to their starting configuration they release the energy and activate neurons.)

Microwaves are about 1mm or 1cm long, on the red side. They are emitted by microwave ovens, cell phones, wifi hotspots, and millimeter-wave detectors. Right now it's not thought that these are "dangerous" radiation any more than white light is, because their "kicks" don't excite the atomic bonds but are instead absorbed by proteins as a whole, in a process we presently think is indistinguishable from any other sort of heat transfer. That is, they heat you up, but don't do much else.

If they did something else, probably very large changes would have to be made to our modern scientific understanding, which I of course would totally support if experiments bore it out. At present there are no good experiments which show any other effects of microwaves on biological tissue, other than the heating thing.

<comment><USER19> I like this response a lot and am going to adapt it to explain this to my radiation-paranoid family.

The concept of wavelength as the sole distinction between these types of radiation is probably abstract to most non-science-educated people. Can you (or anyone else) think of a good concrete real-world analogy of different types of X that vary only in Y and some X are harmless but those with Y are not? Maybe an analogy of throwing sand at someone vs. shooting a bullet?

<comment><USER18> The sand/bullet one is probably apt, if indirect. The issue is that different "kicks" get absorbed in different ways by the stuff which makes up your cells. One gets absorbed by the chemical bonds and tears them apart; one gets absorbed by the molecule as a whole.

I think maybe the best way to give the idea is to contrast a car crash with a bullet at the same energy. According to Wikipedia, a really strong rifle cartridge (in this case, the .220 Swift) fires its bullet with at most 2.4 kJ of kinetic energy, which is about the energy of me moving at 15 mph. So you can imagine me, getting shot, flying backward at ~10 mph. But also there's the exact same energy and momentum transfer as is in me falling asleep and veering into a tree while driving at 10 mph. So why do I think that the 10mph crash is survivable as long as I don't get thrown from the vehicle, while the bullet would likely be fatal?

The difference is that the seat belt distributes the force over most of my upper torso, whereas the rifle distributes all of its kick in a particular place. Similarly, the "smaller" photons distribute all of their kick on particular atoms, while the "bigger" photons tend to distribute their kick on the protein as a whole. One "rips the stuff apart", the other causes it to bump into its surroundings more.

<comment><USER19> Thanks.

What's your take on the possibility of damage suffered from exposure to RF radiation? There are reports from credible institutions (/u/jamoes mentions one above) that RFR, despite causing "only heating", may have detrimental impacts.

When I see lists of studies like this [1], it's hard to know what to think. Are most of these weak studies or unsettled science?

I know this is a really broad question; I'm obviously not asking for comments on specific studies listed those tables. I'm curious about comments on the seeming contradiction between the observation that at a theoretical level RF radiation at moderate intensity is thought to be known to be provably harmless, and the large number of reports of observed non-trivial(?) effects.

[1] [http://www.bioinitiative.org/rf-color- charts/](http://www.bioinitiative.org/rf-color-charts/)

<comment><USER18> That's really hard for me to answer, because while I can address the physics side pretty well the physiology side is not really my forte. More importantly, you have to have someone who knows the studies _holistically_ rather than piecemeal, because of the numbers.

What I mean is -- and I'm not necessarily accusing bioinitiative.org; I'm just stating that it's something we have to watch out for -- it's possible for a lot of reports from credible institutions that have good, correct studies warning about X, even if X is totally harmless.

One of the easiest ways for this to happen is the simple fact that at least one in twenty journal results should be wrong, because that's how 95% confidence intervals work. If a thousand 95% studies are done on a safe thing then you should ideally have 50 studies which can't make that conclusion.

Let me speak about a case which is related which I _do_ know a little about; the Interphone study. This was a massive international case-control study on the effect of mobile phone radiation (also microwaves) on various forms of brain cancer. You can see one of the full articles reporting the data here:

[http://ije.oxfordjournals.org/content/39/3/675.long](http://ije.oxfordjournals.org/content/39/3/675.long)

In this case, bioinitiative.org released a press release stating "Today's release of the final results of the ten-year long World Health Organization INTERPHONE Study confirms previous reports showing what many experts have warned – that regular use of a cell phone by adults can significantly increase the risk of glioma by 40% with 1640 hours or more of use (this is about one- half hour per day over ten years). Tumors were more likely to occur on the side of the head most used for calling."

I will state that _that press release_ \-- not necessarily the whole bioinitiative.org project; I don't know enough to say that, but _that press release_ in particular -- is cherry-picking the data _significantly_. Lots of bloggers picked up this headline too, but I don't think they read the scientific study that they were blogging about (as a rule).

If you _actually look_ at that study you'll see -- to take table 2 as my example -- that there is a table of 50 results presented with 95% confidence intervals. Of those 50 results, a shocking twenty of them result a statistically-siginificant observed _preventative_ effect of cell phone radiation on meningioma and glioma while only one of them (the glioma case that they cite) showed a statistically observed damaging effect. The authors' actual conclusion was much more meek, "Overall, no increase in risk of glioma or meningioma was observed with use of mobile phones. There were suggestions of an increased risk of glioma at the highest exposure levels, but biases and error prevent a causal interpretation. The possible effects of long-term heavy use of mobile phones require further investigation." (There may even be simple correlations which would cause cell-phone users to have less cancer -- maybe strong social bonds protect against cancer and cause cell phone use; or maybe people who use their brains more find the distraction of cell phones harder to resist and also have a higher turnover in brain cells, making it harder for cancer cells to find purchase, or something.)

As far as I know, that is the largest study that has ever been done on cancer, but there may be other "detrimental impacts" (as you call them) which are not cancer, of course. You would need to consult someone who has a holistic view of the info, not a physicist who happened to read that one study when it came out in 2010.

<comment><USER19> Thanks. I very much appreciate your substantive response.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> From the FAQ:

> _Q. Isn't it bad to publish details of possible attacks?_

> We have omitted a small number of sensitive details from our attacks in > order to avoid providing recipes that would allow an attacker to reliably > defeat the screening process without having access to a machine for testing.

</comment><comment><AUTHOR> And the USENIX page: [https://www.usenix.org/conference/usenixsecurity14/technical...](https://www.usenix.org/conference/usenixsecurity14/technical- sessions/presentation/mowery)</comment>


Set up the CTRL text-generating model on GCE with just a few console commands - <AUTHOR> https://github.com/minimaxir/ctrl-gce <comment><AUTHOR> This repo is the promised followup to my comment on the CTRL submission yesterday which linked to examples I made during testing: [https://news.ycombinator.com/item?id=20948760](https://news.ycombinator.com/item?id=20948760)

<comment><USER2> Thanks! Stupid question: if I don't want to spend fifty cents an hour to play with it, and have a machine with lots of RAM, is it possible to hold the model in RAM instead (rather than VRAM)? I'm sure this would be a serious slow-down, but it seems possible?

<comment><AUTHOR> It _should_ be possible to run the model on a CPU, but I haven't tested it.</comment></comment></comment>


Ask YC: Other than Google Adwords, what is the best form of paid advertising? - <AUTHOR>

I am helping with a stealth startup that will use Adwords predominantly for its advertising.  What other effective paid advertising tools are out there.  Creative responses would be great too. <comment><USER2> For paid ads, I like searching the Adbrite.com directory for bargains. Find sites with 500 to 5000 hits a day. Pay the default .05 cents per CPM and you will be paying .05 to .25cents a day to reach all of those people. Finding the right sites is a bit of a challenge but you only have to find a few sites and stick with those to drive new traffic to your site every day.

</comment><comment><USER3> <http://inthesidebar.com> is a recently-launched ad network targeting developer/designer crowds. (disclosure note: i am one of their publishers)

there is also the deck <http://decknetwork.net/>

<http://adify.com> is the head honcho but I haven't had a good experience with them.

</comment><comment><USER4> I have had great luck with StumbleUpon advertising, but it really depends on the site you're trying to promote. The problem with SU is that you need to capture the user in the first few seconds, or they're just going to click "stumble" and bounce to the next site. But if you do have a fun/interesting/cool site, SU is a great source for consistent and cheap traffic ($0.05 per visitor).

</comment><comment><USER5> How about <http://www.projectwonderful.com/> ?

I actually used it once to advertise my blog. It worked fairly well, but I wasn't really interested in advertising my blog; I was just interested in trying Project Wonderful.

</comment><comment><USER6> Stick with AdWords initially and worry about it more later. Until you have a significant amount of traffic no one cares about you. Once you do have traffic you can try out a bunch of ad networks until you find the best one(s) for your site.

</comment><comment><USER7> Federated Media is popular among tech-targeted sites. You can check out their publishers here: <http://www.federatedmedia.net/authors/index>

</comment><comment><USER8> There's also interesting affiliate programs. Everyone knows about Amazon's affiliate program. There's also Linkshare.com that represents a large number of web sites as well as numerous web sites that have an affiliate link.

<comment><USER9> We use Share A Sale for our (newly launched) affiliate program. However, the bigger sites generally aren't in their network, so you don't get top tier placement across the web.

</comment></comment><comment><USER10> I'd look into serving ads (using your own system) with affiliate codes built in that target the niche your startup is servicing.

Payouts tend to be higher than AdWords, but are based on actions not clicks.

</comment><comment><USER11> You should check out right media, their ad exchange (soon to be Yahoo AMP) pulls in multiple ad networks. <http://www.rightmedia.com/>

</comment><comment><USER12> really depends on what your app does and what market it targets. there are tons of specialized ad networks that work to maximize revenue based on what you're doing.

or you could go down the route of obtaining sponsors/advertisers yourself, and managing ads on your own. cut out the middleman, get a bigger profit, but have to deal with the overhead of it yourself.

</comment><comment><USER13> <http://www.lookery.com>

though I don't know how effective it is

</comment><comment><USER14> use pubmatic.

</comment><comment><USER15> check out appsavvy</comment>


The development of handwriting recognition for Windows 7 - <AUTHOR> http://blogs.msdn.com/e7/archive/2009/02/09/recognizing-improvements-in-windows-7-handwriting.aspx

<comment><USER2> Pretty interesting stuff.. it's a pretty stunning demonstration of neural networks and related algorithms. I find it amazing at just how broadly this kind of technology can be applied.. from speech and handwriting recognition.. to breaking captchas. Awesome stuff. :)</comment>


NS8 CEO resigns; investigation and layoffs follow - <AUTHOR> https://www.reviewjournal.com/news/science-and-technology/tech-company-ceo-abruptly-resigns-investigation-and-layoffs-follow-2117209/ <comment><USER2> Simply shocking for a company that closed a $123MM Series A that in June, led by Lightspeed.

[https://techcrunch.com/2020/06/10/ns8-raises-123m-led-by- lig...](https://techcrunch.com/2020/06/10/ns8-raises-123m-led-by-lightspeed- for-its-suite-of-online-fraud-prevention-tools/)</comment>


A Look Back at Single-Threaded CPU Performance - <AUTHOR> http://preshing.com/20120208/a-look-back-at-single-threaded-cpu-performance/ <comment><USER2> (2012)</comment>