NIST Draft: The KMAC, TupleHash, and FPH Functions [pdf] - <AUTHOR> https://www.ietf.org/mail-archive/web/saag/current/pdfxrzR9rycq3.pdf <comment><USER2> In case you're wondering, these are new NIST standards for things you can do with SHA-3 beyond simply using it as a hash.

KMAC is SHA-3's alternative to HMAC. You can use HMAC with SHA-3, but it's wasteful, since part of the point of SHA-3 is to make the HMAC construction (which applies the hash function twice to achieve separation between the key and the data being authenticated) unnecessary.

TupleHash is a construction that reliably hashes an array of byte strings, some entries of which might be the empty string.

FPH is a construction that exploits parallelism to more quickly hash huge strings.

</comment><comment><AUTHOR> These slides from 2015 [1] detail some of the rationale that went into designing these functions.

Specifically, slide 13 says these 'Domain Separated' functions are "completely unrelated", ie. they can't be computed from each other. According to them "this should make it a little harder to shoot yourself in the foot with these functions".

It appears the designers are realizing that assembling crypto building blocks in ways that remain secure and make sense is difficult, so they're providing ready-made versions made for specific uses.

[1] [http://csrc.nist.gov/news_events/cif_2015/research/day1_rese...](http://csrc.nist.gov/news_events/cif_2015/research/day1_research_200-250pt1.pdf)

<comment><USER2> Two interesting bits of context:

* Being usable in a straightforward way as a MAC --- something SHA-2 isn't, like MD5 and SHA-1 --- was one of the design criteria for the SHA-3 contest.

* This is also part of a heartening trend in crypto research towards "misuse-resistant" cryptography. The "misusers" in MR crypto are... wait for it... application developers. :)

A good example of a crypto primitive designed specifically for misuse resistance is Rogaway's SIV mode, which is making a comeback in GCM-SIV. The most popular example of misuse-resistant crypto is of course the Nacl/Sodium library.

</comment></comment><comment><USER3> The others I understand but tuplehash seems bit odd. It essentially just defines a naive serialization format for tuples, but I would have thought that generally it would be left to applications to figure it out how to get a hashable blob from their data structures.

Is there some large application for tuplehashes that explain its inclusion in a standard? Because I don't know any.

<comment><USER4> Because people often don't realize that if you want to hash a bunch of pieces of data in a cryptographically secure fashion, you have to serialize them (with an injective function). People tend to think that just somehow feeding it all into the hash function will take care of it, so simple concatenation is common, with occasionally disastrous consequences.

<comment><USER5> In particular, there's all sorts of mischief an attacker can do when serialized(A,B)==serialized(C,D) but A!=C and B!=D. I've seen OAuth implementations do this, allowing someone to submit the signature from a "good" message along with "bad" arguments (of their own choosing), with a very different meaning.

An impatient application developer might just use hash(concat(args)). Raw concatenation is serialization, but it's ambiguous: s("manage", "able") == s("man", "ageable"). The safest approach is to ensure that the serialization function is reversible (even though you're just going to throw it into a hash, which is obviously not). When your arguments are arbitrary bytes, you either use a delimiter character (and escape any places where it appears naturally), or prefix each string with (a fixed-length representation of) its length. Either way, if you could conceivably parse the serialized form back into the original arguments, then you're safe from tricky format-confusion attacks.

<comment><USER4> That's what "injective" means :-)

Also, I think that serialization is actually injective by definition. If you can't deserialize it, it's not a serialization, it's just an arbitrary sequence of symbols that you maybe happen to have generated based on some non- serial structure.

And actually, it's not just the safest way, it is the only way. Though it's true that the hash is not injective, it is collision resistant (based on current understanding), that is what makes it a cryptographic hash function. The only theoretical alternative to (injective) serialization would be to feed the data into a collision resistant function that takes tuple inputs, which by definition would be a cryptographic hash function, which would make it pointless to feed the result into another cryptographic hash function.

The solutions you suggest are good advice, though. Also, don't forget to tag message types if you use a key for multiple purposes, so one message cannot be replayed as another type of message.

</comment></comment></comment></comment><comment><USER6> I have been so desperate for an expert-crafted standardized tree-hash. Hallelujah!

<comment><AUTHOR> Though it does not meet all your criteria -- it's not standardized by an institute -- BLAKE2 [1] also supports tree-hashing, is expert-crafted from a SHA-3 finalist, and has seen adoption in the last two years.

Notably, on recent architectures, it's faster than SHA-3, SHA-256, or even SHA-1.

[1] [https://blake2.net/](https://blake2.net/)

<comment><USER6> It is really the standardization that's the thing, as my application would be hashing of disk images for digital forensics purposes/evidence authentication purposes. BLAKE2 seems like a fine algorithm otherwise.

</comment></comment></comment><comment><USER7> Without actually comparing the spec to the Sakura paper [1]: are these instantiations of the Sakura scheme?

[1] [http://keccak.noekeon.org/Sakura.pdf](http://keccak.noekeon.org/Sakura.pdf)

<comment><AUTHOR> The FPH (Fast Parallel Hash) schemes are, as their core is CSHAKE, which is a user-customizable (parameterized) SHAKE, which uses the Sakura construction.

In the Sakura paper's conclusion, they state:

"In the current FIPS 202 draft, the SHA-3 extendable-output functions chosen by NIST adopt SAKURA for sequential hashing as a special case of tree hashing." Similarly, the FIPS 202 document refers to SAKURA when it talks about the XOFs SHAKE128 and SHAKE256:

"The two SHA-3 XOFs are also specified in a manner that allows for the development of dedicated variants. Moreover, the SHA-3 XOFs are compatible with the Sakura coding scheme for tree hashing in order to support the development of parallelizable variants of the XOFs, to be specified in a separate document." [1]

[1] [http://www.nist.gov/customcf/get_pdf.cfm?pub_id=919061](http://www.nist.gov/customcf/get_pdf.cfm?pub_id=919061)

</comment></comment><comment><USER8> But is it _trustworthy_?</comment>


The computer, which can stand on the tip of a grain of rice - <AUTHOR> https://www.cnet.com/news/university-of-michigan-outdoes-ibm-with-worlds-smallest-computer/ <comment><USER2> It has Cortex-M0+ 32-bit CPU. Amazing.</comment>


Elementary OS Isis is now Freya - <AUTHOR> http://elementaryos.org/journal/elementary-os-isis-is-now-freya

<comment><USER2> I think "Fregna" would have been a better name.</comment>


Mystery company blazes a trail in fusion energy - <AUTHOR> http://news.sciencemag.org/physics/2015/06/mystery-company-blazes-trail-fusion-energy

<comment><USER2> Wouldn't it be ironic if many of the Suns in the universe were from advanced civilizations that developed a technology they did not understand and accidentally turned their planets into Suns. No more Fermi's paradox! (I know, not likely, but a good premise for a Sifi movie).</comment>


Show HN: Twillio powered Click-to-Call service for small business websites - <AUTHOR> http://www.tringify.com

<comment><AUTHOR> Cofounder of Tringify here. Would love to get feedback from the community.</comment>


Ask HN: Tech/Dev meetups in NYC over the next ten days? - <AUTHOR>

I am visiting NYC for the next ten days. Any interesting tech talks or dev meetups or hack nights happening over the next ten days in NYC? I am trying to figure out a way to meet a few developers in the area, and get a sense of their interests.
My general interests are in machine learning, computer vision, and graphical models. I am a software engineer, currently working at a mid size startup building a digital advertising and data aggregation platform.
Thanks! <comment><USER2> I am not sure if this is what you are looking for but as far as NYC tech events are concerned this should be relevant enough - [http://betabeat.com/2012/12/best-tech-events-this-week- happy...](http://betabeat.com/2012/12/best-tech-events-this-week-happy- holidays/)

Though I am not in NYC but I often visit BetaBeat and this is something which I've remembered.

Hope this helps. Have fun in Big Apple.

<comment><USER3> You might just miss it, but if you're still in town, check out the Foursquare hackathon on 1/5.

</comment></comment><comment><USER4> Some of these are tech-related: <http://www.meetup.com/cities/us/ny/new_york/>

Also, a good Reddit meetup: <http://www.meetup.com/NYC- Redditors/events/96246432/>

</comment><comment><USER5> Gary's guide is probably the best source of tech events in NYC (apart from meetup). I used to go to quite a few of the events here before I got my current programming job.

</comment><comment><USER6> Come visit We Work Labs. It's a room full of entrepreneurs, many of us developers.

</comment><comment><AUTHOR> thanks for the quick replies guys, i will check out the links...

</comment><comment><USER7> Where are you located?

<comment><AUTHOR> I am staying in queens during my visit, about half an hour to get to union square.

<comment><USER8> if the transit God's deem you worthy you _might_ have a chance at getting there in 30 minutes. :) enjoy your stay!</comment></comment></comment>


[1206.0312] Quantitative Analysis of Narrative Reports of Psychedelic Drugs - <AUTHOR> http://arxiv.org/abs/1206.0312 <comment><USER2> Fascinating stuff, will delve more into it as I'm able, but kudos to Jeremy and Matt (and JC for some of the programming work) - all outstanding former colleagues! Congratulations, you guys!

A while ago I briefly mulled over a loosely related question (e.g., "Could sentiment analysis of social data discover trends in experiences with various substances?") about whether user reports of drug experience on social media could be useful or illuminating:

[http://apps.keithflower.org/?p=344](http://apps.keithflower.org/?p=344)

</comment><comment><AUTHOR> Linked here: [https://news.ycombinator.com/item?id=8939637](https://news.ycombinator.com/item?id=8939637)</comment>


Eric Schmidt: Turing Test will be passed within 5 years - <AUTHOR> http://www.youtube.com/watch?v=3Ox4EMFMy48 <comment><USER2> I think it won't. That would basically mean that the singularity will happen in 5 years.</comment>


Up for Lunch with YC Founders in SF? (Airbnb Experience) - <AUTHOR> Hey, we're the team from Zinc.io (YC W14). We're based in sunny Union Square in the heart of downtown SF.
We've decided to allow outsiders into our office to meet with us for lunch, and so we've created an Airbnb experience for $275 where you can come and have lunch with us.
Check it out here: https://www.airbnb.com/experiences/213130
Please forward the experience listing to anyone you think might be interested in visiting.
Looking forward to a great response from the HN crowd!
Email email@example.com with any comments or questions. Trolling is also welcome. <comment><USER2> Hey there all. I'm an entrepreneur who has confounded a startup, founded a few individual startups, worked at HP Labs, currently work with a venture capital fund to help with startups and other businesses they invest in as a technical consultant, and I have a law background. I have never attended YC. I have a tad bit of experience and I like chatting with people.

If anyone is ever in the northern Utah area and would like to have lunch, you can email me! We can eat food. Maybe we'll split the bill. If you can't split the bill, I'll pay. It will be fun.

I disagree with paying for this sort of experience. Yes there is value in meeting me and having lunch. But it's a mutually beneficial relationship. I get to meet too! And there are plenty of Bay Area startups that are more than happy to meet with new founders or basically anyone.

And yes, my offer is very serious.

<comment><USER3> Is this offer valid to non-founders, such as generalist technologists (happy to pickup the entire tab for lunch)?

<comment><USER2> Absolutely! And for anyone interested my email is my username at gmail.

</comment></comment></comment><comment><USER4> I'm not going to troll you via email (as you welcome in the post), but...really? You're going to (or going to try to) charge somebody $275 to have lunch with you because you went through YC 4 years ago?

Maybe the line between hustling and scamming is a fine one, but is this what you really want to be known for? The guy that charges almost $300 for lunch?

<comment><AUTHOR> I personally did the same thing in Amsterdam and truly enjoyed it. [https://www.airbnb.com/experiences/45839](https://www.airbnb.com/experiences/45839)

There's also one in Paris where you visit BlaBlaCar and Airbnb Paris [https://www.airbnb.com/experiences/946](https://www.airbnb.com/experiences/946)

It's hard to see the value of the cultural experience economy until you jump in headfirst. Come check it out Pedalpete!

<comment><USER5> Did you just plagiarize someone's Airbnb post and then link directly to it?

The Amsterdam post ([https://www.airbnb.com/experiences/45839](https://www.airbnb.com/experiences/45839)):

> Thierry will share his tremendous experience, content and network of the > local startups/angels/investors world. Inspiring!

Your post ([https://www.airbnb.com/experiences/213130](https://www.airbnb.com/experiences/213130)):

> [...] we will share our tremendous experience and knowledge of local > startups/angels/investors. Super inspiring!

</comment></comment></comment><comment><USER6> Hmmmm, I go to your site, look at the list of products along the front and see "Subtotal, Eat for Less - Pay with Subtotal at your favorite restaurants and earn up to 10% cash back."

Click the link and it goes to a url that doesn't return a site.

Either one of your flagship products is down or you've abandoned it and haven't bothered to take it off your front page.

Either way, smells kinda fishy and a little desperate considering a $275 lunch "experience" you guys are selling.

</comment><comment><AUTHOR> Experience here [https://www.airbnb.com/experiences/213130](https://www.airbnb.com/experiences/213130)

</comment><comment><USER7> I hope the airbnb is better than your apartment.

</comment><comment><USER8> I accept, but I'll need the $275 in advance in addition to plane tickets.

</comment><comment><USER9> Why is it on the main page? Is it a legit upvote or data manipulation? :)</comment>


Where Pair Programming Fails for Me - <AUTHOR> http://tersesystems.com/2010/12/29/where-pair-programming-fails-for-me <comment><USER2> This guy describes a really common antipattern I've seen with pair- programmers, call it "Workstation Chain Gang". This is where _all_ work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating.

The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to read about this. Let's get back together in half an hour." Or even say, "I need some alone time" They attend to their own needs along with the needs of their pair. This can take a lot of personal courage and honesty sometimes, and requires an environment that encourages attending to yourself.

This guy sounds like he felt like he needed to put on a continuous show for his partner, and that was really hard for him. Which it is!

I bet he was right that he had to be constantly chained to the workstation. The "eight-week sprint" sounds like a pretty awful slog, especially with the set-in-stone up-front design. Overall, it sounded like a lousy, poorly managed setup.

Its too bad that he associated it with pair programming particularly, but oh well. There's many ways of working in the world, and it sounds like he's happier now.

<comment><USER3> > "let's take a walk" and then talk through design problems.

That is the MOST important part and yet every single training fails t mention this.

</comment></comment><comment><USER4> I've pair programmed quite sucessfuly for several years. However, it is a very hard practice. It requires trust between people, first and foremost. Besides that, it requires knowledge that you can't do it all day. It is too intense and tiresome, and this lack of slack is bad for creative thinking. About the pride: it is like co-foundind a startup, where you build something toguether with other people (it is all yours).

Some other links:

\- Dijkstra Pair Programming: <http://c2.com/cgi/wiki?DijkstraPairProgramming>

\- Some notes on Pair Programming <http://wp.me/puh71-1y>

\- How Pair Programming Really Works: <http://bit.ly/5oOd4C>

\- Why I Don't Like Pair Programming (and Why I Left Pivotal): [http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair- pro...](http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming- and.html)

\- The real motivation behind pair programming: <http://bit.ly/9DNurb>

</comment><comment><USER5> What a fucking nightmare.

Whether what he did was or was not Official Pair Programming (tm) is beside the point. Obviously, some people will thrive having to interact with a partner all day, every day, while others will wither. Requiring all your developers to work in this style is just nuts. It's like requiring all your developers to wear size 31 jeans.

<comment><USER6> I don't think it is nuts if it is clear in your hiring process. Grockit has you pair for a day for your interview (or they did a few years ago) so you can experience what it is like, and see if you are a good fit. I agree that surprising people with pairing or trying to mandate it on an existing team is unwise, but building a company upon an ethos (to the exclusion of certain personality types) is a reasonable decision.

</comment></comment><comment><USER7> "And if I was writing code, I found something very interesting: I don't think in English when I write code. I think in code first, and I can translate written code to English. When I was trying to talk to people when I was writing code, I found that I'd have to write pseudocode and then talk to them about it -- and when my pair wanted me to talk about code, he wanted me to stop typing. But if I stopped typing, I couldn't describe what I was doing. _Every time I tried to write code and talk to my partner at the same time, I could feel the lurch between what I could feel -- the complex shape of it in my head -- and what I was having to say._ "

(emphasis mine). What an incredibly familiar description. Does anyone else ever feel this way? This is why in situations where I'm trying to describe a solution I end up just grabbing the keyboard, doing it myself, and letting the code talk for itself.

For me, pair programming comes easily when describing a solution that can be simply defined and understood. Doesn't matter how difficult the problem itself is. Pair programming becomes more difficult once you have to interrupt your coding to facilitate the process. As an introvert, this comes incredibly unnaturally to me.

<comment><USER8> Yes, that does sound familiar. I've never done pair programming, but I have the feeling I'd have a lot of the same problems as the OP. I'm very much an introvert, and even just our open-plan office sometimes has me wanting to shut myself away by the end of the day. And the more code I write, the less English I seem to speak, especially to describe code. I wind up either flailing my arms and speaking gibberish (only a mild exaggeration) or just giving up and writing pseudo-code because I just _can't_ express the concept any other way. English just isn't _precise_ enough.

</comment></comment><comment><USER9> Great article. I like to see people giving a detailed critical response about a practice which has increasingly become a kind of "Politically Correct" element in software development. Must always write units tests, for everything, and first -- hallelujah! Must pair program -- praise be thy name, thou art in heaven!

My own take: if it works well, do it. If it doesn't, do something else. Repeat. But your bottlenecks in the larger world tend to be talent, time and cash (though the latter is becoming less so in software development). If you have (enough of) those, use them and ship, get profitable, and anything procedural or paradigmatic should be far down your list of priorities.

</comment><comment><USER10> This matches my experience as well.

Like most things advocated by XP people, pair programming is simply soul crushing and meant to replace skill and experience ("I know it's not the simplest thing that could possibly work but my experience tells me we'll be needing this later") with mindless repetition.

Very much like religion.

Thanks, but no thanks.

</comment><comment><USER11> I hate pair programming. I find a lot of the times my partners are distracting me with a forgotten semicolon while I have already added that to my queue while my fingers are racing along.

On the other hand having to justify an idea to someone else (provided they are non-contentious, but really trying to analyze things) is worth its weight in gold.

In short. pair programming only works for me if I am surrounded by "yes men".

</comment><comment><USER12> I got to the point where the other person started typing when it wasn't their turn.

First, pair programming has to be between near-equals, or it just doesn't work. If one person knows a lot more than the other, most of the time is spent in training.

Second, if the other person just starts typing, it isn't really pair programming. It's what we call 'peer programming' where you peer over someone's shoulder and they do all the work.

'Peer programming' happens a lot with mis-matched skill levels.

I didn't read the rest, but I assume it's all as much a bastardization of Pair Programming as the first bit.

PP didn't fail you. Your coworkers weren't using it.

<comment><USER13> > First, pair programming has to be between near-equals, or it just doesn't > work.

That depends on what you think the goal of pair programming is.

> If one person knows a lot more than the other, most of the time is spent in > training.

Which is part of the intended effect of pair programming. It forces everyone to share their knowledge with everyone else both about programming, and about the code base. This brings new people up to speed quicker, allows the more experience to better share their knowledge, and protects the company from having too much knowledge locked up in one individual.

<comment><USER14> I agree.

To the GP's point though, they still weren't doing effective pairing for the 'training' or 'coaching' scenario. The pairing was contentious and out of balance. The coach didn't do any coaching.

> ...if I paused too long, or seemed to be typing the wrong thing -- my pair > had another keyboard, and he would type over me to try to "finish the > sentence" rather than talk to me.

In this case, a coach should engage the driver. Ask about what he's thinking and nudge him in the correct direction if needed. Coaching is a lot like driving school. The coach uses his brakes (keyboard) very seldom. If the coach _is_ using his brakes very often, it is as likely as not that the coach is the problem (too scared, poor instruction, etc) and not the driver.

There are simple tricks. I usually put my keyboard behind the monitor. I've also turned my keyboard around so that I'm looking at the keys upside down. Those both take physical effort to get the keyboard in position to type. Another strategy that I've heard is oven mitts (I really want to try this one!) :)

Edit: Also, another strike against his coach (though this is more programming related..)

> To me, this was "refactor mercilessly" and "once and only once." But to my > partner, this was a violation of "do the simplest thing that could possibly > work."

I'd agree with the OP here. Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high. Do the simplest thing when you have a red test in order to deliver features.

<comment><USER13> > Simplest thing is how you get tests to pass. DRYness is a property of code > quality. They are orthogonal. Refactor mercilessly when you have green tests > in order to keep quality high.

And once tests are passing, you should be able to convince your partner the code isn't dry simply by pointing out duplication, preferably 3 or 4 instances of it so you have enough examples to generalize a solution. You don't need tests to convince him something needs done.

</comment></comment></comment></comment><comment><USER15> My view is that pair-programming is a tool which only really works for stuff dealing with tactical decision making, logic/fact checking, teaching or debugging.

Higher level abstract stuff which involves creativity (design) or strategic decisions won't work because there is no process for these activities. You can't synchronize (communicate) where you are on your way to the "eureka" moment. Discussing with others certainly helps but there nothing pair- programming specific about it.

Also, don't forget that most, if not all, of the assumed benefits of pair- programming can be gained using a more flexible common sense approach:

Reducing defects? Code-reviews.

Over engineering? Design documents.

New hires? People switching projects? Assign a mentor for a week or so and have them pair-program.

Faster debugging? Understand that it is OK to ask a colleague for help.

<comment><USER16> I didn't even know people pair programmed full-time. It sounds... awful.

My idea of pair programming is a ~monthly "Hey coworker, you want to do sitdown this afternoon and figure out (in code) this bug/feature/design?"

Doing it fulltime sounds inflexible and impractical.

</comment></comment><comment><USER17> I don't have any experience with Pair Programming as it is typically prescribed by "agile" project managers, but from my understanding of Pair Programming, I believe that there are more cases like this where Pair Programming doesn't work than there are cases where it does work.

I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I do not have experience working on an "agile" team doing every day pair programming. There are a lot of job descriptions that back this issue up.

I learned Ruby on Rails on my own and have successfully developed and deployed two significant applications during my spare time using Ruby on Rails in the last 3 years. The applications I've written are not open source and they are not public access sites, and until I do get something written within the public facing / open source realm, I am convinced that I probably won't ever get considered for a full time rails job.

I've mostly just about given up on ever expecting to get hired by a company that uses Ruby on Rails. It is all total bullshit in my opinion. I will continue to use Ruby on Rails on my own and ignore Pair Programming because I see Pair Programming as a form of micromanagement and not an opportunity for programming productivity.

I have plenty of experience working with other software developers on the same piece of code, in front of the same terminal window, for two or three hours at a time - always initiated by myself or the other developer, not prescribed by management. The fact that I don't do it every day is irrelevant in my opinion.

<comment><USER6> "I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I do not have experience working on an "agile" team doing every day pair programming."

This sounds like sample error. It is true that RoR culture overlaps with pair programming/XP culture and agile culture, but there are VERY MANY RoR places that do _not_ pair every day.

</comment></comment><comment><USER18> No one should have to suffer what this particular man suffered. Holy crap that's depressing.

<comment><USER19> His experiences with pair programming parallel my own. I had to quit an otherwise fun job, that paid really well, because I simply could not stand being that close to other people for that much of the day.

</comment></comment><comment><USER20> After a few months of pair programming, I can only agree. At points, when my partner saw a better way of doing things, it was insightful. In the end, however, we found that it was more efficient to split up the work, merging code when necessary.

</comment><comment><USER21> I generally like pair programming in some cases, and dislike it in others.

You have to combine it with TDD or else each person focuses on something different, and basically reverts to being a spelling mistake checker until it is their turn.

I have only enjoyed it when doing mostly new development, in a modern language with modern tools, combined with a strict red green refactor process, where one person writes the test , and the next makes it pass and writes the next test.

For more exploratory stuff, or doing it without TDD, or using old crappy languages and tools, or doing maintenance, it just sucks and I prefer to work alone.

</comment><comment><USER22> In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time.

I basically believe that crunch time increases the probability of errors by orders of magnitude. Secondly, as the author mentions, that is the time when gaps in knowledge need to bridged over... at the expense of personal ego if need be.

<comment><USER10> > In my place, I sort of enforce pair-programming for about 2 weeks before a > deadline. Basically at crunch time. I basically believe that crunch time > increases the probability of errors by orders of magnitude.

Code reviews will give you the same benefits without the soul crushing drawbacks described in the article.

<comment><USER22> For a short, intense period of time - pair programming can produce the same benefit as code + code review, without taking as much time.

Plus code review has an inherent context switch (for the reviewer) that is even worse during a crunch time.

<comment><USER10> I did code reviews at Google for four years and it never felt like a burden, more like a part of my job that feels gratifying and useful. I also loved knowing that every single line of code I wrote was going to be reviewed.

Pair programming is not used at all at Google, mostly for all the bad reasons cited in the article. And also because code reviews really do work (admittedly, Google has a fantastic infrastructure to support it).

</comment></comment></comment></comment><comment><USER23> I think the author is conflating Pair Programming with other concepts.

 _There are no high notes, no thought out design. There's only the design that could have tests written for it, in the time you had to write the tests. The classes look reasonable at first glance, and the methods are seemingly bug free. But the cracks are there, if you know where to look._ ...

 _Eventually, I realized that many of my partners had never worked outside a test driven development process: they didn't have the same idea of design or architecture as patterns distinct from code. Trying to argue for encapsulation or adherence to SOLID principles is pointless if your partner has no background, let alone hands on experience, with what you're saying. This goes double when you're talking about hard-won domain expertise: the more I knew about a subject, the less I could say._ ...

 _The large part of pair programming was doing things in "The Simplest Possible Way That Could Work." In practice, this meant doing it the way that it had been done previously, with the least possible amount of change._ ...

What on earth does any of that have to do with Pair Programming?

<comment><USER24> > What on earth does any of that have to do with Pair Programming?

I'm the OP.

What I'm describing is my experience Pair Programming in one organization, and why it didn't work for me. To tell the story, I needed to provide the context and the background to say why it didn't work for me. They're distinct issues, but the only way we could relate to those issues and work through them was through the lens of pair programming.

Keep in mind that I'm not trying to say that Pair Programming is a flawed practice in principle, or even that their approach was flawed _in practice_ for the company -- there are other metrics besides code quality that a startup needs to consider if it's going to survive, and sometimes "good enough" code is good enough.

I'm well aware that pair programming works very well for some people, and that my experience may not be typical. However, just because my experience wasn't typical doesn't mean it didn't happen.

</comment></comment><comment><USER25> I've had good experiences with pair programming. This does not sound like my experiences and I feel for the writer. It sounds like a horrible situation to have lived through.

</comment><comment><USER26> Sometimes I feel like I'm the only person that enjoys pairing way more than coding by myself. :/

<comment><USER27> I think of it kind of like romantic relationships. If you're paired with the right person, it's bliss beyond bliss. If you're not...</comment></comment>


JavaScript async/await implemented in V8 - <AUTHOR> https://chromium.googlesource.com/v8/v8.git/+/d08c0304c5779223d6c468373af4815ec3ccdb84 <comment><USER2> The moment I started using async await (with babel) combined with the new fetch API so many libraries got obsolete.

Getting data is as easy as:

      async function main () {
        try {
          const res = await fetch('https://api.github.com/orgs/facebook');
          const json = await res.json();
          console.log(json);
        } catch (e) {
          // handle error
        }
      }

So I am quite happy when this lands in modern browsers asap.

<comment><USER3> Is the syntax composable? Can I do

        const json = await (await fetch(https://api.github.com/orgs/facebook')).json();

or do I have to name it?

<comment><USER4> What you asked for is whether `await` is idempotent. No it isn't. The "argument" to `await` is a Promise, and the "return value" of it is the resolved _value_ of the Promise (i.e. `Promise#then`).

EDIT: I missed the `.json()` part, but I suppose it doesn't return a Promise, no?

<comment><USER2> actually .json() returns a Promise. The first fetch only returns HTTP status code and some other details. The content itself is streamed. You can also access the stream if you want too. In general you would rather just call .json() and get the parsed data.

The fetch function can for example also be used to get images. There you would use .blob() and assign that to an image.src with URL.createObjectURL(blob);

See here: [https://developer.mozilla.org/en- US/docs/Web/API/Fetch_API/U...](https://developer.mozilla.org/en- US/docs/Web/API/Fetch_API/Using_Fetch)

</comment></comment></comment></comment><comment><USER5> Thank you to Microsoft and Anders Hejlsberg for inventing Async/Await (and to F# for the original inspiration) [https://en.wikipedia.org/wiki/Futures_and_promises](https://en.wikipedia.org/wiki/Futures_and_promises)

<comment> Lx1oG-AWb6h_ZG0 async/await as we know it actually came from Midori's C# dialect, which indeed was inspired from F#: [http://joeduffyblog.com/2015/11/19/asynchronous- everything/](http://joeduffyblog.com/2015/11/19/asynchronous-everything/)

(Although, just to be pedantic, the concept of futures is way older than F#. Alice's syntax, for example, is pretty close)

<comment><USER6> The nice part about F#'s async implementation is that it was purely a library. I wish languages aimed at allowing developers to build things for the language, rather than providing more compiler built-ins. Making it extensible is more elegant (though I understand it might be easier to optimize perf).

<comment><USER7> Integrated features are easier to tool and provide good diagnostics for. It's nice to have enough expressiveness to model monadic computations without too much syntactic overhead - and monads are usually enough, since they hand blobs of user code to the library to be composed as necessary - but debugging a reshuffled graph of closures is no picnic.

</comment></comment></comment></comment><comment><USER8> This news is almost as important as the rest of ES2015 being implemented in Webkit.

async/await is the final piece in the puzzle of providing real solutions to callback hell in JavaScript.

<comment><USER9> I am willing to admit that async/await is a bridge between the Node and .Net communities -- surmounting this means we are that much closer to literally doubling the developer pool for either sections of the community.

<comment><USER10> how so? I like the JS async/await a lot, but you couldnt pay me to write .net

I personally don't know many devs who would choose to learn a new lang because of a feature (assuming that they didn't want to learn it before it existed)

<comment><USER11> I don't understand. I also like JS async/await and like JS and node in general but .NET is simply beautiful IMHO (given you are using F# or C#). Why would you rather not write .NET code?

<comment><USER12> c# is a great language but many people don't want to have to specify type information so often or create classes so often. Even many statically-typed languages don't require as much List<T> stuff. Also, everything outside of the language itself sucks. The frameworks, the operating system is has to run on, the community, etc.

<comment><USER13> I object to this. The .NET Framework is top tier and sets a high bar for standard libraries, in my opinion. It also runs on any OS just fine, especially now that Microsoft's own implementation is open source and MIT licensed. The community is also very strong with tons of docs and libraries and SO Q&As and plenty of jobs and local user groups. And if you don't like the C# boilerplate, F# has all of the same benefits.

Enough with the FUD around .NET/C#, I'm a full time Linux greybeard and even I'm sick of it.

</comment></comment></comment></comment></comment></comment><comment><USER14> Here's a simple guide to async/await.

[https://www.twilio.com/blog/2015/10/asyncawait-the-hero- java...](https://www.twilio.com/blog/2015/10/asyncawait-the-hero-javascript- deserved.html)

<comment><USER15> Eddie Zaneski is an awesome and friendly guy!

Here's another awesome article on it:

[http://amasad.me/2015/10/31/javascript-async-functions- for-e...](http://amasad.me/2015/10/31/javascript-async-functions-for-easier- concurrent-programming/)

</comment></comment><comment><USER16> Why is "async" keyword needed? Can't JS engine infer from the use of "await" in a function that this function need to be async? I'm using async/await for a while now, and so many times I've introduced bugs in my code because i forget to put "async" in front of the function, or put "async" in front of wrong function. It's simply annoying to go back and put "async" when in middle of writing a function I realise I need to use await.

<comment><USER17> Reason is mentioned here: [https://github.com/tc39/ecmascript- asyncawait/issues/88#issu...](https://github.com/tc39/ecmascript- asyncawait/issues/88#issuecomment-181517500)

<comment><USER18> Thanks for this! Also later in that thread is an example to further bring home the point: [https://github.com/tc39/ecmascript- asyncawait/issues/88#issu...](https://github.com/tc39/ecmascript- asyncawait/issues/88#issuecomment-181574985)

Solid reasoning, in my opinion.

</comment></comment></comment><comment><USER19> Looking at Kangax's support table:

[http://kangax.github.io/compat-table/esnext/#test- async_func...](http://kangax.github.io/compat-table/esnext/#test- async_functions)

Apparently Microsoft Edge seems to have been the first browser to implement it... good job Microsoft!

</comment><comment><USER20> I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't make tons of sense either. I've done a lot of async and I've never needed anything beyond Q that I can recall.

This feels like a step toward added confusion rather than language unity. Much like the majority of of ES6 feels to me: bolted-on features from popular synchronous languages that themselves are only now adding features like lambdas.

I don't want to write faux-event-driven code that hides the eventedness beneath native abstractions. And I definitely don't want to work with developers, new and old, trying to learn the language and whether/when they should use async/await, promises, or fall back to an es5 library or on* event handlers. I want developers who grok functional event-driven code with contextual closures.

<comment><USER21> Allow me to make both a theoretical and practical argument.

It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data flow. Instruction scheduling is an explicit sequence with callbacks (well, assuming the API calls you back precisely once), but scheduling is an implicit topological sort of the directed acyclic dependency graph of promises.

Sometimes, when it comes to side effects, implicit scheduling is less than ideal. You need specific things to happen in a specific order. The solution is to introduce data dependencies to force a particular schedule. This is precisely what is done by monads in Haskell. However, unlike Haskell, JavaScript doesn't have "do" syntax, so there's no convenient notation for a nested chain of bindings.

The result of not having monadic binding syntax is that you wind up with some funky nested chain of getY(x).then(y => y.then(z => z.then(.... OR you have to declare variables up top, flatten your then blocks in to a promise chain, and often ignore intermediate values:

        let y, z;
        getY(x)
        .then(returnedY => { y = returnedY; return zPromise(); )
        .then(returnedZ => { z = returnedZ; return ......; }
        .then(......another side effect.....)
        .then(_ => f(y, z))

async/await neatly eliminates this problem by reusing the traditional coupling of data flow dependencies with first-order control flow dependencies.

Practically:

        let y = await getY(x);
        let z = await getZ(y);
        ......another side effect....
        return f(y, z)

<comment><USER20> > It's been said that "callbacks are imperative; promises are functional". > It's true. Furthermore, callbacks structure control flow and promises > structure data flow.

Do you have any good escapes l examples of further reading on this? I'm not sure I agree with this statement, or perhaps don't fully understand it. It seems like both cases boil down to functions as data (function pointers essentially) that are called at the end of some event or chain of events.

To me, they seem to be the exact same thing but worth promises being much more human readable.

<comment><USER21> You can google that quote and find more, but the control flow vs data flow formulation is not widely discussed from what I've seen.

<comment><USER22> It's widely discussed in Haskell communities, fwiw ;)

</comment></comment></comment></comment></comment><comment><USER23> Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises?

I'd love to hear about people who have used it in large and complex projects, from a debugging standpoint.

As of now, using Bluebird (with its source in a different, blackboxed script), it is possible to follow the code execution through the event loop with async debugging, in a very elegant and enjoyable fashion.

I find async/await much more appealing when coding, but I'm worried about quality of life when hardcore debugging, as in my current project it can make me waste hours at a time when something if completely fringe happens.

<comment><USER24> I have some medium/large projects using async-await.

There are 2 ways to transpile async-await.

a) Default, with regenerator, transpiles it to ES5

b) If your env supports generators (like Node, or newer browsers), you can use async-to-generator plugin.

Regenerator gives you unreadable code, but it will run everywhere. async-to- generator gives you (relatively) readable code.

Source maps support has improved a lot, and you can choose to see only your original code while debugging. You'd be setting breakpoints on your code instead of transpiled code. So you should be fine whether you're using regenerator or async-to-generator. There _might be_ corner cases (very rare) depending on your env; in which case if you're using regenerator you might need to switch to async-to-generator to find the bug.

Source maps work well with node-inspector. If you'd like to see better stack traces in say "mocha" tests (or other test framework), use [https://github.com/evanw/node-source-map- support](https://github.com/evanw/node-source-map-support).

Overall, the developer experience is now pretty good. Thanks to all the work that's gone into the tooling.

</comment></comment><comment><USER25> It has been in Microsoft Edge/Chakra for a while. But I couldn't make it work with Babel + webpack2. I still needed babel for static properties and React. It was either webpack parsing couldn't recognize async/await or webpack executes modules on Nodejs which wasn't supporting asyn/await by the time. So bundling was failing.

I wonder if there is any babel/webpack gurus out there can make it work ?

Oh btw, I recommend windows users to try microsoft edge for debugging and runtime inspection, it is so slick :)

</comment><comment><USER26> > [esnext] prototype runtime implementation for async functions

Well, it claims to be a prototype. Can anyone from the team comment?

Quite exciting in any case!

</comment><comment><USER27> Promises are like cancer, and async/await is just treating the symptoms.

      // Callback
      dataCollection.find('somethingSpecific', function getIds(dataArray) {
        var ids = dataArray.map(item => item.id));
        display(ids)
      });

      // Promise
      var dataArray = dataCollection.find('somethingSpecific');
      var ids = pmap(dataArray, function(item) { // Cancer cell
        return item.id;
      });
      pdisplay(ids); // Cancer cell
      // The cancer grows ...
      function pmap (dataPromise, fn) {
        return dataPromise.then(
        function(data) {
          return map(data, fn);
        });
      }
      // The cancer grows ...
      function pdisplay(dataPromise) {
        dataPromise.then(function(data) {
          display(data);
        },function(err) {
          display(err);
        });
      }

</comment><comment><USER28> In the meantime there's the co library which provides the next best thing using yield.

<comment><USER29> And a swifter way to handle legacy callback (using thunks). Co is _great_ and work today (even in browser)

</comment></comment><comment><USER30> I'm definitely rooting for the feature to be included in the spec as soon as possible, but I'm a little weary when features are added to the engine before being standardized. Object.observe, anyone?

<comment><USER31> The only reason that async/await hasn't been included in standard is because there were not enough implementations.

</comment></comment><comment><USER32> Man, I used to love the times when try/catch was used to exception only, and with exceptions that leaves the program in a bad state, I used to think when you see a throw something really bad is going on, not just a simple ajax fail.

Dont know why people love so much async/await. In the end of the day, this all (in node land, for instance) will be just a function call in the libuv, this will never change, this is because the pattern is really good.. Why overcomplicate that?

</comment><comment><USER33> I think my problem with this approach is the way it throws away the functional programming paradigm JS has been sharpening over these last few years. When I see await, I'm reminded of Java or .net, languages that didn't traditionally have functions as first class citizens.

OTOH, I can't complain about removing dependencies like "when" or "bluebird", and it'll be nice to not have to simulate promise returns in testing.

<comment><USER34> I think it's nice to have both options. I prefer the functional style of chaining promises for the most part, but there are definitely a few times when await is easier to use IMO (awaiting inside of a loop, for example).

</comment></comment><comment><USER35> Super excited to start seeing async/await in some of the browsers. Async/await makes certain function decorator patterns even more useful, e.g. [http://innolitics.com/10x/javascript-decorators-for- promise-...](http://innolitics.com/10x/javascript-decorators-for-promise- returning-functions/)

</comment><comment><USER36> I like how it rhymes.

</comment><comment><USER37> From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that?

Like, what's the equivalent of Promise.all with async/await? And how do tou do stuff synchronously after kicking off an async process?

<comment><USER38> I'm not sure you fully grok async/await then. Thing is, using async/await _means_ using promises. You can't use async/await without promises. An async function returns a promise. _Always_. (in a way, `async` can be seen as something of a type annotation).

If you want to use async/await with something that's asynchronous but not Promise based, you'll first need to convert it into a promise before you can async/await it. This is actually very elegant in my opinion: instead of proposing _yet another_ way to do asynchronicity in JS, async/await fully embraces Promises, which you already know.

Of course, this means that async/await also has all of Promise's downsides. For example, you can only resolve a promise once, so neither Promises now async/await make dealing with streams of asynchonous events any easier.

<comment><USER39> I don't see that as a downside. Callbacks make sense for the pipelining portion of async streams. I usually wrap things up such that i set up my callback/event based stream pipeline, and then have a promise that gets resolves on completion/end. That way your stream code is 100% normal callbacks, and you still have promises/async/await for overall flow control.

</comment></comment></comment><comment><USER40> What about this nodejs async,

[https://github.com/caolan/async](https://github.com/caolan/async)

May be a replacement until the async is implemented in V8

<comment><AUTHOR> It's not a replacement at all, and has almost nothing in common with what is discussed here (except the name).

</comment></comment><comment><USER41> what's the point of explicitly declaring functions "async", and then explicitly saying "await". IMHO all this could be done automatically by language.

<comment><USER24> Because you don't always have to await a function, and it isn't always possible for the runtime or language to decide whether to "await" or not.

      /*
        The following code may or may not use an await.
        Not await-ing would be better user experience.
      */

      async function sendEmails(id) { ... }

      async function signUp(userData) {
        const user = await db.saveUser(userData);
        sendEmails(user.id); // <-- Not awaiting send to complete
        return "Congrats. Signup complete!"
      }

      /*
        On the other hand this code needs an await:
      */

      async function updateGlobalState(obj) { ... }

      async function doSomething(data) {
        await updateGlobalState(data); //await needed
        return global.x;
      }

<comment><USER42> is the non-awaiting one guaranteed to finish (assuming no errors)?

<comment><USER43> It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with an awaited return value). It's "finished" as soon as it's finished _initiating_ the send, since it doesn't await the result.

(The _exact_ point where this gets resolved, relative to other pending callbacks/resolutions, is a very wonky detail involving constructs not exposed at the language level, which varies from engine to engine in spite of what the standard says: [https://jakearchibald.com/2015/tasks-microtasks-queues- and-s...](https://jakearchibald.com/2015/tasks-microtasks-queues-and- schedules/))

Whenever the call resolves, even if the send _does_ encounter errors, this function or its caller aren't going to know about it either way. That's why this kind of promise-abandonment is pretty bad design - I wouldn't be surprised if there's already a draft in the works for some kind of "use strict" option that causes warnings / crashes when synchronous code finishes with Promises unreferenced (or at least something in tooling / profiling to trace 'promise leaks').

<comment><USER42> Interesting!

</comment></comment></comment></comment></comment><comment><USER27> I can't see how wrapping everything in a promise and a try/catch, plus adding async/await is any easier then a callback.

<comment><USER44> Exactly! When you count for nested try/catchs you see no significant improvement

<comment><USER45> Why would you nest try/catches? At worst you get try/catch parades:

        try {
          await thing1()
        } catch (e) {
          console.log(e)
        }
        try {
          await thing2()
        } catch (e) {
          console.log(e)
        }
        // ... and so forth ...

That's still nothing like the pyramids you get in callback world.

<comment><USER44> That won't work because if thing1() throws you usually don't want to process to thing2

Take this for example:

         const response = await fetch('./api.json');
            try {
                const json = await response.json();
                console.log('YAY! JSON!', json);
            } catch (jsonParseError) {
                alert('damn it!');
            }
         } catch(fetchError) {
            console.warn('this is not cool');
         }

<comment><USER45> Okay, that's a fair counter-argument. My gut feeling is that's possibly one catch to many and as much as possible I'd want to try to merge the two catches/unifying the error response logic.

Another idea is that you could reformat to a "parade" try/catch by adding returns to the catch:

        try {
            const response = await fetch('./api.json')
        } catch (fetchError) {
            console.warn('this is not cool')
            return // Exit
        }
        try {
            const json = await response.json();
            console.log('YAY! JSON!', json);
        } catch (jsonParseError) {
            alert('damn it!');
        }

Obviously you'd need to move any code you'd want to run regardless of error up into the parent function or out into a wrapper function.

</comment></comment></comment></comment></comment><comment><USER46> The one extra diff I would really like to see in that list is some documentation. The V8 docs have always been too sparse.

</comment><comment><USER47> So what does this mean in terms of being implemented in Node.js? How soon can we expect that to happen?

</comment><comment><USER48> This is so good. Great days for JS. This is going to save us from a lot of headaches.

</comment><comment><USER9> Realistically does this mean we will see async/await in node-v7.0?

<comment><USER49> I hope the node APIs are changed/extended to return promises eventually so I don't have to keep on using promise wrappers for all of them.

<comment><USER50> Is there a reason you always wrap them? Even if it's awkward I tend to leave most platform APIs alone and treat them as special cases if I'm doing something, say, promises or messages.

<comment><USER45> Promises are much each to compose. Promise objects can be passed around and reused. (Multiple things can wait on the result of the same promise.) Code is much easier to read with flat .then() and .catch() chains, versus sometimes the "pyramid of doom" callbacks can create. Code is much, much easier to read with Promises when you can use async/await, and getting everything wrapped to promises now makes it that much sooner you can use async/await.

<comment><USER50> I get the why people want to use Promises in general but when they're used to simply wrap a standard node / browser call feels dirty to me because it changes what you expect it to return (e.g. a promise instead of whatever it normal returns).

I dunno I just don't like to give the impression I'm changing anything about how I'm accessing / using the standard library but I guess this is a bit subjective.

> versus sometimes the "pyramid of doom" callbacks can create

If you structure the code well you never run into this (callback soup is very overblown; if you find yourself in that position then someone screwed something up). But I get promises and async / await are nice :)</comment></comment></comment></comment></comment>


Ask HN:Friend is math/algorithmic genius, wants to learn programming. Resources? - <AUTHOR>

I have a friend, who has an uncanny talent for anything mathematical. He can write formulas and functions to solve the most obscure math problems, and he has the mind of an algorithmic thinker that I and probably many wish they had. Think project Euler, he's really good at those types of problems.<p>He doesn't actually know any code, but I feel like he would be able to accomplish so many things with it. I've talked to him about it, and he's really interested, but he doesn't know where to start. Due to financial issues, he occasionally does not have Internet, but he does have a decent and functional computer to work with. What books/tutorials/resources should I give him so that he can put his mathematical and problem-solving talent to good use? <comment><USER2> Learn Python the Hard Way: [http://learnpythonthehardway.org/](http://learnpythonthehardway.org/)

You can download it and run it off-line. It concentrates initially on drilling simple things so that later it you can release your mind to work on real problems, and not constantly trip over the trivial.

Seems a great place to start.

</comment><comment><USER3> First: [http://www.paulgraham.com/onlisp.html](http://www.paulgraham.com/onlisp.html)

Then, once he is frothing at the mouth: [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

Then for the love of god protect him from Emacs: [http://www.franz.com/downloads/clp/survey](http://www.franz.com/downloads/clp/survey)

hth

<comment><USER4> For what particular reason do you want him to start with Lisp?

</comment></comment><comment><USER3> ps. Have him take a crack at protein-folding so he does not get bored.</comment>


Ask HN: DevOps folks, how much time do you spend on security vs. compliance? - <AUTHOR> I keep hearing from some DevOps leaders that compliance is a pain in the behind and they spend an inordinate amount of time on compliance certifications. Would like to hear more viewpoints. <comment><USER2> I wear both a DevSecOps and a System Architect hat at work so take my experience with a grain of salt.

I spend maybe half of my time working alongside developers to define security controls that need to be added, verifying they were implemented, and testing production. I do this because I realized when reading _The Phoenix Project_ that the only way for security to be taken seriously by a company, I have to have an integral hand in the SDLC. Ironically enough, by defining the security controls that must be put into scope this early in the process, I also am able to make sure our software maintains compliance. This experience will be very different for a company that has more technical debt then we do, keep in mind.

I spend maybe 10% of my time on compliance. However, this is because we've already achieved our benchmarks; I only focus on determining violations, remediation, and making sure the company is ready for the next audit. Like I said, we have little technical debt and I work tirelessly to make sure security controls have been identified before the scrum starts. Back when I was working to get us to this point, I spent perhaps 90% of my time learning about the compliance benchmarks we needed to achieve and when needed to happen for us to get there.

</comment><comment><USER3> I work with companies < 50 people and do not hear this. Most of them are first looking for stability and velocity, then security.

Where I do see compliance come up is from customer demand or niche applications (healthcare). Even so, compliance is more about people and paper than technology, so yeah it takes longer, it's bureaucracy!</comment>


Can We Delay a Greenhouse Warming? (1983) [pdf] - <AUTHOR> https://nepis.epa.gov/Exe/ZyPDF.cgi/9101HEAX.PDF?Dockey=9101HEAX.PDF <comment><AUTHOR> [https://twitter.com/davelevitan/status/1100141281332940802?s...](https://twitter.com/davelevitan/status/1100141281332940802?s=21) Twitter thread with some choice quotes

</comment><comment><USER2> Terribly sad to see that the Fossil Fuel industry has waged such an effective stall campaign for as long as it has. We're all the victims for it.

<comment><USER3> As long as they keep getting away with it they will continue to corrupt our institutions.

</comment></comment><comment><USER4> Relevant piece, _Losing Earth: The Decade We Almost Stopped Climate Change_ (covers the time frame when this was published), was discussed here:

[https://www.nytimes.com/interactive/2018/08/01/magazine/clim...](https://www.nytimes.com/interactive/2018/08/01/magazine/climate- change-losing-earth.html)

[https://news.ycombinator.com/item?id=17661450](https://news.ycombinator.com/item?id=17661450)

</comment><comment><USER5> It looks like they were predicting a 3-4 degree celcious increase by 2020 if I'm reading the chart right. I wonder why that didn't materialize? Maybe more warming later on.

<comment><USER6> IIRC, while the paper notes the ocean serves as a carbon sink, its capacity was not yet known, and that it later proved much larger than anticipated.

</comment></comment><comment><USER7> It's pretty remarkable that in the first paragraph they say that the temperature increase is likely to be about 2 degrees C by the middle of the 21st century and about 5 degrees by the year 2100. And that's almost exactly what we're on track for now.

<comment><USER7> Downvotes. Really guys. I'm just saying, it's impressive that they were that accurate with the primitive models they had way back in 1983.

</comment></comment><comment><USER8> Interesting.

It's funny how the conversation have changed now to Climate Change instead of global warming.

A lot of this has been pushed by the environmental organizations who despite their claims that CO2 is the biggest threat to humankind still are overwhelmingly against nuclear energy despite it being both safer, more scaleable, more reliable and actually able to provide energy compared to unrealiables like wind and sun.

If anything this just shows how long this discussion have been going on and how much of this is politics and ideology rather than science.

<comment><USER9> You've posted about this a lot, and your comments are unfortunately crossing into flamewar at times. We've had to warn you about this before. Can you please reduce the quantity and increase the quality of what you post? Remember that the guidelines say: "Comments should get more civil and substantive, not less, as a topic gets more divisive."

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER8> Hi Dang,

Fair enough, I will try and reduce my comments on this topic but people are asking me questions often with lots of personal attacks in there and I am trying to answer the questions.

I am seriously trying to understand how my comment is not mostly civil or substantive or how they are crossing into flamewar which is defined as:

"A flame war is a series of flame posts or messages in a thread that are considered derogatory in nature or are completely off-topic. Often these flames are posted for the sole purpose of offending or upsetting other users."

That's not at all my intention quite the contrary. I am trying to get balance into the very one-sided nature of this debate which is easily verified by looking at the claims of the posted articles/essays.

I am totally fine with being in the minority when it comes to what I think is substantive but I frankly do not see how it's not civil any more than some of the comments I get which doesn't get treated or told off or downvoted into oblivion.

<comment><USER9> By 'flamewar' I mean the kind of internet discussion that gets angrier and shallower as it goes along, typically on divisive topics, typically repeating things that have been said many times before, with people trying to defeat rather than connect with each other. There's no intellectual curiosity in those arguments, so they're off topic here.

Also, they're tedious, except to the minority whose passions happen to be inflamed on that topic, and people tend not to know when to stop. These are the sorts of thread that make HN worse, and which all users are asked to have the discipline to refrain from. I know it's hard sometimes.

I'm sure that some of the replies you're getting are also breaking the guidelines, but we don't see all of those. Flagging them helps bring them to our attention. If there's anything particularly abusive you can email us at firstname.lastname@example.com.

</comment></comment></comment></comment><comment><USER10> The solution is to curb development in countries like India. But good luck selling that idea.

Instead, let's over-regulate Western markets, because there's definitely not any private investment going towards renewable energy, and the US definitely doesn't lead in carbon emission reduction /s

<comment><USER11> given US is one of the biggest contributors in absolute terms and also is incredibly high in per person terms, surely that's the best place to start.

<comment><USER10> What about in terms of GDP?

<comment><USER12> The US is the world leader in GDP.</comment></comment></comment></comment>


New algorithm significantly boosts routing efficiency of networks - <AUTHOR> http://www.physorg.com/news138281890.html <comment><USER2> Can we have the paper instead of the press release? I guess it wouldn't get voted up, though.

<comment><AUTHOR> sorry about that! <http://charlotte.ucsd.edu/users/savage/papers/Sigcomm08.pdf>

</comment></comment><comment><USER3> Quick summary:

"The real technical innovation of their work, said another of the authors, Geoffrey M. Voelker, 'is in how information about changes in the network is propagated. The XL routing algorithm propagates only some updates, reducing the number of updates sent through the network.'"</comment>


The Bash Guide - <AUTHOR> http://guide.bash.academy/

<comment><USER2> A very useful guide, particularly for beginners. I like the way this is formatted and the descriptions/definitions are accessible.</comment>


Idea: uber for telescopes? - <AUTHOR>

Any value in such an idea? Are telescopes a shareable resource? <comment><USER2> Check out [http://www.lightbuckets.com](http://www.lightbuckets.com) or [http://www.itelescope.net](http://www.itelescope.net)

There are a few other services as well, but it's certainly a thing folks do.

</comment><comment><USER3> I think it's a very small market. How many people want to rent a telescope? How often? How much want them to pay? If you get a 10% cut, can you live with it?

Another problem is that when you use car with Uber, the driver is there to prevent misuses and vandalism. Do you rent the telescope with the telescope owner/operator, or only the telescope?</comment>


Show HN: GetPhabricator.com - <AUTHOR> http://www.getphabricator.com/

<comment><USER2> Hi -

Like it - getting it out there as early as possible. Will be interesting to see where you are in the process the next time you show HN.

Something patio11 has said before might be useful here - (<http://news.ycombinator.com/item?id=4311205>) the key bit: "instead of "Please give me your email address because that would help me a lot", you'd say "Do you have a problem grant-writing? Of course you do. I'll send you a free copy of my 15-page report on grant writing, including these 3 tips which will save you time/stress and make it more likely that your grant is successful. Where should I send your report? [email address] [Get My Free Report]"

Good luck!</comment>


How much is a decent price to ask for this job? - <AUTHOR>

Hey all, I've been commissioned by a company in San Francisco to do some html5 / javascript web design work to make a 3d model viewer for their product.
I need to integrate it in with their current web store which is some prepackaged php thing and have it vary the price and configuration of both the model and the texturing / color of the model based on package options.
What's a good hourly rate to ask for for this job?
Thanks! <comment><USER2> It depends.

It depends on how long you think it will take, how long they think it will take, what their budget is, your experience, your demonstrable experience, your portfolio, whether you want the job, whether there will be feature creep, whether you're willing to take the risk on over-run, how good you are at estimating, and whether you want this to be a one off, or an on-going working relationship.

How 'bout telling us something of yourself? You have no karma, no submissions (except this one), no comments, no contact details, and no pointer to other work.

So, it depends.

</comment><comment><USER3> For this kind of work I wouldn't recommend charging an hourly rate, because when projects like this overrun (and if it's HTML5/JavaScript the chance of it happening is likely) the employer will feel cheated if paying for longer than they expect (and let's be honest, all employers think that websites take half the time to build).

The best thing to do in this instance is to find out their overall budget for this thing, break it down into an hourly wage and set an overall price based on what you feel your time is worth.

<comment><USER4> _The best thing to do in this instance is to find out their overall budget for this thing, break it down into an hourly wage and set an overall price based on what you feel your time is worth._

A Mechanic does not fix you car based on a total cost, they charge a hourly labor rate + parts. A lawyer bills for his services by the hour. Both will provide a best guess at what they think it will take, but if you add some work or they find some problems you eat that cost not them.

Why people think software development should be any different is beyond me. If you are not getting equity in the project then you should not be working on a fixed price contract. It places all the risk on you while limiting your upside (you can only make the sticker price on the contract). Meanwhile the client has unlimited upside in this arrangement and shoulders none of the risk beyond the sticker price.

 _the employer will feel cheated if paying for longer than they expect (and let's be honest, all employers think that websites take half the time to build)._

Ignorance of the discipline of software development is the employer problem, a good software developer can show them how scope creep, change in priorities and adjustments to specification has a negative impact on their expectations. If they feel cheated that is their problem to deal with, software development is not charity and if it takes twice as long to build and a developer puts in twice as many hours then they should be paid twice the hours just as any other service professional is.

The client/employer is not going to say "oh wow we made twice as much as we expected off the software you developed, here you go, here is some free money". So why would the developer say "oh wow the project will take twice a long as, the employers uneducated analysis says it will, let me eat half the labor costs"

That being said, only extremely experienced freelancers should consider taking a fixed price contract. It can lead to financial ruin, in almost all situations a freelancer should be insisting on time and materials, like 90% of other service professionals. The exceptions would be reproducible services where times can be estimated with certainty (e.g installing wordpress or Postgres).

To answer the parent posters question, I see a lot of Senior level JavaScript freelancers charging in the area of $100-$200 hr for their services. That is what I charge and stay busy.

<comment><USER3> > A Mechanic does not fix you car based on a total cost, they charge a hourly > labor rate + parts. A lawyer bills for his services by the hour. Both will > provide a best guess at what they think it will take, but if you add some > work or they find some problems you eat that cost not them.

You're not a Lawyer or a Mechanic, you're (possibly) a Web Developer and it's fairly standard to charge based on project, as referenced by countless guides, online resources and notably within SitePoint's Web Design Business Kit. I've already stated the reasons why you do this, because it confirms the overall cost with the client, it ensures the project will not overrun at the clients expense, and in the end the client has an overall budget for this work, not a certain amount to spend per hour.

As time has shown, paying by the hour is a poor and dated way to do business on the web because building software isn't an exact science and many projects overrun. In the same vein I cannot understand why people have to treat software development as a "profession" like Lawyers or Doctors. You're selling a software solution to a client, so you should charge for that solution, in the same way that people who offer products or solutions charge.

> Ignorance of the discipline of software development is the employer problem, > a good software developer can show them how scope creep, change in > priorities and adjustments to specification has a negative impact on their > expectations. If they feel cheated that is their problem to deal with, > software development is not charity and if it takes twice as long to build > and a developer puts in twice as many hours then they should be paid twice > the hours just as any other service professional is.

That's a fantastic way not to get hired for a project.

It cannot be more simple than setting a price on your time per hour, estimating how long a project will take and charging what you feel your time is worth as a lump sum. The client should not get to dictate that, because you're the expert and you'll have the better idea of how long it should take.

<comment><USER4> _You're not a Lawyer or a Mechanic_

The nature of the arrangement is more similar that not. Both do project based work as service professionals. And both have unforeseen variables that cannot be known at the time of estimating. Lawyers routinely deal with unforeseen political issue (ruling not going the way they expected) and mechanics routinely deal with unforeseen problems that are technical in nature (mechanical failure, that was not known until the heads where pulled off).

Software developers routinely deal with both natures of unforeseen variables in addition to the client adding work after the estimate. Which would be akin to a mechanic giving someone a quote and then when they are half way through the project the client saying well while you are in there go ahead and change out the pistons for forged steel ones, and then arguing because the client got charged for the parts and labor. In all three cases the client pays for the additional work not the service provider.

 _paying by the hour is a poor and dated way to do business_

I differ on that opinion as well Sitepoint does too, almost all of the top talent in any development field works by the hour not by the project. Most know to not take the entrepreneurial risk of another company while engaging in a contract that limits their reward.

[http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing- vs-h...](http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-hourly- billing/)

 _You're selling a software solution to a client, so you should charge for that solution_

Right and if I am shouldering the risk of the development costs, I am going to license it to that company as well as there competitors. If they own the result of my labor then they pay for that labor.

 _building software isn't an exact science and many projects overrun._

and that is not the developers burden to bear. Scope creep is a reality with any novice firm who is looking for software development. A fixed bid set up an adversarial relationship immediately. You will constantly be parroting "out of scope" to the point that the client will be just as pissed as they would have been about cost overruns as they are about not getting the product they want. The knife cuts both ways, and the reality is more fixed bid projects fail, because at a certain point of losses the developer walks or the software gets shelved because the project as scoped is not what the client thought they wanted at the time of developing a functional specification.

 _That's a fantastic way not to get hired for a project._

It's really not, I educate my clients on the risks of software development and what they can do to limit scope creep, changes in priorities and politics, the three big killers of projects. Further all of my clients now are big tech firms, so they are well versus in these realities. Not allowing myself to into a bad deal in no way affects my ability to get projects. Coming off as an amateur in contract negotiations can hurt far more than being firm on how you structure your work.

 _because you're the expert and you'll have the better idea of how long it should take._

Unless you are a politician, there is no way that you can do this with any accuracy, the client will creep scope, it is a given, with time and materials you have a lever that you can pull to say OK we can add it, but it is going to affect you budget by X and your delivery by Y. It puts the onus on them to control scope creep, if it is on you, you will be strong armed into accepting it.

If you don't they are just as mad as cost overruns and you have received no money, so when they pull the plug you are the one left holding the bag. I have been doing this for 20 years and have seen first hand that fixed bids cause more problems for both sides. Take a look at all the top guys on HN, take a look at there stories as to why they only do time and materials, each and every one of them will have a fixed big horror story.

<comment><USER3> As most of your comments focus on the same subjects I'll address them with one reply.

When I work I simply tally up the time it will take me to do things, add a bit more time for delays, some small scope creep and a bit extra for time to polish things off and to finish early and charge a single fee, with half to be paid at the start of the project and half when the project is completed. Before I start any project I have it written in the contract everything that I am paid to do, and with this I stress deeply that this is the final list and that any additions are separate payments (although I don't charge for basic alterations, or won't charge on one change to keep clients happy).

This system has worked perfectly for me, and I rarely experience scope creep or drastically late projects. If anything, I make it my business to make a project finish before time to add extra features for my client to make them feel that they're getting a better product for their initial investment in me. Ever since I started doing this I have not lost a single client, and have gained more than I can handle from word-of-mouth.

Believe me, I've tried educating my clients, but when they've got kids that can build a basic page in Dreamweaver or a secretary that has written a basic HTML newsletter people will believe that building large-scale websites is easy.

</comment></comment></comment></comment></comment><comment><USER5> You could:

Ask them if they have a budget figure per hour in mind. or Tell them a number and say "is $X per hour in the range of what you had in mind to pay for this?"

</comment><comment><USER6> Your hourly rate should depend on your skills, not the job for the client, so it really depends on how skilled a developer you are.</comment>


Ask HN: How can I securely install Truecrypt on OS X? - <AUTHOR>

I want to download an install Truecrypt on OS X 10.9.  Unfortunately, the Mac installer available on the Truecrypt website is not signed the way that OS X installers are normally signed.  Instead, I need to use the PGP method described on this page: http://www.truecrypt.org/docs/digital-signatures
So the problem then becomes: How can I securely install a program to check PGP signatures?  I've come across 3 options, each with problems:
1. Download the GnuPG source zip file and check the SHA-1 checksum as described here: http://www.gnupg.org/download/index.html But isn't it possible for a 'man in the middle' to tamper with the download while still producing the same SHA-1 checksum?
2. Download the Mac installer from this site: http://gpgtools.org/ But it is signed by someone called 'Lukas Pitschl' who I've never heard of and so cannot trust.
3. Download the Macports installer and install GnuPG as described here: http://www.mattnworb.com/post/16019918033/how-to-verify-a-pgp-signature-with-gnupg But the Macports OS X installer is signed by Robert Mercer - again, this is someone I have never heard of and cannot trust.
So how can I install Truecrypt securely without trusting someone I've never heard of? <comment><USER2> 1) The probability of someone producing the a different download with the same checksum is 1 / 2^80

2) Then why trust the truecrypt guys?

3) Then why trust the truecrypt guys?

The only way to achieve the level of security you're looking for is to download the truecrypt source code, audit it and then compile it and use that.</comment>


Ask HN: College internships? - <AUTHOR>

Hi HN. I'm a college sophomore and I'm in a quite weird position now - I started off college thinking about medical school and essentially took a bunch of bio&chem classes. However, I recently had a change of heart... I'm either going to major in physics / minor in cs, or just cram the cs major into the remaining two years. I had some CS background in high school (took the AP course, learned some languages on my own).<p>The thing is, I'm looking for internships now in tech stuff and it's pretty hard to find anything that I can apply for. It seems like most of the stuff require 2-3 years of CS experience, something that I don't have. Does anyone have any ideas on how to pursue this? Can I get an internship in tech? How would you recommend I proceed? <comment><USER2> To echo what was said earlier, the independent projects help a ton. At my previous job we would ask for X number of years of exp. but would overlook that requirement if the person genuinely seemed passionate and intelligent. The way we would figure that out is through their projects outside of their job.

Also, even if a company doesn't have an internship position listed on their website it doesn't necessarily mean they won't hire an intern. Just email them your resume and a cover letter that highlights a couple projects you have done, how the projects may relate to their business/software, and, if possible, a link to an online portfolio with screenshots/demos.

</comment><comment><USER3> how much are you willing to work for? what skills do you have? what hobby cs projects have you done? (when I hire, that's what I look at. If you don't have hobby experience, you are probably a 'just a job' type, and you are at a serious disadvantage competing with someone who is actually interested in the technology. I can give you production experience. I can't make you think it is interesting.)

If you don't need money, your options are wide open. you can do a starup with $0, if your living expenses are taken care of.

</comment><comment><USER4> Do some projects for fun to build up a portfolio, then apply showing your sample work even if you don't have the years of experience to qualify. I think a lot of dev leads and managers would hire you if you show that you're passionate about it, even if you don't have the years of experience.</comment>


Do Not Use Meson - <AUTHOR> https://www.rojtberg.net/1481/do-not-use-meson/ <comment><AUTHOR> I really like Meson, so I was surprised to stumble across this blog post. The author has a point about too many build tools and I really have never given used CMake because of the lack of clear documentation, but is better documentation all that CMake needs?</comment>


Hourly Billing is Nuts (book) - <AUTHOR> http://hourlybillingisnuts.com <comment><USER2> I highly recommend this book. The author, Jonathan Stark, really knows his stuff when it comes to pricing. His advice on value based pricing has changed the way I approach some parts of my business.

<comment><USER3> It comes across as one of those "we know the secret to losing weight", that then go on and on about how much better you'll feel once you lost weight. It never tells you how, only asking for your money in exchange for the secret.

I've done work fixed-priced work, hourly work, and product sales.

The most profitable of these has been on-site, short-term fixed-time contracts. That is, I go to a client's site for 1-2 weeks and work on a problem they have, customized for their site.

(I haven't done a subscription service, because I develop software for pharmaceutical R&D, and pharmas regard their data and even user queries to non-proprietary data sets as highly proprietary.)

I also know what my clients and customers in my field are willing to pay. Why should I believe that this author knows my field better than I do?

The link uses the phrase "effective hourly rate of $2000+ per hour". That "effective" is suspiciously hand-wavy. It's like saying that if I do 5 hours of sales and marketing work to sell a product for $10,000 that took me 1 year to develop, then the additional sales and marketing to get to that sale is "effectively" $2,000/hour.

It also reminds me of the guy who says he only works one hour per week, then to learn he spends his entire waking life hustling, but only calls part of it "work."

The link says: "As long as you bill yourself out by the hour, your clients will treat you as labor. Hired help. A pair of hands to be directed. "

WTF? This stinks of classism. We _are_ labor. We _are_ members of the working class. But master laborers from any field, whether carpenters, programmers, or rocket designers, are not "a pair of hands to be directed" any more than the VP of, say, a marketing company.

> "Right now, the book is a little over 100 pages"

I don't like that tally. When I look at the book pages screenshot with 111 pages, I see that 25 are single page chapter headings. It also looks like it has high line spacing and wide margins, which are common techniques to inflate the page count.

With that wariness in mind, would you care to explain what changed in your pricing model and why the other parts of the model didn't change? What is your "effective hourly rate", and what does "effective" mean to you?

<comment><USER4> Hi! Author here. Thanks for your comment :) I was preparing to answer your questions and then I read that you consider yourself a laborer. If you see yourself as a laboror, my book is definitely not for you. If at some point in the future you start to feel like you've maxed out your annual income and don't know what to do about it, you might want to revisit the idea of ditching hourly billing. Cheers! —J

<comment><USER3> It's clear now that you use "laborer" as a slur.

My extended family is not so far out of poverty that such class warfare snobbery appeals to me.

You are not using the normal definition of "laborer". Merriam-Webster defines it as "a person who does hard physical work for money". Wikipedia defines it as "a person who works in one of the construction trades, traditionally considered unskilled manual labor, as opposed to skilled labor."

Neither you nor I mean that definition of laborer.

I believe you use it as a metaphorical slur. Rather than use that interpretaion, I decided to use the more common Marxist analysis of calling those who labor, including skilled laborers like programmers, the proletariat.

Your secret sauce is likely to encourage people to become capitalists, perhaps a rentier capitalist, and thereby join the bourgeoisie class.

Marx pointed out the petite bourgeoisie, of which we are members for I both consult and sell software, are more likely to identify with the haute bourgeoisie; those who truly control capital. But I prefer to identify with craft-based workers (and unlike the old AFL policy, promote labor solidarity over trade separatism; though free education/training and strong social services).

Now, I agree with Piketty that capital return is greater than the rate of economic growth, so if your proposal is that people should become capitalists, the you are right. But we cannot all become capitalists. That's why, to resolve the dilemma of the categorical imperative, I support a progressive global wealth tax.

As an observation, many people running a con choose marks who already half- believe in the con. The ones who follow up on a Nigerian prince scam are those who want to believe. Your last paragraph follows the same lines of only trying to convince those who want to believe you are right. If my guess is correct, and since I don't think a Marxist analysis like this is flawed, I think it's a shame that you find yourself needing to use these tactics for something I don't think is a scam.

Rather than trying to understand your ideas through promotional materials, I hoped to get some input from jagthedrummer, who it seems has found that they are not applicable to part of a business. I'm curious to know both the success and failures. jagthedrummer? Care to speak up?, since the author thinks I'm not worthy of his time.

<comment><USER4> Dalke,

I see that I have insulted you and for that I am sorry. I doubt that there is much I can say in this medium to undo that damage other than to tell you that it was unintentional.

I really don't see the word "labor" as a slur but I do agree that I didn't use it in the strictest sense. To me, the word "laborer" equates to something like: "someone who is instructed by their employer what to do."

I don't begrudge or judge anyone who is comfortable with such an arrangement. If my words contained a tone of disdain, it's because I've absorbed the frustrations of literally hundreds of people who are not comfortable with such an arrangement.

My book is for folks - usually experts in their field - who are sick of their employers telling them what to do. Sick of being micromanaged, second-guessed, and generally disrespected by clients who have nothing but a checkbook and an opinion.

My impression from your previous comment is that you do not fall into this category, and therefore, my book would be useless to you. In retrospect, I do understand why you took offense and again I apologize for that.

Yours,

Jonathan</comment></comment></comment></comment></comment>


Giving teams freedom to structure their own time - <AUTHOR> https://www.madetech.com/news/giving-teams-freedom-to-structure-their-own-time <comment><USER2> Dead link.</comment>


Sample Data Files - <AUTHOR> https://people.sc.fsu.edu/~jburkardt/data/data.html <comment><USER2> Could be a useful resource.

Some of the links appear to be dead though: [https://people.sc.fsu.edu/~jburkardt/data/byu/byu.html](https://people.sc.fsu.edu/~jburkardt/data/byu/byu.html)</comment>


The Great PC RAM Swindle - <AUTHOR> http://www.appleinsider.com/articles/08/09/03/road_to_mac_os_x_snow_leopard_64_bits_santa_rosa_and_the_great_pc_swindle.html

<comment><USER2> Really old news, sensationalist headline for a crappy biased article. Microsoft have been moving forward towards 64-bit for a while, although they arguably should offer 64-bit as default on new builds, and a large proportion of people run 64-bit Linux.

Apple offered upgrades to 4gb of memory without explaining the disadvantages and Mac OS X Tiger showed the amount of physical memory rather than the amount addressable - <http://forums.macrumors.com/showthread.php?t=364707> \- why is it a "swindle" when Dell do it but not when Apple do it?

<comment><USER3> Actually, a tiny _proportion_ of people run 64-bit Linux.

<comment><USER4> I'd actually say its easier to run 64-bit Vista than Linux due to the fact that people often ship binaries for Windows that seem to work whereas the SOs in Linux leave you with a mixed-mode install. Sigh.

<comment><USER5> The biggest problem I ran into with this was that earlier versions of package managers didn't handle multiple arches installed on the same system very well (claims of package conflicts due to the names being the same, things like that). That seems to have been fixed or is being worked on.

<comment><USER4> My honest response is I don't know what the current state of the world is like in 64bit land.

My one experience was deeply frightening (what do you mean I can't listen to music without having to maintain a 32bit userland?)

</comment></comment></comment></comment></comment><comment><USER6> If there is no 32-bit version of Mac OS X Leopard, then why does it need the 8gb hack at all?

And why does Microsoft still sell 32-bit Windows?

<comment><USER7> Maybe why needs an 8gb hack:

"Currently, Mac OS X Leopard hosts both 32-bit and 64-bit apps on top of a 32-bit kernel (below). Using PAE, the 32-bit kernel can address 32GB of RAM in the Mac Pro and Xserve; Apple's consumer machines only support 4GB RAM, but unlike 32-bit operating systems they can use the entire 4GB (with appropriate hardware support). Leopard's 32-bit kernel enabled Apple to ship 64-bit development tools to give coders the ability to build applications that can work with huge data sets in a 64-bit virtual memory space (and port over existing 64-bit code), without also requiring an immediate upgrade to all of Mac OS X's drivers and other kernel-level extensions. That transition will happen with Snow Leopard." [http://www.appleinsider.com/articles/08/08/26/road_to_mac_os...](http://www.appleinsider.com/articles/08/08/26/road_to_mac_os_x_10_6_snow_leopard_64_bits.html&page=3)

I don't know if this is right, but it caught my attention when I read it.

</comment></comment><comment><USER8> They seem to hype the whole 64-bit stuff a lot. I've had a full 64-bit Gentoo running for quite year and the difference to 32-bit wasn't even noticeable.

<comment><USER9> Running what?

Unless you're doing CAD, 3D or video editing, 64-bit on the desktop is just for bragging.

<comment><USER10> well he said gentoo, so i guess that means running gcc.

<comment><USER9> Over and over and over again... :-P</comment></comment></comment></comment>


Startup generation ready to fix economy - msnbc.com - <AUTHOR> http://www.msnbc.msn.com/id/43976881/ns/business-eye_on_the_economy/ <comment><USER2> We need to encourage entrepreneurs of all ages who want to start all types of businesses.

For example, a friend of ours started a business creating fantastic pastries and desserts for restaurants. Her company will never go public. But she employs 8 or 9 people who probably never would be hired by a tech startup.

A couple of the big obstacles to starting a business need to be addressed:

1\. Healthcare - our friend wouldn't have started her business if she didn't have coverage through her husband's employer. She couldn't afford the financial risk.

2\. Intellectual property laws are a mess. Everyone on HN already knows about the patent fiasco, but the continual and unjustified extension of copyright law also presents an obstacle for some endeavors.

<comment><USER3> "She couldn't afford the financial risk"

If you are under thirty and single, you can get health care for $200 or less per month, which is pretty affordable. There are also group plans for small business owners.

<comment><USER4> Unless you can't get anyone to offer you coverage which is pretty common.

</comment></comment></comment><comment><USER5> If we want to save the economy it starts by congress realizing they allocate capital poorly and should stop doing it.

"One element would be a program to forgive student loans and debt for young entrepreneurs, which he says would address a major hindrance to recent graduates who want to set up their own shop."

This is silly, either everyone owes their debts, or they don't. It's tantamount to pushing your student loan debt onto everyone else and reducing the risk that the lendee has by spreading it to everyone else. If you want to have the reward of starting a business then you need to take the risk, otherwise society should also get the profits from the business. (eg. when you sign the document saying your loans are forgiven then the people get 90% of their company because they are taking all the risk).

The idea that a Harvard grad should be bailed out by a person making minimum wage so they can be risk free enough to start a business is ludicrous. If someone was so stupid to agree to take on debts that can't be bankrupted to the degree that they can't rent servers for free from Amazon, Google, Microsoft, et al, then they deserve what they got coming to them. Bailing these people out at 22 will lead to the next generation of too big to fail companies that can't manage a balance sheet, nor understand the different types of debt and the legal obligations that come with them.

<comment><USER6> I agree it would make more sense for the next generation of students to seriously consider alternatives to certain overpriced educational institutions.

On the other hand, with the printing press at maximum, now is a good time to have debt.</comment></comment>


RubyConf; Why You Should Go Next Year and How to Convince Your Boss - <AUTHOR> https://medium.com/on-coding/2f0da4944d9a

<comment><USER2> I'm not a fan of conferences, but I'd pay 1600 to meet Yukihiro. Well written, my buddy just forwarded it to his boss.

Can you describe byebug in short detail? / like a tagline?

<comment><AUTHOR> Debugging in Ruby 2</comment></comment>