Helptext.js - <AUTHOR> http://luckydev.github.com/helptext.js/ jQuery plugin to have help text in the form elements <comment><USER2> Why wouldn't you use the placeholder, attribute, then detect support, then use a fallback if needed... Something like:

function hasPlaceholder() { var input = document.createElement('input'); return ('placeholder' in input); }

should do the job to detect support.

<comment><USER3> Was thinking the exact same thing - placeHolder support is native with HTML5 spec - so better to utilize the 'future' and rollback for IE<9

[http://dev.w3.org/html5/spec/Overview.html#the- placeholder-a...](http://dev.w3.org/html5/spec/Overview.html#the-placeholder- attribute)

</comment></comment><comment><USER4> Not sure why... in-field labels are a better approach. <http://bit.ly/r4vVAa> Plus the placeholder attribute is the long term.

</comment><comment><USER5> What if I want my password field to say 'password', and on focus to be obscured with dots?</comment>


Competing With Silicon Valley's Cushy Benefits - <AUTHOR> http://simplicity.laserfiche.com/content/competing-silicon-valleys-cushy-benefits

<comment><USER2> "Todd Carlisle, director of staffing at Google, told a panel at the Inforum conference...that no job applicants ask about work perks, and no one turns down a job based on what perks are available."

That's not true at all. I terminated my interview process with Google because they would not commit to very simple benefit requirements (ie: would I keep my same level of benefits if I change product teams; am I required to use the doctor office closest to the job site or am I free to choose my own; who pays for the hardware/software to do the job; can I roll a 401k into the company provided 401k and does the company 401k allow to be transferred if I leave Google).

As for Google "gourmet" food - nobody in their right mind cares if HR hands out vending machine token for muffins with "gourmet" on the wrapper. But show me a company that can successfully respond to the above issues and they'll have no problem hiring - and no one terminating the process.

</comment><comment><USER3> _Todd Carlisle, director of staffing at Google, told a panel at the Inforum conference...that no job applicants ask about work perks, and no one turns down a job based on what perks are available._

It is possible that no applicants need to ask because they are already familiar with the perks Google offers. I recently turned down a very generous job offer when I found out the hours were very rigid and the dress code strictly enforced.

I wish there were a site like Glassdoor that detailed the perks offered at various companies. I'd like to know upfront what the dress code is, what hours employees are expected to work, how many vacation and sick days are offered, what holidays are observed, what the 401k match is, and what health insurance plans there are, etc.

<comment><USER4> I totally agree.

Take one of the obvious benefits, for instance: Health insurance. There's a big difference between the cost of insurance you get at a big company (one employer covered _two_ sets of glasses per person per year!) and what comes with the health benefits from a smaller firm (my spouse's company has a reasonably affordable plan, but we have a $12,000 deductable... which we hope to never need to use up).

There are other tradeoffs, of course, and he loves his job so he isn't looking, but the point is that you don't know what the benefits are, going in. They are absolutely part of the compensation package a developer (or anyone else) has to consider, but nobody willingly offers the details until the job offer is on the table, or until Day 1 on the new job.

Some of these things are negotiable, so I can understand why they rarely are mentioned. For instance I had some CIOs recommend that in salary negotiations, if the company balks on more money you can ask for a third week of vacation and usually get a Yes.

But yeah, I'd like it if Glassdoor collected such data!

<comment><USER3> Health insurance is an even bigger factor once you consider kids. I went to work for a startup which at the time I joined did not offer health insurance. I was able to do that mainly because my wife's plan covers her, a spouse, and all dependents, free of charge. Now that my company offers health coverage, it is free for me, but a spouse would be ~$200/mo and dependents ~$400/mo. If you have a spouse and 2 kids, you'd be looking at $1000/mo difference between the two companies.

</comment></comment></comment><comment><USER5> _the unlimited vacation, aside from being a perk, is an attempted way around California's laws on vacation. It keeps companies from piling up liabilities -- which the company has to pay out when the employee leaves -- from all the vacation employees are accumulating and not being able to take because the hours are so arduous._

Any lawyers care to comment on this?</comment>


Biomass for energy might be both a sustainable and economical scenario. - <AUTHOR> http://esciencenews.com/articles/2008/12/15/turning.over.a.new.leaf.future.energy.supplies

<comment><USER2> Is there anything such as true sustainability? If we assume the premise that perpetual motion machines are not possible, and hence all energy sources are eventually depleted, then what is the definition of sustainability in a practical sense? Is it until our sun supernovas? Until we destroy ourselves through war? Until we decide having children no longer suits our lifestyles? I keep seeing this word put out as some achievable concept when nobody seems to have defined it in any way that I can see that takes into account the ultimate reality of physics and I have wonder if I've gone mad or if maybe I'm truly missing something. I mean do people really think sustainability, in the sense of a perpetual, clean, energy source is actually achievable or do most people realize that ultimately it is impossible but use the term anyway as a mis-used but simple and useful term rather than something like hyper-efficient or something else?

<comment><USER3> As you say, yes, if you _really_ sit down and think about it, it's a tricky concept.

My conclusion: It's all about the energy, and to a lesser extent, atoms. With sufficient energy and the right atoms, we can make anything we may wish to consume. With sufficient energy and technology we may even be able to fiddle with atoms to some extent.

Therefore, "sustainable" technology is when we can survive on less energy than we can bring in for the given time period, and on fewer atoms than we can bring in for the given time.

We are taking both out of the Earth at a fantastic rate, which isn't as bad as it sounds because the Earth (not to mention the universe) is freakin' huge and awash in both energy and atoms in the general sense. (The Universe is young.) What we run short on is two things: _cheap_ atoms and energy, and _complicated_ atomic configurations, particularly "food". In the case of some particular atoms, we can run out of those relatively soon (like palladium), but those are generally substitutable to some acceptable extent with other atoms and energy.

Our current issues with inefficient and dangerous atom extraction and extraction of cheap energy from the Earth is an aberration, albeit a multi- century one that is still going strong. Long-term, there are only two solutions: To live with the meager resources that nature will provide us, which is to say, to live like savages, or to develop a nanotechnology so powerful that with the input of relatively small amounts of energy, a life form can be sustained. There's a low solution and is almost certainly a high solution; the middle solution (modern technology) is, as you intimate, _not_ long-term sustainable no matter what we do. It does not matter how much we recycle or conserve or reuse, it doesn't matter if we drive Priuses or Hummers, this can't last.

It _can_ , however, extend the time frame we have to develop high technology, and given the various outcomes which I won't take the time to enumerate, it is almost certainly a good idea, as long as it doesn't hurt research into high technology. So even though what we currently call "sustainability" isn't, it does directly contribute to eventual sustainability by extending the time frame we have to develop it.

Personally, I think the only limit for nanotechnology is ultimate physical limits, I see no great impediment remaining but time and effort. But I don't think anything less than a technology that can sustain a high-tech civilization truly indefinitely with only an energy input is truly "sustainable".

I observe that if you look at the problem like this, a lot of things promoted in the name of sustainability actually harm our prospects of such technology.

</comment></comment><comment><AUTHOR> The gotcha:

> The authors do concede that new technologies will be required to convert the > chemical energy stored in biomass to electrical energy more efficiently.

<comment><USER4> Worse, this technology will create stronger incentives to pillage the remaining natural forests.</comment></comment>


Productivity Techniques to Achieve Success - <AUTHOR> https://thinkandgrowentrepreneur.com/productivity-techniques-to-achieve-success/?ref=hackernews <comment><AUTHOR> Wrote this post while reflecting on my past productivity binge. Trying to find the best solution for me</comment>


The Not-So-Surprising Survival of Foursquare - <AUTHOR> http://www.newyorker.com/business/currency/the-not-so-surprising-survival-of-foursquare <comment><USER2> I had never thought _that_ would be the data Foursquare would profit from. Enhanced location data... Interesting read.</comment>


Computer Scientists Find Bias in Algorithms - <AUTHOR> http://spectrum.ieee.org/tech-talk/computing/software/computer-scientists-find-bias-in-algorithms <comment><USER2> First, some definitions:

Equality of opportunity: everyone takes the same test, outcome is dependent on individual, even if the group containning that individual scores differently than other groups

Equality of outcomes: everyone takes the same test, but the individuals scores are weighted based on the group of which they are a member, so that representation of groups is equivalent across all groups.

Further, we can separate bias in terms of intentional and unintentional, where the former indicates direct manipulation of selection criteria in order to change group outcomes to match the manipulator's desires. The latter occurs when systematic bias affects the individual's scores, such as when a particular group has less access to educational opportunities.

The article values equality of outcomes, by encouraging algorithms to take into account the individual's group when performing selection. But in cases of unintentional bias, this can mask problems. In the long term, it would be more beneficial to ensure groups have equal access to education than to upwardly adjust their scores.

In fact, this upward bias to adjust for perceived unintentional lowered outcomes can in fact perpetuate the initial biases: the message is that a particular group underperforms, and thus _needs_ extra help.

</comment><comment><USER3> This is totally ridiculous. All it does is remove the useful data from the dataset and makes it's predictions worse.

Imagine are using an algorithm to predict how likely someone is to pay back a loan, or make an insurance claim, or perform as an employee, etc. Things like their grades or education would correlate with that. but it might also correlate with race or gender, so the algorithm would be labelled "racist" and "sexist".

Even though it has nothing to do with racism whatsoever. A white person and a black person with the same education would get exactly the same result. The algorithm is totally fair and meritorious.

The true solution would be to condition on the race or sex. So the algorithm predicts the probability they will be paid back _given_ that they are male or female. Then in production you average the results of each possible sex and race together.

So if women were really better drivers than men, they would still pay the same rate. The algorithm would know that they are better drivers, but it would treat everyone gender neutral. But it would still take into account education or other variables.

Although it's not clear to me why you would want to do this. If men really are more risky drivers than women, they should pay more. And they do. If they really are less likely to pay back a loan, then they should have a higher interest rate.

In any case, humans make decisions about stuff like this all the time and they are way, way, worse and more biased. In most cases very simple statistics vastly outperform the best humans: [http://lesswrong.com/lw/3gv/statistical_prediction_rules_out...](http://lesswrong.com/lw/3gv/statistical_prediction_rules_outperform_expert/)

</comment><comment><USER4> "If the test results show that the algorithm under question can distinguish attributes—like whether a data point represents a male or female—then it's labeled biased. The other algorithm the researchers introduced tries to remedy the bias by modifying the actual data set so that any selection algorithm would deliver fair results. The algorithm does this by blurring attributes that may be correlated to, say, race or gender."

So if you're testing construction workers, you identify bias, then you select strength as the variable causing bias, and you adjust the strength values of the dataset or force the algorithm to devalue strength?

Racism/sexism are real and we need new ways to fight them, but this is like a right wing satire of affirmative action.

<comment><USER5> I think the desirability of eliminating this kind of bias depends on the context of the problem that the algorithm would be used to solve. Per your example, suppose that strength is what an algorithm is _predicting_. We might not want the algorithm to lowball the strength of a candidate just because that candidate "looks like a woman" due to some other causally unrelated correlation.

<comment><USER4> Sure, and I agree. But that's not what they're doing here. Paper is available online:

[http://arxiv.org/pdf/1412.3756v3.pdf](http://arxiv.org/pdf/1412.3756v3.pdf)

</comment></comment></comment><comment><USER6> The basis of the argument is that if decisions correlate with race, than the cause of the decision is race. This is of course wrong. Correlation does not imply causation and the algorithms cannot even have a concept of race or sex unless that data is deliberately and explicitly placed into the data set.

A realistic complaint would be that these algorithms dehumanize people and create a weird algorithm based bureaucracy that mimics The Trial.

Maybe someone is trying to conflate the two arguments so they can dismiss the second one by pretending it's the first?</comment>


Apple Store display in London - <AUTHOR> https://vid.me/XwoP

<comment><USER2> Magnets under the table I imagine?

<comment><USER3> Definitely magnets moving under the table. I used to put together a ton of window displays when I was on the visuals team at an Apple Store and it was the best part of the job.

</comment></comment><comment><USER4> I happened to see this in Bellevue, Washington today as well. I was in a rush though so I didn't get to stop and look at how it worked. I actually assumed it was just fishing line. It served the correct purpose though of catching my eye in a store where I normally just walk straight past.

<comment><USER5> The cases are magnetic,you wouldnt be able to get that kind of fluidity with a string

</comment></comment><comment><USER6> I've seen this at 2 Apple shops in Vic, Aus too.

</comment><comment><USER7> Pretty rad

</comment><comment><USER8> The most interesting thing I've seen about Apple this past year, which is telling.

<comment><USER9> A flashy shop display is more interesting than a new programming language for the platform?

I think that says more about you than it does Apple.

<comment><USER10> I imagine it says that he is a consumer?</comment></comment></comment>


The "C is Efficient" Language Fallacy - <AUTHOR> http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php <comment><USER2> This argument is as old as the hills. It's probably true in a lot of niche situations. But the fact is, most C code is faster than higher-level language code, because:

* C programmers have more freedom to arrange data in memory to exploit locality

* C data structures need less bookkeeping

* C programs manage memory manually, and so lack GC overhead

* C programs can easily swap in different allocators for different work sets

* C function calls are usually wired into the code, not indirected through (several layers of) tables.

That's to say nothing of bytecode interpretation overhead, which is probably a straw-man argument.

I buy the instruction scheduling argument for inner-loop numerical and vector scenarios, but even in performant code, that's usually less than 10% of the total, and from what I've seen, both C and HLL code tends to delegate that to machine-specific assembly libraries.

<comment><AUTHOR> While I don't have enough experience in _really_ low-level tuning, I know that sometimes people get so focused on optimizing their current implementation that they fail to see that their overall design has trapped them in a local maxima. Problems like inappropriate algorithms are usually more obvious in higher level languages, because there's less detail obscuring them. That stuff needs to be right before getting to fine tuning. (Prototyping in another language first helps.)

C and C++ are quite fast locally, but sometimes that works against being fast overall.

<comment><USER3> The standard approach I heard was to code in a very high level language (like python) to get the algorithms right, then rewrite in C for performance. Python then becomes a sort drawing board as part of the design stage, instead of "coding".

<comment><USER4> Rewrite only those pieces that are consuming a lot of time or memory, leave the rest in Python, which is particularly good at integration with C/C++. Many programs are a lot of setup, error handling, and edge cases where performance is not an issue. but LOC is.

<comment><USER3> I thought about including the idea of only rewriting the hotspots, but left it out as detracting from the main point and it seemed tedious to iterate the details. But then there are 3 replies pointing this out, and which seem to be more valued than mine by the community (according to their votes.)

Ask HN: Does this mean that HN would prefer I wrote comments that do cover all the cases, instead of just sticking to the key point? Or is it just that there seemed to be a gap in my comment, which people naturally wanted to cover?

Note: the replies add more than just "rewrite only hotspots" (like the above one detailing setup, errors, edge cases), and I certainly appreciate extra details being filled in. Is the valuable extra detail the reason for the extra votes? I just feel kind of annoyed that the replies seem to suggest I was stupid in not mentioning the hotspot idea. This has happened to me a few times now. Am I taking it too personally? Is it just a question of different opinions on what is important? Or is it just that I failed to communicate my decision, and then get annoyed when people point out the other branch of the decision?

There is a issue of preference here: I prefer to keep all the code in one language. One factor in this is that my projects are small, and for these, the overhead of switching languages and managing the different source isn't worth it. I'm not running up against efficiency problems either. I'm sure it's different for larger projects, especially multi-person ones, and particularly if the project covers different kinds of activities (for which different languages are suitable), and even more so if there's need to integrate with or reuse existing assets in different languages.

Thanks for any clarifications you may have. :-)

<comment><AUTHOR> > I just feel kind of annoyed that the replies seem to suggest I was stupid in > not mentioning the hotspot idea.

I didn't mean anything personal, and I don't read any of the other comments that way.

The other comments may have just been voted up by people who also like Lua or Mercurial, or something. I thought it was worth noting that Lua was explicitly designed for that style of development. (Lua's also my favorite language.)

<comment><USER3> Thanks. Yes, that's true. I appreciate the information about Lua and an example of Mercurial - it was just the hotspot part. I guess the fairest guess is that a comment is voted up as a whole, based on _all_ the things they add, not just the part that I happen to be concerned about. It seems a bit silly of me now, but I much appreciate your reply.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Fortran's (alleged) dominance in scientific is probably attributable to tradition (they still teach it to undergrads in non-CS departments) but the native multidimensional arrays have a much bigger impact than aliasing. In Fortran you just index your array like A(i,j,k) and the compiler will compute (and optimize) the addressing for you. In C, a typical (non-computer) scientist who doesn't really focus on mundane shit like this will end up writing something like

        for ( int i=0; i<ni; ++i )
        for ( int j=0; j<nj; ++j )
        for ( int k=0; k<nk; ++k ) {
           a[ k*ni*nj + j*ni + i ] = ...
        }

which sucks. Optimizing multidimensional array access (which characterizes most of scientific computing) is much easier for a Fortran compiler.

<comment><USER6> This looks like a lot of calcs for the inner loop but is quite easily optimized. The compiler knows that (j * ni + i) is constant in the k loop and that ni * nj is constant. Check the assembly output. But it is probably better to reorder the loops and traverse linearly through memory so that each cache line brought down is fully consumed in order.

<comment><USER7> The point of that code example is not the calculations, but accessing memory in a cache-friendly way.

<comment><USER5> Well, yeah, but since Fortran stores things in column-major that's not really an issue. My broader point was that all of these details are hidden from programmers, so there's less for the programmer to screw up and more room for the compiler to work within.

</comment></comment></comment></comment><comment><USER3> _Java: 1 minute 20 seconds._

 _About a year later, testing a new JIT for Java, the Java time was down to 0.7 seconds_

I've been surprised at the speed of Java recently. I wonder how much improvement is left in dynamic compilation.

 _The HP project Dynamo was an experimental JIT compiler where the bytecode format and the machine code format were of the same type; the system turned HPA-8000 machine code into HPA-8000 machine code. Counterintuitively, this resulted in speed ups, in some cases of 30% since doing this permitted optimisations at the machine code level. For example inlining code for better cache usage and optimizations of calls to dynamic libraries and many other run-time optimizations which conventional compilers are not able to attempt._ <http://en.wikipedia.org/wiki/Just-in-time_compilation>

<comment><USER8> Time-space trade-off. Meaning Java uses a lot of memory for almost anything. Speed isn't everything.

<comment><USER9> Sometimes memory can cost speed as well.

I find with java essentially you are amortising gains which are payed back with GC at a later date (in many cases I guess it is worth it).

Its not one size fits all !

<comment><USER10> This sounds like it had less to do with Java and more to do with a large number of short-lived allocations in your design. A garbage collector can be abused in any language that has one.

</comment></comment></comment></comment><comment><USER11> I worked on VMware's virtual machine monitor from 2000 until June. Overcoming customers' performance fears was a major impediment in the early years. Every fraction of a percent we gave up relative to native ruled out whole classes of applications. Nothing other than C would have been conceivable. Even C++ would have been wildly inappropriate, as it is for most kernels, because so much invisible code can hide behind a close-brace.

The mapping from source to machine representation in C is relatively trivial, which is the source of all C's ups and downs. If you ever plan to count microseconds, cache misses, TLB misses, mispredicted branches, etc., you had better start with a toolchain whose machine-level output is grokable from the source.

</comment><comment><USER12> Read the comments: turns out the author was ignorant of C++ templates (including Blitz++ scientific computing library) and he was lumping C and C++ together in his "benchmarks".

It always annoys me when clueless people judge a language they don't even understand.

Repeat after me: there is no such thing as C/C++.

<comment><USER13> > turns out the author was ignorant of C++ templates

I believe you actually meant 'ignorant of C++ template metaprogramming techniques'. The author seems well aware of C++ templates and even says:

>> the thing I coded immediately before the Stellation experiments was a very hairy template analysis for a C++ compiler

>he was lumping C and C++ together in his "benchmarks".

I couldn't see where, could you point out which comment leads to that inference?

</comment></comment><comment><USER14> Always remember that the total time between you having a problem, and you achieving results, includes the coding (and recoding) time, _and_ the run time. There's a tendency for people to ignore "slow" languages because they focus only on the runtime.

I am well aware that there are good reasons to optimize things in languages like C (and I use them), but consider...

If I take several extra _weeks_ to code, debug and test a C solution, and I could have had a script done much sooner, then my results were not faster overall. Why? Well, the script could be slow as dirt, but if it has a few extra weeks to churn through data and produce results, it may be done before the C program is even ready.

It's also important to remember that not all bugs are in software. Suppose I was looking at an entire problem in the wrong way, and this wasn't apparent until I started seeing results? In that case, my earlier start with a "slow" program meant that this mistake was found much sooner, so the script can be thrown out and redone, producing _correct_ results with not much of a time penalty.

<comment><USER15> Also, thought I would mention the fact that if you take a day to write a slow program that takes a week to run, that's cheaper than spending a week writing a fast program that finishes in a day. After all, your time is much more expensive than the computer's!

<comment><USER16> You're both making a pretty odd assumption here, which is that a program typically runs exactly once and that I am the only user of my own program.

Users' time is also much more expensive than the computer's. That's why we write software in the first place.

<comment><USER14> No, I expect my scripts to run for a long time with many users. This doesn't preclude optimization; some of it is automatic (new hardware, interpreter library improvements), some of it is well established (using SWIG and C to replace only a _tiny piece_ of the program that must be faster).

In some respects, having long-lived software with lots of users makes speed the least of my concerns, because they're always asking for new features, and those are relatively easy to add to scripts.

And the relationship between software speed and productivity isn't linear, because people multitask. If a program takes 10 seconds to run, I might sit and wait for it to complete, without doing anything else. Whereas, if the program takes a minute, I may decide to switch to another quick task, and then return to see results. In this case, both tasks needed to be done, one took longer _but_ it ate up the "slow" runtime of the program, and was only parallelized because of that long runtime.

<comment><USER16> I was referring to this statement: "Well, the script could be slow as dirt, but if it has a few extra weeks to churn through data and produce results, it may be done before the C program is even ready."

The comparison of development times and running times simply makes no sense if you assume the script is going to run a 1000 times. I agree that this relationship isn't linear. That's exactly why it's pointless to compare the the two numbers as if it were. The only number that is comparable is probably the profit you make in each case.

<comment><USER15> Yes, good point. I guess he was referring more to the scientific end of things, where you write a program that runs for days on massive data, and there really isn't a user

</comment></comment></comment></comment></comment></comment><comment><USER17> Much as I take his overall point - that a close to the metal language is not always best for performance - the author would be well advised to take a look at the C99 restrict keyword.

<comment><USER18> Just looked it up... looks like you're right. The whole blog post is nonsense.

<comment><USER19> Just asking, does currently available compilers support restrict? (or C99 standards)?

I use msvc mostly and gcc sometimes.

<comment><USER17> gcc certainly does (use -std=c99). If you don't want to use C99, use __restrict__ to use it as a gcc extension. This is C-specific - I don't believe a similar standard has worked its way into C++ yet, although compilers may have extensions that support it. I don't know about msvc, I'm afraid.

GCC's C99 implementation is mostly complete - you can find out more here: <http://gcc.gnu.org/c99status.html>

</comment></comment></comment></comment><comment><USER20> I think a large part of the "C is Efficient" fallacy/truth is that C is more predictable with its assembly output than HLLs. Since ultimately all programs are converted to machine instructions at some point, you will always be able to write machine instructions that are at least as efficient.

The test lies in the ability of the programmer to do so.

</comment><comment><USER21> Reminds me of The Practice Of Programming, by Kernighan and Pike, a truly excellent book. They cover some of the bum steers of C efficiency quite well there. A classic.

</comment><comment><USER22> One issue that I see is that they only (seem) to compare with gcc, which is not particularly good. It would be better to compare against something like icc, which has better register coloring, SIMD support, etc.

This might redeem C a little.

However, the real reason C will not go away any time soon is that there is no replacement for low-level software yet. Nothing eles has quite the same minimal dependencies.

<comment><USER5> GCC C vs Intel Fortran : [http://shootout.alioth.debian.org/u64/benchmark.php?test=all...](http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gcc&lang2=ifc&box=1)

Intel C vs Intel Fortran : [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...](http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=icc&lang2=ifc&box=1)

(I'm not even going to link to the GCC Fortran benchmarks. They're embarrassing.)

C is no slower than Fortran on any of those benchmarks, and on some it cleans Fortran's clock. The aliasing issue is the only thing Fortran has going in its favor, but clearly its not ubiquitous. The n-body benchmark, for instance, is fairly typical numerical code. You might even think, since it's simultaneously reading and writing through multiple pointers of the same type, that aliasing is an issue, but its not. And in the rare case that it becomes an issue, there's compiler hints (e.g. C99 restrict) for that.

Picking Fortran over C solely because of aliasing worries is premature optimization of the worst kind.

<comment><USER22> This matches with my experiences with ICC doing kernel development. It would vectorize loops and break out the SIMD instructions where gcc would not.

It was quite strange the first time looking through the objdump seeing things like punpwlkd and xmm.

And then discovering what -fast would do to things (it makes icc look at your whole program to optimize, so it does things like ignore CDECL and uses whatever registers it can.

</comment></comment></comment><comment><USER23> For the given example code the answer is to use the underlying SIMD types and intrinsic instructions. If you're on Intel or PowerPC then the SSE or Altivec registers and instructions are available. Use them and you'll beat any compiler optimization every time. And, most importantly, the chances that up- to-date SIMD types and intrinsics will be available in any language _but_ C/C++ is vanishingly small. Java, Ocaml, Haskell... you name it, you can't properly use SIMD (AFAIK... please let me know if there are exceptions).

And if you're application doesn't fit the native SIMD properly, there's no chance the compiler can really do anything meaningful with it anyway.

<comment><USER24> Some quick googling suggests you are wrong:

[http://www.cas.mcmaster.ca/~kahl/Publications/TR/Anand- Kahl-...](http://www.cas.mcmaster.ca/~kahl/Publications/TR/Anand- Kahl-2007a_DSL/)

[http://wwwlasmea.univ- bpclermont.fr/Personnel/Jocelyn.Serot/...](http://wwwlasmea.univ- bpclermont.fr/Personnel/Jocelyn.Serot/camlg4.html)

<http://tirania.org/blog/archive/2008/Nov-03.html>

etc.

<comment><USER23> I would suggest taking a closer look at those links. They bring up another point in that you'll only find current, usable, robust support for SIMD in C++:

The first link is just a paper; the second is a 1.0 release that is seven years old, it only supports SSE, and it's all in French; the third is only for Mono, it only supports SSE and its SSE support is old and incomplete.

On the other hand, if you try to use SIMD types and intrinsics in C++ you'll find current and comprehensive support from the major compilers on all SIMD platforms.

(I'd love to use a current and comprehensive version of Haskell SIMD, but its just not ready for prime time.)

<comment><USER24> _(I'd love to use a current and comprehensive version of Haskell SIMD, but its just not ready for prime time.)_

Since you're obviously an expert in the area, why aren't you helping make it ready for prime time?

<comment><USER7> That's really not fair. I know of many things in and outside of my area of research that need improvement, as does any researcher. But we can only work on one thing at a time.

</comment></comment></comment></comment></comment><comment><USER25> I disagree with some of the Authors points.

The language is a tool, the efficiency of it really depends on how the programmer who designs and implements a program. You can have a horrible coder write something in C that would be very slow and inefficient, and given the same problem to good programmer and you can arrive at a faster and more efficient result using a bash script.

The reason why lot of people (including my self) believe that C/C++ is a high performance language is not because it fast for all applications, but gives the programmer more control instead of leaving all the fine details to the compiler to second guess. (@tptacek's reasons are perfect for this).

<comment><USER17> ...except that in this case, when you take full control of the memory management, you slow things down. The problem with using pointers (without using the restrict keyword) is that it can seriously impede out of order processing on modern CPUs. Now, the author has missed the existence of the restrict keyword in C99, but in the absence of that his point is good.

</comment></comment><comment><USER26> The arguments about language efficiency on a single processor machine are probably outdated today. Most machines have multiple cores. We need good tools which can exploit this CPU architecture. Languages like C/C++ place a large amount of responsibility on the shoulders of a programmer. Effectively, you are writing two programs - one for the task at hand, and the other is memory allocation for it. Control does not always give speedup, also it is not always a boon. It implies managing the different resources on your own. In a large scale application, this is not a great idea. GC is a good alternative over Malloc and Free'ing when the size of the application gets huge.

Also, the scalability of a single system is limited. If you really need extra speed, I think going parallel is the key. Most numerical methods are parallelizable. And C/C++ were not created keeping this mind. It can be a programmer's nightmare to debug multiple threads with memory leaks. Languages like Java do make this task easier using programming paradigms like Map/Reduce.

<comment><USER27> It doesn't make sense to use mapreduce as an example of Java making parallelism easier, given that the original Google MapReduce is a C++ framework.

</comment></comment><comment><USER28> The debate seems to be between trusting your compiler to generate good code or writing close-to-metal code yourself.

There might be a third option though - code generation in a HLL. Coconut is a nice example of this:

[http://www.youtube.com/watch?gl=GB&hl=en- GB&v=yHd0u6...](http://www.youtube.com/watch?gl=GB&hl=en-GB&v=yHd0u6zuWdw)

Instead the compiler being a black box, Coconut is structured as a set of libraries for code generation, analysis and optimisation. They report outperforming c SIMD by up to 4x on the cell architecture.

</comment><comment><USER29> Where is the "Assembly is Efficient" Language Fallacy article?

</comment><comment><USER30> "In C and C++, there's no such thing as an array - there's just pointers, which you can subscript and a shorthand for pointer arithmetic and indirection(x[n] in C/C++ is the same thing as _(x+n).)"

Please remember that "char x[N];" and "char _x = malloc(N);" are NOT the same. (Not sure if this is news to anyone, but when I was learning C reading that would have made me think otherwise).

</comment><comment><USER31> He's absolutely right about pointer aliasing. I work on a DSP compiler for architectures strongly geared towards instruction-level parallelism, and when the compiler occurs pointers that may alias (but probably won't, but we can't tell because of the language's liberal use of pointers), many optimizations have to be a lot more conservative.

</comment><comment><USER32> C is one of the fastest languages and most space-efficient languages out of the box. Other languages get their speed by resource trading (memory, space, time). You could arguably gain these sort of speed ups in C if you invested enough time in writing a VM or JIT-ing/dynamic compiler to host your C program.

</comment><comment><USER33> C works in CUDA and OpenCL - which for scientific programming is the fastest thing there is.

The GPU is used with C.

C isn't faster than hand coded assembler on cpus... but is pretty damn quick.

There are specialist compilers for C, like vector C etc.

anyway... whatever. back to typing text into a file now.

<comment><USER34> CUDA and OpenCL have C syntax, but they are not C.

</comment></comment><comment><USER35> This is an interesting article, but I believe that the benchmarks should be updated since a ton of progress has been made in compilers and how they handle aliasing.

</comment><comment><USER36> <http://news.ycombinator.com/item?id=591897>

</comment><comment><USER37> I remember reading this article years ago :)

</comment><comment><USER38> Regarding the discussion of "real" arrays in Fortran vs. "pointer arrays" in c, it seems in the real world often we need resizable arrays, which means the only way to do that is to have pointer arrays. A Fortran array cannot be resized. What if I want to read in a tab delimted file that has ints, and read that into a 2-D matrix, where the matrix rows correspond to the file rows, and the matrix columns correspond to the tab delimited columns in the file. And I have say no idea how big the file is. So the only way I can do this is to have a resizable array. I can "guess" that say my rows/columns won't be more than some arbitrarily large number, but then I likely end up wasting a lot of space. So out of curiousity how would I even do that with "real arrays"? Seems like if I ever need to resize an array, even in just as simple an example as reading in a file, then I need a pointer array, since "real" (fortran-like) arrays will not resize. Am I missing something here?

</comment><comment><USER39> In most cases manually cooked food is much cheaper and more healthy than purchased one, if you can cook. The same is correct for C/C++ programming in terms of execution speed and resource usage if you have knowledge and experience.

btw, JVM is mere a c++ code.</comment>


Open Letter to sites with annoying interfaces - <AUTHOR> http://bitonic.org/blog/?p=176 <comment><USER2> Thanks so much for this article. Hidden interface elements that only appear when hovering over a secret spot like it's some kind of easter egg is one of the most frustrating things I have seen. It's not really user interface _design_ so much as it is user interface _abject failure and total ignorance of how interfaces work_. I refuse to call anything so dysfunctional design!

This has been sneaking into desktop application interfaces also for about 5 years now.

There's no problem with it in a video game where you are finding a secret passage, or it is an easter egg that is of absolutely no consequence whether anyone finds or not.

But for critical functionality it is inexcusably and is so offensive to concepts of usability that any "designer" using this technique in software for basic functions should be identified and blacklisted from industry.

What is the affordance of invisibility? There isn't one.

<comment><USER3> My work involves designing interfaces and this discussion could help me understand this topic better; but like the author of the article, your post shows some intense frustration towards rollover-only elements, but none made it very evident to me as to why it's so frustrating and why it's so "stupid". We all experience things differently, and I'd love to picture a perspective where it's so frustrating.

Here's how I see it (and as you'll see, I'll be taking various assumptions. Please feel free to tell me I'm wrong (but make a case)):

We like to have everything at hand, but we also like (it's more like a need actually) to _focus_. Too many elements are a distraction. That's basically why we put things in boxes even if we don't intend to transport them anywhere: out of our sight. Our brains want/need to focus. That would be my answer to your question "What is the affordance of invisibility?".

The example of Google - if that really is a delete contact button, I don't use that app - I would agree is bad design, because its effort to find it outweights the benefits of having it hidden (partly because its placement is not apparently logical and that makes it extra hard to find).

In the first example in the article (github) however, I would tend to think that that specific solution is OK. The author of the article forgot to explain what that button does. A quick look at github, a rollover and a click (three actions) shows me that its function is it edits _the description of the repository_. How often do you edit the description of a repository? Not that often. Probably very rarely. And the more you use github, the smaller its usage gets proportionally to the rest of the app. The day you need it, you'll find it relatively quickly. Because you've experienced this practice for a while in other sites, and even more so because you've seen github act like that every now and then. Your brain is able to predict that if you don't see it, it might very well be rollover-only. The first logical place you try is the _within the repository dashboard, over the description of the repository_. Not too hard. I think in this case the benefits of _every time I read that page not having that element there and not having to neutralize it myself with my brain by ignoring it_ vastly outshine the effort of _looking for it when I rarely need it_. It's a good deal. [1]

I would love to understand a little more about why this concept didn't work out for you.

 _edit: typos, formatting and deleted some unneeded parts_

\--

[1] The github element in the case of a touch interface is not great, I would agree, because it's harder to _predict_ that by _touching_ the white area of the description the button will show up. But it works (as in: you can still access it). And you have to cut interface designers some slack (or instead give us the strength we need): we're still trying to figure out what to do exactly with the current mess of having two very different types of clients (mouse and touch) accessing our web interfaces. After we figure out _if_ we should unify, we need to figure out _how_. Killing rollover interactions might be a necessary casualty in that road (but that would make part of me sad, there are wonderful usages of rollover, see for example the custom sliders in here: <http://worrydream.com/LadderOfAbstraction/>), either way I'd love to understand a little more, and I assumed that in this discussion we're focusing on rollover, not touch.

<comment><USER4> I don't know anything about design. The solution that I propose seems obvious though; am I missing something?

> _Too many elements are a distraction._

> _What is the affordance of invisibility?_

There is a middle though: instead of either making it invisible OR cluttered, couldn't you just design it with a small clue, such as an arrow, which would open a drop-down menu when rolled over (on a computer) or tapped on (on a touch device)?

A drop-down menu with a small icon to prompt the user would hit the middle between simplicity and obnoxious prompting.

<comment><USER5> That's just hiding functionality again. MS started doing this by hiding vital functionality in a stupid looking windows logo jewel in the upper left hand corner. I had to ask other experienced people where the file menu was- it was not obvious that thing was anything more than decoration.

The solution to clutter isn't to hide functionality. It's to have your software do /less things/. If you need it to do more things, make those few things your software does a flexible set of tools that can be combined in novel ways.

Update: (I got downvoted so I thought I'd modify the post a bit, hopefully it's better?)

in any case, when it comes to software design, clutter isn't the worst thing software can do. Hiding things is, however, pretty close to the worst thing you can do. At least, without a consistent and obvious method of discovering the hidden things.

<comment><USER2> I liked the first post! The bit you removed: "Now you have two problems" I had just pasted it into my quote file, so it's not gone. I'm going to bring it back because it is a stylish way to say a lot. Ok I'll fiddle with it a bit too, play at being an editor.

> When it comes to software design, clutter isn't the worst thing software can > do. Hiding things is. So, to paraphrase JWZ: "You have a problem with > clutter, so you hide it. Now you have two problems." Thus, the solution to > clutter isn't to hide the functionality because that creates more problems > not less. The solution to clutter is to have fewer functions.

That's really good. Some reading this might be confused by fewer functions as meaning dumbing down and restricting the user, so let me expand that. That's not what it is. Fewer functions means making things simpler to the point that they are generic enough to have much more functionality, but with fewer explicit functions. For example, the unix command line is pretty simple to look it, but unlimited in what you can do. Type whatever you like there. The pipe thing lets you stitch things together in combination.

<comment><USER6> "Now you have two problems" is a common meme used to talk about a lot of computer programming decisions. It appears to be originally meant as a comment on regular expressions.

<http://regex.info/blog/2006-09-15/247>

</comment></comment></comment></comment></comment></comment><comment><USER7> That _isn't_ the "delete contact" button. Did he even try it? The "delete contact" button is in the toolbar, which makes perfect sense. The trash can next to the name field simply clears the name field. So why not always show it? This is not just the "edit contact" screen, it's also the "view contact" screen, and cluttering it up with trash cans next to every field would absolutely detract from the scannability of the page when you're not editing. Why not have separate pages for viewing and editing? That's bad for usability too; it invites mode errors.

<comment><USER8> And right there you define where you should and shouldn't use roll-over based UI elements: if a UI element is only useful as part of interacting with another, then hiding it in other situations makes sense (e.g., clearing a text field as part of editing the text in the field).

</comment></comment><comment><USER9> I have always called these interfaces 'scrubbing interfaces' and I believe it's a well known anti-pattern. It used to be popular with flash programming and design-heavy sites that didn't want all of those 'ugly controls'.

Here is my rule of thumb: avoid attaching functionality to the hover event. Visual effects/indications are fine.

<comment><USER2> I agree. I hadn't heard that term. There's a related anti-pattern called Mystery Meat Navigation.

<http://www.webpagesthatsuck.com/mysterymeatnavigation.html> <http://en.wikipedia.org/wiki/Mystery_meat_navigation>

Mystery meat was weird looking inexplicable icons that you had to click to find what they do or hover to get a description. Sometimes, including in both those references, they extend it to be cases where the inexplicable icon doesn't even exist and a description is invisible until hover. The hover patter, what you call scrubbing, seems to me to be related to but different from mystery meat, which is characterized by seeing a navigation element and saying "What on earth is that supposed to be?"

</comment></comment><comment><USER10> Putting hover-revealed controls on elements users interact with often is perfectly acceptable. Throwing every single control on the interface, regardless of how often they are used, is bad design and it overwhelms non- techie users.

</comment><comment><USER11> I'd like to add 2 other sites to this list with _horrible_ mobile interfaces that frequently show up on HN.

extremetech.com and geek.com

Extreme Tech's mobile site is totally unusable. They have a very crummy interface, instituted with javascript, that overrides the simple scrolling ability built into the browser and overlay it with a system that tries pseudo- pagination. If they would simply get rid of their attempt at a clever interface and just display their actual site, there wouldn't be a problem. If any Extreme Tech developers are reading this, please fix your mobile site.

The 2nd culprit, geek.com, crashes Mobile Safari. I'm on an iPhone 4. Because of whatever you are loading on your mobile site, it freezes the browser for upwards of a minute. Half the time the browser crashes before its done loading. Please, fix that too.

I actively avoid reading any of those sites, since I read HN from my phone about as often from a regular browser.

Another more generic complaint are to the people who use position:fixed on their sites to create headers and side navigation. Guess what, on mobile devices _these don't scale_. What ends up happening is that I need to zoom in to read your text, but then 3/4 of the screen is covered with your nav menu. Please, stop doing that.

Test your sites on mobile browsers. Its easy. Take the one in your pocket out and try your site. I'm not even advocating extensive dedicated testing. Just try it out like a normal user does and make sure it works most of the time. These are things that are so horrendously, obviously bad that I don't know how they _ever_ got through any reasonable kind of QA.

 __Edited for excessive usage of caps. Sorry.

<comment><USER12> position: fixed; is long as you use percents. Thing is position: fixed doesn't even work on iOS: <https://gist.github.com/1196262>

<comment><USER11> position: fixed was added in iOS 5. However, it becomes unstuck when pinch/zooming.

<comment><USER13> This kind of problems amazes me. It's year 2011, almost 2012 - we should have had flying cars and forcefield doors by now. Yet we are still struggling with getting a web page to work identically in different web browsers.

<comment><USER14> I am willing to bet that when we have flying cars and forcefield doors, there will still be problems of this kind in "information management", or whatever name you want to give to the problem that the web tries to solve.

</comment></comment></comment></comment></comment><comment><USER15> I agree!

Here is another semi-close example. Not about hovering, but how about needless hiding of important user experience?

<https://github.com/mozilla/browserid/issues/797>

I filed this super minor issue in the browserid issue tracker and it was closed with 'as designed'. No feedback as to why it was designed this way, but it sure seems silly to me to hide the 'remove' button under an 'edit' button.

I can understand this on a UI like an iPhone, but on a web page?

Oh well.

<comment><USER16> Wow, that's just silly. I agree - "Delete" is simply not a subset of "Edit"ing an option in a configuration. It may be a subset of editing the entire configuration, but having a two-step process that makes a non-connected action into a child action is mind boggling. People need to learn their CRUD/BREAD better.

<comment><USER15> Interesting that you write 'Edit' vs. 'edit'...

Here is another issue I just filed last night:

<https://github.com/mozilla/browserid/issues/809>

tl;dr: Super minor, but the case of buttons is actually important UX too.

I'm worried about BrowserID UX because we are implementing it on our site as an additional login system along with Facebook Connect. I'd love to see BrowserID become successful since we need an alternative to Facebook and OpenID is a train wreck. But, I worry that with bad UX, it will remain just an unused interesting idea.

<comment><USER16> Yeah, but I'm probably just used to it and since I was referring to BREAD, it kind of made sense. I guess it's one of those age old questions like "do we say 'your' or 'my'?".

</comment></comment></comment></comment><comment><USER17> I agree. Google seems to have replaced the concept of "Simplicity is best" with a misconceived notion about elegance. I don't want to search for hidden buttons just to log off, or delete, or open, or save changes. I just want to get things done and move on.

</comment><comment><USER18> And good luck discovering these with a touch screen interface. People always forget that one.

<comment><USER19> HN isn't that great on a touch screen either. I guess pg doesn't use a tablet because the comments link is too small and awkwardly placed for a finger.

<comment><USER20> I've become very adept at zoom&tap. In fact I probably do it about as fast postioning the pointer with my laptop's trackpad. I agree it'd be nice not to have to zoom before tapping.

</comment></comment></comment><comment><USER12> It made me both LOL and think. We are doing a snazzy crazy UI in the admin panel. But the thing is, we don't want people to use it. That sounds strange, but we optimized our convention, and we do allow people to configure stuff by themselves, but we don't want to motivate them to do so. An input field is crying for you to put something there. A little edit button in the corner not so much. And the added bonus is that we can hide all those ugly forms until they are really needed.

Also, think about an experience that was the exact opposite of this post. You thought about something ('where is the delete button?') and you 'gambled' where that button will show up, or what touch move you should use - think how awesome the filling was when you were correct.

</comment><comment><USER21> Strongly disagree with the article. you have to ask yourself: How often are you searching for a contact and want to edit it and not only view it? On average, most people won't edit it, so it's useless to have an edit button 90% of the time.

I think it's a pretty neat solution. The poster only has to get accustomed to 21st century technology, it's not 1990 anymore with textfields and buttons all over the place. It's like the typical rant of an old grandfather, complaining that something has changed and that everything was better decades ago. Bullshit. Just be a bit more flexible.

The placement of the hidden edit button can be discussed though. I am wondering why the github button is so far away from the content to edit...

Another example: The G+ profile editing is one of the best i have ever seen. It's "this is how your profile looks like to another person, hover the field and edit it". It's just easy and it's change something where it is shown, not going to another page and edit some values and go back and forth to see the changes.

</comment><comment><USER22> The GitHub example used to be better designed in that the "edit" link would appear right next to the text. So, you'd the see the repository title, move your mouse over it, and hey! see how to change it.

With the button all the way to the right, that connection is somewhat lost.

</comment><comment><USER23> Tab. The tab key should first take me to the most important clickable (or text-entry) part of your page. If you don't do this... It's not the "I'm not angry, I'm just disappointed" routine. It's both. I'm both angry AND disappointed.

</comment><comment><USER24> This 'hiding' makes sense with lists of items, each of which has the same options. You wouldn't want to see 30 identical delete icons, it would be ugly. There are two important examples. Twitter hides the actions buttons and facebook doesn't.

Twitter uses icons and media-poor tweets. So having the actions invisible is the best way to go, otherwise the UI will be too cluttered with actions.

Facebook has wider spacing, more graphics in the post itself, and its actions are text-only. That's why they can be visible - they don't distract you from the content.

So I wouldn't say having invisible actions is bad. It's just not always good.

</comment><comment><USER25> Please. The first example is for editing the repository description, and becomes visibile when hovering over the description. The second is for clearing the name field, and becomes visible as soon as you are actually editing this field. I agree that hidden interface elements should be used carefully, but if these really are the best examples you've encountered, then it's not really a big problem. I wouldn't even consider the second "example" a hidden interface element.

</comment><comment><USER26> Mystery meat nav (and bad design) is what I call it.

</comment><comment><USER27> On the one hand, it's better to reduce clutter for the less common case of editing rather than reading. On the other hand, it's better to indicate availability of functionality without requiring hovering.

What do you think of a modal solution whereby individual editing interface elements are shown collectively only when the user indicates editing intent through a single, master control?

<comment><USER2> Personally, I like those. I assume you are talking of the interface on some sites with let's say a user profile and there is a visible [EDIT] button in the upper right. Click on it, and all the nice formatted readable content is replaced with editable text elements that can be tabbed through, and these might have formatting bars in them or section delete buttons. Different from the discussed scenarios where basic functions are hidden and one must move the mouse around to different places to see if they may or may not exist, which is bad and smacks of video game treasure finding design, which is fine for video games and absolutely not fine for other applications. With the proposed [EDIT] design it is quite clear what is going on by examining the page visually. A related issue would be that the same profile viewed by other than the owner of the profile would show no [EDIT] button at all, nor would such button appear to them under any circumstances. No features hidden because for non-owners, there is nothing to edit.

</comment></comment><comment><USER28> I've always thought that reveal-on-hover controls makes perfect sense when you present a list of similar things. In that case, showing one edit button, one delete button, and possibly a detail button is too much noise.

My basic rule is, if there's more than one or two of the same control, then it should be hidden.

<comment><USER13> Yes, hidden, but with a visual clue (small arrow, button with an ellipsis) that clearly says: look, here are additional controls relevant to this part you're looking at.

</comment></comment><comment><USER29> The iOS interface is full of this behavior. I thought that was part the reason why it was so clutter free and easy to use due to less clutter.

</comment><comment><USER30> I find the behavior can cut down on clutter when pulled off correctly, though. Twitter offering context-based actions, for instance.

<comment><USER31> I'm not sure I agree. It completely breaks on tablets for one thing.

<comment><USER32> Does not have to though, Tweetbot's UI behaves nicely in this regard. It does not have hover, but its equivalent is to tap a tweet. This opens a small "drawer" of 5 tweet-specific buttons (reply, retweet, favorite, detail and "actions", which include posting a link to the tweet, copying the tweet's content, emailing the tweet's content and translating the tweet's content).

</comment></comment></comment><comment><USER33> Users, always them… My reaction? Meh!

</comment><comment><USER34> I didn't read this carefully, but it seems that "hidden" interfaces that pop up during a mouse hover and so on are a main objection.

Well, I must say, that often when using a web app, I expect to have to wait 5 seconds for a reload as I am moving my mouse in for a click (for example, imagine if there is a text link "Rate this page" under the current average rating) -- when, instead, as I hover over it it turns to 5 empty stars immediately, so that I have just saved 5 seconds for a page reload, I am immensely delighted.

Basically, I do agree that hidden interface elements are awful. At the same time, every "second page" that you would normally have to wait for is far better as a 'hidden interface' that pops up right away!

I dare say that when you wireframe out the possible pages of your web app, the _very best interface_ might be having most of those pages right in the main page, just hidden. Report feedback, report a bug, reset your password, all these things that would require a page reload and losing your scrolling in the page and so on, can be brought 5000 ms closer to the user but putting them in right at the point of the click.

So, I do agree that there is nothing as frustrating as a hidden user interface element. However, you can also pleasantly delight your user by bring the 'next page' right there.

</comment><comment><USER35> "Open letter to sites with annoying interfaces"?!

Maybe I'll write an open letter to traffic. Or an open letter to waiting in line at the post office. Or an open letter to humidity.

</comment><comment><USER36> This is so true. I look forward to Web3.0 through...</comment>


IPv6 Day Has Started - <AUTHOR> http://isc.sans.org/diary.html?storyid=11023&rss <comment><USER3> BTW in case it is a non-event, you can post fun IPv6 addresses that you notice.

Here's some. Check the AAAA for:

www.facebook.com www.luns.net.uk www.cisco.com

EDIT:

I meant, check the literal IPv6 addresses that correspond to these hostnames. I'll put emphasis so it is more visible :)

2620:0:1c08:4000:===face:b00c===:0:1, 2a01:8900:0:1::===b00b:1e5===, 2001:420:80:1:===c:15c0:d06:f00d===

EDIT2:

And while you're at it - maybe enable AAAA record for your site and give it a whirl! (and come up with some more creative IPv6 addresses in the process!) Thanks to guylhem for reminding about this.

<comment><USER4> sprint.net has a pretty nice one. Theirs isn't an IPv6 day exclusive either. Kind of amusing address for a telecom company...

<comment><USER5> For anyone else whose ISP doesn't support IPv6:

      PING sprint.net: 56 data bytes
      64 bytes from www.sprint.net (2600::): icmp_seq=0. time=156. ms
      64 bytes from www.sprint.net (2600::): icmp_seq=1. time=151. ms
      64 bytes from www.sprint.net (2600::): icmp_seq=2. time=153. ms
      64 bytes from www.sprint.net (2600::): icmp_seq=3. time=151. ms
      64 bytes from www.sprint.net (2600::): icmp_seq=4. time=151. ms

      ----sprint.net PING Statistics----
      5 packets transmitted, 5 packets received, 0% packet loss
      round-trip (ms)  min/avg/max/stddev = 151./152./156./2.5

2600 refers to <https://secure.wikimedia.org/wikipedia/en/wiki/2600> (first two articles on the disambiguation page are relevant).

</comment></comment></comment><comment><USER6> Wonderful. I switched from an hetunnel to native ipv6 on my linode, and it actually reduces latency over the ipv4 connection:

        [~] 0 (jon@snowball2)
        $ ping itchy.jrock.us
        PING itchy.jrock.us (184.108.40.206) 56(84) bytes of data.
        64 bytes from itchy.jrock.us (184.108.40.206): icmp_req=1 ttl=49 time=59.4 ms

And then with native ipv6:

        [~] 0 (jon@snowball2)
        $ ping6 itchy.jrock.us
        PING itchy.jrock.us(2600:3c00::f03c:91ff:fe93:50b0) 56 data bytes
        64 bytes from 2600:3c00::f03c:91ff:fe93:50b0: icmp_seq=1 ttl=246 time=36.6 ms

Pretty good!

<comment><USER3> During one of the last FOSDEMs (fosdem.org) we noticed similar thing - the RTT to google.com was slightly smaller over IPv6 than IPv4.

But it's a mixed bag. All one can conclusively say that the average patient temperature in the hospital is pretty close to normal.

</comment></comment><comment><USER7> My web site has been open for ipv6 business for a while. At home today, I installed tunneling software on my openwrt box, and it's working with comcast. Once I found the right set of instructions it went smoothly (<https://wiki.xkyle.com/Comcast_IPv6_on_Openwrt>). I can see unicorns now: <http://ismyipv6working.com/>

<comment><USER8> Yeah, installing a tunnel went pretty smoothly, but finding the home router documentation was not that easy, this has details for O2 broadnband in UK [http://blog.technologyofcontent.com/2011/05/this-blog-is- now...](http://blog.technologyofcontent.com/2011/05/this-blog-is-now- ipv6-enabled/)

</comment></comment><comment><USER9> Akamai has some visualizations here:

<http://www.akamai.com/ipv6>

<comment><USER10> Interesting how South America and Africa have absolutely zero traffic reported. I thought at least Africa, with it's shortage of IPv4 addresses, much like Asia, would have picked up on IPv6 to a larger extent than the "IPv4 wealthy" nations in the industrialized parts of the world.

Anyone have any theories? Ideas?

<comment><USER11> There's no IPv4 shortage in Africa; there might be a shortage of computers per capita but that's a different issue. <http://www.potaroo.net/tools/ipv4/>

</comment></comment></comment><comment><USER12> 99.99% of people won't have an IPv6 connection and can't be bothered to set up a tunnel. However it's still possible to play with IPv6 on your home network, and relatively simple too if you have at least one Linux box:

<https://rwmj.wordpress.com/2011/06/02/ipv6-lan/> (Make sure you read the comments for clarifications and fixes)

<comment><USER3> The point of the day is to ensure that enabling AAAAs on the _server_ side does not break the world. clientside IPv6 connectivity is a nice plus, but optional.

A couple of corrections:

1) ULAs are normally not routable over the internet. Though of course blocking them explicitly would not hurt.

2) depending on the RFC3484 configuration on the hosts, this "IPv6" might break connectivity to dualstack sites.

Please - go to tunnelbroker.net (or sixxs.net) and get yourself a tunnel - <USER2> is not that difficult, really.

<comment><USER12> You can test clients and servers on a LAN, far more simply than setting up a tunnel.

Anyway, I'm trying to get _everyone_ to test IPv6, and believe me most people are not going to want to set up a tunnel to do this.

Edit: and the "point" of today is to test IPv6 in software. Only a tiny part is to make sure that IPv6 can be routed across the internet-at-large.

<comment><USER3> Ah, if the intent is to test the clients/server in an isolated LAN - then, yes, ULAs might work.

Though you can as well use the 2001:db8::/32 and later you can also publish your examples readily.

My comment was about any testing that involves the boxes that may want IPv4 or IPv6 connectivity to external world, apologies if I misunderstood.

</comment></comment></comment></comment><comment><USER13> The large company I work for (~5000 people worldwide) doesn't appear to support any of this. Attempting to reach ipv6day.org gives the message "No DNS records."

Sites that already had IPv4 records work.

<comment><USER14> I have fully working IPv6 connectivity (10/10 by test-ipv6.com metrics), but ipv6day.org still fails for me. It seems that the problem is that there're no A/AAAA records:

        $ host -t AAAA ipv6day.org
        ipv6day.org has no AAAA record
        $ host -t A ipv6day.org
        ipv6day.org has no A record
        $ host -t MX ipv6day.org
        ipv6day.org mail is handled by 20 mail2.consulintel.es.
        ipv6day.org mail is handled by 30 dns1.consulintel.com.
        ipv6day.org mail is handled by 10 mail.consulintel.es.
        $ host -t SOA ipv6day.org
        ipv6day.org has SOA record ns1.euro6ix.com. dnsadmin.consulintel.es. 2010120100 86400 7200 2592000 172800

<comment><USER4> try www.ipv6day.org. `ipv6day.org` doesn't even have a regular A record.

</comment></comment></comment><comment><USER15> I've just gone with the common ones.

firstname.lastname@example.com [~]# host jacen.kly.no jacen.kly.no has IPv6 address 2001:16d8:eea2:30::dead

firstname.lastname@example.com [~]# host civ5.flexd.net civ5.flexd.net has address 188.8.131.52 civ5.flexd.net has IPv6 address 2001:16d8:eea2:30::beef

email@example.com [~]# host caedus.kly.no caedus.kly.no has IPv6 address 2001:16d8:eea2:30::daad

IPv4 users hit a IPv4 varnish which redirects to another varnish on the proper server (woo, double). IPv6 hits the proper server varnish directly. Seems to work great from everywhere!

</comment><comment><USER3> Would be very interesting to hear what the HN folks' experiences are with the whole v6day thing. Hopefully it should be a non-event, but interesting to know anything otherwise.

<comment><USER16> It's just a good opportunity to configure services and test how it works. Personally I had never touched anything ipv6 related before this spring. There was no real reason to (blame me). Now seems a good moment.

<comment><USER7> I think that's exactly the idea. If an annual nudge gets some folks to set up ipv6, then there is a steady increase in the size of the ipv6 network. For the most part, no one will have any reason to turn it off again the next day.

When can we start an annual "turn off ipv4" day? <http://bgp.he.net/ipv6-progress-report.cgi> suggests that we'll have to wait a while.

<comment><USER17> I think they're turning off fax and IPv4 on the same day, I read that somewhere.

<comment><USER18> I normally avoid posting jokes on HN, but this is highly relevant: [http://www.thehighdefinite.com/wp- content/uploads/2010/02/20...](http://www.thehighdefinite.com/wp- content/uploads/2010/02/2010-02-05-27c71fd.png)

</comment></comment></comment></comment></comment><comment><USER19> Can anyone tell me why <http://ipv6day.org> is failing after a lengthy timeout, but <http://www.ipv6day.org> works? There are links to the non-www version in this article, so I assume it worked at some point.

Edit: Actually, I think SANS just linked to the wrong site. It should be <http://www.worldipv6day.org/>

</comment><comment><USER20> Facebook: 2620::1c00:0: _face:b00c_ :0:2

Clever.

<comment><USER21> Everybody notice the part:

face:b00c

Cool! :)

</comment></comment><comment><USER8> This Firefox plugin lets you see the IP you connect to which is useful to see if you get IPv6 [https://addons.mozilla.org/en- US/firefox/addon/showip/?id=59...](https://addons.mozilla.org/en- US/firefox/addon/showip/?id=590)

The bbc is odd, as www.bbc.co.uk has ipv6 address 2001:4b10:bbc::2 but Firefox only connects to ipv4.. [edit] finally connected on ipv6 after a restart...

<comment><AUTHOR> from what i remember, that add-on just tries to resolve hostnames that it sees, it doesn't actually show you whether you connected to that specific ipv4 or ipv6 address.

</comment></comment><comment><USER22> Netregistry.com.au also joined in on the ipv6 fun, funny their main competitor melbourneIT seems not to be interested in it.

</comment><comment><USER23> Looks like www.rackspace.com is IPv6 now. I can't route to it since I'm on TimeWarner, but it seems to have a AAAA record.

</comment><comment><USER24> My HE tunnel is working great! Looks like my latency to Google is the same as it is on IPv4.

</comment><comment><USER25> Some sites that don't have AAAA DNS today:

www.apple.com

www.amazon.com

www.sony.com

www.oracle.com

www.ibm.com

www.intel.com

www.adobe.com

www.ebay.com

www.dell.com

www.hp.com

www.nasa.gov

www.hotmail.com

www.wikipedia.org

news.ycombinator.com

</comment><comment><USER26> www.tokyotosho.info 2001:67c:2a0:5:0:b00b:babe:cafe

<comment><USER6> That IPv6 address is very misleading. There was no cafe at all!

</comment></comment><comment><USER27> working great so far here!

www.google.com has aaaa 2a00:1450:4008:c00::69 www.youtube.com has aaaa 2a00:1450:4008:c00::be www.facebook.com has aaaa 2620::1c00:0:face:b00c:0:1 www.bcc.com has aaaa 2001:4b10:bbc::1

checked with ipv6 check @ <http://www.upordown.de/www.youtube.com>

<comment><USER6> Resolving AAAA records doesn't have much to do with IPv6 connectivity. The whole point today is to see what happens when clients receive AAAA records in addition to A records. If a misconfigured client thinks it can use IPv6 but can't, then the existence of that AAAA causes problems.

<comment><USER27> That's true. But i think it's real good that these big sites add aaaa records for today. Hopefully the results will show that the percentage of broken users is really small. Someone has to start deploying ipv6 - either isps or content providers.

</comment></comment></comment><comment><USER28> Awesome, since Google via IPv6 is not responding for me now and has been all day.

<comment><USER3> ping me if you want any help with the debugging. I might be a bit busy but will try to help.

Either my gmail or work address could work as XMPP contact.

</comment></comment><comment><USER29> ycombinator.com (188.8.131.52) is up via IPv4! ycombinator.com doesn't have an IPv6(AAAA) DNS Entry!

:(

(<http://www.upordown.de/ycombinator.com>)

<comment><USER3> you can try <http://news.ycombinator.com.sixxs.org/> until PG gets dualstack

</comment></comment><comment><USER18> I'm going to try to see if I can get IPv6 working for my linodes.

<comment><USER30> If you're in Fremont, Newark, or Dallas, it's pretty easy... Just open a ticket (I hear there's actually a button now) and reboot.

<comment><USER31> There is a button in the dashboard. A script of theirs will alter your MAC address and reboot your machine. When it comes back up, IPv6 is working like a champ.

I just did mine; I got a new IPv6 address and the same IPv4 address.

</comment></comment></comment><comment><USER32> :101:ca75: Can I haz? Share your ideas for pretty ipv6</comment>


What Is a 'Nautical Mile'? (2011) - <AUTHOR> https://science.howstuffworks.com/innovation/science-questions/question79.htm <comment><USER2> > A minute of arc on the planet Earth is 1 nautical mile.

Only if that minute of arc lies on a great circle route.

As an interesting addendum, when measuring distance made good on a nautical chart, you will use a divider to measure the straight line distance, then lay this onto the latitude scale to convert it to nautical miles.

If you were to use the longitude scale, you would be off by approximately the cosine of your latitude, because the lines of latitude( _) (apart from the equator) are not great circles.

(_) corrected longitude to latitude here - longitude is obviously great circles, latitude apart from the equator are not.

<comment><USER3> I can believe that it's true that lines of longitude are not great circles, but I can't picture why in my head. Isn't a great circle formed by extending the shortest distance between two points on the surface of a sphere?

<comment><USER4> Lines of longitude are great circles. Grandparent must mean latitude: the equator is a line of latitude, and the only one that is a great circle.

<comment><USER2> Thanks, I've corrected my previous comment.

</comment></comment></comment></comment><comment><USER5> Its interesting that the nautical mile is based on a more abstract number that would define when looking at maps and charts, rather then something more immediate and physical like the distance to the horizon when out on the ocean. Most imperial units seem to be based on simple laymen measurements.

<comment><USER2> Distance to the horizon is variable. Sea state, height of deck over water, visibility etc will all affect it. Whereas, with a sextant and a decent maritime chronometer it is very easy (*) to determine longitude and latitude.

<comment><USER6> The length of people's feet vary and so does the amount of land a yoke of oxen could plough in one day.

</comment></comment></comment><comment><USER7> The metre was originally supposed to be based on a division of the Earth's circumference as well.

<comment><USER8> Indeed, IIRC the intention was to define the meter so that the distance between the North Pole and the equator at the meridian through Paris would be exactly 10000 km, making the full circumference along that meridian and the one opposite it 40000 km.

EDIT: that information is already in the article, making my comment redundant and unnecessary.

<comment><USER7> Mine also. ¯\\_(ツ)_/¯

</comment></comment></comment><comment><USER9> At what elevation are they measuring these arcs / circumference of the earth? At sea level? Feel like that needs to be explicit if we are trying to be technical. Because you can't "travel around the Earth at the equator" in "21,600 nautical miles, 24,857 miles or 40,003 kilometers" without going underneath a mountain or two.

<comment><USER10> They aren't. It was based on an early spherical model, but in the modern world a nautical mile is defined as exactly 1852 meters, period. The notion of the arc minute is historical context in the same way that a "mile" was originally a thousand (mille) paces.

</comment></comment><comment><USER11> Hah! I was in the Navy and never knew that.

P.S.: Supply Corps, so never needed to know it.

</comment><comment><USER12> > A kilometer is also defined using the planet Earth as a standard of > distance.

Wrong. It used to be that way, but not anymore.

<comment><USER13> Which is why it says: ... you would have the traditional unit for the kilometer as defined in 1791 by the French Academy of Sciences.

<comment><USER12> Wouldn't you need the 1791 Earth, too?

The article doesn't mention that it's not the current definition.

</comment></comment></comment><comment><USER14> I teach this as part of the science of diving course and there is always an audible groan at the mention of the word "mile".

By the time I am done explaining the basis it is always funny how the classrooms attitude changes to "that makes a lot of sense".

</comment><comment><USER15> I would never get used to how to remember the diameter of the earth. Now all I need to remember is how many km's are there in a nautical mile, get the length of the equator and divide it by pi. i.e. (360 x 60 x 1.85/3.14)

<comment><USER16> The perimeter is 40,000 km. You just need to learn pi ;-)

</comment></comment><comment><USER17> It's the only mile that metric people approve of :-)

<comment><USER18> No, the nautical mile is hated by proponents of the metric system. As with all customary units, it favors a specific use-case at the cost of errors and conversions, has limited accuracy and doesn't handle orders of magnitude.

<comment><USER19> Yes. This is the most annoying side-effect: industry-specific systems of measuring.

As I'm typing this, I'm looking at the power extension cord for my computer, which has a thickness 1.10 Micro Nautical Mile, ie. AWG 12, ie. 2.05mm…</comment></comment></comment>


Improvements to Notification Emails - <AUTHOR> https://github.com/blog/2183-improvements-to-notification-emails <comment><USER2> The cc addresses work great with Google Inbox bundles. Thanks for adding that.</comment>


Ask HN: I finished building a crowdsourcing platform but idk what to do with it - <AUTHOR> https://www.eraise.loans
Eraise is a platform that allows you to donate to an American struggling with student debt. Donations are securely sent directly to a random Eraise user's loan provider.
It was a fun project I did in my spare time as an excuse to practice my design skills and play with some cool technology (nextjs, ts node. For a full breakdown check out my case study: http://www.kolbysisk.com/work/eraise)
But now I don't know what to do with it. I feel like I can't launch Eraise without incorporating and talking to lawyers because it deals with sensitive data and money transactions.
I also don't know a whole lot about the business side of things, plus I'm not super confident that it's even worth pursuing.
I'd really appreciate any feedback or direction. <comment><USER2> [https://www.eraise.loans/terms](https://www.eraise.loans/terms) 404s for me

edit: So does [https://www.eraise.loans/cookies](https://www.eraise.loans/cookies)

</comment><comment><USER3> Sounds like it is just something to add to your resume/portfolio

<comment><AUTHOR> Thanks for the honesty.</comment></comment>


Show HN: Distributed Homomorphic Encryption Adder (Weekend Project) - <AUTHOR> http://9ac345a5509a.github.io/p2p-paillier/

<comment><USER2> Honestly, I think the potential advent of _efficient_ fully-homomorphic encryption is potentially one of the largest effects we could ever see on privacy-related computing. The possibilities are absolutely staggering. Imagine, for example, a search engine that returns useful results but does not know what the user is searching for. And so on; the possibilities are well- covered in the literature.

As of right now, the current-day state-of-the-art fully-homomorphic schemes impose roughly a billion-factor overhead on operations, but this is quickly decreasing (in the past 4 years, we've already knocked off three orders of magnitude). But I am personally convinced that an efficient scheme would likely revolutionize privacy in computing. Exciting stuff, especially with recent events.

Unfortunately, I don't expect an efficient scheme to be widely-used for at least 15-25 years. For one, even if a super-efficient FHE scheme was published tomorrow, it'd probably take at least 6-10 years of powerful, sustained cryptanalysis for the community to trust it. Add the time to discover such a scheme (if even possible...) and you have quite a while. But still, the potential is amazing.

<comment><USER3> By fully-homomorphic do you mean Turing-complete?

<comment><USER4> No, by fully homomorphic he means the usual meaning of this phrase: [http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_ho...](http://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_homomorphic_encryption)

<comment><USER5> I suppose it depends on which you consider more fundamental to the definition. The reason this particular ring and set of operations is _interesting_ is because it implies being able to compute any Turing-computable function of the data. Hence Gentry's high-level overview paper was entitled "Computing arbitrary functions of encrypted data" [1].

[1] [http://ece.gmu.edu/coursewebpages/ECE/ECE646/F10/project/F10...](http://ece.gmu.edu/coursewebpages/ECE/ECE646/F10/project/F10_Project_Resources/Computing_Arbitrary_Functions_of_Encrypted_Data.pdf)

</comment></comment></comment></comment><comment><USER6> Here's a hypothetical use case for homomorphic encryption, although I think it needs to do a lot more than the linked example if it's actually going to work in this case:

There's a bunch of data on a server, including, say, encrypted names. Users accessing the server have a key to decrypt those names, but they also need to be able to search for and sort names. Decrypting all the names and searching/sorting would be one option, but with enough names, it becomes very, very slow. Another option is having a big index that you decrypt for searching/sorting. This is kind of unwieldy as well, even if it's faster than decrypting everything piece by piece.

Perhaps the right homomorphic encryption techniques could also be used, although you'd have to account for substring searching in the case of names: finding "David" searching for "Dav".

</comment><comment><USER7> This reminds me of the average salary tool. If you are not allowed, or it is bad form, to ask your peers' salaries you can create a list of people add a random number to your own salary give it to the first person on the list that person had their salary and gives it to the next continuing through the list. The last person give you the final number. You subtract your random number and divide by the total number of people and bingo you have the average salary of the group.

I actually did this once at a company I worked for. Both the management and the employees ended up unhappy.

(the typical, and more secure, version of this includes public key encryption between each participant)

<comment><USER8> Can you expand a little on why the result of this made people unhappy? At a guess, something relating to significant differences in salary for similar jobs?

<comment><USER9> I assume he has three groups:

1\. Employees paid less than the average 2\. Employees paid equal to or more than the average 3\. Management.

Reactions are:

1\. Unhappy: Being paid less than average 2\. Happy: Being paid more than average 3\. Unhappy: Half of their employees now know they are being paid less and are unhappy.

<comment><USER7> Yep that's it. Less then half of the total people involved are made happy by this.

However, one thing management should be more happy about is that usually the highest paid people are the nosiest. With a tool like this perhaps they can shut them up.

</comment></comment></comment></comment><comment><USER10> Very intriguing, but this is broken for me on Chrome 28 for OSX. A while after I try to add two numbers, console gives the following:

      Uncaught TypeError: Cannot read property 'length' of undefined      BigInt.js:1
      expand                                                              BigInt.js:1
      powMod                                                              BigInt.js:1
      decryptRecAns                                                    paillier.js:70
      getConsensus                                                   distribute.js:94

</comment><comment><USER11> 1 + -1 = 1

Are negative numbers not yet supported?

editted to add: Or indeed decimal numbers.

Natural numbers only then?

Still seems cool even if how it works is a mystery to me.

<comment><AUTHOR> Very nice observation, and yes, natural numbers only. I believe it could be modified to allow for negative numbers.

</comment></comment><comment><USER12> This makes me curious.

Is it possible to use homomorphic encryption to create a network of "dump pipes" for exchanging data?

Tor is slow because data has to hop from peer to peer until it hits its destination. What if the "nodes" between you and the recipient ran on a single machine? Clients would simply send a homomorphically encrypted program to a central server which merely executed it. The programs and the data exchanged could be completely transparent, you could even give law enforcement access, and assuming:

1\. the homomorphic encryption is secure

2\. your data passes through enough trustworthy peers

3\. there are enough nodes involved for plausible deniability

...it would not be possible to identify the path data takes as it is routed around.

Or am I missing something?

<comment><USER13> Could you explain what you mean a bit more clearly?

Traffic can be anonamised hopping it around many peers (assuming that a critical mass of them are not observed, which seems entirely likely these days).

If you sent a request to a single machine, which routed it between processes, eventually decoding the request, you are saying that the machine would not know what user made that request, and it could return the result via the same chain. But because both ends and the processing are observed, traffic analysis would yield which client asked for the file trivially. Rather like if the enemy controlled every node on your darknet, they could trivially know who you were and what you were doing.

The strength of the network is lots of nodes and lots of hops, in the hope that you will pass through enough uncontrolled ones that traffic can't be resolved. While what you suggest might, possibly reduce the risk from a compromised node in a multihop chain, it would not defeat traffic analysis, which is the major problem. Better just to inject fake traffic.

<comment><USER12> Traffic analysis would not be a concern if the data being transferred and decoded by each program was interlaced with data from other streams. This would prevent an all-knowing adversary from following the data as it changes state through each program's execution.

And of course, the standard onion-encryption would be applied. The data on one end would be different than on the other or at any point in between. Padding to prevent size attacks, etc. (Everything Tor already does, I believe.)

The homomorphic-encryption would just allow you to 'outsource' your cryptography, routing and buffering mechanisms to a remote host, making data transfer between each individual 'identity' much faster without jeopardizing anonymity.

</comment></comment></comment><comment><USER14> Homomorphic encryption is interesting from a business standpoint (think: manipulating credit card numbers without being able to read them).

For anonymization systems, care must be taken: being able to manipulate encrypted data could very well create information leaks.

There have been some interesting theoretical uses of the Pallier cryptosystem in private information retrieval systems, though.

<comment><USER15> What kind of arithmetic operations would you ever need to do on a credit card number? Other than maybe verifying the checksum digit.

</comment></comment><comment><USER16> Stuck on "Awaiting network consensus"</comment>


Vulnerability in ICMPv6 could allow Denial of Service - <AUTHOR> https://technet.microsoft.com/en-us/security/bulletin/ms13-065

<comment><USER2> > Vulnerability in ICMPv6 could allow Denial of Service (microsoft.com) 12 > points by vog 1 hour ago | flag | 7 comments

I read the linked page and all I could see was a vulnerability in Windows.

> The security update addresses the vulnerability by correcting how the > Windows TCP/IP stack allocates memory while processing specially crafted > ICMPv6 packets.

What website am I on, Slashdot?

<comment><AUTHOR> _> I read the linked page and all I could see was a vulnerability in Windows._

I never entered that crappy title. I chose a completely different one, which was then changed by some admin. I added a new HN entry about this incident:

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

</comment></comment><comment><USER3> Vulnerability in how Windows does ICMPv6....

[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-31...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-3183)

<comment><AUTHOR> _> Vulnerability in how Windows does ICMPv6_

I never entered that crappy title. I chose a completely different one, which was then changed by some admin. I added a new HN entry about this incident:

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

</comment></comment><comment><USER4> No, vulnerability in Windows allows Denial of Service. This isn't a protocol flaw in ICMPv6.

<comment><AUTHOR> I never entered that crappy title. I chose a completely different one, which was then changed by some admin. I added a new HN entry about this incident:

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

</comment></comment><comment> X-Istence Could it be added that this is just in Windows, in the title? Sure it links to a Microsoft.com domain, but there are plenty of research projects hosted by Microsoft that are not necessarily on Windows...

This had me worried I would be spending time checking to make sure all the OS's I admin are secured against this "threat" somehow...

<comment><AUTHOR> _> Could it be added that this is just in Windows, in the title_

I never entered that crappy title. I chose a completely different one, which was then changed by some admin. I added a new HN entry about this incident:

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

</comment></comment><comment><USER5> I know it isn't particularly noteworthy, but if you go through MS's buglist, essentially every single critical hole is due to using unsafe languages. And despite how much effort has gone into tooling and scanning and automation, stuff like this is still found monthly.

<comment><USER6> Same thing with every browser. IE, Firefox, Chrome all push security updates monthly now.

</comment></comment><comment><USER7> This happens in every single fucking version of Windows. Every time, since 3.11, they find another remote DoS using just ICMP. It's insane. It's like they plant it there to force people to apply the next service patch.

</comment><comment><USER8> damn, and I thought that ICMPv6 made us impervious to DoS attacks.

</comment><comment><USER9> Not sure why one Windows bug out of thousands is front page material.

<comment><USER10> I guess you may have just woken up from a coma that started in the late 90s.. in any case, Windows security is vastly improved in recent years, and even if it weren't, remote DoS against a hugely deployed OS in a kernel driver in the default install is still very noteworthy.</comment></comment>