ARM and Intel have different performance characteristics: a case study - <AUTHOR> https://lemire.me/blog/2019/03/20/arm-and-intel-have-different-performance-characteristics-a-case-study-in-random-number-generation/ <comment><USER2> I suspect if you were to compare code that uses both the remainder and quotient of a division, you would find a similar trend: the x86 division instructions produce both, but ARM has only a quotient-generating division instruction, and you have to do another multiplication(!) and subtraction to get the remainder.

That, along with the fact that earlier ARMs _didn 't even have a divide instruction_, is one of the reasons why I'm not at all fan of the "RISC approach" \--- division may not have been easy to implement, but microcoding would've been at least as fast as doing the algorithm in software while taking up far less space, and with hardware advances that move operations from microcode into direct execution, existing software that already has those instructions would automatically become faster on newer hardware with no other action needed.

Division hardware almost always will generate the remainder along with the quotient, but ARM would either need to add another instruction (no benefit to existing software, only new software that knows how to use it) or attempt to detect patterns of simpler instructions that are doing the same thing in order to replace them with one "fused uop" (much more difficult to do.)

<comment><USER3> There is a good reason why nobody implements multiply and divide like x86 did: it's terrible for register allocation. Especially on 32-bit, where register pressure is very high, having division input _and_ output registers hardwired is obnoxious, _and_ it kills a register for the upper half of the product or remainder or quotient that you almost never need. ARM has the correct design. Even Intel admits this: look at the MULX instruction that retrofits the right design onto x86.

Earlier versions of ARM didn't have a divide instruction because of die space and the fact that it's rarely needed. Integer division is usually by a constant, so a shift and/or a multiplication suffices. There's no need to microcode a divide instruction either, because the kernel can just trap the #UD and perform the division itself, just like soft float works. (Yeah, it's slow, but software division is always slow.) Modern designs like RISC-V do this properly: expose division as an optional extension so as to scale down to microcontrollers.

<comment><USER4> I wrote a simple compiler for mathematical operations recently, [https://github.com/skx/math-compiler/](https://github.com/skx/math-compiler/) and I have to say I really appreciated the ability to get the two halves of the result in one operation.

I've just provisioned an ARM server so I can experiment with generating ARM assembly as well as Intel. No doubt I'll have fun learning of the different instructions available - until now I've only ever written assembly for intel and Z80 processors.

<comment><USER3> The problem doesn't appear until you start implementing register allocation.

<comment><USER4> Yeah I can appreciate register starvation, something I've come across in previous coding.

</comment></comment></comment></comment></comment><comment><USER5> Can someone explain this in a bit more detail? Why does "the computation of the most significant bits of a 64-bit product on an ARM processor requires a separate and expensive instruction"?

<comment><USER6> ARM64 has separate instructions for computing the low and high halves of a product, in keeping with its single destination register approach. x86-64 has a single instruction that computes both halves simultaneously, writing to two registers.

<comment><USER7> On a modern out of order uarch that kind of "complex" instruction would by spited in two micro operation, one for each register result. And Agner's tables [1] confirms that the mul 64*64 => 128 is split in two micro-ops on Skylake. So it doesn't give any strong advantage.

[1] [https://www.agner.org/optimize/instruction_tables.pdf](https://www.agner.org/optimize/instruction_tables.pdf)

<comment><USER8> Yes, but the second uop is not expensive like the first in this case. That is, it seems like the the full multiplication is done by the latency-3 op on p1 and the other uop is just needed to move the high half of the result to the destination (indeed, instructions with 2 outputs always need 2 uops due to the way the renamer works). The whole 64x64->128 multiplication still has a latency of only 3, and a throughput of 1 per cycle.

So the 64x64->128 multiplication is still quite efficient compared to ARM where two "full strength" multiplications are needed. It is odd though that there is nearly a 20x difference in relative speeds though, I wouldn't expect multiply upper to be _that_ slow.

<comment><USER9> Note: The test seems to have been done on Skylark (aka: Ampere), which is a non-standard ARM core. I can't find any documentation on Skylark's latency / throughput specifications.

</comment></comment></comment></comment></comment><comment><USER10> ARMv8 NEON has a 64x64->128 multiply.

<comment><USER11> Aye, it's PMULL, and it's available as part of the ARM Crypto Extensions.

This patch shows that using it can result in a large performance improvement: [https://github.com/randombit/botan/issues/842](https://github.com/randombit/botan/issues/842)

<comment><USER12> Hm, why aren't compilers generating that instruction?

upd: apparently reasons like:

> So I guess for most of the case loading or storing i128, the data will be > used by some library functions running on cores instead of NEON, so storing > i128 to two GPR64 is more general.

[https://reviews.llvm.org/D2344](https://reviews.llvm.org/D2344)

<comment><USER9> > Hm, why aren't compilers generating that instruction?

Thats polynomial multiply. Its (almost) a multiplication in GF2 for elliptical curves. Thats not a "normal" multiply.

"PMULL" is basically a bitshift and XOR. Your traditional "MUL" is bitshift and ADD. Its called "polynomial multiply" because bitshift-and-xor has very similar properties to bitshift-and-add (it distributes over XOR, associative, communative, etc. etc).

Bitshift-and-xor has a few features that are better for cryptography. But its NOT the multiplication you are taught in grade school.

\</comment></comment></comment></comment><comment>--

EDIT: With that being said... those "better features" for cryptography would make PMULL probably a better function for random-number generation. PMULL will return a different result than the real multiplication, but you'll have an easier time making a field (aka: reversable 1-to-1 bijections) out of PMULL than MUL...

</comment><comment><USER13> Moreover, different ARM chips have different performance characteristics as well. Apple's implementation, for instance, seems to be easily twice as fast on most problems at the same clock speed as its leading competitors.

</comment><comment><USER14> I'm guessing the 128-bit multiplication implementation on the ARM architecture isn't as well done as is on the Intel platform?

You might be able to reclaim the performance if you manually implement the multiplication using 64-bit variables instead.

<comment><USER15> No, the compiler is generating good code. If you use a smaller word size you just end up doing more multiplications (e.g. cut your word size in half, do 4x as many multiplications).

</comment></comment><comment><USER16> Should we be surprised? The __(u)int128_t types are an optional extension of the C standard, hence there can be no expectation that operations with these are implemented well or at all, let alone implemented in silicon.

<comment><USER17> I don't see what specification has to do with this. I mean, a 32 bit 2's complement integer is __also __a technically optional part of the C standard, and indeed there is hardware that doesn 't support multiplications on them with a single instruction.

What's happening here isn't related to word size, really. It's that multiplication, as an operation, is lossy. It produces 2 words worth of output, not one. Traditionally, most RISC architectures have just skipped the complexity and returned the product modulo the word space. But x86 didn't, it put the product into two registers (specific registers: DX and AX, and their subsequent extensions).

Most of the time this just a quirk of the instruction set and an annoyance to compiler writers. But sometimes (and this trick has been exploited on x86 for decades for applications like hashing) it turns out to be really, really useful.

<comment><USER16> Integer multiplication always carries the risk of Integer overflow. Integer Overflow is undefined behavior in C, so it's the programmer's responsibility to make sure it doesn't happen.

To that end in the example a __uint128_t was used, which is nonstandard, and apparently not implemented all that well with the given combination of compiler and ARM CPU. Given that we're talking about a 64-bit CPU, my argument is that this is not very surprising.

<comment><USER14> > Integer Overflow is undefined behavior in C

 _Signed_ overflow is undefined behavior, unsigned overflow is defined in both C/C++.

Apart from that, I agree with you. It has to do with the fact that OP is using 128-bit variables on a 64-bit architecture.

Come to think of it, it's actually more mesmerizing that x86 is _not_ slowed down by a 128-bit variable. The ARM architecture is behaving as is to be expected, Intel is actually the odd one out.

Someone mentioned cryptography, I can imagine that because of it, Intel has a few instructions to optimize integer arithmetic on wider integers, and that is probably the reason of the anomaly, which is actually Intel and not ARM.

<comment><USER17> As mentioned upthread, the mermerizing instruction in question is "MUL", which debuted in 1978 on the 8086 and, except for register width, behaves identically today.

<comment><USER14> I'm no expert, but shouldn't x86 then produce two 128-bit register entries if it multiplies two 128-bit integers, so totaling actually four registry entries on a 64-bit architecture? If this were the case, Intel would slow down just as much as ARM on a double-than-archictecture-width-integer multiplication, but it doesn't. That's what I find mesmerizing. I'm guessing that Intel simply discards the earlier double registry logic once it goes beyond architecture width, which would explain the speed up.

I.e. 64b * 64b = 2x64b registry entries, according to MUL should be 128b * 128b = 2x64b * 2x64b = 4x64b, but Intel discards this in favor for 128b * 128b = 2x64b * 2x64b = 2x64b.

<comment><USER17> x86 can't multiply two 128 bit numbers at a time. But it can multiply two 64 bit numbers without losing the high 64 bits of the 128 bit product, which makes the 128 bit multiplication much faster to implement.

<comment><USER14> > x86 can't multiply two 128 bit numbers at a time.

What's happening here then? Are these not two 128-bit integers? One's a 64-bit recasted to 128-bit, the other a 128-bit constant. Code would be doing faulty math, if it just decides to drop any bits. Coincidence, maybe, that the upper half of the recasted is in this case 0x0, but the code must work for 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as well, and probably does too.

      __uint128_t tmp;
      tmp = (__uint128_t) wyhash64_x * 0xa3b195354a39b70d;

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> CSA: Don't fixate on the code generated by Godbolt in isolation; it's not going to reflect what happens in the benchmark loop.

(see my other reply to dimitrgy for more details)

</comment><comment><USER19> Article is very light on details, and contains zero citations, and only a single result of a single benchmark the guy ran, with no details of how it was run. It follows up by stating his theory as to why this happens as a fact (again with no citations). Author does not even offer us a clue as to what ARM core is used. The claim is:

      > The difference is that the computation
      > of the most significant bits of a
      > 64-bit product on an ARM processor
      > requires a separate and expensive
      > instruction.

I see no proof of this anywhere in the ARMv8 spec. You get the lower 64 bits of result using _MUL_ and higher 64 bits using _UMULH_. Neither of those is that expensive.

Looking at [1] we can see that MUL has throughput of 1 and latency of 3, UMULH has 1/4 and 6, but as long as you do not issue another multiply just after your UMULH, this 1/4 throughput is easily hidden, since only the multiplier is busy, the rest of the CPU can go on. So unless your entire loop is under 6 cycles, or you simply have no instructions to schedule that do not need a multiply within the next 3 of UMULH, it shouldn't matter. Given those large constants that need to be loaded, they will each need 4 instrs (mov+movk+movk+movk), there are plenty of instrs to schedule after UMULH. Either OP's compiler messed up, or something entirely different is going on.

If, the author was using a weaker in-order core, say Cortex-A55, still more performance is expected than appears demonstrated. There [2] the low part is calculated in 2 or 3 cycles, the high in 4. But comparing an ARM in-order little core to a modern OoO x86 is just not fair.

EDIT: Indeed, looking [3] at what gcc produces for this code is sad. For example, why it is bothering synthesizing 0x1b03738712fad5c9 before issuing the first UMULH is unclear, but it _IS_ stupid.

EDIT2: on skylake [4] MUL has a latency of 3, so faster than on ARM but not by that much. I'd guess the constant loading on arm using 4 instructions per constant hurts more than UMULH

EDIT3: in comments on original site, author said the ARM chip being used is a "Skylark" by "Ampere Computing" [5]. Given that I cannot find any info on that microarchitecture, I cannot say more about why it might be slow.

[1] Cortex®-A72 Software Optimization Guide: [https://static.docs.arm.com/uan0016/a/cortex_a72_software_op...](https://static.docs.arm.com/uan0016/a/cortex_a72_software_optimization_guide_external.pdf)

[2] Cortex®-A55 Software Optimization Guide: [https://static.docs.arm.com/epm128372/20/arm_cortex_a55_soft...](https://static.docs.arm.com/epm128372/20/arm_cortex_a55_software_optimization_guide_v2.pdf)

[3] Godbolt for this code: [https://godbolt.org/z/UeOo6C](https://godbolt.org/z/UeOo6C)

[4] Lists of instruction latencies, throughputs and micro operation breakdowns for Intel, AMD and VIA CPUs: [https://www.agner.org/optimize/instruction_tables.pdf](https://www.agner.org/optimize/instruction_tables.pdf)

[5] Skylark - Microarchitectures - AppliedMicro: [https://en.wikichip.org/wiki/apm/microarchitectures/skylark](https://en.wikichip.org/wiki/apm/microarchitectures/skylark)

<comment><USER18> I think Daniel's use of the word "separate" in "separate and expensive" is ill-advised, as it implies a critique of ARM's ISA design in a way that isn't relevant _for this case_. One might be concerned if you needed all 128 bits in some other use, but not here.

As for loading large constants, if you read the post and follow the link at "reuse my benchmark" ([https://github.com/lemire/Code-used-on-Daniel-Lemire-s- blog/...](https://github.com/lemire/Code-used-on-Daniel-Lemire-s- blog/blob/master/2019/03/20/fastestrng.cpp)) you will see that these functions as _measured_ are inside hot loops. As such, presumably constant loading is very likely to be hoisted out of these loops on both architectures.

This will make the _considerably_ slower UMULH stick out like a sore thumb. Also note that the measurement loop allows most of the work of each iteration to be done in parallel - the work of the rng is a long dependency chain within the calculation but the update of the seed is quick and independent of that.

I would guess that the Ampere box has a wretchedly slow multiply. In a comment on the post, Daniel finds an ugly performance corner on A57 (possibly related, possibly not): "On a Cortex A57 processor, to compute the most significant 64 bits of a 64-bit product, you must use the multiply-high instructions (umulh and smulh), but they require six cycles of latency and they prevent the execution of other multi-cycle instructions for an additional three cycles."

<comment><USER20> There could be an instruction scheduler impact here as well. Intel processors are known for having an uncommonly deep execution window.

It turns out that the Nth wyhash64_x doesn't depend on any of the multiplies in the N-1th iterations. It only depends on the addition of the zeroth order constant.

So, with a sufficiently deep pipeline, the instruction scheduler can effectively be in the middle of several of those wyhash iterations all at the same time, thus hiding nearly all of the hash's latency by using the other iterations to do it.

Such are the perils of micro-benchmarking.

<comment><USER18> Indeed. Of course, the idea that this is invalid implies that "real" application code (whatever that is) would be designed to have a sequential dependency on a single wyhash64 result and to sit on its thumbs waiting. Maybe, and maybe not. One can make up any argument one likes.

</comment></comment></comment></comment><comment><USER21> Uhm, isn't the article title obvious? It would be rather surprising if they had the same characteristics.

<comment><USER22> Sure, but it may not be intuitive to people that one function could be exactly as fast on two very different processors, but another very similar function would be orders of magnitude different.

<comment><USER23> This was pretty common in the RISC heyday. The competition meant lots of jockeying to lead benchmarks from Sparc, Alpha, PA-RISC, Power, etc.

This seems to be on the rise again with AMD and ARM being closer to Intel in servers than they were in the recent past.

</comment></comment></comment><comment><USER24> Novice here ... but how do these results give random results? Are the uninitialized memory considered random? Or is there some other source of randomness. It seems like a deterministic function to me if the variables are initialized to zero.

<comment><USER25> They are deterministic.

<comment><USER24> Why wouldn't one use some sort of pseudorandom seed instead of just uninitialized memory? Couldn't one sample a clock, image sensor, thermometer or some other sensor that would have a random value to use as a seed? Seems like a part of memory allocated by the compiler might always be zero.

<comment><USER26> There's no uninitialized memory. File-scoped variables are initialized to 0 in C.

</comment></comment></comment></comment><comment><USER27> I am very confused isn't mul a 64bit multiply on arm64? Or is this a comparison of a 64 bit processor to a 32bit one?

<comment><USER10> He's trying to get a 128bit result from a 64x64 multiply.

<comment><USER27> ahhhh ok

</comment></comment></comment><comment><USER28> Are there differences in speculative execution?</comment>


Why Vegetarians Are More Intelligent Than Meat Eaters - <AUTHOR> https://www.psychologytoday.com/intl/blog/the-scientific-fundamentalist/201005/why-vegetarians-are-more-intelligent-meat-eaters <comment><USER2> Correlation doesn't imply causation. People with higher IQs self select for more education and are exposed to more eco-philosophy as a consequence.

Also, people with higher IQ self select for higher paying jobs and are better able to afford the more expensive vegetarian lifestyle.

Also, IQ is linked to better nutrition and educational opportunity and having parents of a higher economic class with likely higher IQ so again the higher in economic standing your parents are, the more likely you will be presented with environments that will teach vegetarianism.

(That said, as a high IQ person with all those advantages, I still eat meat some of the time.)</comment>


Silicon Valley Bank is setting up shop in Canada - <AUTHOR> http://business.financialpost.com/news/fp-street/silicon-valley-bank-is-coming-for-canadas-burgeoning-tech-scene <comment><USER2> Russian money</comment>


What's a software engineer, anyway? - <AUTHOR> http://www.nczonline.net/blog/2012/06/28/whats-a-software-engineer-anyway/

<comment><USER2> In some set of states, a "software engineer" isn't anything. To use the term "engineer" there, you must meet a rigid set of requirements; I don't think software has ever become an acknowledged field, such as "civil engineering".</comment>


Show HN: Preemptive Multitasking on an AVR Microcontroller - <AUTHOR> https://github.com/TurkeyMcMac/avr_threads <comment><USER2> Ahhh this reminded me of when I as a teen saved up and bought "Assembly Language Master Class"[1], the only assembly-related book I could find in my local bookstore that didn't look like a complete intro-book. I had learned a bit of asm from some articles I had downloaded from various BBSes, and wanted to take the next step.

After reading through it a few times I got the idea to try to write a pre- emptive scheduler myself. This was way before the internet so I just knew the concept existed, and the book didn't have anything like that in it per se. So I spent a day or two figuring out by my self how to preserve and restore the registers and flags without disturbing them.

I wrote it in Turbo Pascal, using the inline asm for the task switcher. Each "process" was just a procedure (subroutine) that ran in a loop until a global bool was set.

I decided to hook the RTC[2] for switching tasks, but nothing more. So each time-slice was fixed at 18.2ms which didn't make things terribly interactive.

Never got further, it was more of a "can I do it" type project, but boy that feeling when I saw my three "processes" running one after another without cooperation... priceless!

[1]: [https://www.amazon.com/Assembly-Language-Master-Class- Press/...](https://www.amazon.com/Assembly-Language-Master-Class- Press/dp/1874416346)

[2]: [https://en.wikipedia.org/wiki/Interrupt_request_%28PC_archit...](https://en.wikipedia.org/wiki/Interrupt_request_%28PC_architecture%29#Slave_PIC)

<comment><USER2> Ah found the code. Not pasting the whole thing, but here's the relevant bits of the task switching. Keep in mind this was me with a few years of programming in general under my belt so yeah, still bit of a noob.

        type
            task_type = record
                              stack: array[0..1023] of byte;
                              eax, ebx, ecx, edx, esi, edi, ebp, esp, eip, flags: longint;
                              es, ds, cs, ss, fs, gs: word;
                         end;
            task_type_ptr = ^task_type;

        procedure MTaskHandler; assembler;
        asm
           cli
        {  save vital information }
        {
           eax, ebx, ecx, edx, esi, edi, ebp, esp, eip, dflags: longint;
           es, ds, cs, ss, fs, gs: word;
        }
           db $66; mov word ptr [@@tmp], ax
           db $66; mov word ptr [@@tmp+4], bx
           db $66; mov word ptr [@@tmp+8], cx
           db $66; mov word ptr [@@tmp+12], dx
           db $66; mov word ptr [@@tmp+16], si
           db $66; mov word ptr [@@tmp+20], di

        {  get ip }
           db $66; xor ax, ax
           pop ax { pop the ip from stack }
           db $66; mov word ptr [@@tmp+32], ax { ip }

        {  get cs }
           pop dx

        {  get flags }
           db $66; pushf
           db $66; pop ax
           pop ax
           db $66; mov word ptr [@@tmp+36], ax { dflags }

        {  save bp and sp after the modification }
           db $66; mov word ptr [@@tmp+24], bp
           db $66; mov word ptr [@@tmp+28], sp

           mov word ptr [@@tmp+40], es
           mov word ptr [@@tmp+42], ds
           mov word ptr [@@tmp+44], dx  { cs }
           mov word ptr [@@tmp+46], ss

        {  setup own stack }
           db $66; mov word ptr [@@bp], bp
           db $66; mov word ptr [@@sp], sp
           mov word ptr [@@ss], ss

           db $66; xor bp, bp
           db $66; xor sp, sp
           mov sp, offset Stack + 1022
           mov bp, sp
           mov ax, seg Stack
           mov ss, ax

        {  restore data segment }
           mov ax, seg @data
           mov ds, ax

        {  call old interrupt }

           pushf
           call dword ptr Int8_Save

        {  save task info }
           mov  dx, word ptr [@@cur_t]
           mov  bx, dx
           shl  bx, 2

           les  di, dword ptr Tasks[bx]

        {  skip stack }
           add  di, 1024

        {  save register info }
           mov  cx, 13
           push ds
           mov  ax, cs
           mov  ds, ax
           mov  si, offset @@tmp
           db $66; rep  movsw
           pop  ds

        {  get next task }
           mov  dx, word ptr [@@cur_t]

        @@task_loop:

           inc  dx
           and  dx, 7
           mov  bx, dx
           shl  bx, 2

        {  load task info pointer }
           les  di, dword ptr Tasks[bx]

        {  if valid task, go out }
           mov  ax, es
           cmp  ax, 0
           jne  @@got_task

        {  if looped, exit }
           cmp  dx, word ptr [@@cur_t]
           je   @@exit

           jmp  @@task_loop

        @@got_task:
        {  save new task id }
           mov  word ptr [@@cur_t], dx

           jmp  @@exit

        @@exit:
        {  restore information }
           mov  dx, es
           mov  si, di

        {  skip stack }
           add  si, 1024

        {  save register info }
           mov  cx, 13

           mov  ds, dx
           mov  ax, cs
           mov  es, ax
           mov  di, offset @@tmp
           db $66; rep  movsw

        {  restore registers from prev. task }
           db $66; mov bx, word ptr [@@tmp+4]
           db $66; mov cx, word ptr [@@tmp+8]
           db $66; mov dx, word ptr [@@tmp+12]
           db $66; mov si, word ptr [@@tmp+16]
           db $66; mov di, word ptr [@@tmp+20]
           db $66; mov bp, word ptr [@@tmp+24]
           db $66; mov sp, word ptr [@@tmp+28]

           mov es, word ptr [@@tmp+40]
           mov ds, word ptr [@@tmp+42]
           mov ax, word ptr [@@tmp+46]
           mov ss, ax

           xor ax, ax
           xor ax, ax

        {  set new return address and return the proper way }
           mov ax, word ptr [@@tmp+36]
           push ax
           mov ax, word ptr [@@tmp+44]
           push ax
           mov ax, word ptr [@@tmp+32]
           push ax

        {  restore used register }
           db $66; mov ax, word ptr [@@tmp]

           iret

        {  temporary storage }
        @@tmp:
        {
           eax, ebx, ecx, edx, esi, edi, ebp, esp, eip, dflags: longint;
           es, ds, cs, ss, fs, gs: word;
        }
           dd 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
           dw 0, 0, 0, 0, 0, 0
        {  current task }
        @@cur_t:
           dw 0

        @@bp:
           dd 0

        @@sp:
           dd 0
        @@ss:
           dw 0

        end;

<comment><USER3> cool code, but oof. can you make that a link to a pastebin? my scroll-wheel finger would thank you.

<comment><USER2> Not anymore :(

But point taken for next time!

<comment><USER4> There's edit for comments.

<comment><USER5> And there's a time limit after which that opportunity is gone.

</comment></comment></comment></comment></comment></comment><comment><USER6> From the github:

>> I do not see a practical use for this library, but I think it's interesting.

+100

This is the essence of hacking.

<comment><USER7> indeed. Yet I might have a use for this library in a project I have no practical use for.

</comment></comment><comment><USER8> I'm looking at these long series of pushes and pops [1]. You have 26 general- purpose registers plus X, Y, Z. I wonder if it would be possible to have e.g. only 4 threads and have dedicated registers for each thread, avoiding the need to store/load all of them on each context switch. This would reduce the overhead and might make this a bit more usable in the real world.

I mean, this is certainly possible when writing assembly. But I wonder if you can convince avr-gcc to do it. To have it limit its use of registers for a part of the compiled C code.

A similar problem appears with interrupt handlers in C [2]. avr-gcc is smart enough to only push/pop registers in a handler that were actually clobbered in the code. But if you call a function pointer from an interrupt handler, it will always push/pop entire CPU state since it will assume that the code the pointer points to will potentially clobber everything. This significantly increases interrupt latency.

[1] [https://github.com/TurkeyMcMac/avr_threads/blob/master/avrt....](https://github.com/TurkeyMcMac/avr_threads/blob/master/avrt.S#L133)

[2] [https://www.avrfreaks.net/forum/calling-function-pointers- is...](https://www.avrfreaks.net/forum/calling-function-pointers-isr)

<comment><AUTHOR> Maybe one could use the option -ffixed- _reg_ and put different threads in different compilation units with different options. Even so, one would not be able to use the standard library, since it is not compiled with the right options, and even custom functions would have to be compiled separately for each thread. It would be a lot of hassle, but it might work.

<comment><USER9> If you are gonna go through all that work with this chip in particular, you'd probably be better off putting four of them on one board. It's all kinda moot with more powerful chips available for cheaper anyway.

<comment><USER8> It's always interesting to explore how far a thing can be pushed software- wise. Copying bits is free and small AVRs are literally cents per piece in large quantities.

</comment></comment></comment></comment><comment><USER10> > /* Don't change these flag values! */

Rant:

It always annoys me when I see comments like this in the source. If it is important enough to implore people not to change something then it is surely important enough to explain why.

When I saw comments like this during code reviews I always asked the author to add a comment that briefly explained the reason for the values being the way they are.

Of course this was rather rare because most developers don't write many comments in the first place.

<comment><AUTHOR> You're right. I have added a description. Thanks.

<comment><USER11> I love the HN live code review.

</comment></comment></comment><comment><USER12> I wrote a pre-emptive, multi-threaded OS for the AVR atmega 128 back in college as a sensor networking operating system called Mantis OS (mos). For anyone interested in this direction, it also provides a device layer and "drivers" for timers, ADCs, eeprom, serial port, networking, etc. A great group of folks kept improving it for years so there is a lot there to learn from just as a resource too.

[https://github.com/rosejn/mantis](https://github.com/rosejn/mantis)

<comment><USER13> I also wrote a preemptive threaded operating system for AVR atmega 128.

At the start we had threads, pipes between threads, serial io, interrupts.

After we finished the project, I ported the system to standard UNIX system calls. Now I can tinker on it, and get full access to GDB/prints/profilers. I use signals, timers and pipes to simulate interrupts, clock and serial ports respectively.

Because I'm targeting UNIX it's pretty easy to get started and build little toy experiments. I haven't gotten it to compile on AVR for 10 years. But I have been maintaining it as a playground for new ideas.

Some recent additions are resumable functions (like python generators), A lisp user space, and a performance regression test suite.

[https://github.com/andrewguy9/kernelpanic](https://github.com/andrewguy9/kernelpanic)

</comment></comment><comment><USER14> I love it. The next level of this hack would be integrating it with the Rust/AVR work and building pseudo-threads with memory and thread safety on the platform (for no reason other than to do it).</comment>


Improving the GitHub Workflow for the Microsoft Community - <AUTHOR> https://github.com/blog/1989-improving-the-github-workflow-for-the-microsoft-community <comment><USER2> Looks like a step in the right direction, where a lot of other developers already are. When they were pushing TFS, I didn't know if it was a 'me too' kind of move, or an attempt to provide an MS proprietary solution, or what. But getting in step with a lot of other developers, and hopefully playing nice, will get them a seat at the table with all developers, instead of projecting an attitude of: the world revolves around us. MS has been making some remarkable announcements at this Build conference, and making it easier for developers to get into MS technologies as well. This is a much better approach than when Ballmer was CEO.

</comment><comment><USER3> I guess the biggest functionality here is the ability to create repositories easier from within VS?

Because Visual Studio already has very good integration with git. I probably only use git from the command line once every couple of months.

<comment><USER4> Yeah, not sure about this either. What's exactly the point in having that Github UI in VS ?

A IDE is for writing code not integrating all kind of crap into it......

<comment><USER5> I'm pretty sure "integrating all kind of crap into it" is the distinction between an _integrated_ development environment and other environments for writing code, like a simple programmer's editor (though the line is somewhat fuzzy, and programmer's editors _also_ tend to integrate all kind of stuff, and provide extension points to integrate more.)

</comment></comment></comment><comment><USER6> GitHub gearing for a Microsoft acquisition OR am I reading too much?

<comment><USER7> Probably reading too much, in this case.

But since you mention it it'd make a lot of sense for Microsoft to want to buy Github.

Microsoft has been doing a _lot_ of cool stuff engineering-wise in recent years. They've released so many FOSS projects I've lost track[0]. But they still suffer from a problem of being "uncool" because of their past reputation. Which was deserved, but they've changed a _lot_ [1]. Microsoft needs a new brand for their FOSS work, because the Microsoft brand is badly tainted in the FOSS world.

Github is one of the few companies that could earn them respect in the FOSS world if they were to acquire them (and of course, not screw everything up).

[0] Heck, I've literally lost track of the number of FOSS things they've released _this week_

[1] Fifteen years ago, could you imagine Microsoft hosting a launch party for Debian? Because that's what they did this last weekend: [http://openness.microsoft.com/blog/2015/04/21/microsoft- debi...](http://openness.microsoft.com/blog/2015/04/21/microsoft- debian-8-linuxfest/)

<comment><USER8> IMO it would tarnish Github more than it would redeem Microsoft.

You don't become cool by buying the cool new gadget-of-the-week just as you don't become cool by buying a cool company.

Ill be comfortable calling them cool when they've demonstrated they no longer follow Embrace Extend Extinguish but until then they don't deserve the benefit of the doubt.

As far as I'm concerned they realized they tried to move to fast into the extinguishing phase so they're taking a step back into the extend phase. Im not falling for it.

<comment><USER7> > Ill be comfortable calling them cool when they've demonstrated they no > longer follow Embrace Extend Extinguish but until then they don't deserve > the benefit of the doubt.

I'm not saying that Microsoft _doesn 't_ still have this intention to some degree. It's impossible to prove a negative, especially for such a large and fragmented company.

But it's inconsistent that Microsoft still receives so much hate for having practice this a decade ago, when there are companies that are literally doing it today, in the plain light of day, in very large ways, and receiving far less criticism than Microsoft does.

I say all this as a Linux user typing in Iceweasel from a Debian machine that has no non-free software on it except the wifi driver. I have no love for Microsoft or proprietary software, but they still receive so much criticism that it crowds out criticism of other companies that are just as bad _today_ (or even worse) compared to Microsoft _today_.

<comment><USER9> I agree. In fact I think github is doing more to extend and extinguish. They are the ones who just introduced their own proprietary closed method of binary storage while git-annex was already there.

<comment><USER10> If you're talking about Git-LFS, it's open source: [https://github.com/github/git-lfs](https://github.com/github/git-lfs)

The API spec is available here: [https://github.com/github/git- lfs/blob/master/docs/api.md](https://github.com/github/git- lfs/blob/master/docs/api.md)

There's a reference implementation here: [https://github.com/github/lfs-test- server](https://github.com/github/lfs-test-server)

</comment></comment></comment></comment></comment></comment><comment><USER11> Cool, Microsoft is a beast when focused. Wonder how long it will last.

<comment><USER12> It's almost surreal to see that one of the douchiest companies around is so radically transforming.

<comment><USER13> Maybe MS desktop OS division was sort of douche, or maybe desktop MS office is not all that innovative.

OTOH, MS Research was always very cool (and they started contributing to e.g. OpenBSD many years ago), OS kernel has always been much better than a glance over win32 API shows you, and Office365 is definitely world-class.

I suspect that the engineering culture in MS has always been rather good (with engineers like you and me, and many of them a good deal better); the radical transformation is probably mostly within the top management.

<comment><USER14> The kernel is _very cool_. I get to work near it, and their description of the NT multi-headed setup helped change my mind about Microsoft engineering. e.g. the POSIX subsystem is just another NT usermode head, so it's incredibly performant.

<comment><USER15> I am not up to date on the latest kernels - I last wrote an NT driver in 2002 (Win2K/XP compatible), but based on that experience I beg to differ.

My no-stalgia: It was an overengineered beast at the time, with an original grand vision that wasn't performing well enough, and seemed to be fixed with duct tape.

The Video Driver + GDI, originally conceived to be outside the kernel, was too slow - so it was moved back in, causing a lot of problems.

The IO subsystem was nicely abstracted with IRPs. Except it was too slow, so they added the "FastPath" interface, which fixed the speed but made it impossible to safely unload or stack drivers. IIRC, they were the main reason for the "PlugFest" parties, where microsoft would invite vendors to come to place and then install their drivers in random orders and to debug the collisions -- the fact that microsoft needed to organize these parties is an indication of how bad it was.

The POSIX subsystem was removed in XP/Server 2002. Perhaps you mean SFU? That was discontinued in 2004. Oh, you mean SUA (nee Interix). Well, that was removed in 8.1.

And your experience might be different, but "incredibly performant" is quite the opposite of my experience with the POSIX subsystem.

<comment><USER14> You certainly work(ed) closer than I do, my experiences are mostly based off of what I see around me. I assume the kernel has changed quite a bit since Vista. I imagine that the POSIX system hasn't been entirely killed off quite yet, given it's already come back twice.

<comment><USER15> The POSIX subsystem was never there for technical reasons. It was there for political reasons - back in the day, a lot of government and army contracts mandated a POSIX system, so Microsoft made sure they comply with the letter of the law. (The intended spirit of the law was to require a standard OS to avoid vendor lock in....)

And they've been trying to remove it since that political requirement was off the table. Except it turns out that it was actually in used by some customers, so they keep bringing subsets back.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Cool!

Forgive me, but what is the advantage of buying Github enterprise and then having it hosted in Azure? I was under the impression that most enterprise customers were interested in self hosting.

<comment><USER17> Azure is self hosting. If you have on-prem, it makes sense to host on physical gear, but most startups aren't at that phase of their lifecycle. GHE vs GitHub for me is a data lifecycle decision, and even with GHE on Azure, you have more control over your data than in public GitHub.

Influencing factors can be regulatory, policy, SLA, that sort of thing. A prior employer had a blanket policy against intellectual property in a public service no matter the security, for example. GitHub has reliability issues lately as well.

One practical thing I've heard is that it's really easy to accidentally make a repo public on GitHub (I agree).

<comment><USER18> Another example is the regulatory requirement for data sovereignty to ensure data remains under the data protection laws of the organisation's country.

With hosted Github you have no choice - data will presumably live on mainland US. With Azure/AWS/whatever, you can host your data in the most suitable location (always worth checking the contracts though)</comment></comment></comment>


Why podcasting is failing - <AUTHOR> http://www.thestandard.com/news/2008/04/11/why-podcasting-failing

<comment><USER2> This was a better article than I was expecting.

However, I'm not really convinced by the use of the word "failure". Podcasts may be less successful than their most breathless hype predicted... but what invention isn't?

Podcasts are a modest success. They're modest, in part, because the masters of podcasting turn out to be radio producers. This is _completely_ unsurprising -- the radio folks have been evolving their audio production skills in a competitive environment for nearly a _century_ \-- and it's the very un- surprisingness of it that keeps the phenomenon under the radar. Who besides advertisers knows or cares what the audience of a radio program is? Radio hasn't been the stuff of tech news since the 1930s.

The other problem with podcasting is that the term is badly chosen and too narrowly defined. The word is associated with downloading (rather than streaming), audio (rather than video), RSS (rather than simple web links), the use of portable devices for playback (rather than PCs), and amateur production (rather than pros). Youtube and its clones represent the same core phenomenon as podcasting -- ubiquitous, cheap distribution of audio and video over the web -- except that they offer better UI and lower costs for users, producers, _and_ advertisers. But somehow the word "podcasting" isn't used for Youtube.

It's not the podcasting phenomenon that's "failing": It's the _word_ "podcasting", and the specific constellation of technologies that it implies.

</comment><comment><USER3> In traditional radio, an interviewer had x-minutes to get the job done. The duration of the time slot was the hard limit they were working against and it ensured a tight focus on the content. You received a lot of information in a short burst of time.

Amateur podcasts by contrast can go on for however long the interviewer would like. The result seems to be an unstructured rambling chat rather than a to- the-point discussion, and you can't skim it like a blog post or text article to pull out the valuable points – you have to listen to the whole danged thing.

Perhaps if podcasts were set to have a hard limit of ten minutes we'd see a spike in quality? Much as Twitter forces a condensed to-the-point blog.

<comment><USER4> The downside to the time limits is that, often, interesting programs get cut off too soon.

Podcasts will get better as better people start doing them.

</comment></comment><comment><USER5> Podcasting is failing because 99% of the population doesn't even know WTF "podcasting" is and won't even try to click "Podcasts" button or whatever. GMail would have failed miserably if they tried to replace "emailing" with "ajaxing".

For two years I worked at RSS company where technology didn't matter: what mattered was that people were too tired to learn yet another buzzword. Even now, while immensely useful, RSS is still used mostly by geeks.

Just use plain English goddamit.

</comment><comment> ten-seven Podcasting isn't failing. It's not meeting some people's expectations, but it's not failing. FTA I too get news from a podcast, since my commute may not take me through the next hourly update. With a little effort (and an AutoHotKey script) I get my iPod charged, and it's ready to go when I am. I also get the weekly Maximum PC podcast (rant on, Gordon!).

I don't care much for video podcasts, since I'm driving.

</comment><comment><USER6> I think podcasting is failing because it's too much work to get a podcast where I need it - in the car.

If I'm at a PC, I'd much rather read a transcript of the podcast - it's much faster for me to read than to listen.

<comment><USER7> Most stereos sold these days come with a front auxiliary jack that you can plug an iPod (or any other portable music player) straight into. Many aftermarket stereos come with iPod dock connectors or USB connectors. I've installed one in my car and it makes it painfully easy to listen to podcasts in the car. Yeah, it'd be great if iTunes would wirelessly beam my podcasts to my car, but having them on an iPod that seamlessly integrates into the car stereo is a close second.

<comment><USER6> I have the same - but there are still 2 big problems:

1) Finding new great content

2) Even when 1) happens, I don't update my ipod (it usually stays in the car).

<comment><USER5> Well... by now it should be obvious to everybody that

a) Your cell phone and your iPod should be the same device

b) It should always be connected to the Internet

c) It should be an open platform that everybody could develop for: I suspect you'll have no issues finding software that downloads your picks into your phone automatically.

The industry, however, is fighting hard to postpone this reality. Not just Verizon, Sprint&Friends (closed networks, locked phones) but even Apple themselves (dumbed down iPhone API, draconian control over developers)

<comment><USER6> Once these things happen, podcasting may well take off. I know I'd use it much more.

</comment></comment></comment></comment></comment><comment><USER8> My girlfriend is just finishing up teachers college and a large portion of her course was spent on technology in the classroom.

I heard her talking about podcasting once and she was told at a conference in January that podcasting was the future and teachers should be integrating it into their classrooms and this and that.

That said neither of us could figure out how to best introduce podcasts into a classroom without them being at best a simple distraction(neither could the presenters it would seem as they gave no ideas either).

That fact is though that there are a lot of new teachers that will take these peoples word as gospel and try to introduce podcasting into their classes which is the start of the cycle.

So podcasting may not be a huge success now but possibly the kids that are currently in elementary school will be the first group to truely embrace the idea of non-live radio?

<comment><USER9> I think if you were interested in a particular area, and could download an audio commentary that contributed to this, then that would be useful. For me, pod casting is a new attempt on an old idea called "push" that wants to steer the internet towards broadcast rather than browsing. Consumers spoke on this long ago.

A more fleshed-out version of what I've written here: [http://cratuki.blogspot.com/2008/04/technology-is- so-1998.ht...](http://cratuki.blogspot.com/2008/04/technology-is-so-1998.html)

</comment></comment><comment> patrickg-zill I would have thought that a lack of search capability would matter. How many neat pages or sites have you come across due to searching via Google? There is currently no easy way to search the podcast content for stuff I am interested in.

<comment><USER10> Maybe there's an opportunity here. The article points to a number of aggregation issues.</comment></comment>


Ask HN: LinkedIn blocking public profiles? - <AUTHOR> Confirmed by users around the world, it seems like LinkedIn started to hide every profile behind an "authwall" - even the ones explicitly set to public. Fiddling with the settings don't work and don't make profiles public any more, in any form, not even name and image.<p>Had anyone noticed the same or is it an anomaly? <comment><USER2> LinkedIn hates it when people crawl their site, lost a lawsuit that prevented them from using the law to stop crawling their site, so now they use technical measures to make it harder.</comment>


The Programmer Dress Code  - <AUTHOR> http://www.codethinked.com/post/2007/12/The-Programmer-Dress-Code.aspx <comment><USER2> Surely I cannot be the only programmer around who enjoys dressing well and taking a certain amount of pride and interest in my appearance. Hacker news and The Sartorialist are the two first bookmarks on my bookmark bar and I find the both equally inspirational.

<comment><USER3> I do not enjoy dressing well and I have no _intrinsic_ interest in my appearance. Nevertheless, it is sometimes useful to engage in signalling when dealing with the outside world (e.g., superficial investors, superficial women). For this reason, I have an _extrinsic_ interest in my appearance.

A service I'd pay for: I send you a photo of myself, my measurements and money. You make me look good.

<comment><USER4> > A service I'd pay for: I send you a photo of myself, my measurements and > money. You make me look good.

I think this exists. I can't think of any names but I know I've heard of basically this concept.

<comment><USER5> Somewhat, perhaps, more cumbersome, but very workable, is to hire yourself a personal shopper for a day. Those are available at all major cities.

That person will guide you throughout the day while you go out and buy the stuff society at large would like to see you wear. End the day with a visit to a, from them, suggested barber and you're set.

<comment><USER3> This is probably closer to what I'm looking for, though ideally I'd be able to avoid the actual "going shopping with them" part. However, until my ideal service exists, I'll probably hire a personal shopper if I lack a girlfriend.

Also, there is sometimes a principal-agent problem; many personal shoppers work for the stores, and simply buy for you whatever the store is trying to get rid of.

</comment></comment></comment></comment></comment><comment><USER6> Given that we tend to prefer low-to-no maintenance grooming choices, I'm surprised more hackers don't shave (or closely buzz) their heads:

1) You can do it yourself. Never pay for another hair cut.

2) You don't need shampoo or conditioner. Just use whatever you're already using on the rest of you.

3) _Nothing_ needs to be done to make it presentable.

4) It's never itchy or hot or in the way or anything.

5) Works great if you're balding -- confident, like you've accepted the inevitable.

6) You look more like a Buddhist monk.

<comment><USER7> But you have to maintain it every couple months or it starts to look scruffy. If you're accustomed to a long hair look, you can forget about it for several months at a time.

I'd wager that regular maintainence is the mental cost those guys are trying to avoid.

<comment><USER6> I've never understood that argument. Whatever time you may save on monthly upkeep is lost many times over on daily (or at least, hopefully, weekly) washing and brushing and pony tailing, etc. I rebuzz my head about once every two or three weeks and that is literally _it_.

<comment><USER7> Ah, but time spent is not what we are trying to optimize.

Washing and brushing one's hair does add time to daily tasks, but it is not a lot of time. Not compared to general time spent going to the bathroom, showering, eating. That time as a whole _could_ be greatly reduced. By moving and concentrating vigorously, one can get through the shower in 120 seconds, through breakfast in 45. Hang out with ex-military types and you will see this behavior. (You will also see buzz cuts.) This sort of thing is pointedly _not_ what hackers generally do.

We conserve mental effort. Not because we are lazy, but because we have only so much mental effort to use in a day, and we want to use all of it on very specific tasks. Concentration is currency. Remembering things has a cost. Routine, menial tasks are almost free. In fact, like play, they can have a slight negative cost. They allow the mind to wander. For many of us, shower time is often _productive_ time. But even when it's not, we attempt to get through it, not with a minimum expendeture of time, but with a minimum of mental fuss. Not going fast, not going slow. Just getting through it and thinking about other things.

Hence, daily hair maintainence is not really costly. It's a routine. But remembering to schedule a haircut or assessing whether it's time to get out the razor is one more thing to think about. One more thing to remember.

One cannot attack complex problems without proactively and repeatedly clearing the mind of unnecessary details. Abstract and forget. This is a critical skill. Avoiding periodic hair maintenence is an extension of that. Perhaps a silly one, but an extension nonetheless.

For some, maintaining a hairstyle is a specifically chosen hobby, and that's fine. But for everyone else, forgetting about your long hair is a habit borne of simple good intellectual hygeine.

<comment><USER6> Just to be clear, the styles we're comparing are buzz vs. long (pony-tailable) hair, right? Because the lengths in between are the real attention-sappers -- scheduled retail hair-cuts and at least some sort of daily styling, which requires (sometimes a lot of) attention.

You make good points. And we've successfully moved from the mundane to the philosophical. But as far as maintaining a clear mind, I can weather a head- buzzing every few weeks without suffering any serious thought-train derailment. I even find it rather meditative. There's something purifying and exhilarating about shaving one's head -- it's like throwing away a lot of useless shit you've been accumulating, or putting one's mental baggage astern. My head feels lighter -- and it is!

</comment></comment></comment></comment></comment><comment><USER7> Optimization. Our peers don't care how we dress. In general, they don't _see_ how we dress. We communicate through code and email.

On the other hand, our peers do care about our writing, so our writing is always stylish. The spectrum among hackers starts at cocktail party and runs through business casual and black tie clear into zoot suit. Not a slobby "i agree" in sight.

<comment><USER8> This, absolutely.

I've actually moved to wearing just striaght-up all black all the time. I'm a tall skinny young dude, so skinny jeans + band tshirt is even almost in style!

Half the reason that I've done this is because I can just reach in my drawer and put on anything, and it works. It may not be as optimal, but it's good enough.

</comment></comment><comment><USER9> It's because we all secretly want to be Gandalf.

<comment><USER10> A code wizard is never late, nor is he early; he arrives precisely when he means to, usually around ten-thirty to eleven.

<comment><USER11> And 7am if they're married.

</comment></comment></comment><comment><USER12> This was good -- although I have to say, we femgeeks don't generally sport beards, I don't think. The rest still applies though.

</comment><comment><USER13> Reminds me of this awesome flash game: <http://www.malevole.com/mv/misc/killerquiz/>

</comment><comment><USER14> Matz (ruby) is alleged by the following article to have grown a beard due to the claim that they correlate with language success: [http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/...](http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer- languages-and-facial-hair-take-two.aspx)

</comment><comment><USER15> "The first thing you will need to get started with Emacs is a beard." -- Wilhelm Bierbaum

<comment><USER16> You might be right. Vim users seem to get by without it (<http://www.moolenaar.net/kopk.jpg>). TextMate users just need a soul patch.

Hmm, does this mean there's a marketing opportunity for hipster-oriented Emacs screencasts?

</comment></comment><comment><USER17> Please, add DHH.

Seems to have a Puma sponsorship :)

</comment><comment><USER18> My priority is comfort, both physically and socially, that means if I'm somewhere decent, or important it's compfortable to be dressed properly. OTHO I work from home and during the summer time I'll be damned if I'm wearing anything besides shorts and a t-shirt.

</comment><comment><USER19> In my teens i got influenced by punk, and I've been wearing black t-shirts with jeans with holes in them, had unkempt hair and have been shaving every 2 weeks or so, ever since. Yes, i actually try to look like a homeless person as a fashion statement.

</comment><comment><USER20> Surely Dennis Ritchie and Ken Thompson are the winners as the masters of the style. I saw them at a Usenix convention 20 years or so after the picture in the posting. Their beard were much fuller and much grayer, beer bellies of remarkable proportions and wearing shorts and Hawaiian shirts.

(Now, was that where I got my Digital Equipment eye-shades with the flashing lights. Think so.)

</comment><comment><USER21> Somewhat related: programming language inventor, or serial killer? <http://www.malevole.com/mv/misc/killerquiz/>

</comment><comment><USER22> I'm wearing a yellow polo and pink plaid linen shorts today.

<comment><USER23> I think the article was talking about work wear not golf wear.

</comment></comment><comment><USER24> lol...great post!

</comment><comment><USER25> under GVR:

"...he has an afro that would make Snoop Dog smile."

LMAO</comment>


XSS Attack Embedded in an ERC20 Token Contract Steals Thousands - <AUTHOR> https://hackernoon.com/how-one-hacker-stole-thousands-of-dollars-worth-of-cryptocurrency-with-a-classic-code-injection-a3aba5d2bff0 <comment><USER3> >Thus, users of EtherDelta must enter their public wallet address and private key when using the site, meaning their private key could be captured from the browser session by a malicious code injection.

This isn't some sort of fancy cryptocontract based attack. The private key is just stored as a JavaScript object in the session and an attacker found and exploited a reflected XSS vulnerability to send off the key.

Even if you're not sending your private key to the server directly surely some people must have made these users aware of the risks they were taking? Not only XSS risks, but risks of a rogue admin or backend compromise injecting malicious JS.

<comment><USER3> (Persistent XSS actually, but exploited similarly to a reflected XSS vulnerability because you have to send a specific link to your victims. It has a much higher exploitation success chance than reflected XSS since pesky browser XSS auditors won't be able to step in.)

</comment></comment><comment><USER4> I'm surprised and disappointed that EtherDelta doesn't use Content-Security- Policy headers. They pretty much solve XSS.

Google has a good introduction to using them here: [https://csp.withgoogle.com/](https://csp.withgoogle.com/)

<comment><USER5> You will need to disable inline scripts which is inconvenient. CSP looks more like as hack for broken sites.

<comment><USER4> Personally and from experience, I think inline scripts are generally a bad idea often abused for hacky one-off tweaks, so the fact that CSP blocks them by default is a bonus to me. But for the cases that they do make sense, there are ways to allow them with the nonce property.

CSP doesn't mean that people should forget about proper HTML encoding of user input, but it means that when a developer messes that up somewhere, the issue is generally a minor formatting glitch rather than an exploitable flaw that lets attackers do whatever they want with users' browsers within your domain (like steal thousands of dollars). It's some invaluable defense-in-depth.

</comment></comment></comment><comment><USER6> > I want to make one point clear: I believe that EtherDelta, in concept, is > safer and more "trustworthy" than a traditional exchange. Everything about > how EtherDelta functions is transparent and verifiable by users.... The > attack detailed in this piece could have been identified by anyone before it > was exploited, and if there had been a security review protocol in place, it > would have been easily prevented.

Even "in concept", releasing fintech software without doing the security basics verges on professional misconduct.

<comment><USER7> This blows my mind. These programmers can implement quite complex contacts- financial-exchanges on top of a quite complex distributed system, but then fail to sanitize user input in their web interface. It makes no sense.

<comment><USER8> Well, from my blog post three days ago, discussed here:

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

"I put it to you that it's impossible to write secure web apps."

<comment><USER9> This is like saying "It's impossible to perfectly secure a bike on a city steet" when it gets stolen because you forgot to engage the lock. I have fuzzers that would of likely found this pretty quickly.

<comment><USER8> I doubt that. What sort of fuzzer is going to create an Ethereum smart contract of a very specific type, insert JavaScript into the contract title, insert the contract into the Ethereum block chain, synthesise the correct URL (which doesn't contain any JavaScript) and then detect that data from the backend was emitted unescaped?

Someone else in this thread said, well, serves them right, they should have used CSP, and then someone else pointed out that doesn't work for inline scripts, and there was a reply of the form "only stupid people use inline scripts" although this is news to me, as nearly every website I see uses inline scripts of some form or another. This whole discussion looks like people in denial.

The problem here is that XSS is so easy to create. A jungle of half-broken workarounds, mitigations, static analysis tools, fuzzers etc doesn't change the basic truth that the web is a fundamentally unsound platform on which to do secure coding. Data and code bleed together far, far too easily - <USER2> design.

<comment><USER9> I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.

<comment><USER8> The article was updated. Apparently there were two different XSS at the same time.

One is the exploit I describe above: data taken from the block chain was not escaped properly.

Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page.

[https://github.com/etherdelta/etherdelta.github.io/issues/14...](https://github.com/etherdelta/etherdelta.github.io/issues/143)

The reason is, the data after the hash was not escaped.

Perhaps a fuzzer would have caught that. But a good tool would make it hard to make such mistakes by default. A desktop app would not have suffered from such errors, by construction. The web is not a good tool.

<comment><USER9> >A desktop app would not have suffered from such errors, by construction. The web is not a good tool.

While you are correct it would not of suffered from this particular vulnerability, a improperly utilized malloc for example could have similar if not more disastrous effects and would be exploitable under the same threat model. Yet I wouldn't call it a bad tool, just a tool used by an inexperienced carpenter.

<comment><USER8> Yes, but modern desktop apps tend to be written in GCd and bounds checked languages.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I read the headline and my immediate guess was cryptocurrency. I clicked and, sure enough, there it was.

Maybe it's time to refine some of these ideas? While regular money does get stolen, maybe storing it online isn't the best method? Maybe requiring some human interaction is a good idea?

At this point, I can't really justify investing in any cryptocurrency. I'm absolutely unable to justify investing in any ICO.

If I opened a contract and my PayPal balance disappeared, I'd be pretty angry and might have some recourse. I'd absolutely have some options if it were with my credit/debit card or directly through my bank.

Good luck, folks. I'm still going to maintain the wait-and-see approach.

<comment><USER11> The story is almost like the 2008 time where wall street wiz kids package the mortgages to special mortgages back securities/contacts and resell them over and over again to banks, mutual funds, etc.

Hugh hype was created.

Last time: It was safe because it was back by mortgage.

This time: It is safe because it is back by crypto algorithm.

Last time few smart insiders got billions richer and unload everything before the bubble burst.

And the time ...... (Love to see all imaginable endings to this time's story - good or bad)

<comment><USER10> In 2007, I sold my business. In 2008, I put a bunch into the stock market and property. It was comparatively dirt cheap. I made a killing.

I'd do the same with cryptocurrency, but I can't figure out how. My 2008 investments were pretty risk-free. Of course the economy was going to recover. It always does.

I've no idea how to do that with cryptocurrency.

<comment><USER12> What are you having trouble figuring out? Happy to help people into crypto

<comment><USER10> Basically, how to bet that it is going to plummet in value and make money on that process. I figure it's a bubble and there's going to be a popping, even if it is done by force of law.

These ICOs are starting to make powerful people angry. Thefts like this one are starting to get regular media coverage. At some point, probably soon, the governments are going to come and clamp down on it.

Is there a way to long-term short Etherium or Bitcoin?

<comment><USER13> Media coverage is negative only because that's what people like to click on. I think government regulation will only legitimize it and bring it to the masses.

<comment><USER10> This very thread is about a negative. Would you rather they just ignore it?

<comment><USER13> Ignore? No. I found the story interesting myself & there's some nice discussion on here.

News would be boring if it wasn't for the negative stuff.

All I'm saying that one should always question the motives of the media & not necessarily conclude a general opinion just by reading a bunch of articles that landed on the front page.

As for the exploit itself, it's hard to believe that in this day and age XSS is still a problem despite so many solutions & fixes for it.

<comment><USER10> I'm not sure what is worse, the XSS or that the system allows transfer of assets without human intervention. Probably the latter, actually. Why would a coin system even allow that? That is, shall we say, not the best idea.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The smart contracts in Ethereum sounds awesome in practice and way more useful than Bitcoin mining but it seems like a giant security hole.

<comment><USER15> Kinda like a knife -- it's a very useful tool if used well and a very painful tool if mishandled.

<comment><USER16> You're assuming it's _possible_ to "use well". It's _delusional_ to believe it's possible to understand the subtle interactions within and between "smart contracts". Even if we ignore the ambiguity of the real world, malicious actors, and other complexity multipliers, we already know it isn't possible to know if a "smart contract" will _halt_.

Code will _always_ have bugs, and you cannot truly understand how something written in a Turing complete language will behave without running it.

> very painful tool if mishandled

Part of being a skilled craftsman is choosing the right tools, which includes understanding and respecting their limits. The language for writing contracts makes all state mutable by default, has ambiguous operators that change behavior depending on storage location or if the operand was a literal, and doesn't defined the order of evaluation for expressions, to name just a few of it's design problems[1]. This isn't a "useful tool:", it's a strong indicator of a another fractal of bad design[2].

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

[2] [https://blog.codinghorror.com/the-php- singularity/](https://blog.codinghorror.com/the-php-singularity/)

<comment><USER17> Isn't that something that can be helped by having a good standard library though (e.g. STL)? OpenZeppelin [1] is one example that comes to mind.

There are also other contract languages aimed to solve some of the limitations you mention, like Tezos/Michelson [2][3], which facilitate formal verification.

The issues you point out are certainly valid, but I believe people in the space are cognizant of them and are working on solutions.

[1] [https://openzeppelin.org/](https://openzeppelin.org/)

[2] [https://www.tezos.com/](https://www.tezos.com/)

[3] [https://www.tezos.com/static/papers/language.pdf](https://www.tezos.com/static/papers/language.pdf)

<comment><USER16> While a good standard library would help, the fundamental problem (undecidability) still exists. You could build a system that is understandable if you _only_ use calls into a (presumably proven/tested to be safe) standard library. At that point it would _de facto_ be a declarative language, which is decidable iff the grammar is _not_ Turing complete[1].

It's limiting, but you can still have many of the fancier features by baking standard versions of them into the language/stdlib itself.

> I believe people in the space are cognizant of them and are working on > solutions.

The problem with that is that this isn't a bug or engineering problem that we can solve with impossibly talented devs and a sufficiently large r&d budget. Questions about any non-trivial semantic behavior of a program (such as, "will the program halt"[2]) are known[3] too be undecidable[4].

[1] according to LangSec, the grammar needs to be deterministic context-free (or simpler). Anything more complex is undecidable.

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

[3] [https://en.wikipedia.org/wiki/Rice%27s_theorem](https://en.wikipedia.org/wiki/Rice%27s_theorem)

[4] [https://en.wikipedia.org/wiki/Undecidable_problem](https://en.wikipedia.org/wiki/Undecidable_problem)

</comment></comment></comment></comment></comment><comment><USER18> Don't you also have to trust that the person running EtherDelta hasn't modified what's running on the site...?

<comment><USER4> If you use EtherDelta through MetaMask or Mist, then EtherDelta doesn't have direct access to your private keys, and you're given a prompt outside of EtherDelta's control to confirm any action you take, so you're much less vulnerable to malicious behavior from the EtherDelta admin.

<comment><USER18> Aw, so there's some local client you run that you use to do the cryptographic bits, and the web client is just used to display results and let you navigate things?

<comment><USER4> Optionally yes, but EtherDelta specifically does let you instead use it in a normal browser if you give it an Ethereum private key. The hack only affected people who used it that way.

</comment></comment></comment></comment><comment> chroem- >thousands of dollars

The article is out of date. People are saying the amount is now $6 billion.

<comment><USER19> This linked to an 'unlisted' token (a token which doesn't have enough recognition to be 'officially listed' on Etherdelta, and thus doesn't have its own ticker symbol), which the vast majority of token buyers have no interest in, so there's no chance that many people were interested in purchasing it, let alone through Etherdelta (which still has very little volume relative to centralized exchanges).</comment></comment>


No Single Points of Failure - <AUTHOR> http://techblog.mdsol.com/2014/06/16/no_single_points_failure.html <comment><USER2> A good summary with one exception: the monitoring, instrumentation and logging didn't get enough attention. The failure is the norm so firsts and foremost you want to know when a failure occurs and then you need to be able to investigate what went wrong. You should literally monitor/instrument everything: every API call, every DB access, every page rendering should include code to monitor latency, result codes, payload size, etc. Every error (even benign) should be logged preferably with stack traces. Any unexpected condition should be checked and logged. All the instrumentation data should be graphed and stored for a long period of time so you can analyze the impact of your code changes on system performance and correlate it with system failures.

</comment><comment><USER3> I don't like 'no single point of failure' maxim because I think it leads people to make strange or incorrect decisions and neglect things in order to serve the maxim instead of doing what's best.

Being 'fail safe' is much more important than being redundant. That is, you need to design your product's failure. How well it works and how rarely it fails are important, but not nearly as important as how well it fails.

This means monitoring for knowing when it fails, auditing for knowing how it did fail after the fact, backups for after the fact, and most importantly (and harder to define) is predicting what can fail and how and designing your product's behavior after that failure.

<comment><USER4> I agree that monitoring and quick recover are important. It is hard to eliminate all points of failure.

My favorite failures are what I call "distributed single points of failure". An example is a linux bug that is triggered by a cron-job that is set to run at the same time across all servers.

</comment></comment><comment><USER5> There's always a single point of failure. The user.</comment>


Man compelled by police to undergo surgical procedure to "search for drugs" - <AUTHOR> http://www.kob.com/article/stories/s3209305.shtml#.UnlKY5TEqG9

<comment><USER2> Whoa, the colonoscopy, which is hardly a simple or safe procedure, really crosses the line of "first, do no harm" ([https://en.wikipedia.org/wiki/Primum_non_nocere](https://en.wikipedia.org/wiki/Primum_non_nocere)). Echoing jlgreco, all the "doctors" involved should lose their licenses to practice and be barred from ever gaining one in the US in the future. Ditto the equivalent for nurses.

Of course, I know there are efforts to change the Hippocratic Oath et. al. to put "the good of society" before that of your patient, so maybe I'm just being old fashioned.

</comment><comment><USER3> Wow, those providers need to lose their jobs. Performing a surgical procedure without getting consent from the patient in a non-life threatening situation? Seriously messed up.

</comment><comment><AUTHOR> I am actually so naive, I would have thought no amount of probable cause could force any sort of medical procedure whatsoever. Under any circumstances. No matter what.

<comment><USER4> Yes, I too thought there was no such thing as a court-ordered colonoscopy.

<comment><USER5> There might be, but I don't see a court being involved here. Looks like the cops shopped around for compliant doctors.

<comment><USER6> They apparently got a warrant, but the "searches" were performed in the wrong jurisdiction and after the warrant was expired.

That a warrant could be issued for such a thing is a problem in itself; the judge that saw fit to sign that should be thrown out and any law that might permit such a thing needs to be rectified.

<comment><USER5> Oh, I misread that! Anyway, I think anal searches should be allowed, and getting a warrant is probably the right way to go about it.

<comment><USER7> Probably?

<comment><USER5> Well, if a cop sees a guy put a knife up there to hide it, maybe a warrant shouldn't be required. I think that's already covered by current law though.

On the other hand, the court is supposed to provide oversight, and clearly failed in this example. The warrant was overly broad, and may have been issued on bad information (we don't know what the cop told the judge to get the warrant). Either the court is not really keeping an eye on these cops, or the court itself needs supervision to stop it from issuing overbroad warrants.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is so outrageous that for a second I thought the article may be an Onion- type hoax. I hope that man sues the county and the police force. They need to be taken to task.

</comment><comment><USER9> How can appearing to clench one's buttocks constitute probable cause for a search warrant?

<comment><USER6> When we allow fear to consume us, when we _embrace and encourage_ fear instead of being ashamed of cowardice, then this is the sort of thing that becomes justifiable. The shear magnitude of the irrational fear of drugs is dumfounding, and creates a climate that nurtures shit like this.

<comment><USER2> " _The shear magnitude of the irrational fear of drugs is dumfounding_ "

Who says it has anything to do with that at this point?

The police-judicial system have a good thing going, now that real violent crime rates have overall precipitously dropped. Without pulling this sort of shit, if you'll pardon the topical expression, there would have to be layoffs in many police departments and courthouses, and that wouldn't do.

(For more on this theme, about how the police-judicial system (my words of art) need a steady diet of "the clueless", read _Arrest-Proof Yourself: An Ex- Cop Reveals How Easy It Is for Anyone to Get Arrested, How Even a Single Arrest Could Ruin Your Life, and What to Do If the Police Get in Your Face_ ([http://www.amazon.com/Arrest-Proof-Yourself-Ex-Cop- Reveals-A...](http://www.amazon.com/Arrest-Proof-Yourself-Ex-Cop-Reveals- Arrested/dp/1556526377/))

<comment><USER6> The People have traditionally accepted/embraced police state tactics and brutality to fight "the war on drugs" because they fear drugs. Without that embrace of irrational fear, we would have never given the police the tools and leeway they have today.

<comment><USER2> Which doesn't address my point at all. E.g. if you'd said "create[ _d_ ] a climate that nurtures shit like this." we'd be in closer alignment.

I've seen that totally irrational fear in well educated, nominally rational parents, where I get them to accept that The War on Drugs is creating a police state for their children to live in, and they still prefer it.

But I believe we're _way_ past that point, and if I'm right, if it's now institutionalized in a way where such fear has become irrelevant to its perpetuation, then you might want to listen to me if you're searching for solutions.

</comment></comment></comment></comment></comment><comment><AUTHOR> After a routine traffic stop.

<comment><USER6> Because he _" appeared to be clenching his buttocks"_.

There should be criminal charges for everyone involved in doing this to this man, including the doctors at the _second_ hospital they went to. The doctors at the first hospital rightly refused to participate, demonstrating that the doctors at the second could have as well. Instead they repeatedly raped him _after_ an x-ray showed that there were no drugs.

<comment><USER10> _and_ they try to collect the money for the procedures from the victim.

</comment></comment></comment><comment><USER11> The cops and medical professionals should be quickly shown the location of the unemployment line. When you read the things that were done, at least two digital anal examinations and three enemas, you can tell this was just to harass the victim. I don't think any rational person in society thinks such procedures should be made available to beat cops because someone clenched their butt cheeks.

</comment><comment><USER12> In America "peace officers" are now responsible for disturbing the peace, not for keeping it.

</comment><comment><USER13> If anyone is going to go down, it will be the doctors. The cops that went out of their way to anally violate a suspect will walk away, and absurd search warrants will continue to be issued on a flimsy notions.

The same search warrants that end up with your dog getting shot and possibly anyone else who might raise the slightest suspicion of being a threat to them in their midnight raid of your home.

</comment><comment><USER5> I don't think a colonoscopy counts as surgery. As bad as this is, we don't need hyperbole.

<comment><AUTHOR> I thought it counted as a "surgical procedure" if not surgery. It involves sedation/anesthetic and invasion of the body by medical equipment. I don't know, I am happy to change the title if you like.

<comment><USER2> Note that in a normal cancer screening one, the probe is used to snip off suspect pre- or cancerous polyps.

I'd keep surgery in the title.</comment></comment></comment>


Remove p21 Gene = Grow new limbs like lizards tail - <AUTHOR> http://www.physorg.com/news187879295.html#top

<comment><USER2> Article slightly overhyped. Title should be "Single gene finally pinpointed as source of unusual regenerative powers of MRL mice". They can't regenerate limbs, but they can regrow heart sections, ear holes, fingers, etc.

[http://www.fightaging.org/archives/2010/03/regeneration- in-m...](http://www.fightaging.org/archives/2010/03/regeneration-in-mice- through-a-single-gene-deletion.php)

The MRL breed existed for a while (created for another purpose) before their regenerative powers were noticed. Similarly, the p21-knockout breed used to confirm the findings here also existed for years, and no-one noticed they could regrow ear tissues without scarring, etc. Makes you wonder what else exists in the hundreds of common lab breeds.

Anyway, the significance of this is that from a single gene, researchers can now walk through the list of biochemical mechanisms that gene pertains to, and perhaps more quickly answer the questions:

a) do mammals still have all the necessary machinery to regenerate like salamanders? b) can it be activated easily?

My gut feel on the bigger picture is that evolution ditched regeneration in favor of cancer suppression in mammals - though mice are not a good example of that process in action, being pretty much cancer factories in comparison to other mammalian species. If you look at p21, it's central to all sorts of stem cell related and cancer suppression mechanisms. It's surprising and unknown as to why p21-knockout mice are so normal, frankly.

Cancer, embryonic development, and blastema-style regrowth in adult creatures all look quite similar in many ways. A heavy duty anti-cancer mechanism and regrowth of tissues in adults may just not be terribly compatible from an evolutionary perspective. Which isn't they aren't compatible from a biotech perspective; many small single or few gene changes that produce favorable outcomes have not been selected for, but demonstrated in the lab to increase mouse life span, boost cancer resistance, provide regenerative powers at little cost, and so forth.

</comment><comment><USER3> So, does that make it a valid question what evolutionary advantage was gained by _losing_ that gene ?

<comment><USER4> Maybe I misread the article, but it sounded like having the gene could raise one's risk of cancer.

<comment><USER5> It could (particularly since p21's suppression is related to general anti- cancer processes), though they explicitly said they did not observe it in the mice trials (they were actively looking for cancer).

<comment><USER6> Mice have short lives. I am not sure how frequent cancer is in mice compared to humans.

</comment></comment></comment></comment><comment><USER7> Wonder what happens if you _split_ a limb?

<comment><USER8> It'll be just like earthworms. You can cut off your finger and plant it somewhere and create a clone of yourself.

</comment></comment><comment><USER9> It's cuz p21 regulates the cell cycle (mitosis). p21 is a CDK inhibitor. CDK is necessary for the cell cycle to proceed past "checkpoints". So when you have p21, you have CDK inhibitors, so cell division doesn't proceed. No p21 = less inhibition = more growth. (And unchecked growth is one main cause of tumors).</comment>


Facebook, Facebook, Facebook + non-Facebook news - <AUTHOR> http://untether.tv/2012/facebook-facebook-facebook-non-facebook-news// <comment><USER2> Extremely informative and update to date news..</comment>


Ask HN: Review my prelaunch sign-up page - <AUTHOR>

http://www.coderstack.co.uk/
There doesn't seem to be very much written about how to best design prelaunch sign-up pages (especially for marketplace type sites where pre-launch momentum is critical to avoid the chicken&egg problem) beyond simple A/B testing guidelines, so it'd be great if I could get some feedback on what works/doesn't work.
I've made an attempt to mimic the "long sales letter" style pages that apparently convert well for ebooks, etc. But I'm not personally convinced that's the right approach for tech-savy users. <comment><USER2> I'm not your target demo either, but here's my 2 cents from a usability & web conversion perspective: I'd keep everything above the fold (or rather, don't make the page scroll at all) and keep the Get Notified, FB, Twitter visible (maybe on the right side, along with the copy. The get notified is your call to action - your goal is to convert people into giving you their email addresses - don't hide it at the bottom.

And yes, your copy can be tightened and be more compelling. good luck! :)

</comment><comment><USER3> I would suggest moving the 'sign up' form above the two column split. So you get the basic pitch, you see that there's a signup (if you are interested and say "what should I do next?") and if not, you've got text below to get them engaged.

</comment><comment><USER4> I am not your target demo, but here is my .02

\+ Clean, \- Too much text, looks daunting when you land on it

Personally, those "long sales letters" = leave immediately for me. Your site does not remind me of them, however.

</comment><comment><AUTHOR> Clickable: <http://www.coderstack.co.uk/>

</comment><comment><USER5> Is your e-mail link functionality active? Been a few minutes and nothing yet...

<comment><AUTHOR> I hope so, it's powered by mailchimp who I'd assume are fairly reliable.

Edit: I did one of my own email addresses and it took 12 minutes to get an email asking for confim. hmm might be time to switch over wufoo or something similar.</comment></comment>


Man Finds Card Skimmer On Bank ATM - <AUTHOR> http://consumerist.com/5200818/reader-finds-card-skimmer-on-bank-atm

<comment><USER2> Are these that unusual? It seems like I hear about cops finding these relatively frequently in the local news wherever I am. I haven't used an ATM in years without checking it out first and covering my hand so a camera can't get the PIN.

<comment><USER3> At least in the UK it's common enough that there are usually notices on the machine to warn you of suspicious devices attached to it and phone number to call...

</comment></comment><comment><USER4> This is an article about a similar skim on one of the machines for the Dutch railways:

[http://web.inter.nl.net/users/p.c.wiegmans/skimapparaat/inde...](http://web.inter.nl.net/users/p.c.wiegmans/skimapparaat/index.html)

<comment><USER5> Really fantastic work. The best touch was the camera lens actually was set inside the 'Houd uw PIN privé' sticker.

P.S. NL Hacker meetup? I'm noticing a few people from/in Holland recently.

</comment></comment><comment><USER6> Snopes also has a good explanation of card skimmers:

<http://www.snopes.com/fraud/atm/atmcamera.asp>

</comment><comment><USER7> How do they get the PINs?

Also, you would think these organizations would have enough money to produce something less sketchy. Was it attached with masking tape?

<comment><USER8> You only need a PIN to withdraw money from ATMs. Most debit cards can now also be used to shop, without specifying the PIN

<comment><USER5> Yeah but then most online places are going to require the extended information number, or a street address and other info which isn't on the card's magnetic stripe.

I suppose these guys could be setting up their own merchant accounts and finding providers who don't require this info. Or even creating fake cards and then using those. Both of those options seem a bit riskier to me...

</comment></comment></comment><comment><USER9> This has been known to happen where I live (Greater Toronto Area)

<comment><USER10> I moved to Toronto last year. One thing that I still can't wrap my head around is that a huge number of ATMs are open to the street. I always feel VERY uncomfortable getting money from them.</comment></comment>


Object detection: an overview in the age of Deep Learning - <AUTHOR> https://tryolabs.com/blog/2017/08/30/object-detection-an-overview-in-the-age-of-deep-learning/ <comment><USER2> The progress in this field is very exciting. But the last section of the fine article makes a really important point -- ultimately the training dataset defines the output that the algorithms can provide:

 _" Unfortunately, there aren't enough datasets for object detection. Data is harder (and more expensive) to generate, companies probably don't feel like freely giving away their investment, and universities do not have that many resources."_

Even ImageNet has only 200 classes. Imagine a person with a vocabulary of exactly 200 concepts trying to describe the world. As Wittgenstein wrote, "The limits of my language mean the limits of my world" \-- and the language we can teach to computers is still very limited.

<comment><USER3> Is this something that can be crowdsourced?

Mozilla is crowd sourcing voice data, for example: [https://voice.mozilla.org](https://voice.mozilla.org)

<comment><USER4> Yes, but somebody still has to pay or donate their time and the 'human' computational time require is pretty heavy for an object detection task.

It's also usually ideal to just have one person label one image, people often miss things or mislabel things. If you want low noise data, you need to have people repeatedly labeling the same image until they reach a consensus. The more objects the more opportunity for confusion, requiring more labeling.

You have probably been prompted to use captcha-like thing for selecting portions of an image containing a street sign. That's object detection, for a single class of object.

To answer your question, yes it should be crowdsourced, yes it is being crowdsourced, but the companies that are doing it are keeping the data to themselves because of the value/expense in collecting it.

<comment><USER5> From a company's perspective this is essentially their business strategy and perhaps it makes sense to crowdfund crowdsourcing or something along the likes of SETI@Home.

</comment></comment></comment></comment><comment><USER6> How far out are we from Object Detection that can identify at different scales? - i.e. angled, facing towards, rotated, skewed, etc...

We seem to have good OD that can create horizontal bounding boxes, but these bounding boxes seem to be generic estimates.

Even rectangle detection with these models can't identify the angle or skew of a rectangle in a frame (we get the same generic bounding box)

OpenCV seemed to have models awhile ago that could do this just fine.

<comment><USER7> You can re-pose it as a regression problem to detect the coordinates of the 4 corners in the case of a single object in the image.</comment></comment>


Apply HN: Hire neighborhood students to do your chores while you bloviate online - <AUTHOR> http://www.runnr.ca <comment><USER2> This is a duplicate: [https://news.ycombinator.com/item?id=11442689](https://news.ycombinator.com/item?id=11442689)</comment>


7 ways to raise money for your start-up - <AUTHOR> http://www.16thletter.com/2008/02/19/7-ways-to-raise-money-for-your-start-up/ <comment><USER2> Why does everyone always leave out one of the greatest ways to fund a company: customers?

Yes, I know, raising money helps you scale up to become huge ... but most startups never get to that stage. The easiest way not to run out of money is to make something that people want so much that they'll pay you for it.

<comment><USER3> Right on the money...

A few years ago I went to a talk with a serial entrepreneur with one of the most impressive CV's I've ever seen. This guy has started more than 40 successful companies, the first one when he was seven, and had one of his companies sold for more than a billion dollars.

His formula for success is respect for customers. He said that he has never started a company without first having at least one customer. He also insists on taking engineers to sales meetings because they are great at selling technical products: They understand what they are talking about and they think what they're doing is really neat. Customers notice that.

</comment></comment><comment><USER4> Interesting idea about govt grants. Never thought of that one.</comment>