Beautiful Code - <AUTHOR> http://alarmingdevelopment.org/?p=79 <comment><USER2> Three sad programmer stories and a happy ending:

In order to handle complexity, I split my program carefully into modules with low coupling. I'm happy until a new feature comes along which cannot be implemented without destroying the independence of the existing modules. Then there are two options: Either I redesign the system based on the new requirements or hack the new feature into the old architecture. Both alternatives make me sad.

I recognize some repetitive pattern in my code. So I create some straightforward abstraction that removes the redundancy. I'm happy until the pattern appears again, but this time in some slightly different form so that the old abstraction can't handle it. Then I change the abstraction to include the new case. Eventually, I realize that the abstraction has only complicated the system, because now one has to understand both the implementation of the abstraction and the use of it. This make me sad.

I'm working on some easy task. I know that I have solved problems like this many times before. Unfortunately this time my brain just refuses to solve the problem. Without solving the problem, I go home and think about pursuing a different career.

On the next morning I solve the problem within 5 minutes and I'm glad to be a programmer.

<comment><USER3> > Eventually, I realize that the abstraction has only complicated the system, > because now one has to understand both the implementation of the abstraction > and the use of it.

That's a real problem. The best abstractions are so useful, that they even help understanding when you only use them once.

E.g. functions come to my mind --- because they have clear entry and exit points (of control and communication), they can be easier to understand than the same code inlined.

(Functors and Monads also seem to enhance my understanding.)

<comment><USER4> Functions are indeed a good tool but at one point, they accumulate more and more parameters or more complex structures as parameters. Eventually, while you still understand the purpose of a function, it is difficult to understand all that it abstracts away.

I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.

<comment><USER3> Yes, a function should be short and sweet. This applies very well to functions in Haskell or Scheme (or words in Forth). Those languages (Scheme slightly less so) also have low syntactic overhead for defining a function/word.

It's OK for functions to grow more abstract. Just provide the simple things, too.

E.g. you start out with `map' and `filter', but then realize that `foldr' can express both of them and much more. One viable path is to rewrite the definitions of `map' and `filter' in terms of `foldr'. One should not use `foldr' everytime in the code where a `map' or `filter' suffice.

One can layer abstractions and then use the most specific tool possible that still has all the flexibility you need at each point.

<comment><USER4> As features accumulate over time, I find this is harder and harder to maintain. But it heavily depends on the situation (abstractions don't always hold as well as originally hoped). I guess I just remember more the times it goes wrong than the times it went right.

<comment><USER3> Oh, I often have to bang my head against the wall quite a few times, before I hit on the right abstraction.

Having more powerful abstraction techniques, like they are possible in languages like Haskell or Scheme/Lisp, tends to give less leaky abstractions for me.

</comment></comment></comment></comment></comment></comment><comment><USER5> I've been learning functional programming over the last few months and I really like it. I can't help but notice, however, that there is a difference in "beauty" as it applies to fp and oop.

A good piece of OOP code is verbose yet simple. It may be a world of nouns, but there's a little tiny chunk of code in there that does one thing and does it well. Beautiful OOP is made for morons. And I mean that as a compliment.

FP, on the other hand, couples the data structures so tightly in with the code that I'm always the human linker -- keeping track of dozens of different things at the same time. But when done well, all of this incredible amount of work just falls out of a line or two of code. You have to keep track of the pieces, but your opportunity to combine them in cool ways is incredibly higher. Beautiful FP is like watching origami -- from a simple base somehow something beautifully complex emerges.

Then there's the difference between beautiful startup code -- you have no idea of the problem so it is able to pivot in multiple directions quickly, and beautiful commercial code -- you know the problem and you've met the solution in the most maintainable, understandable way possible.

The term "beautiful" is overloaded too many times. And good coders aren't looking for artistic perfection. I agree with the author: it's a bad idea.

<comment><USER6> "I can't help but notice, however, that there is a difference in "beauty" as it applies to fp and oop."

I don't know that I agree with this. Code is code. Now, I _will_ agree that you may have to take a different approach to writing beautiful code in OOP vs FP. But I don't think that what makes functional code beautiful is different than what makes object-oriented code beautiful.

In all, I feel that beautiful code is (in this order):

* Something that gets the job done.

* Something that gets the job done _correctly_ (there _is_ a difference).

* Something that tackles a complex problem in an easy-to-understand way.

I agree that we as programmers shouldn't seek perfection when no perfect solution exists. However, it's usually in your best interests in the long term to put forth the extra effort to make your solution beautiful where it's feasible.

</comment></comment><comment><USER7> Another quote re: 'not smart enough':

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

\--Brian Kernighan

</comment><comment><USER8> _...there are no general principles or techniques of software design. I hope that someday we will discover such principles._

Many of us already have.

The lack of a Universal Theory of Software Design != "no general principles or techniques".

Anyone programming today is standing on the shoulders of giants. Their trial and error is our starting point. No, they didn't figure everything out, but it they had, programs would be written by other computers, not us. Maybe someday, but I, for one, am not quite ready for that.

</comment><comment><USER9> Maybe this is an argument about what "beauty" means. The "alternative" presented in the text of "straightforwardness and conventionality" _are_ examples of what makes code beautiful, in my opinion.

<comment><USER10> That is the problem with these vague terms that are used to describe poorly defined virtues, isn't it? Everyone can take whatever meaning they choose out of a term like "beautiful code." For you, I suspect "beauty" is nearly synonymous with "good". For the author, I think "beauty" was closer to "elegance." But there I go, defining one vague term with another.

<comment><USER6> From someone on StackOverflow:

"Beautiful code is like obscenity. You know it when you see it."

[http://stackoverflow.com/questions/20564/what-constitutes- be...](http://stackoverflow.com/questions/20564/what-constitutes-beautiful- code/20580#20580)

</comment></comment></comment><comment><USER11> _Beauty is not a sufficient basis for a happy marriage._

But every happy marriage is founded on that each finds the other beautiful.

If you at least get the foundation of the system "beautiful", when the abstractions start to leak, as they invariably will, you can manage them to a much greater extent. You're right about not expecting the simplicity and elegance to remain, but there's a huge difference in manageability toward the end of each system's life. Get the foundation right; the house will follow.

<comment><USER12> _But every happy marriage is founded on that each finds the other beautiful._

Really? That doesn't accord with my experience, or any actual research that I've read. The conclusion of the research that I've read is that appearance generally matters more to men, and less to women. And anecdotal experience suggests that the initial infatuation fades in perhaps 7 years or so, and after that looks don't help that much.

Not that you're likely to believe me. After all I've only been married 20 years, so what could I know?

<comment><USER13> Good, if beauty is not important, tell your partner you don't find him/her beautiful anymore.

I think his/her reaction will disabuse you of that notion.

<comment><USER12> Way ahead of you.

I told my girlfriend that I didn't get together with her for her looks yet she married me anyways. That was 20 years ago and we're still married.

</comment></comment></comment></comment><comment><USER14> What's sad is that he refused the project rather than express his viewpoint.

If his point was that beautiful code is rare and only refined through a long iterative process perhaps he could've found some code that was initially average or even bad and showed what each incremental refactor/rewrite did to it until it became "beautiful".

<comment><USER15> I don't think it's sad. He felt that the project put forward a way of thinking he disagreed with - I too disagree with that way of thinking.

My last boss told me "there are programmers who produce code with absolutely no bugs or problems". I would prefer no to give that kind of misconception any more ammunition.

</comment></comment><comment><USER16> In the larger sense beautiful code may not be a very useful concept, but when it comes to a tangible piece of code, the actual lines in front of you on the monitor, there is definitely a difference between ugly and beautiful code. No question about it. And over 80% of the time the prettier code is the better one.

</comment><comment><USER17> When he says that he has learned to distrust beauty, what he should be saying is to distrust infatuation. It is infatuation that blinds us to the limitations of code (or anything else). You can get past the infatuation and beautiful code will still be beautiful -- even though you can see its limitations.

</comment><comment><USER18> I wonder how much of the tension the author alludes to between code and beauty is due to the connotation that beauty is somehow uncompromising. I too share a certain discomfort with that notion, largely because most projects evolve, which makes full understanding impossible and compromise necessary. That said, I think there's a certain beauty in a good trade-off and perhaps us programmers could benefit from celebrating that.

</comment><comment><USER19> Trade-off, trade-off, trade-off.</comment>


Ask HN: Best way to monetize free compute power? - <AUTHOR> For various reasons that I won't go into, I have free access to an unused g2.2xlarge EC2 instance (8 cores, 15GB RAM, GPU) for the next 6 months. What is the most profitable way to turn that free compute power into money?
I am currently attempting to mine ETH (I have never mined anything before), but from my limited understanding this is probably a waste of time with these compute specs. I'm sure there are up-and-coming coins that would be easier to mine, but the variety of choices is quite daunting. According to my tests, it has a mean hash rate of ~1MH/s, and a max of ~3 MH/s.
Bandwidth will be billed at the regular AWS rate, so any schemes that involve moving large amounts of data around will probably be unprofitable. I also have limited time (I work full-time at a startup and do consulting on the side), so labor/time-intensive ideas like starting a WordPress host will not be possible. I have ~20 years experience of programming and linux skills, so suggestions can be technical as you like.
I'm not expecting to make huge sums of money, but beer money would be nice, and would avoid having the machine sitting idle. I'm willing to try out any (legal) suggestions, however left-field they may appear. <comment><USER2> check out monero</comment>


Designing Pragmatic RESTful APIs - <AUTHOR> http://info.apigee.com/Portals/62317/docs/web%20api.pdf <comment><USER2> Developing REST API per definition of REST cannot be done pragmatically in the way described, so you are going to screw a lot of people if they think this is the last word on REST.

1\. REST is a hypermedia API that (somewhat) describes its own services by returning URLs to resources, etc.

Most people don't understand what REST was meant to be that can drive how REST clients were meant to be developed. Some of the major players with "REST" APIs don't either.

2\. REST does not have to be versioned if for internal use.

I actually agree with the versioning part, however I've also been on two teams over the past 10 years that developed versioned APIs and neither time did versioning matter, because those APIs were for internal use.

3\. This is not a RESTful requirement, but, practically, you shouldn't design an API that allows any querying of resources beyond what should be needed.

This is because of the memory required for caching responses (in a large application), because it therefore can be an easy target for attacks (lets throw a bunch of query params on here... mwhahahahaha), and just because it opens up security holes. Be explicit in what is allowed in your code and your documentation.

4\. The querying and filtering I see in this document is insufficient for some applications and interfaces.

It didn't take us long to run into the limitation of the search functionality described in this document in our current REST API based app.

<comment><USER3> Could you explain a bit more on the limitations of the search functionality and how you got around it? Would likely be very useful.

</comment></comment><comment><USER4> I rather like the "Richardson Maturity Model" described by Martin Fowler:

[http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html)

This gives different levels of "conformance" with the spirit of REST without name calling.

<comment><USER5> I just got round to reading that article last week, it's incredibly informative and like you say, avoids any mud slinging.

</comment></comment><comment><USER6> _Insert standard comment about how this does not touch on HATEOS and is therefore not only not REST, but evil and perverse and all that is wrong with the world_

<comment><USER7> Maybe we need a new name/acronym for this "pragmatic REST" style?

<comment><USER8> REST level 1. Or 2.

[http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html#level2)

I don't agree with people who say that only level 3 is "true REST", but there _is_ a qualitative difference.

</comment></comment></comment><comment><USER9> Totally agree @hakaaak, especially with the care that should be put into making the API navigable using hyperlinks.

It's kind of cool to have a browser-friendly API to play with in the beginning, but it should be pure bonus. APIs are designed to allow a computer program to interact with another one. Favouring query strings over HTTP headers for anything other than altering the projection of a resource is non- sense.

I also don't seem to understand why we must reinvent the wheel and duplicate features when HTTP clearly mentions how to specify an output format, and how to handle partial responses (Range, Content-Range, 206 Partial Response, etc).

PUT is not the equivalent of "update" in CRUD. PUT is meant to replace an existing resource projection with another one. PATCH is the way to go if you want to update specific attributes of an existing resource.

And what about ETags? conditional requests?

It kills me when people mix pragmatism with embracing years of bad practices. That's how we end up with standards where history and legacy are more important than common sense.

<comment><USER10> >> _I also don't seem to understand why we must reinvent the wheel and duplicate features when HTTP clearly mentions how to specify an output format, and how to handle partial responses (Range, Content-Range, 206 Partial Response, etc)._

It's not just individual features such as pagination and format handling where the article fails to suggest using standard HTTP features. After the first few pages -which do a pretty good job of explaining the most basic aspects of REST APIs- the document more or less switches to a 'just put it in the querystring'-attitude for about everything that goes beyond basic CRUD operations. Want a subselection of resources based on attribute values? Put the attributes in the query string. Want to limit the returned fields? Put them in the querystring. Need to non-standard logic for handling the request? Signal it in the querystring, so the API user can 'see it'. Want to query something or get a calculated response that needs input parameters (i.e. JSON- RPC)? Put all parameters in the query string. Want to suppress error codes or otherwise instruct the server to change its behaviour? Querystring...

Personally I don't really like using the querystring for every bit of information you want to include in a request, because before you know it the amount of crap you can include in URLS will grow out of hand. I think dumping everything into the querystring pollutes the URI space of your API, which makes it harder to efficiently cache responses or limit access to certain API endpoints.

I'm working on a web application with a REST API at the moment, and I'm trying to avoid using the querystring as much as possible. For example query arguments can also be POST-ed to a query URI that returns a link temporary resource that identifies the query result. Format specification can (and should) be handled using the Accept/Content-Type headers. Pagination can be implemented using the range and partial response headers. Complex queries that are performed often and cannot easily be encoded in a POST body (or a query string) can get their own URI (e.g. '/dogs/by-age/0-1y', '/dogs/by-age/1-5y', etc).

Probably this approach has some serious downsides, but I'm still sticking with it for now. Maybe someone can make me change my mind with good arguments? ;-)

<comment><USER9> You're heading the right direction.

I'm one of the authors of <http://greendizer.com/docs/api/>, and <https://github.com/mohamedattahri/Nuages>

Take a look at them.

</comment></comment></comment><comment><USER11> If I had to restart my API over again I would make it self-documentable.

Browsing to /dogs with an Accept: text/html would include a description about that end-point with the possibly accepted parameters, and links to related resources.

If authenticated it would also include the content of that actual route and maybe even a small JavaScript request builder.

<comment><USER12> I like the idea of self documentation but please don't do this with a text/html header. Oftentimes I want to see in the browser what the GET response is. Probably it's better to explicitly use a .html extension instead.

</comment></comment><comment><USER13> In the section "What about attribute names?" I think they get it wrong by saying that camel case would be better than snake case because it would make more sense in Javascript that way.

The issue I take with that is you can't assume your API consumer is using Javascript at all. Thus, making it camel case might look right in Javascript or many other languages, but weird in Ruby.

There are a lot of good ideas here, but I think the author messed up on that assumption. A huge portion of modern API usage is in Objective-C, Java, PHP, Ruby, C#. So, attribute naming could be valid as FooBar, fooBar, or foo_bar.

I think the right point would be to be consistent in attribute naming style. Pick one format and use that.

Designing your API to be consumed by one language is mostly foolish unless you are the only one using the API.

<comment><USER14> Yes, but JSON is JavaScript Object Notation, not (PHP|Ruby|C#|Java|Other) Object Notation. Therefore, since JSON is a serialization of JavaScript, it recommends that you should adopt the JavaScript convention of camelCase.

</comment></comment><comment><USER15> bcoates left an excellent comment here that has been marked dead for no reason that I can see.

</comment><comment><USER16> How does he talk about REST and totally forget about HATEOAS...</comment>


The other side of technical skill: domain knowledge and long-term vision - <AUTHOR> https://www.sihui.io/domain-knowledge-and-vision/ <comment><USER2> This is very hard to learn unless you keep your eyes and ears open and even your mouth sometimes; are willing to move cheese when need be; put the customer's needs before your own or even the organization if necessary; cultivate relationships even when they seem to bring nothing in at the moment; look at everything around you even if it seems not connected to what you are doing; see the big picture in even the smallest detail; learn from every misstep until you make fewer of them; and do all this without getting completely burned out.

I've spent almost 40 years try to do this in every place I've worked, sometimes you fail but often you make the place better, if only for little while.

In all the last point is the hardest, as this profession can be hard to keep doing. Every day I still wonder if it's worth it but I keep going.

</comment><comment><USER3> I totally agree with this article but I still think it didn't add much to my "knowledge base". In other words, it was quite obvious: who actually thinks domain knowledge and long term vision aren't important? For me these are skills that are necessary by all programmers, and in fact any skilled human working in any field should have these traits.

The rest of the article is quite high-level and abstract but also quite dull to the point that any of the points can be applied to anything.

Nonetheless I appreciate the writing; just wish it could have more compelling information or evidence. But also I'm being sunday grumpy so don't take me too seriously :)

<comment><USER4> I think most people would say "yes" if asked "are domain knowledge and long- term vision important?" But I don't believe most people would answer "domain knowledge and vision" if asked "what is important in a senior engineer?" For a lot of years, my answer to the latter question would have centered on technological knowledge, even though if prompted I would have acknowledged the importance of domain knowledge and vision. The distinction is significant because we will only be working on those skills that we independently identify as important.

</comment></comment><comment><USER5> I guess domain knowledged is not mentioned so often because it is (by design) very specific to the (narrow) field you are working at. Hence there is very little comercial interest on it, and few people care to talk about it.</comment>


SHA-1 Deprecation Update - <AUTHOR> http://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/ <comment><USER2> If the cost of creating a collision is $75K, it's _far_ too late to be deprecating SHA1.

Even if everyone were to somehow remove SHA1 instantly _now_ , there is stuff that has (for example) been authenticated using SHA1-HMAC over the last year which will still be relevant for years. It's not hard to think of cases where spoofed messages from a user a year ago are useful to a malicious attacker.

<comment><USER3> Exactly why Google moved to an "aggressive" timeline to deprecate SHA-1. Schneier predicted the cost of SHA-1 collisions _years ago_ and said _criminal groups_ will be able to create collisions by 2018 - which means you needed to start pushing for killing SHA-1 support _years earlier_.

But when Google did that everyone jumped on them for "trying to control the Internet" or something (because obviously trying to make the Internet adopt stronger security is a power tripping thing). I hope at least now they've seen the error in their ways.

Oh, and it turns out Schneier was actually _too optimistic_ about the costs of SHA-1 collissions - by about an order of magnitude:

> 211 * 28.4 = 219.4 ~ $700K by 2015

[https://www.schneier.com/blog/archives/2012/10/when_will_we_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

<comment><USER4> And Google's push to deprecate SHA-1 to try to drag the internet into modern security practices pales in comparison to Apple's ATS implementation, which has a brutally modern set of minimum requirements (TLS1.2, 256-bit elliptic curve, SHA-256, 2048-bit RSA key).

And given Apple's extremely vocal stance on privacy and security, and their 'sudden' addition of ATS, it wouldn't surprise me if ATS became a hard requirement in iOS 10.

<comment><USER5> ATS has nothing to do with web browsing though.

</comment></comment></comment></comment><comment><USER6> The basis of it is interesting to me: breakthroughs in finding collisions have lowered cost estimates to about $75k to break a single collision (based on GPU rented from Amazon EC2). It's interesting to see it quantified that way.

<comment><USER7> I would prefer it be measured in size of botnet. Criminals don't use EC2. They use hacked boxes. They have no cost beyond compromising the machine.

<comment><USER4> Sure, but it provides an interesting context. $75k at Amazon's EC2 prices gives you a good idea of what the ballpark is - i.e. reasonably accessible for any large organization, esp. criminal organizations.

If EC2 can collide SHA-1 with $75k of rented GPU time, imagine how trivial it is for an organization willing to buy $100k of dedicated GPU compute hardware to devote to colliding SHA-1 certificates. You don't even _have_ to botnet once you have enough working capital.

Never mind how trivial it is for an organization like the NSA or GCH to do this sort of thing with their existing hardware.

<comment><USER7> Just to note, with large GPU farms the cost of the power to run them will exceed the hardware cost in a matter of weeks.

</comment></comment></comment></comment><comment><USER8> If certs would have included both MD5 and SHA1 signatures, and required both to match, would that have bought a lot of safety? What if another hash had been added too? Because then you'd need to find simultaneous collisions across multiple functions, which at least sounds a lot tougher. But perhaps not?

<comment><USER9> Combining weak hashes doesn't provide any assurance. Let's assume that finding a new way to break MD5 is a rite of passage into certain professional cryptoanalyst circles. Do you know what they know?

Besides, there are no X509 signature types that are a combination. You'd need to update browsers... and it would be much easier to just update your hash.

<comment><USER8> Well I'm thinking more along the lines of future-proofing designs. Like right now, should a new protocol use both SHA2 and SHA3, just to be safe?

<comment><USER10> "new protocol" is likely going to be less secure than TLS1.2. And TLS1.2 doesn't allow multiple signatures - it's usually in the form of "(hash)-with-(encryption)" (for example oid 1.2.840.1135220.127.116.11 - SHA-1 with RSA Encryption) and since that's embedded in the hashed contents, you can't easily add new signatures that require specific parameters.

<comment><USER8> I don't mean related at all to TLS. I mean in general, is the principle of using multiple algorithms that bad? If, in an alternative universe certs were signed with MD5 and SHA1, would that not have been a practical defense to buy some more time? And thus for new, incompatible protocols, is it not a safer choice to use a couple of algorithms? That way if SHA2 or 3 are found to have some terrible weakness, you're still OK. And if practical attacks are found on both, it still might not mean that such attacks work _together_?

There's a bit of precedent in 3DES which just runs the same algorithm 3 times in a row... Which I guess you could do by using the same hash algorithm several times on the same input plus some fixed data or transform. So even though you can find two inputs a and b that h(a) = h(b), you might not be able to get h(f(a)) = h(f(b)) hmm? (Though I understand certain hash attacks will do exactly that for certain values of f.)

</comment></comment></comment></comment></comment><comment><USER3> While Microsoft is still debating whether it should disable SHA-1 in mid-2016, early 2017 or at the end of 2017, Google is already moving to require all certificates to support Certificate Transparency, to vastly increase the trust we can put in Certificate Authorities. As per their article they are still only "considering" removing SHA-1 support by mid-2016.

Microsoft needs to stop wasting time with _obvious_ stuff (like deprecating SHA-1, RC4, MD5, and all that), and be a little more aggressive with securing their products as well.

<comment><USER4> Keep in mind that Microsoft is a large organization, and they have to carefully consider which action is actually 'the greater good'. For example, making a breaking change (like deprecating SHA-1 in Edge) _might_ force external developers/vendors to update their servers to SHA-256, but it might also encourage enterprises to avoid updating to Windows 10 entirely, and, overall, that's far worse than letting SHA-1 certificates kick around for another six months (especially since those certs won't work with iOS 9, Chrome, or Firefox anyway).

Apple can get away with ATS because for every service/site/app that doesn't bother to update, there are ten other apps waiting in the wings to steal your users. On Windows, there's little incentive for most people to upgrade, and strong existing disincentives for enterprises/schools/organizations.

</comment></comment><comment><USER11> Good, they should accelerate it.

However, I wish that Microsoft made it extremely clear in these announcements that root certificates are not subject to SHA-1 collision attacks. Certain people [1] have misunderstood the situation and removed trust for SHA-1 signed roots (and that project is definitely not alone). Mozilla's announcement [2] does draw a distinction, but it's quite easy to miss. CAs like Entrust are much more clear about this, since their business relies on it.

It is security theater [3] to tell users that they shouldn't use a SHA-1 signed root if they want their connections to be secure. Security vulnerabilities need to be very simply and clearly communicated -- otherwise you get solutions based on preconceived notions and simplistic "X is always BAD" thinking that do more harm than good.

In this instance, people have spent days debugging connectivity issues and opening tickets with service providers. And the reasoning behind the move is not based in fact -- Mozilla has NOT removed SHA1 certs from their trusted roots [4] and they have announced no timetable in which to do so. It's simply because someone heard "SHA-1 is bad" and acted accordingly.

The current SHA-1 deprecation push applies only to chain and end certificates, _not to roots_ \-- removing trust for SHA-1 signed roots is not necessary to prevent these sorts of attacks and it is much too soon to take that step in any environment that talks to systems which you don't control on the public Internet.

[1] [http://certifiio.readthedocs.org/](http://certifiio.readthedocs.org/)

[2] [https://blog.mozilla.org/security/2015/10/20/continuing- to-p...](https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out- sha-1-certificates/)

[3] [https://github.com/certifi/python- certifi/issues/26#issuecom...](https://github.com/certifi/python- certifi/issues/26#issuecomment-147962495)

[4] [https://mozillacaprogram.secure.force.com/CA/IncludedCACerti...](https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport)

</comment><comment><USER12> Can anyone point to an existing published SHA-1 collision?

<comment><USER13> FTA: [https://sites.google.com/site/itstheshappening/](https://sites.google.com/site/itstheshappening/)

There are freestart collisions, but no actual collisions yet.

<comment><USER12> It seems surprising that if it's that cheap to find one no one has credibly claimed to have done it yet.

</comment></comment></comment><comment><USER14> Slight nitpick: I wish they would use the term "other browser suppliers" instead of "other browser vendors", as Firefox, Chrome, Opera, etc. are not sold for money, they are supplied for free.

But this is good news. Die SHA-1, die!

<comment><USER15> I'm confused; IE isn't sold for money either.

<comment><USER14> Now I'm confused, because I didn't ever imply that it was.</comment></comment></comment>


Amazon introduces Kindle for BlackBerry - <AUTHOR> http://www.amazon.com/gp/feature.html/ref=amb_link_129429842_2?ie=UTF8&docId=1000468551&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=0JYAK5DJB3T79MNT9AXN&pf_rd_t=101&pf_rd_p=722231022&pf_rd_i=507846

<comment><USER2> Still waiting for Kindle for Mac...</comment>


Show HN: GitHub App for locking closed issues after a period of inactivity - <AUTHOR> https://github.com/dessant/lock-threads <comment><USER2> is there a way to use this or try it without spinning up an instance, like Travis? I don't understand the github apps structure entirely.

<comment><AUTHOR> Sure! The app can be installed from [https://github.com/apps/lock](https://github.com/apps/lock) if you do not wish to host your own instance. The second step is to add the config file to your repository and you're all set.

[https://github.com/dessant/lock- threads#usage](https://github.com/dessant/lock-threads#usage)</comment></comment>


The many sliders of Photoshop CS4 - <AUTHOR> http://mrgan.tumblr.com/post/235455865/the-many-sliders-of-photoshop-cs4 <comment><USER2> What kind of development process leads to such variety of sliders? Don't they have one GUI library team? Did they buy all the components from other companies that happened to have their own slider implementation?

I mean, sure, some specialized implementations are useful (e.g., picking a color/hue), but this is a bit excessive. Somebody must have written all these implementations. Somebody needs to maintain them. This costs real money... why would you want to do that?

<comment><USER3> _Don't they have one GUI library team?_

Nope. They don't even have one string object or math library.

When I talked to a guy who worked on Mac stuff for Adobe, he said that pretty much anything that could be shared, _isn't_. Every flagship product is independent, and most were the result of at least one acquisition (some circular!). Pretty much every effort they've made to rationalize things into a coherent suite has just resulted in regressions, as none of the object models line up.

The engineers at Adobe know full well how shitty their flagship products are. Lightroom is what they can produce in green-field development, and it is awesome both in implementation (mostly Lua) and usability (no bloat). Apple's Aperture had a significant public first start, and was still quickly beaten with a superior product. Quite unexpected.

<comment><USER4> FWIW I still prefer Aperture over LR. LR's UI wastes a lot of screen real estate IMO.

But your main point is spot on.

</comment></comment></comment><comment><USER5> PhotoShop may be the oldest program running on your computer now. The fact that there's even a modicum of commonality in the UI is amazing. While I agree that there's a lot of room for improvement, anyone working who's ever touched legacy code can see that there's more to this issue.

[http://blogs.adobe.com/jnack/2009/05/some_thoughts_about_psd...](http://blogs.adobe.com/jnack/2009/05/some_thoughts_about_psd.html)

<comment><USER6> He's defending PSD by saying "It works great the way it is. And people shouldn't be wanting interoperability with Photoshop.

A key phrase is " _And it's not at all clear that the benefits here would outweigh the costs._ ". Whose costs, and whose benefits? Obviously it wouldn't be great for Adobe to have to re-write their file format, and they wouldn't get that many happy customers initially.

</comment></comment><comment><USER7> Sliders? There are features in Photoshop that only make sense if you have done darkroom development. They are already so heavily invested into being complex and it has been OK so far. For more reasonable UI, you can use Adobe Lightroom.

</comment><comment><USER8> I don't get it. It seems like for the author, ugly means 'not like OSX', since the only one found likeable was the one most like the default OSX slider.

In particular, layer blender, threshold, and color balance would suffer if it was more like the default.

<comment><USER9> Well, ugly could also mean "doesn't fit in with the rest of the desktop".

</comment></comment><comment><USER10> Sliders are truly annoying in computers which lack them as a physical input device.

Now, if you could a laptop with ten knobs on the side of it AND an API to use them, then sliders in an app would be cool.

</comment><comment><USER11> Is Photoshop vulnerable now? I wonder what a scrappy start-up could do in this space. What are the major technical challenges? Marketing challenges?

<comment><USER12> The problem is that there is a whole industry created around Photoshop, all artists use it, it's taught in every college/course, and there are a million books written about it. For a startup to compete against that momentum would be extremely difficult. There is also considerable competition from open source/free programs like GIMP and Paint.Net. Pixelmator seems like it's doing well, though.

I think the opportunities lie more in creating niche tools. Just look at all the tools created the last few years for photographers, the top one perhaps being Adobe Lightroom. It contains most of the image editing tools from PS that a photographer needs, but is built more around the photographer's workflow.

<comment><USER13> > _For a startup to compete against that momentum would be extremely > difficult._

I think it would be very difficult for a startup to make a replacement photoshop, but that shouldn't really be anyone's goal (photoshop already exists), and with actual novel ideas about how editing should be done, I think there are quite reasonable opportunities: it's always difficult to make quality software, but image editors and their market aren't inherently worse in this respect than email clients, say, or word processors, or many types of games, etc.

> _considerable competition from open source/free programs like GIMP and > Paint.Net_

Really? I don't know anyone who uses these for serious work. I understand the GIMP gets used in particular niches, such as among free software ideologues, but I don't think competition from these would be a real problem for anyone trying to make a serious image editor.

> _It contains most of the image editing tools from PS that a photographer > needs_

Not really. Most Lightroom users also use Photoshop, and Lightroom's goals as a product are completely different from Photoshop's (image organization, selection, comparison, rather than careful editing): they're complementary, not competitors.

<comment><USER14> I use The GIMP for serious work - production of advertising materials for print and for any non-vector elements of website designs. The quality demands (see eg <http://photoshopdisasters.blogspot.com/> ) seem so low in the print media industry that most graphic designers probably aren't using CS4 to any great advantage.

The only times I've needed anything else have been because the printers say "we only accept a PSD" or "files must be from Corel 9" or whatever. They always take something else in the end. Actually it's more often I need to use AI files and Inkscape's not doing to bad on that.

Exact colour match (pantones, etc.) doesn't matter for me; my target market couldn't generally care less that the shade is ever so slightly out and in most print situations the colour is either off at print (newspapers) or off by the point of viewing (eg magazine in a rack that's faded for a month).

<comment><USER13> > _I use The GIMP for serious work_

When you say "production of advertising materials" what do you mean? You work for an ad agency? Or you sometimes wear a "design hat" in addition to your other roles at your company? Because if you were spending 40 hours a week on design work, buying and learning and using Photoshop instead of the GIMP would pay for itself quite quickly.

I should have been clearer. I'm sure _there exist_ people who use the GIMP, even though I don't know them. I do not, however, think the GIMP provides "considerable competition" in the image editing space by any reasonable definition of "considerable". I don't have any solid numbers of my own, and really have no idea how I'd look for any, but if we just judge by, for instance, relative numbers of books offered for sale about each product, Photoshop has a simply crushing market-share advantage.

> _quality demands seem so low in the print media industry_

I don't work in print media (I'm a political science student), but this seems like a pretty cheap shot. One could take similar shots at programmers, musicians, scientists, etc.

<comment><USER14> _I don't work in print media (I'm a political science student), but this seems like a pretty cheap shot._

It's my opinion. There seems to be a lot more typos and grammatical errors that should have been caught in proof stages, a lot more poor "it'll do" type photo-shopping than in the past. This may be because I've become more focussed and more observant with respect to print media given that I'm using it for inspiration for online work and to suggest what the zeitgeist might be.

Incidentally, as you note, this probably is true in other fields too.

Edit: typo, lol!</comment></comment></comment></comment></comment></comment>


User interface for the Enterprise - <AUTHOR> https://github.com/Garrett-/lcars <comment><USER2> Dammit! I clicked the "up" button before I read the web page, thinking it was a Star Trek Enterprise, not some boring business Enterprise, where they call everything "product" and MBAs think you can treat all employees as replaceable.</comment>


Emergence - <AUTHOR> http://emergence.maxcooper.net <comment><USER2> I first discovered Cooper through his song Resynthesis[1]. I'm not very much familiar with electronic music but really like his records. His frequent collaborations with Rob Clouth[2] are also great.

I had a ton of fun remaking Resynthesis when I was first learning to use reaper using free VSTs.

[1]: [https://www.youtube.com/watch?v=Kpm1l0HfkV0](https://www.youtube.com/watch?v=Kpm1l0HfkV0) [2]: [https://www.youtube.com/watch?v=sAJaJXnE2vI](https://www.youtube.com/watch?v=sAJaJXnE2vI)

</comment><comment><USER3> If you like the music, I recommend one of Max's AV shows, they are spectacular. Here's one of them: [https://www.aether.live](https://www.aether.live)

His latest album is different musically from Emergence but it has a central narrative, this time focused on the human mind. [http://onehundredbillionsparks.net](http://onehundredbillionsparks.net)

Emergence is probably my favourite album :)

</comment><comment><USER4> Max Cooper is an absolute genius. I've been a fan since echoes reality

[https://youtu.be/gra4ugWIzLE](https://youtu.be/gra4ugWIzLE)

</comment><comment><USER5> I'm sorry, I'm one of those people that can't pick up on implicit cues very easily. This site is only an artist's visualization of scientific words with beautiful animation and imagery, right? I mean, I'm not missing any code or technical concepts, am I?

It's definitely beautiful art, and that's the only reason why it's on the front-page, right?

<comment><USER6> For the most part I think it's fair to say they are artistic representations, though one of the first images on the page is the Sacks spiral[1].

Also for whatever it's worth the artist[2] has a PhD in Computation Biology.

[1]: [https://en.wikipedia.org/wiki/Ulam_spiral#Variants](https://en.wikipedia.org/wiki/Ulam_spiral#Variants)

[2]: [https://en.wikipedia.org/wiki/Max_Cooper_(electronica_musici...](https://en.wikipedia.org/wiki/Max_Cooper_\(electronica_musician\))

<comment><USER7> Thanks for the link, hadn't heard about those spiral variants before.

ps Is it just a coincidence that..in this field where the spiral is super- reminiscent of the old computer game Snake, the triangular version was discovered by Klauber, a _herpetologist_ of all things?! Maybe. (Preston Sturges' wonderful movie _The Lady Eve_ has a scene with Henry Fonda (a herpetologist) reading a book called _Are Snakes Necessary?_ which would make a cute maths paper title.)</comment></comment></comment>


PHP Dark Arts: GUI Programming with GTK - <AUTHOR> http://www.re-cycledair.com/php-dark-arts-gui-programming-with-gtk

<comment><USER2> While I knew this was possible, I'd never considered it. However, with HipHop (<http://github.com/facebook/hiphop-php/wiki>), this might actually be an acceptable and great way to develop desktop applications.

</comment><comment><USER3> You can really use the code because it is badly formatted: <http://i.imgur.com/qOVK6.png>. Embarrassing.

<comment><USER4> Annoying, but not the end of the world. Doesn't make the article useless.</comment></comment>


Scientists Enhance Intelligence of Mice with Human Brain Cells - <AUTHOR> http://io9.com/5988969/scientists-enhance-intelligence-of-mice-with-human-brain-cells

<comment><USER2> It's great that this study has gotten so much attention in the general press (NPR story, prominent placement in Cell Stem Cell). Given the forum though, I'd like to point out that the idea that glia are of equal (or greater) importance to neurons is by no means new.

For years, it has been known that the number of neurons changes very little between lower-level mammals and humans, while the ratio of neurons:glia changes dramatically. We've also identified that direct mesenchymal stem cell (MSC) injection increased rodent cognition, and MSCs are known to differentiate almost entirely into glia in the presence of neurotrophic factors, such as in the CNS environment. Even base neuronal morphology changes little between mammalian species, while astrocytic morphology is readily distinguishable between species.

tl;dr - Nice to see it all come together, but I like to be pedantic and discuss where the impetus for this experiment came from.

<comment><USER3> >where the impetus for this experiment came from...?

Seems clear to me that the ultimate purpose is to lower the cost of white- collar workers.

</comment></comment><comment><USER4> be sure to send Algernon flowers</comment>


Travelling Salesman Shipping Depreciating Items to Different Markets - <AUTHOR> https://www.hackerrank.com/codesprint4/challenges/tbsp

<comment><AUTHOR> This challenge is like the standard TSP, with some extra twists: The salesman needs to track both his own travel costs and those of the items he is selling. Each city has different prices which the items sell for, but these prices go down over his journey.</comment>


Data Replication Between Client and Cloud - <AUTHOR> http://www.projectmeadow.com/replication

<comment><USER2> Would love to get some dialog going about better ways to accomplish this, any thoughts?</comment>


I made a tool to quickly add text to any screenshot - <AUTHOR> https://www.goodannotations.com/add-text-to-screenshot <comment><USER2> I don't want to be "that guy" but this seems like extra hassle and to be based on a false analysis:

      >You probably want a fast screen capture and maybe the ability to add text... There's no need to jump from ap [sic] to app to do something as simple as taking, editing and sharing screenshots.

On OSX, the built-in screengrab function already allows adding text and arrows/boxes etc. to screen grabs. And, for those not on OSX, using something like Yandex Disc [0] allows the same functionality via its built-in screengrab editor.

I'm not seeing why people would opt to do a roundtrip via a 3rd party website, when it can all be done with a locally installed app [and in the case of OSX, a built-in one]

[0] [https://disk.yandex.com](https://disk.yandex.com)</comment>


Ask HN: Best way for a beginner to learn Networks and Async Programming - <AUTHOR>

Hello averybody!
I've just finished Harvard's CS50 and MIT's 6.00x courses on edx. They are introdutory courses on Computer Science (the first one in C and the second one in Python).
I work as a P.O in a project, and attended this courses to understand better what my team does. The courses are excellent, and now i want to expand my studies in the area. In my project, we have code running on several machines, and i would like to understand better how they talk to each other (networking, event loops, async programming, basically).
I`ve found this course https://class.coursera.org/posa-001 (Pattern-Oriented Software Architectures for Concurrent and Networked Software), but it requires a more solid background on programming.
Any thoughts, sites, books, keywords, courses about the subject? <comment><USER2> Coursera also has a computer networks class - <https://www.coursera.org/course/comnetworks>. It might be what you are looking for. I checked it out briefly before. I think it's pretty good. For real time web apps, this stackoverflow post might help - [http://stackoverflow.com/questions/11077857/what-are-long- po...](http://stackoverflow.com/questions/11077857/what-are-long-polling- websockets-server-sent-events-sse-and-comet).</comment>


The Post-Agile Movement - <AUTHOR> https://riskfirst.org//Post-Agile <comment><AUTHOR> It's almost an article of faith ob HN that things like scrum and stand-ups are broken.

Some of us forced into sub-optimal patterns of behaviour now because the power structures of the organisations we work in prescribe following certain Agile "standards'.

There's lots of complaining (which is summarised in the article) but a lack of concrete suggestions to take things forward.

What's on the top of your wish list of improvements to make?</comment>


New way to recycle lithium-ion batteries - <AUTHOR> http://www.latimes.com/business/technology/la-fi-lithium-ion-battery-recycling-20180316-story.html <comment><USER2> " _Unfortunately, our website is currently unavailable in most European countries._ "

Here's an archived copy that works:

[https://archive.is/PaAIm](https://archive.is/PaAIm)

<comment><USER3> Yes, something is wrong at Tronc, other than their name. I noticed if you make the URL [https://](https://) manually, it works.

<comment><USER2> It doesn't work for me. I still get a redirect to: [http://www.tronc.com/gdpr/latimes.com/](http://www.tronc.com/gdpr/latimes.com/)

</comment></comment></comment><comment><USER4> Without detailed knowledge, I've been a bit puzzled by this. As far as I understand, the inputs to manufacturing of the cells (as opposed to their packaging) are all elements and oxides of elements and/or similar. Not complex molecules that can be difficult to construct.

Given enough energy, and time to find optimal processes, I don't understand why these cells aren't essentially fully recyclable.

In the meantime, if we can't do so or do so profitably, yet, segregate them from the waste stream for the day when we can and/or economics makes this profitable.

I guess this is more "planning" and consistency than most societies today are capable of.

But, our existing processes don't "destroy" the lithium, nor the cobalt. It's there, already mined, refined, and now used once. Waiting for recovery.

Perhaps we need some standards and regulations regarding packaging, both of cells and cells within their devices, to help facilitate recovery. And that could get involved, trying not to end up limiting technical and design advances.

But you could say, whatever one ends up building, the battery components have to be recoverable to X extent -- that must be a factor in your design, whatever your form-factor.

And up to this point, a lot of consumer designs are packaging multiples of more or less standard cell designs. So...

<comment><USER5> I see three factors that together have prevented recycling:

1\. quickly raising demand (this means the recycling pool is small relative to production)

2\. low cost of the mined source materials

3\. established processes

Oh I forgot number four the human factor: general shortsightedness.

As the supply of old cells grows relative to newly produced cells, the incentives will change. Especially if we hit supply shortages that increase prices.

</comment></comment><comment><USER6> Same article from Scientific American in February: [https://blogs.scientificamerican.com/plugged-in/a-new-way- to...](https://blogs.scientificamerican.com/plugged-in/a-new-way-to-recycle- batteries-uses-half-the-energy/)

</comment><comment><USER7> > metal found in finite supplies

It averages about 25 parts per million in the Earth's crust, a bit more common than lithium at 20 ppm. Gold is 4 parts per billion yet no one seems to be predicting the end of gold supplies.

i suspect that ordinary price signals will drive better utilization, newer chemistries, political will to recycle more, etc.

<comment><USER8> That wasn't what the article said. If you truncate sentences in both directions to make a distorted point, you might as well stop. The rest of the sentence reads:

> ... cobalt, a metal found in finite supplies and concentrated in one of the > globe's more precarious countries.

Notice how it reads differently.

<comment><USER7> It was a general point about how there are endless articles predicting that there will not be enough of element X when that element is in fact not rare, merely energetically costly to refine, and in fact currently so common as to not drive effective recycling or conservation.

</comment></comment></comment><comment><USER9> While good to have I wonder about the utility long term with changing battery chemistries. At least cobalt has other uses in alloys even if it becomes completely obsolete in batteries.</comment>


AlexNet hallucination quiz: can you find which image matches the stated class? - <AUTHOR> http://www.robots.ox.ac.uk/~vgg/research/deepquiz/ <comment><AUTHOR> Some context on image classifier trained on ImageNet dataset here: [https://github.com/stared/thinking-in-tensors-writing-in- pyt...](https://github.com/stared/thinking-in-tensors-writing-in- pytorch/blob/master/extra/Using%20an%20ImageNet-pretrained%20model.ipynb) (a Jupyter/Colab notebook, so you can use various networks, including AlexNet).

Such hallucinations are related to [https://distill.pub/2017/feature- visualization/](https://distill.pub/2017/feature-visualization/) (also with Colab code how to create such).

</comment><comment><USER2> Who is the intended audience? Some of them appeared to be westernized Japanese words, so even after seeing which ones were the right answer, I still don't know what those ones were.

Other than that, it is kinda cool searching through the distortions.

<comment><USER3> It's a reverse captcha. Only robots can answer all images with ease, while humans will have difficulties.

<comment><USER4> I didn't have any problem at all. Couldn't find one I didnt get on the first try. I fail maybe 30% of captchas haha.

<comment><USER5> U, Robot.

</comment></comment></comment></comment><comment><USER6> I was 9 for 9, then I got asked to select a "palace". I didn't really know how to visualize one, but there was a picture reminiscent of a an clearly very ornate chair in a room, which I figured could be a palace interior. I broke my streak choosing that chair :(

</comment><comment><USER7> Got most of them right when I allowed myself search for pictures of the word to know what I was looking for.

</comment><comment><USER8> This is actually a really fun game</comment>


Amazon Smile - <AUTHOR> http://smile.amazon.com/

<comment><USER2> That's pretty impressive.

Even if they restrict the donations to only a few _" eligible products"_ (which doesn't seem to be the case [1]), 0.5% for a retailer is an incredible amount of money.

Wondering if they're compensating this move with tax rebates. Amazon already operates under razor thin margins; they can't afford to take another 0.5% from the bottom line.

[1] From [http://smile.amazon.com/gp/charity/pd.html/ref=smi_se_saas_p...](http://smile.amazon.com/gp/charity/pd.html/ref=smi_se_saas_pd_pd) _Purchases Eligible for Donations Tens of millions of products on AmazonSmile are eligible for donations. You will see eligible products marked "Eligible for AmazonSmile donation" on their product detail pages. Recurring Subscribe- and-Save purchases and subscription renewals are not currently eligible._

<comment><USER3> "0.5% for a retailer is an incredible amount of money." It's not nothing, but Amazon makes pretty healthy margins on a lot of what it sells. It's $.50 on a $100 purchase, which is cheap for an Amazon leader.

It's just really smart. Surely less than the difference between Prime shipping costs and the annual subscription fee, and with the same purpose: chipping away at the reasons people would buy anything anywhere else ever.

<comment><USER2> _> Amazon makes pretty healthy margins on a lot of what it sells_

I guess you're not following Amazon earning reports closely. In Q2 this year, Amazon's margin was number 1,428, out of 1,515 US companies [1] [2]. That's barely 1% after-tax margin. In several quarters they reported close to break- even or losses.

At these levels, a "mere" 0.5% donation would be unsustainable for shareholders, unless there's a way to claim most/all donations to reduce their own tax payments.

Margins got better in Q3, but still (intentionally) low.

[1] [http://www.forbes.com/sites/greatspeculations/2013/05/21/ama...](http://www.forbes.com/sites/greatspeculations/2013/05/21/amazons- thin-margins-do-not-support-sky-high-valuation/)

[2] [http://247wallst.com/investing/2013/07/25/amazon-com- company...](http://247wallst.com/investing/2013/07/25/amazon-com-company- earnings-keep-margin-heading-to-zero/)

<comment><USER3> Margin on an item is different than gross operating margin.

Amazon makes 20%+ margin, "pretty healthy", on "a lot of what it sells" (almost all retail items that are marked down 30% or less from their MSRP) and .5% isn't a lot of that. It is less than Amazon loses on popular books, and less than they lose on prime shipping.

Of all the things Amazon loses money on to incentivize customers, it's a small one.

Gross operating margin is only tangentially related and can be increased by them at any time by spending less money on other investments.

</comment></comment></comment></comment><comment><USER4> Is this new?</comment>


Kelly Criterion - <AUTHOR> https://en.wikipedia.org/wiki/Kelly_criterion <comment><AUTHOR> This is related to the discussion of Pascal's Mugging that made it to the front page yesterday. If we're interested in that it is probably time for a reminder about the Kelly Criterion.

Previously, eg: [https://news.ycombinator.com/item?id=18484631](https://news.ycombinator.com/item?id=18484631)</comment>


Named Arguments - <AUTHOR> http://gimmecsharp.blogspot.com/2010/08/named-arguments.html <comment><USER2> Hi rueleonheart,

I can tell that you're a C# enthusiast, but I'd just like to say something. Looking at your posting history over the last four days you've blessed us with 23 postings about minor, pretty much trivial, points of C#.

I admire your energy, but can I ask, please, give it a rest? This is "Hacker News" and I would guess that most of the people here really, really don't need assistance at this level.

To provide support for my point you've got a total of 7 up-votes, and 4 comments. One comment pointed out an inaccuracy, one offered a small correction, one offered a work-around, and one - I like this - pointed out that this stuff is trivial and doesn't really belong on Hacker News.

Since you're clearly a C# advocate I'd really be interested in deeper insights about the structure, or the philosophy, or "gotchas", or neat tricks. These simplistic syntactic points are, well, pointless.

Let's have some content. I'm ready for a main meal, not constant appetisers.

Thanks.

<comment><AUTHOR> OK, point taken. Thanks for the warning.</comment></comment>


Ask HN: Is this normal for US companies hiring full-time remote? - <AUTHOR> I am offered a full-time remote position from a US company. However I'm told I need to set up a ltd. company in my home country and sign a contract with them through that company. I'm told I'll not be getting any equity, health care package or any other benefits offered to regular employees since they can't hire me as an employee legally.
I am not sure if it is true and want to know if this is a normal case for others who work full time remote for US company (as I'm assuming they are also not legally allowed to work in US). Salary offered is decent if I'm just working as individual contractor. Filling out W8BEN form has worked for me in the past working with US based clients. However setting up a ltd company I would be paying much higher taxes, health insurance etc charges (ignoring the up front cost required to setup such company).
I'm negotiating the offer so any tips or advice would be helpful, thanks. <comment><USER2> So you're a full time contractor instead of a full time employee. This is a very gray zone in the US, which is probably why they require you to setup a company that you are working through. That's because hiring an individual full time moves them from contractor => employee under US law.

At this point it's just a business decision. Extra taxes and costs for you? Document what they are, bump the offer up by that amount, and counter. They most likely don't know the tax law in your country and so they won't realize this is a burden to you.

"It's fine to not pay me healthcare or give me options, but there's an issue with having to setup my own company. In my country companies are required to pay XX% tax on revenue, and then I also have to pay a personal income tax. I'm happy to setup the company to make this work, however to do so you'll need to bump your offer up by XX% + $Y,000 for the additional overhead that comes with managing the company's paperwork, registration, and legal fees."

<comment><AUTHOR> Excellent, this is why I love HN (using a throwaway atm).

</comment></comment><comment><USER3> They're not hiring you. They're contracting you for your services through an independent company (that you'd own). There's a reason why contractors charge more than employees - to cover all the costs you're finding out about now. If you're contracting at normal employee wages then, financially speaking, you're getting a pretty bad deal. That doesn't necessarily make it bad job though - if it's something you really want to do then it could still be worthwhile.

<comment><AUTHOR> Thanks for laying it out straight for me. I feel pretty stupid now that this seems to be the truth. I was led to believe I was being interviewed for a full time employee position. I wouldn't have wasted 5 rounds of interview time and a take home exercise that I spent 2 days full time working only to find out in the end they would be low balling me with this caveat. At least I have time to negotiate now.

<comment><USER2> Every company will try to get you for as low as they can.

Don't think of it as wasted time, this is a really valuable learning experience regarding contracting, and even a chance to practice your negotiation skills. :)

<comment><AUTHOR> I appreciate your positivity, great advice, thanks.

</comment></comment></comment></comment><comment><USER4> I don't believe this is a bad deal. Hiring a full time remote in another country would probably carry complex legal requirements in the United States (they basically are saying they have a foreign office in your country). This would significantly raise their cost. Then on top of that they would have to follow all regulations for operating their business in your country and all employee/employer regulations which requires even more legal knowledge. (BTW the W8BEN I don't think is valid for fulltime employees because the employer would be specifying how and when you work)

Maintaining all of that for a company in the US is a huge time and money cost. On top of that, maybe operating a foreign office would raise their taxes significantly.

Overall its not a bad deal just because of this. Just make sure that you factor in the cost of any benefits and if you get taxes are worse for being a contractor (though you may be taxed less if you are able to write things off like in the US).

<comment><AUTHOR> Thanks for your response. Just to be clear, they are not asking to open their subsidiary in my country on their behalf. They are asking me to set up a company on my own name and invoice through it. One time setup cost is also expected to be borne by me. Good point about W8BEN, thanks.

<comment><USER4> I am not saying they are asking to open a subsidiary. I am referring to the fact that if you were a full time employee (instead of an independent company) then they now have a fulltime employee working in a different country which under US law would mean they are operating a foreign office in your country.

</comment></comment></comment><comment><USER5> I wouldn't say you are being "low balled" here.

I also work full-time remote for a US company and I bill through my company in Germany. You could be hired as an actual employee, however they would legally need to follow the law re employee tax/benefits of the country that you reside in. This is obviously a pain to manage between both parties, which is why "digital nomads" bill through their own ltd.

You could negotiate extra for benefits, but it sounds like you will have the work locked-in (i.e. you're not a typical contractor who can charge a premium as the work is fixed).

Where do you live? For me, the difference in being taxed as an ltd is trivial; actually, it's better as I can claim extra back as expenses through the business, like electricity, internet, etc.

<comment><USER6> How do you deal with the risk due to FX rate? Your salary is probably constant in dollars but not in euros the currency you use.

<comment><USER5> I don't really worry about it. If I could predict the direction of currencies, I wouldn't be working.

Sure, I have extra bills compared to my on-site colleagues but I also get to live in a city with a much lower COL. I'm sure there are ways to optimize my setup further but I'm generally content getting a US salary in Europe.

</comment></comment></comment><comment><USER7> I had the same opportunity few months ago. I was interviewed for position/contract where US corporate was hiring through UK agency. They have a lot remote engineers over the world with reporting to the US/UK manager.

All of hired engineers have to have own company or entrepreneurship license in domestic country. Charges are above average wages, but you have to take care about all related staff: insurance, taxes etc.

In this case it's better to hire accountant, but it's still worth.

<comment><AUTHOR> Definitely going to hire a CPA. Thanks for your inputs.

</comment></comment><comment><USER8> I used for work for IBM Research for 6 years in that type of arrangement. What you're paid is not "salary", but rather "rate". They're not hiring you, they're signing contract between them and your company.

It could be a good arrangement that could evolve into long lasting, beneficial relationship.

</comment><comment><USER9> where do you live, which citizenship you have?

yeah, we remote employees / contractors / freelancers / consultants do invoice through our own ltd companies

an accountant unless they are really expertized in cross-border deals usually is not of much help, but there are some knowledgeable

if you are from EU, establishing residence, registering an ltd in britain and getting paid in UK makes sense more than doing that in mainland europe. given there is double taxation treaty between UK and rest of europe (EU and non-EU) you don't owe your country any taxes as you paid them in the UK. also, you can get paid by that company without changing residence as a sole trader in your country of residence

millions of mainland europeans have their companies incorporated in the UK

<comment><AUTHOR> Great. I have no problem setting up a ltd and invoice through that. I just wanted to know if this was common (which from your comment it seems it is) and if I should negotiate the offer as the expenses of contracting through a company are higher vs expenses as an individual contractor. Thanks for your input.

<comment><USER9> sure, it's how most of us work. well, as per default your contracting rates should be at least your salary + expenses and if you are any good (both, as an engineer and a salesman or at least one of the two) your rates should be multiples of that. if it's a long term contract, rates can go a bit lower. if it's a short term gig, rates go up as they need to cover your living and business expenses between gigs

</comment></comment></comment><comment><USER10> I don't know where you are located. In US, setting up LLC S-corp or C-corp is darn easy; and this way of set up does not lead to higher taxes, etc. In fact, it leads to lower taxes.

Check with a local accountant who is competent in these matters.

<comment><AUTHOR> Unfortunately I'm neither american nor a US resident. I'm in from Philippines.</comment></comment>


A Cardiologists Concerns with the New Apple Watch - <AUTHOR> https://medium.com/s/story/im-a-heart-doctor-heres-why-im-wary-of-the-new-apple-watch-2b1999f2d942 <comment><USER2> sounds similar to this [https://en.wikipedia.org/wiki/False_positive_paradox](https://en.wikipedia.org/wiki/False_positive_paradox)</comment>


What's the best laptop for $250 or less? - <AUTHOR> I would prefer to have a windows 7 laptop, but 8 is acceptable. I'm not aware of many good retail deals and I have no real idea of what makes a good laptop either. I'm hoping that any one of you fine people knows what I should get. <comment><USER2> I think a better question is what are you trying to do with a $200 laptop? A chromebook might work for most of what you need it to do. You can even code using a cloud based IDE. But obviously there are certain things that might not work. I like how crafty sixQuarks was buying a cheap laptop and upgrading.

If you buy something used or refurbished you may be able to get what you need. Please provide more info what you are planning to do.

</comment><comment><AUTHOR> The biggest thing I'm planning to do is use it for homework and light disc burning. Mostly though, I don't just want to use the browser, I'm interested in something I can take to college this coming semester.

<comment><USER3> get a tablet and a wireless keyboard. Maybe a nexus 7. That way youcan be portable and type up stuff when you need to. Plus you _could_ write notes on it, though. Some people like to do that on their tablet. (I usually don't) . The nexus 7 is a small tablet granted but it's powerful, built well and if you don't mind spending the time figuring it out, probaby producted. Plus wouldn't you like to have 8 hours of battery vs the 1.5 hours you'll get on a cheap laptop?

just a thought.

</comment></comment><comment><USER4> I just bought a Gateway LT400U on Newegg.com for $199. I spent $10 to upgrade it to 2GB memory, and it works great for me. I plan to take it with me backpacking in Thailand.

</comment><comment><USER5> None work that well with $250 worth of hardware and Windows, unless you're considering a Chromebook, which only has to run the browser, pretty much.

</comment><comment><USER6> For $200 your best bet is a used Thinkpad T-series or X-series or business class HP laptop from ebay or craigslist.</comment>


Why I think using sha256crypt or sha512crypt is dangerous - <AUTHOR> https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ <comment><USER2> Article opens by claiming "DES-Crypt has a core flaw in that, not only was the algorithm reversible ..."

That's not true in any meaningful sense and points to the fact that the author hasn't any clue what they're talking about. Which doesn't magically invalidate their experiments and data, but it does mean you should probably take their opinion with an extra table spoon of salt.

DES of course is reversible, it's an encryption algorithm, so if you have the key you can just reverse it, that's the whole point. But what DES-crypt does is something else, First it takes the DES algorithm and tampers with the internals, it has 12-bits worth of random data for this, a salt (today obviously we use larger salts, but this one already makes time-space tradeoffs painful, 4096 times worse than normal against a "good" DES crypt). Then it encrypts a bunch of zero bytes using the password, and then it encrypts the result, and that result and so on, 25 times in total.

This isn't a reversible algorithm. You can't take some encrypted DES bytes, and then run DES backwards 25 times to find out what the key was knowing the original was all zero bytes, you quickly get conflicting possibilities.

What you _can_ do, in reasonable time, is try all the plausible passwords in turn, for a particular salt value. This is what DES crackers do, and for passwords like "ksdcunfm" it works pretty well on commodity hardware, which is why we don't use DES Crypt any more.

But that's not reversing the algorithm.

<comment><USER3> > Article opens by claiming "DES-Crypt has a core flaw in that, not only was > the algorithm reversible ..."

> That's not true in any meaningful sense

That's exactly right, and when I published the article, I recognized that I needed to change it, but didn't get to it. I've fixed it. Thanks.

> and points to the fact that the author hasn't any clue what they're talking > about.

Ouch.

</comment></comment><comment><USER4> How is the timing here relevant to attacking shacrypt? The run time is a function of the length of the _attacker-provided_ string containing the password guess. That's totally fine, the attacker already knows that string. The output is a fixed-length string that is then compared to a stored (also fixed-length) hash using a constant-time comparison function.

The run time does not depend on the length of any secrets here. I don't see the issue. How can I use that to determine the length of the actual password? That length isn't even available to the password verification system anymore.

<comment><USER5> I think the author is arguing that if someone were to send a 1GB password that it could cause a DOS attack on the server performing the sha-hash of the password. Seems to me the simplest solution is to limit the length of password fields to something reasonable.

<comment><USER6> I always thought you're supposed to hash on the client side first to avoid sending the password to the server, and then hash again on the server. Even if the password is a billion characters long, the server will only see a 60(?) byte array and hash that.

<comment><USER7> no that's not how it works.

If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password. This solution would only protect users from password reuse from theft.

Hashing with a negotiated salt and computing client and server side protects the password in transit but means storing the password in plaintext on the server. We use TLS (or SSH, or other encrypted protocols) to protect passwords in-flight instead, and hash passwords on the server to protect them from theft.

(Remember, the original attack password hashing was protecting against was a world readable file that contained all usernames and passwords, /etc/passwd on Unix. Eventually the world moved to "shadowed" passwords, where the hashes were stored in a root-readable-only file called /etc/shadow.)

There are systems where the user enters a key locally and it's not transmitted over the wire. Kerberos and SRP are two of them.

<comment><USER8> > _If the client could simply send a hashed password over as an authenticator, > then hashing the password database would provide no protection against > theft, because you could simply use the stored hash as the password._

I'm not sure I understand this sentence. Are you reading the parent message as proposing hashing client-side using the same algorithm as the server-side hash and comparing directly on the server against the database-stored hash. This would be outrageously stupid of course, but I'm certain the commenter was not proposing that.

They said:

> _hash on the client side first to avoid sending the password to the server, > and then hash again on the server._

Note, hashing _again_ on the server. To describe this slightly differently, think of the clientside algorithm as effectively being a password generator, with the user inputting their own memorable password as a kind of encryption* key for their "real" auth API password—the main advantage is fighting password reuse.

*encryption!=hashing but I'm just using the term here to illustrate intent.

</comment></comment></comment></comment></comment><comment><USER9> > What this clearly demonstrates, is that the only factor driving execution > time, is the number of iterations you apply to the password, before > delivering the final password hash.

Isn't the reason this is true that bcrypt just truncates the input at 72 characters? And if that's correct, aren't there basically a few options, any of which basically invalidate the argument?

1\. Enforce a password length limit. Fixes the unbounded growth of the shacrypt CPU time while simultaneously ensuring bcrypt is not ignoring input.

2\. Pre-hash the input to bcrypt by passing it through SHA512. Makes bcrypt now grow in the exact same way as shacrypt.

3\. Don't enforce a password limit, but truncate the password. Fixes the CPU time.

I don't know enough about bcrypt in practice to know which of those options is most commonly advised, but it just seems like a bit of a strawman here. Passing 4096 bytes to bcrypt is the same as passing 72 bytes to bcrypt because it ignores the last 4024 bytes right?

<comment><USER10> > Pre-hash the input to bcrypt by passing it through SHA512. Makes bcrypt now > grow in the exact same way as shacrypt.

The pre-hash is only applied once, so the change in runtime is linear and very small compared to bcrypt.

<comment><USER9> Edit: I stand corrected, the summary in the link below didn't agree with the more detailed steps it went into below. While the hash is used as the input to the next round, it is (for reasons beyond my understanding) repeated if necessary to match the length of the original password. But it still seems like if you're prehashing in both cases the performance issue goes away.

Is that true? I thought shacrypt stretching worked by passing the output of a round of hashing as the input to the next round of hashing, so it would go from 4096 bytes to 64 bytes (e.g.) after the first round.

That's how it's explained here: [https://www.vidarholen.net/contents/blog/?p=33](https://www.vidarholen.net/contents/blog/?p=33). I'd love to be proven wrong.

So it seems shacrypt and bcrypt would be equivalent. Do the expensive work from 4096 to <72 once, then subsequent rounds are all on the same size of input.

I think my point stands, this is comparing apples and oranges unless you pre- hash the input to bcrypt and include that in the benchmark.

</comment></comment></comment><comment><USER11>
        Passive observation of execution times can predict password length (smaller concern).

Seems like this can radically narrow the focus of a dictionary attack. Also, if you are just trying to get a foothold into a machine, you can focus your energy on short passwords. Of course, I am not sure of all the scenarios where you are privy to how long the encryption took.

<comment><USER3> > _Seems like this can radically narrow the focus of a dictionary attack._

It's leaking information, and we don't like this, but it's not fatal. 96% will have passwords less than 16 characters (see [https://blog.cynosureprime.com/2017/08/320-million-hashes- ex...](https://blog.cynosureprime.com/2017/08/320-million-hashes- exposed.html)). This is within the first "step" in the sha512crypt hashing process, and longer passwords may have enough entropy, so learning their length is not providing any practical advantage in cracking the password, should the database be compromised.

The larger concern is CPU load. There are load jumps between 1-15, and 16-23 characters, and 24-80, etc. Even though 96% of users will fall in the 1-16 range, if you put a minimum length requirement of perhaps 12 characters, you may see that you need to decrease your sha512crypt cost to handle your tested load, because more of your users are passing 16 characters in length (yay) than normal (although most will like do _exactly_ 12 characters).

Does that make sense?

</comment></comment><comment><USER12> The DoS aspect is mitigated via pam and user management controls in the OS (for creating /etc/shadow entries).

scrypt and bcrypt are a long ways out for supported Linux distros. This depends on glibc to make changes that they have stated they won't make. So for now, sha512 shadow hashes are the best most people will have in their datacenters.

Perhaps wrap that rascal with MFA / 2FA to be the first line of defense as a mitigating or compensating control.

<comment><USER13> > This depends on glibc to make changes that they have stated they won't make.

I'm not sure I understand what part of Linux's account security model relies on glibc to make changes. Can't PAM pull in whatever libraries it likes?

If not, then why hasn't (any popular distro of) Linux moved toward the Windows/macOS model of unifying account management + AAA onto a single "directory services only" code-path, where a system that's not "part of a directory" is actually just part of its own "directory of one", with your system running its own little LDAP+Kerberos daemons or what-have-you that your local accounts reside in?

In that sort of model (which, again, is what Windows and macOS both use exclusively nowadays), the kernel, C library, etc. aren't involved in deciding AAA policy; they just implement the simple AAA _mechanism_ of "let users with the right ACL token do the things the ACL token says they can do" and then rely on one or more [local or remote] directory-service servers to actually authenticate users and issue those tokens to them. Drastically smaller attack surface.

<comment><USER12> There is talk of extending crypt in glibc to support external libraries [0] and that would do exactly as you suggest.

[0] - [https://sourceware.org/bugzilla/show_bug.cgi?id=16814](https://sourceware.org/bugzilla/show_bug.cgi?id=16814)

And certainly, if you move the authentication to another service, such as I mentioned with MFA, or LDAP+Kerberos as you mentioned, that could address this, assuming that system supports scrypt / bcrypt.

<comment><USER13> I'm still confused—why is the idea to extend crypt(3), rather than for PAM to just _call something besides crypt(3)_ , pulling in a better hashing library at the libpam level rather than at the libc level?

<comment><USER14> Lots of services call crypt and it expects a variable length string which describes the stored secret to compare the actual password against. It is //very// possible to update this one place and 'solve' support for MANY dependent programs and libraries.

(towards the bottom of the manual page: [http://man7.org/linux/man- pages/man3/crypt.3.html](http://man7.org/linux/man-pages/man3/crypt.3.html) )

</comment></comment></comment></comment></comment><comment><USER15> Sha is a cryptograpic algo used for secure hashing hence the name SHA. The main goal of hashing is confirming the integrity of an object. This mean the object you read now is the same object as when it was stored. The goal was never to encrypt even if its possible to do so.

All hashing functions have the same weakness which is vulnerable to rainbow table attack. I agree with the OP that sha is dangerous if used in the wrong way.

<comment><USER16> _The main goal of hashing is confirming the integrity of an object. [...] The goal was never to encrypt even if its possible to do so._

That is not true, cryptographic hash functions are just cryptographic primitives with certain guarantees about their behavior, they do not imply any usage. There is nothing fundamentally wrong with using a cryptographic hash functions as a building block for an encryption algorithm. The important thing is that almost no use case of cryptography requires exactly and only the guarantees provided by cryptographic hash functions. That is why they are most of the time used as building blocks of more complex algorithms and not on their own.

Ensuring that a file was not modified while you did not look is just an exceptional case where just using a cryptographic hash functions alone may be good enough. But even in this case you might want to consider that an attacker may be able to change the file and its hash together and maybe you actually need an authenticated hash that can not be forged by an attacker. In that case a cryptographic hash functions would again be part of the algorithm but it would not be the only building block.</comment></comment>


Firefox extension makes social network ID spoofing trivial - <AUTHOR> http://www.net-security.org/secworld.php?id=10042

<comment><AUTHOR> Hmm, probably should have linked to the blog entry directly instead: <http://codebutler.com/firesheep></comment>


Career Shift Often Means Drop in Living Standards - <AUTHOR> http://www.cnbc.com/id/40877661

<comment><USER2> "Duh". If there was a career shift before the recession or indeed at any time that they could easily make to a higher living standard, they would have done that. And then in the recession, that would be the baseline we were measuring from.

In fact it seems to me the recession dominates here, not the question of career shifts. In non-recession times career shifts will be made to raise living standards and you could write the complementary article.

I'm not sure what's "news" here.

</comment><comment><USER3> Well that's been true for a lot of people. The inflation driven boom drove up the prices of a lot of things including labor. Prices need to come back down.

That said if suddenly no one wanted programmers I'd be in a lot of trouble :)</comment>