YogaGlo Patent Dropped - <AUTHOR> http://yogainternational.com/article/view/yogaglo-patent-dropped

<comment><USER3> I read the claims, and this patent really is as stupid as described - <USER2> a yoga class from the back. The only thing of interest in the claims is having a "corridor" without students so they don't block the view of the teacher. Prior art is basically anyone who ever said "Can you guys move out of the way?"

Edit: The patent has a flowchart, which looks like a satire of patent flowcharts. It's a two-page flowchart of how to film a yoga class with silly steps like "Students arrive and set up their yoga mats", "Loaded into video editing software". It doesn't even make sense as a sequence of steps.

This is a much worse patent than the Amazon "white background" patent which at least describes a few things that aren't totally obvious to me, such as the positions and brightness of the lights and the choice of lens. (These things may be obvious to a skilled practitioner, though.)

Yoga patent: [https://www.google.com/patents/US8605152](https://www.google.com/patents/US8605152)

White background patent: [https://www.google.com/patents/US8676045](https://www.google.com/patents/US8676045)

<comment><USER4> Regarding the white background patent, I'm by no means a professional photographer but the majority of the items in their patent strike me as basic if not incredibly obvious to a photographer that specializes in this type of work. The first figure is a 4 point lighting setup, something that you could find in hundreds of different textbooks. Their lens selection ( 85mm ) is in no way novel. There is always some debate, but many photographers prefer either an 85mm or 100mm for portraiture. If you look around you will find groups dedicated to taking portraits with the Canon 85mm 1.2L. I'm having a hard time finding how their claim does anything other than describe almost every photography studio in existence. Many video and photo studios even have a white cyclorama built right into the walls, it is almost their default behavior to facilitate what the patent claims to be unique.

It is possible that their specific claims relate to some of their very specific ratios and distances, but it seems like a stretch to me.

<comment><USER5> I've commented this before, but Amazon's white background patent stresses that it achieves a seamless background with no need for post-processing.

There is a very good reason for this.

When this technique was developed, post-processing was done with a wand in a darkroom and electronic computers were yet to be built.

edit - actually, if you replace the camera with an audience, the effect predates photography. Infinity cycloramas being a popular set building technique in 19th century German theatre.

</comment></comment></comment><comment><USER6> The EFF named this "October's Very Bad, No Good, Totally Stupid Patent of the Month: Filming A Yoga Class".

[https://www.eff.org/deeplinks/2014/10/octobers-very-bad- no-g...](https://www.eff.org/deeplinks/2014/10/octobers-very-bad-no-good- totally-stupid-patent-month-filming-yoga-class)

<comment><USER7> Is there no penalty for applicants and prosecutors -- especially considering that for the latter patent prosecution is a part of their _licensed profession_ (assuming they are attorneys) -- for such apparently deliberate mis-representations?

It seems that as long as there is no or minimal cost for such abuse, it will continue.

</comment></comment><comment><AUTHOR> Also worth noting that the organization intends to continue a second application under a slightly modified set of parameters. [http://www.yogaglo.com/blog/2014/10/yogaglo- update-2/](http://www.yogaglo.com/blog/2014/10/yogaglo-update-2/)

<comment><USER8> Thanks for noting this. I'm hoping that a highly parameterized patent is also struck down for the same reasons, _especially_ if it's a subset of their previous patent.

It's funny how, knowing little about yoga, you can develop their scheme.

1\. It's a yoga class! Mats are often used, to provide traction and personal space. Arrange the mats in the room.

2\. Camcorder on the floor... Who does that? So you put it on a tripod, a few feet off the ground. Too high makes it unfamiliar for the viewer, like you're looking down on everyone.

3\. Focus on the instructor! But... the instructor walks off to help a student... Maybe try and capture more of the class by zooming out.

4\. Students stand up during poses and block your view of the instructor. Move their mats out of the line of sight!

Simply tightening the parameters doesn't make this less obvious, and their "look and feel" claim is nonsense.

<comment><USER9> The first patent wasn't struck down, yogaglo was granted the patent, then they dropped their rights to it.

</comment></comment></comment><comment><USER10> This is perhaps one aspect of government that could use an additional layer of bureaucracy. The patent application process needs an initial high-level review step to quash silliness like this before it gets through to the queue for nitty-gritty time-consuming review, which has been proven to repeatedly miss the forest for the trees.

<comment><USER11> Part of the problem is that, thanks partly to precedents from earlier decisions, 'obvious' and 'prior art' have taken on special meanings that do not conform to either common usage or common sense.

</comment></comment><comment><USER12> The title is wrong and misleading. It should be "YogaGlo Patent Dropped." They did not patent yoga; they patented a method of filming yoga classes.

<comment><USER13> Sounds similar to Amazon's patented white background photography.

</comment></comment><comment><USER14> This is a good example of why patent law is broken. I can understand patenting manufacturing process or designs, but you shouldn't be able to patent and idea such as an online shopping cart or a certain way to film something.

<comment><USER15> It seems that this is the whole point of patent law. It's a subsidy to people with access to money and power. That it may be used to some effect by smaller interests is a "happy" by-product of the scheme.

Once you grant that ideas are property and should be protected in the same way, it seems to me that this is the inevitable result.

</comment></comment><comment><USER16> > Needless to say, we were pretty shocked when on December 10th of last year, > YogaGlo's patent (U.S. Patent No. 8,605,152) was granted.

Anyone who knows software will not have been shocked at all!

<comment><USER17> When you're trying to incite emotion, you never want to give the impression of inevitability against your side. Even if you fully expected it to happen, you are still shocked, and possibly even appalled. It helps to give your readers an idea of what kind of emotions they should be feeling.

"Just as we expected, the patent was granted" \- Bummer. Wish there was something I could do about it. Next article.

"Needless to say, we were pretty shocked when the patent was granted." \- Oh my god! Even the experts think this needs to be handled! (I especially love it with the 'needless to say' part... it makes it sound so much more obvious that you should be outraged).

There's nothing wrong with writing like this (unless you're a serious journalist, I guess). I'm just pointing out why they stated the obvious the way they did. I'm pretty sure the EFF does the same thing in their patent posts.

</comment></comment><comment><USER18> It was a stupid proposition right from the get go. What surprised me what the time it took to drop it and the amount of attention it gathered, I mean, it was just a matter of time before it flopped.

</comment><comment><USER19> Why not link this article without #disqus_thread ? As soon as it opened I instantly went to the bottom of the page.

<comment><USER20> Mods: Can you fix the URL to drop the #disqus_thread target?

</comment></comment><comment><USER21> If I may play the devil's advocate for a moment here, what if the filer really did come up with a new way of filming yoga classes that actually is much better, which everyone then proceeded to copy? I don't know if that's the case here, and I am not sure exactly how I feel even if it is. Should any idea be free for anyone to copy once it's "out there"?

<comment><USER22> This kind of patent is nothing more than what clever and dedicated people could do. I'm sure that in the history of filming one could find such setup - for how many decades have instructional videos be produced?

They just, as good weasels, found a weaselly way to patent an not-so-special idea, and patented it, with the assumption that if somebody finds a similar way of filming, say, 4 feet from the ground instead of 3, he certainly _not_ going to have a few million dollars to proceed in court - we're talking about yoga, not android devices (ahem...).

Keep in mind, most importantly, that asserting that _this_ patent is ridiculous doesn't equal or implies that _any_ idea should be free for anyone to copy.

<comment><USER23> > nothing more than what clever and dedicated people could do

_All_ patents are "nothing more than what clever and dedicated people could do".

I'm not defending this particular patent, I just wanted to refute that part of your argument.

<comment><USER24> Depends on what you read into "clever", I'd say. The standard for novelty that the USPTO uses makes anything "obvious to a person having ordinary skill in the art to which the subject matter pertains" non-patentable.

[http://en.wikipedia.org/wiki/Person_having_ordinary_skill_in...](http://en.wikipedia.org/wiki/Person_having_ordinary_skill_in_the_art#United_States)</comment></comment></comment></comment>


Today's Smalltalk: A Second Look At The First OO Language - <AUTHOR> http://blog.smartbear.com/programming/todays-smalltalk-a-second-look-at-the-first-oo-language/ <comment><USER2> I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so.

It wasn't until OSX made Objective-C take off and Rails made Ruby take off that some of the fundamental language features entered the mainstream, and they did so with a gusto that other 'ivory tower' languages wish they could achieve. But only by leaving the image model behind.

It seems like something like Erlang managed to do what Smalltalk tries to do with the image better, allowing for easier to reason about deployment, collaboration, and version control while still letting you deal with a system of relatively opaque boxes of replaceable code.

<comment><USER3>
      But only by leaving the image model behind.

There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks.

That said, I believe the image is a very valid model, and I prefer working on a Pharo environment than anywhere else. However powerful text editors, IDEs and debuggers may be, you can never reach the same level of integration between tools and system if your tools, your language and your system are not the exact same thing.

<comment><USER4> Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven't seen ST implementation with good development tools that is not at least partially image based.

The problem I see with ST IDEs is the fact that most advanced features work by introspecting live image state and autogenerating some source code, which completely break any attempts to meaningfully define what is (versionable) programmer-written input and what is derived tool output.

<comment><USER3> True, they're partially image-based.

       In all I haven't seen ST implementation with good development tools that is not at least partially image based.

But what about Amber?

</comment></comment></comment></comment><comment><USER5> Smalltalk is incredibly cool, but I think one of the main things stunting it is it doesn't have a great free implementation. The only modern smalltalk environment I've used which felt like a serious environment was VisualWorks, and to download that you have to fill out a form and you can only use it under a "personal use" license.

Squeak, despite being impressive, has always felt like a toy. I like Pharo in spirit, but GUI wise, it looks really off. If I can use a weird metaphor to describe it: it's like reading a brilliant PhD thesis written in Comic Sans. That's what the GUI reminds me of. The content is brilliant, but the presentation really leaves you scratching your head. I know it's not fair to judge an entire development environment off its aesthetics, but people are going to do it anyway.

<comment><USER6> I get what you're saying, but it's also really weird to me.

You cannot sanely use Pharo or Squeak to write native apps right now; that's totally true. You also couldn't do that for Visual Works, except for a very narrow window when they properly emulated enough Windows XP widgets you could probably fake it. But Pharo and Squeak proper look (to me) neither more nor less native than IntelliJ, which people happily use. Both have professional- looking IDEs that do not look native. That doesn't impact you if you're doing web work, command-line work, etc.

There are lots of other reasons I would finger instead (C interop was historically poor, people were historically reticent to use VMware-image-like language environments, etc.), but Pharo and Squeak have looked fine for most purposes for awhile.

<comment><USER5> You're probably right about visual works, I haven't used it since 2005 so I kind of fell in that window.

I don't have a problem w/ non-native looking GUI's in principle, but I just think Squeak and Pharo are kinda fugly. Bad spacing, weird colors, weird fonts. If that only effected my development environment I could live with it, but if the apps I make are also going to look like that? Ick. The only thing I'd really use it for is writing games where GUI's are always going to be custom anyway. (I think Smalltalk in general would be great for game development actually.)

Another thing is that at least in other smalltalks, it generally used OS windows at least. The controls might look weird, but it does feel like part of the system. Writing code in Squeak feels like you're either using a VM or Remote Desktop, it's just totally isolated.

The thing is most of these, in isolation, aren't deal killers, but once you've added up enough weird points it gets a bit too weird. You could make similar arguments about Java, but I think the difference is in magnitude: Java's weirdness is kind of weird, smalltalk's weirdness is really weird.

</comment></comment></comment><comment><USER7> There are a number of great answers on StackOverflow as to why Smalltalk wasn't more popular:

[http://stackoverflow.com/questions/711140/why-isnt- smalltalk...](http://stackoverflow.com/questions/711140/why-isnt-smalltalk- popular)

</comment><comment><USER8> Simula is generaly recognized as the first OO language, so it's a second look at the second OO language at best.

<comment><USER3> Correct. Although Smalltalk is generally regarded as the first one because the concept "object orientation" was first used in it.

Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely.

From Kay:

      «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.»

<comment><USER9> I think the reason many later OO languages "missed" messages completely is because the distinction makes little sense in more static languages that lacks a way to dynamically call a method/send a message.

<comment><USER10> And incidentally, dynamic dispatching is recognised as the key feature of OO: (Cook 2009)

 _Object-oriented programming is successful in part because its key technical characteristic—dynamic dispatch-is essential to supporting independent, interoperating extensions; and because interoperable extension is in turn essential to the reuse of architectural code (as in frameworks), and more broadly to the design of modern software ecosystems._

<comment><USER9> I'm not sure if you're agreeing or disagreeing with me.

Dynamic dispatch _is_ supported by most statically typed OO languages. C++ virtual member functions are dynamic dispatch. So indeed, dynamic dispatch is one of the key features that makes the distinction between calling methods and sending messages sufficiently un-important that static OO languages are still useful.

What was (perhaps too imprecisely) referred to in my comment above is late/dynamic _binding_.

</comment></comment></comment></comment></comment><comment><USER11> Nice article, but it fails to explain the experience using Smalltalk environment really is.

Smalltalk, like Lisp Machines, was originally a blend of GUI operating system, development environment and the first real IDE.

<comment><USER12> It's funny. Unix was also meant as an IDE (persistency, logic, machine and user interfaces). It seems they all were trying to reach the same goal in their own way.

<comment><USER11> I never saw UNIX as an IDE, given its command line interface with ed and vi as editors.

<comment><USER12> it's a different user interface paradigm, mainly it's not graphically sophisticated (independent streams of text vs dynamic bitmap overlays)and less time integrated (you have to define how and which script to run when something change). But at the time it was thought so, that's how I felt reading bits of this book [http://en.wikipedia.org/wiki/The_Unix_Programming_Environmen...](http://en.wikipedia.org/wiki/The_Unix_Programming_Environment).

<comment><USER11> My first UNIX experience was in 1993 with Xenix, followed by almost all commercial variants of it.

By then I was already spoiled with GUI environments from Atari ST, Amiga 500, Windows 3.x and GEM, as well as the typical MS-DOS IDEs from Borland.

So I never saw UNIX that way.

<comment><USER13> _UNIX is my IDE. perl5 is my VM. CPAN is my language._

ref: [http://shadow.cat/blog/matt-s-trout/but-i-cant-use- cpan/](http://shadow.cat/blog/matt-s-trout/but-i-cant-use-cpan/) | [https://news.ycombinator.com/item?id=968757](https://news.ycombinator.com/item?id=968757)

NB. Though I think someone else earlier (Audrey Tang perhaps?) made a similar quote (something like _CPAN is my syntax?_ )

</comment></comment></comment></comment></comment></comment><comment><USER6> If you've historically ignored Smalltalk due to its ecosystem or non-native UIs, I'd like to suggest you take a look at Amber ([http://amber- lang.net/](http://amber-lang.net/)), a Smalltalk that runs on Node and works great for web dev.

</comment><comment><USER14> Simula was the first OO language.</comment>


22nd Century C - <AUTHOR> https://procedural.github.io/c22/ <comment><USER2> I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types.

I've commonly needed _access to_ fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function."

"Just has to work" low level code was the norm during the 16-bit to 32-bit transition, so it was a fucking pain. Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit that to high-level languages that don't care about this stuff, and people using better practices like generic word-sized ints and size_t's in lower level code. Keep that stuff on the borders of the application.

I've noticed a decent-sized emphasis on type size in both Crystal and Swift, two not-entirely braindead newer languages. I don't get it, it's a big step backward.

<comment><USER3> C's normal integer types work the closer to the way you want. When you say you're returning an int, you're not really specifying the exact size at all.

For those who don't know, C's char, short, int and long data types aren't really "fixed size". The standard defines their order: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long), but the actual size of these integer types depends on the platform and compiler. If you want to use fixed size ints, you'd need to use the uint8_t, uint16_t, uint32_t types from stdint.h. Although interestingly enough C99 doesn't require the platform to provide these types, it only mandates the uint_least_n_t and uint_fast_n_t types (n=8,16,32..) which are guaranteed to be at least, but not necessarily exactly the requested width.

Now you may be thinking "sure the standard says they could be different, but they aren't really, a char is 8bit, a short is 16-bit an int is 32-bit a long is 64-bit". So here's a couple examples for you: many DSP platforms have a C compiler where char is 16-bit. Also Microsoft Visual c++ on windows on x86_64 compiles longs as 32-bit while GCC on Linux on x86_64 compiles longs as 64-bits.

>Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.)

I know you said it was smooth, and maybe it was for some applications. But for many others, the 32-bit to 64-bit transition actually caused a lot of problems! Andrey Karpov has already done a great job of categorizing many of them, so I won't waste my time repeating him, but you can read his list here: [http://www.viva64.com/en/a/0065/](http://www.viva64.com/en/a/0065/)

<comment><USER2> Yeah, I'm arguing that the situation you describe (accurately) is better than baked-in sizes all over the source code.

Use the platform-native types (whatever size they may be) unless you have a reason not to, then use <stdint.h> or an analogue. If CHAR_BIT is 13, let char be 13 bits: the platform probably chose that for a reason. When you have to pack it into a TCP header, do your strict fixed-width stuff there.

<comment><USER3> I completely agree with you when it comes to function return types.

For data structure fields, especially structs used many, many times like in very large arrays, I'd say it's sometimes worth using fixed size types to get better control over memory use. Using a 64-bit int for a field a 16-bit integer can handle will use up 4x as much memory. And if you've got a ten or a hundred million structs of that type, then it really adds up.

For example size_t is 64-bit on my x86_64 system. But modern x86_64 systems can only use 48-bit address spaces, so a 64-bit sized object can't even be addressed! Even worse is my cpu and motherboard have a 32gb maximum of RAM (for an effective 35-bit physical addressing limitation). And size_t is supposed to be able to store the size of any object in memory, but on this platform it stores things that won't fit in memory. So most of these 64-bits are wasted on modern systems. For files you can use off_t if you're on POSIX, but the C standard doesn't say anything about requiring size_t to be able to store any filesize in a filesystem.

Just using size_t is not enough to make your code work correctly on 64-bit size quantities either. For example, you make your strlen implementation return size_t, and you use size_t everywhere you do anything with a string. But can your application really handle strings that are bigger than the system RAM , or the hardware address space? Are your algorithms even efficient enough to handle the 4,294,967,295 byte maximum string size for a 32-bit system?

The effort to get your program to work efficiently on >32-bit quanities is often much harder than just using size_t instead of int.

So to me, when I see 64-bit size_ts being used everywhere in code that won't actually be able to handle working with >32-bit quantities, it just feels a little useless. Of course this is really more a complaint about how big size_t is on the x86_64 platform than it is a complaint about the idea of size_t in general. If only we had 48-bit size_ts (24-bit would be handy too!)

<comment><USER4> I strongly disagree with your sentiment.

If you wrote an application that's as efficient as possible without any wasted bits in the size_t type, it then only works on your machine.

If I wanted to run such an application on my supercomputer with 2TB of RAM (such machines exist), I would then have to recompile for a 41-bit size_t.

We use machine-neutral (but architecture-specific) size_t for these kinds of things explicitly to avoid recompiling on different machines that are instances of the same platform.

Said another way, binary distributions _could not exist_ if everything was made efficient for the underlying hardware. It would stink to have to recompile the world after upgrading RAM.

I'd rather have a few bits of wasted space (which are typically lost anyway due to struct packing) than lose intra-platform comparability.

<comment><USER3> A 48-bit size_t like I suggested could address up to 256TB of RAM. All modern x86_64 cpus are limited to 48-bits of address space, you're not losing any portability here.

Also consider my strlen example. Say you compute strlen by iterating through the whole string until you find a 0, then you return a size_t for the number of bytes you iterated through. That operation is O(n) in the length of the string. If you were to use my strlen function on a string whose length is greater than would fit into a 32-bit integer, say a 1TB string or something, then the function would take so long to compute it that it would be useless. To be efficient, you'd probably have to redesign your program to do some special things to handle 1TB strings, maybe some special algorithms, or some kind of indexing. Returning a 64-bit integer type does not mean that the function can actually handle working with 64-bit sized quantities. So if you have a lot of datastructures where you keep string length, why store them as a 64-bit size_t when your application would be completely unable to handle strings of that size without keeling over?

Of course you wouldn't really use a 48-bit size_t, because x86_64 cpus don't work well with 48-bit quantities.

</comment></comment></comment></comment></comment></comment><comment><USER5> You can write C in any language. You can also write any language in C.

The fact that it's possible does not imply that it's a good idea. Some of the macros here are in common use (e.g., countof, although often with other names); some will make experienced C developers say "what's this? Oh, you mean <insert expansion here>; why did you use a weird macro?"; and some, like the redefinitions of _case_ and _default_ are actively hostile and are guaranteed to result in bugs when exposed to experienced C developers.

For more of the same, see "things to commit just before leaving your job": [https://gist.github.com/aras-p/6224951](https://gist.github.com/aras-p/6224951)

</comment><comment><USER6> I'm not sure that 'address' is desirable.

        int adress adress adress foo;

vs

        int * * * foo;

Double pointers are extremely common and triple pointers show up now and then.

Also '__attribute__ cleanup' as far as I know only works with automatic variables that live on the stack. Mucking about with code execution and automatic variables as the stack unwinds is not a style I would like to see in general purpose C coding. Its the one type of automatic memory management that you get for free and can't really screw up.

The rest of the macro loops and so forth seem fairly standard. Its good to experiment and explore what you can do with the compiler and the preprocessor.

<comment><USER7>
       int double_address foo; /* ? */

Or is it _n_ steps away from ProducerObserverFactoryStragedy?

<comment><USER6> Actually, its not even an address its a pointer.

To get the address of an object you use the unary 'address of' operator '&'.

His macro was #define address *

The * is a pointer. You can declare a variable of type pointer to T with as many indirections as you want. int * * * * * * foo is fine. But you also use it to deference your object. bob = * foo;

You can't practically have a different name for each level of indirection to what ever the IS0 standard/Compiler limit is for * .

Also you end up with nasty indirections like this.

        **(*((struct foo*)(*bob.x))).y

Its nasty enough as it is without trying to name each pointer indirection.

</comment></comment></comment><comment><USER8>
        fn main() {
            println!("hello, world");
        }

I kid, I kid. This looks cool!

</comment><comment><USER9> Very cool! I wasn't aware of the cleanup attribute, can't wait to try it out:

 _The cleanup attribute runs a function when the variable goes out of scope. This attribute can only be applied to auto function scope variables; it may not be applied to parameters or variables with static storage duration. The function must take one parameter, a pointer to a type compatible with the variable. The return value of the function (if any) is ignored._

[https://gcc.gnu.org/onlinedocs/gcc/Common-Variable- Attribute...](https://gcc.gnu.org/onlinedocs/gcc/Common-Variable- Attributes.html)

<comment><USER10> FYI - here's defer implementation for both gcc/clang - [http://pastebin.com/EXZuRAdT](http://pastebin.com/EXZuRAdT)

</comment></comment><comment><USER11> The "case" and "default" overrides seem kinda dicey.

<comment><USER12> Yeah, that is probably what bothers me the most about this. I write C code almost everyday. I can't remember the last time I forgot a "break", but I do use fallthrough when it simplifies the logic. It also breaks even the simple case of having multiple labels for the same code.

Also, the for-loop overrides are ugly and pointless, IMO.

</comment></comment><comment><USER13> I don't get it. Could someone summarize/explain this.

<comment><USER14> I'm only guessing, but it looks like a C header file with a set of macros that produces neat-looking C code. Not sure what's the deal with the 22nd century thing.

<comment><USER15> It's a clever joke and rather cynical deconstruction of our industry. The author suggests that in 100 years the C language will not only still exist and be widely used, it will have advanced almost nothing at all due to the industry's inability to solve real problems and instead focus on virtue signalling languages such as Clojure and Ruby. The author hammers home his point by demonstrating how a simple header file can at once render the code unreadable, while adding absolutely no value at all. I think he or she is specifically talking about Silicon Valley here, though of course since the joke is expressed in code, one can only guess.

Seriously, I'd hope in 2100 we'd have pushed our systems languages beyond facile keyword redefinition. Maybe even towards concurrency and an actor model. Like I explored in my unfinished (sorry, shit happened) book "Scalable C".

Or, Rust.

</comment></comment></comment><comment><USER16> Maybe the author wanted this to be C99 compliant but a cool thing is that by using clang we even have lambdas. It's called blocks, the same as in Objective-C. [http://clang.llvm.org/docs/BlockLanguageSpec.html](http://clang.llvm.org/docs/BlockLanguageSpec.html)

I've been using them in all my new C code, since I'm stuck to clang anyway, and it's awesome.

</comment><comment><USER17> this is basically an updated version of iso646.h

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

...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.

<comment><USER18> Really? I haven't had a chance to dig into it and a quick google-based look- see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high- level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases.

Thoughts?

<comment><USER19> Sorry, you should do more research... :) Rust has great support for very low level operations. Maybe search for 'bitwise operators' or 'inline assembly'. Memory management is even _more_ explicit and strict than C, since you also have to deal with lifetimes and borrowing.

The best thing is, though, since Rust is such a young language, you can change it! Imagine trying to add a new language feature to C, something like the ? operator currently being evaluated for addition in Rust. It would take years, if not decades, to get those things in C. Even now MSVC is just rolling out support for C99.

I can definitely see Rust taking over C's current place in the market over the next decade or two. Better memory safety, higher-level constructs to improve productivity, more cross-platform compatibility, and modern libraries to deal with things like Unicode are a _huge_ draw.

<comment><USER18> Sounds like I should!

Thanks!

</comment></comment></comment></comment><comment><USER20> Still using header files in the 22nd century?

</comment><comment><USER21> It reminds me of libCello

[http://libcello.org](http://libcello.org)

</comment><comment><USER22> That is very impressive. I really like the cleverness and cleanliness of these "hacks".

Still... I wouldn't introduce it into existing/shared codebase due to risk of confusing everyone, and I will never start my own project in C again.

</comment><comment><USER10> I wonder if this is in any way inspired by this - [https://github.com/google/honggfuzz/blob/master/common.h](https://github.com/google/honggfuzz/blob/master/common.h) ?

I use there defer for both gcc/clang, countof(arr) -> ARRAYSIZE(array)

In any case, yeah, going through gcc/clang internals, and through C11 standards gives people some ways to speed-up and clena-up their implementations a bit.

</comment><comment><USER23> It looks like just a cross between Go, DLang and maybe something else. Maybe I'll use it to troll my programming teacher.

</comment><comment><USER24> This is so fucking stupid.

</comment><comment><USER25> Too little too late. Rust is already taking over, by the 22nd century C will be dead.

<comment><USER26> There will probably be C code running in 2100. That's only 84 years away. FORTRAN is now 60 years old and still going strong in scientific computing. (Partly because, in most other languages, multidimensional array support is worse.)

I suspect, though, that new successful languages will have automatic memory management, either GC/reference counting or Rust-type borrow checking. There's no reason for a new language with the lack of safety of C.

<comment><USER27> Dlang is actually quite nice and mature, although nowhere nearly as hyped as Rust, Go or Swift. You get a GC with the option of deactivating it and doing the memory management yourself, pointers and casts if you need them (you usually don't), an auto type, fast compiling times, among many other cool things.

[https://dlang.org/overview.html](https://dlang.org/overview.html)</comment></comment></comment>


XP-Dev.com gets taken offline by Goldman source code theft - <AUTHOR> http://zerohedge.blogspot.com/2009/07/breaking-news-httpwwwxp-devcom.html

<comment><USER2> Just goes to show you how little the "authorities" understand technology. If this had been a brick and mortar business it is highly unlikely that they would shut them down for 45 hours for one file. They didn't even bother to contact the owner of the site? The assumption that he is involved in the theft simply because he owns the site (which apparently is openly accessible) is asinine. You can just imagine the "authorities" talking in their little uniforms about "these hacker kids" while prodding the the strange boxes with their billy clubs.

<comment><USER3> I agree. An analogy would be closing a long-term storage facility because someone stored a bomb-making manual in one of its lockers.

Well, perhaps they would still close it and search for an actual bomb. But would they also close all of the facilities owned by the same storage company? More to the point, I guess, would they suspect that the storage company is an accomplice? Unlikely.

The problem is, hi tech is outside of the daily experience of most of the people, and much less understood by them. So they have to rely on experts and take the most conservative point of view (as potentially the least dangerous one). We have to be patient with them: education takes time.

</comment></comment><comment><USER4> If I ran Github, I'd put a link to this and a summary on the front page. I haven't heard a better argument for distributed source control.

The guy who uploaded the stolen code is a moron, but the other people using the site don't deserve this.

<comment><USER5> The guy says he was uploading OSS work he did at Goldmans, same as he did when he worked there. It's not unusual for Quant researchers who work in R or SciPy/NumPy to update the modules they use to build their models, that source code is copyright by the developers of the statistical language modules - Goldman's don't own it.

<comment><USER6> Eh ? Not sure what you meant there, but if you and your employer do have a contract that says "all work that you produce while working here is owned by your employer", my understanding would be that updates to those modules, when written for your employers are actually owned by them, no ? (well, within software licensing terms)

<comment><USER5> Let me know what wasn't clear. Most employers who use OSS apps - including R, SciPy NumPy and other statistical languages - are comfortable with staff fixing bugs in those languages and distributing their modified copies of the works.

</comment></comment></comment></comment><comment><USER3> Aleinikov, though Sergey, is no Brin, that's for sure.

More seriously, he obviously did a stupid move. Whether it was malicious or not, I do not know.

But the way the whole collection of servers goes down just because a single remote user has done something suspicious from a legal (not technical) point of view raises concerns, both of legal and technical nature.

One issue is whether a distributed server system would have been able to withstand what is technically an attack from the legal authority.

Another issue is whether there is a technical solution to a legal challenge, specifically, if it is possible to recognize an illegal action by technical means. And if it is advisable too (for example, I would hate to see watermarks in the source code or, more likely, udp/tcp packets, but I would hate it much more if a whole system went down).

This kind of attack may be more efficient than a DOS attack. Can it be prevented?

</comment><comment><USER7> I wonder... in what jurisdictions are these "oh a user is doing something bad, let's take out the company hosting that user with no warning" outages most common in? Most that I remember reading about were in Europe, but at the behest of US corporations.

Now, it does seem like this is a rare occurrence; data center problems are more common, so it doesn't seem like a reason to move just yet, but when it comes time to set up my European location, this is certainly something I will research and I will be less likely to host in countries more likely to give me an unplanned outage.

</comment><comment><USER8> this part got me thinking: _I then erased the bash history, he said, referring to a method of recalling commands used in previous computer sessions.Goldman security measures prevent such deletions, which tipped the firm off to his activities, prosecutors said._

Perhaps he would have gotten away with it had he not erased the bash history. Outside of that, there's probably a lot of data/operations moving about, and would be tough to spot, because I get the impression that he was up to stuff for a while and no one was the wiser.

</comment><comment><AUTHOR> it's scary how the actions of one of your users can cause prolonged outages, regardless of how redundant or robust your infrastructure setup is

<comment><USER9> I'd love to see what would happen if they tried to do this to a big firm like Google (or hell, GS). There would be congressional hearings.

<comment><USER10> Yeah, I would like to see what would happen if these files were in S3 instead.

<comment><USER11> They probably already are!</comment></comment></comment></comment>


Ask HN: What license to use for my open source project? - <AUTHOR> I am working on a open source project, but I have some difficulties in choosing the license.
1. Software will be open source (github source code)
2. I will run a paid hosted version (free version with paid plugins)
3. Anyone can use it for non-commercial purposes, otherwise pay for a license.
Question: What license type suits best for this? <comment><USER2> The first step is to realize that #1 and #3 are incompatible.

By definition, "open source" means people who acquire the software, including those who download it from its github project page, are allowed to use it for commercial purposes without paying for a license.

You cannot say that a project is "open source" if it has a license which restricts it to non-commercial purposes.

</comment><comment><USER3> This page by Github has pretty good outline of different Open Source license options: [http://choosealicense.com/](http://choosealicense.com/)

It also pops up when you try to create a file named LICENSE* on the website.

</comment><comment><USER4> I'd dual license it as GPL/Commercial. People can use GPL code for commercial purposes but its use will be limited, and any company serious about using it without risking legal issues will pay for the commercial version. Qt follows a similar model. You can look at AGPL if your project is SaaS.

</comment><comment><USER5> I had trouble with this recently. I wanted something that prohibited hosted copies and forks but was free in other respects. I couldn't find anything.</comment>


Stranger in a Strange Land: "Big Data" programmer meets HPC community - <AUTHOR> http://www.machinedlearnings.com/2014/02/stranger-in-strange-land.html <comment><USER2> The title was better before the edit, since "Stranger in a Strange Land" is a work of fiction, has been borrowed in many contexts, and the additional title material clarified that it was borrowing that title to talk about an experience in a particular field.

I'm always sad when titles get edited to "match the post" in a way that actually removes clarity as to what the linked material is.

<comment><USER3> Ok, I restored the "original" title.

For my part, I'm always sad when a meta comment that has nothing to do with the content of the post ends up getting voted overwhelmingly to the top. It's less your fault than that of the overwhelming upvoters. But it's an unfortunate glitch that reliably mars HN discussions, and I don't know of a good answer to it.

By the way, the reason we reverted the title in the first place is that the editorialized subtitle immediately provoked a bikeshed debate about the "communities" and whether they're really distinct or not—when the meat of the post is about things like fault tolerance in distributed computing.

<comment><USER2> (This is of course wandering down the same meta path, but...)

I've always wondered if it would be possible to tag comments with tags like "tangent" or "meta" (or whatever else seems good), and then apply sorts based on that (probably in some user selectable way).

> By the way, the reason we reverted the title in the first place is that the > editorialized subtitle immediately provoked a bikeshed debate about the > "communities" and whether they're really distinct or not—when the meat of > the post is about things like fault tolerance in distributed computing.

I disagree that the comment was a bikeshed debate: the article spends several paragraphs (and the first four!) talking about the relationship of the two communities, and the discussion of their relationship (both in the article and here) explained some of the ways that knowledge I knew about math intensive computing (and related technologies, such as GPUs) related to problems I hadn't previously worked on.

Exploring the relationships between subdisciplines, especially closely related ones like these, is a benefit both in the article and in the related discussion.

</comment></comment></comment><comment><USER4> I would argue that they aren't so much "separate communities" as two sides of the same coin. And to the extent that that isn't _entirely_ true, I'd argue that it's becoming more true over time.

Of course, I'm biased, as I went to school and did a degree specifically in "HPC" back when the NSF was pouring money into the field in the mid 2000's and pushing colleges to implement degree programs on the topic. But my background prior to that, and what I mostly did career wise even after getting that degree, is largely focused around the Java / Open Source / Hadoop / etc. world.

So now I build data warehouses using Hadoop and friends, while being informed by the things I learned writing tons of MPI and OpenMP code back in the day. And now that YARN has positioned Hadoop and a general purpose cluster framework, not tied specifically to Map/Reduce (you can implement MPI on top of YARN now), it starts to look more and more like these world really are just different aspects of the same thing.

Where there is a noticeable schism, to me, is the point made in TFA about how some jobs are more about IO and some are more about CPU cycles. IOW, sometimes a job is "big data" because the actual _amount_ of data is literally very large, but other times it's "big data" (or "HPC") because of the nature of the calculation being performed, even though the actual data might not be _that_ big.

I think there will always be a place for the Beowulf type clusters and MPI-CH and OpenMP and their ilk, but I am really excited about the things that you can do in Hadoop and Friends world these days. With the new found flexibility in Hadoop with YARN, and things like Hama (for BSP) and Storm / S4 (for streaming data), SAMOA & Mahout (machine learning / analytics), it's a fun place to play.

<comment><USER5> I'd say that the two communities here are just people working at opposite ends of a continuum of applications that run on large clusters. The HPC community is all the way at the end with tightly coupled applications, low data to computation ratios, and diverse communication patterns. The big data community is characterized by giant data to computation ratios, highly constrained and regular communication patterns, and loose coupling.

The fundamental problems are similar (fault tolerance, load balancing, scheduling) but the best approaches depend on where you are on that continuum.

<comment><USER6> I see that you talk about "large clusters". In the HPC community there is often made a distinction between clusters and supercomputers, where the latter implies fast interconnect between the nodes, allowing synchronization of data between the steps to be fast. Such fast interconnection is often required for some workloads like weather forecasting, simulation of biomolecules. On clusters without such fast interconnection, it is not possible to parallelize such problem beyond a dozen of processors. Real supercomputers can often be an order of magnitude or more expensive per CPU, but is required for such workloads. For such workloads, it is very important how data is moved around, and that is probably what they meant by data locality.

On the other hand, many other HPC tasks are possible to spread across cluster nodes, and for those tasks clusters are sufficient. In fact you will often be denied access to supercomputers for such workloads, and be told to use a cluster instead.

<comment><USER7> Many clusters have tight interconnect, yet I don't call them supercomputers.

Supercomputers are more defined by their capabilities and max capacities: they tend to be orders of magnitude larger in their max memory, and their ability to do X, Y, or Z. It's really just a term at this point, not something truly differentiating.

<comment><USER8> I agree. We have a 128 node cluster where I work (that has infiniband interconnect, etc), but I wouldn't call it a supercomputer. Some of my colleagues, however, have access to machines at various national labs (ORNL, e.g.) that I would call supercomputers. I suppose it's all relative, though. For someone who's only ever developed on a dual-core 2 GHz machine, a 128 multi-core node cluster might be considered the equivalent of The WOPR.

<comment><USER6> I agree that a 128-node computer would not be called a supercomputer regardless of interconnection, my point was more the other way, that a computer without fast interconnections would still be called a cluster, and not a supercomputer regardless of the number of nodes.

</comment></comment></comment></comment></comment></comment><comment><USER9> Despite the marketing stuff below, it's interesting to see the big players in each space partnering, the 2 communities have intersected for a while now:

[http://www.cloudera.com/content/cloudera/en/solutions/partne...](http://www.cloudera.com/content/cloudera/en/solutions/partner/cloudera- and-sgi.html)

[http://www.microway.com/hpc-tech-tips/hadoop-isnt-just- for-w...](http://www.microway.com/hpc-tech-tips/hadoop-isnt-just-for- web-2-0-big-data-anymore-hadoop-for-hpc/)

[http://www.cloudera.com/content/cloudera/en/solutions/partne...](http://www.cloudera.com/content/cloudera/en/solutions/partner/Dell.html)

[http://inside-bigdata.com/2012/10/16/bringing-hadoop-to- hpc-...](http://inside-bigdata.com/2012/10/16/bringing-hadoop-to-hpc-panasas- partners-with-hortonworks/)

[http://hortonworks.com/partner/sgi/](http://hortonworks.com/partner/sgi/)

</comment><comment><USER10> "Programming against an abstraction of a reliable machine" is just plain old separation of concerns. This is good engineering practice. You don't worry about low level failures in high level code, and you shouldn't introduce more high level failure modes than are necessary. Addressing failures in the appropriate layer is perfectly apt. If ECC is insufficient then revise ECC. Declaring the approach to be a fundamentally flawed is to challenge one of the pillars of good engineering.

<comment><USER3> This comment is a middlebrow dismissal. It dismisses the entire article with a woolly generality like "good engineering practice". Not only that, but it dismisses the entire debate that the article is about, as if it were an obvious non-issue.

This article is really substantive and deserves much better.

<comment><USER10> I beg your pardon, Separation of concerns is a fundamental principle of good engineering practice and that seems to be what the debate is about. I gave a couple examples in my comment, not just a vague dismissal (and it's not like SoC needs me to defend it).

OP's article made a few unsubstantiated claims about ECC and silent corruption. These are presented as reasons to abandon the entire approach of "programming to an abstraction of a perfect machine" rather than just addressing the allegedly insufficient failsafes directly.

</comment></comment></comment><comment><USER7> I used to work on supercomputers (Cray T3E to Seaborg era) and then joined google.

The difference between big data and hpc is rapidly disappearing. Many aspects that people ascribe to MR have been removed or varied to enable more HPC-like computing.</comment>


Show HN: HTML5 API for multivariate testing - <AUTHOR> http://xander.io

<comment><AUTHOR> Hi everyone,

We created this project in response to seeing many clients making changes blindly based on gut feeling, and not being completely satisfied by the existing multivariate testing solutions. We wanted a simple way to write variants in HTML(or haml or jade).

For those of you unfamiliar with this design technique, new designs are tested on a statistically significant portion of your users to test for higher conversion rates.

It's also MIT licensed and works with google analytics: <https://github.com/255BITS/xander>

Thanks for any feedback you have!

</comment><comment><USER2> multivariate or multivariant?

Full disclosure: I help with this project and it's quite awesome.</comment>


Nokia to iPhone 5C - Imitation is the best form of flattery  - <AUTHOR> http://www.businessinsider.com.au/nokia-immediately-mocks-new-iphone-on-twitter-2013-9

<comment><USER2> All been done before. iPod Shuffle: [http://images.apple.com/euro/ipod- shuffle/images/hero2.jpg](http://images.apple.com/euro/ipod- shuffle/images/hero2.jpg) iPod Classic 2009: [http://img.gawkerassets.com/img/18mm44f9lif04jpg/ku- medium.j...](http://img.gawkerassets.com/img/18mm44f9lif04jpg/ku-medium.jpg)

Surely this form of personalization must go back to the 1950s

<comment><USER3> Back to cave men, I'm sure</comment></comment>


Superfast rock-paper-scissors robot wins every time - <AUTHOR> http://www.bbc.co.uk/news/technology-24803751 <comment><USER2> They'd go into a nice super-fast loop if you put two facing each other

<comment><USER3> I want to see that now.

</comment></comment><comment><USER4> If you're going to "unveil a robot", then a better looking Scissors would be called for here.

The algorithm is also likely foolable by throwing what appears to be one symbol (e.g. rock), but then morphs into another symbol (two fingers go out late in the symbol formation, in order to present scissors upon completion of the movement).

A comparison of the reaction time of this robot vs. say... Google's automonous driving car, or vs. an automatic stock trading machine, might present the robot as interesting.

Multiple cameras and a wide variety of acceptable symbol geometries on the part of the human player (rock rotated 90 degrees, the use of two hands, etc) would add realistic complexity... and would require more complex recognition algorithms, likely slowing down the reaction time of the robot.

<comment><USER3> Beambot's link below is informative. Turns out this is actually an astoundingly versatile multifunction hand; the three fingers can each oppose each other and are fast enough to dribble a ping-pong ball 10 times a second, precise enough to use tweezers to pick up a singe grain of rice, and agile enough to throw a cell phone in the air and catch it with fingertips.

Rock Paper Scissors is only one trick of many, but of course it's the only one the media is interested in. Oh well.

</comment></comment><comment><USER5> And like most robot systems, you can "trick" the robot by just occluding its sensors. By the way... this robot hand can do other amazing feats of dexterity: [http://www.hizook.com/blog/2009/08/03/high-speed-robot- hand-...](http://www.hizook.com/blog/2009/08/03/high-speed-robot-hand- demonstrates-dexterity-and-skillful-manipulation)

<comment><USER6> > And like most robot systems, you can "trick" the robot by just occluding its > sensors.

I'd probably lose rock-paper-scissors if you blind-folded me, too.

<comment><USER7> Ok, I'll bite. Maybe I'm missing something, but isn't _chance_ the entire point of rock-paper-scissors? In that case, how would observing your opponent have any affect on the result?

Though I guess I'm backwards enough to have grown up calling it "Paper Rock Scissors", so I might be oblivious to something here.

<comment><USER8> Back in grade school, against certain opponents, I could "intuit" their plays. In retrospect, I was probably doing something akin to what the robot here does (recognized what their hand was forming before I make my play) + discerning a pattern in their plays.

Also, at this point I have no idea why we played rock-paper-scissors so much in 3rd grade, but we did.

<comment><USER9> I could beat my younger sister at RPS every throw. I couldn't have told you exactly how I knew, but I knew what she had decided to play whenever she started to move her arm. So I would reveal before her and still win... that freaked her out.

</comment></comment></comment></comment></comment><comment><USER10> Yes, if you consider it a win when you cheat.

<comment><USER11> I don't understand how using all your abilities to win is cheating? I think that is saying smart kids cheat on test because they are smart.

<comment><USER12> Cheating in rock-paper-scissors is changing your throw when you see what the other person is throwing. I can win every time if I see what you are throwing and can change my throw to beat it.

However, if we are okay with using all your abilities to win and not count that as cheating, I can guarantee I win every time against that robot. I'd just remove the power source.

<comment><USER11> Winning is winning, no matter how you do it? [http://en.wikipedia.org/wiki/Kobayashi_Maru#James_T._Kirk.27...](http://en.wikipedia.org/wiki/Kobayashi_Maru#James_T._Kirk.27s_test)

<comment><USER13> At that point, you're not even playing the same game, so how can you claim you've won?

<comment><USER14> Because you become Captain of the Starship Enterprise?

Or, because you've achieved the mission goals?

<comment><USER13> Kirk only got a commendation for that. He had to work for a long time after the Kobayashi Maru incident to get the Enterprise.

You're begging the question. Achieving the same goals with different rules is a different game. Using stilts and a machine gun to get a ball in a hoop is not basketball.

<comment><USER14> Yes, it's not a valid solution to the game of basketball, but it is a valid solution to the "get a ball in a hoop" game.

I don't think the Kobayashi Maru test rules said anything about "don't try to break the game". Success can result from relaxing an irrelevant requirement.

<comment><USER13> It's not irrelevant if it's the difference between winning and losing. Since you're already rewriting the scenario, why not just declare yourself the winner from the start? It would save a lot of effort.

<comment><USER14> Because the people aboard the Kobayashi Maru might live?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Now if they would only take this great invention into outer space like in one of my fav games: [http://www.youtube.com/watch?v=8Tq7QngiiLI#t=163](http://www.youtube.com/watch?v=8Tq7QngiiLI#t=163) .

</comment><comment><USER16> Wow! Physically superior things are superior.

<comment><USER17> I bet robots can win arm wrestling as well!

</comment></comment><comment><USER18> This explains how I kept losing to the hobo with the robotic hand set up on a table outside that nightclub in Tokyo.

</comment><comment><USER19> Watching the video it still seems like I can still see that the bot is responding to the human. (I mean, I know that _is_ what it's doing, but I thought I wasn't supposed to be able to detect it.)

</comment><comment><USER20> I, for one, welcome our new robot overlords. Once they control rock paper scissors, they control the world.

On a less jaded note, this is a pretty neat computer vision application.

<comment><USER21> Holy shit, can you imagine getting into a duel with Yul Brynner out of Westworld with that kind of reaction speed?

<comment><USER16> > Yul Brynner out of Westworld

Dude, I saw that as little kid and it freaked me the hell out. Relentless bald man chased my nightmares for years.

Also, dude! I thought that movie too old / HN too young to remember that sci- fi golden age classic. Thanks for making my day. Although, I worry about bald bad ass chasing me tonight.

<comment><USER21> According to BBC's QI, a guy who used to teach actors how to shoot said that there were only two people who wouldn't blink when they fired a gun...

Clint Eastwood && Yul Brynner.

</comment></comment></comment></comment><comment><USER22> It's like playing Rock Paper Scissors with my son or step daughter! They never lose. However they don't have a 1ms reaction time...

</comment><comment><USER23> Wonder how it would fare with a rotating hand.

</comment><comment><USER24> sort of like HFT vs Regular traders?

</comment><comment><USER25> rock paper scissors lizard spock

</comment><comment><USER26> diplomacy will never be the same</comment>


Ask HN: What programming language syntax do you find amusing, witty, or clever? - <AUTHOR> Now, it's true that dissecting humor is a lot like dissecting a frog: No one laughs and the frog dies.
On the other hand, a collection of syntactical features can, in the words of James Geary, "fit easily into the overhead compartment of your brain and contain everything you need to get through a rough day at the office or a dark night of the soul."
So, what frogs do you keep in your overhead compartment? <comment><USER2> Tabs in Makefiles</comment>


Who said elevator pitches have to be simple? - <AUTHOR> http://blog.palantirtech.com/2007/12/04/what-do-we-do/

<comment><USER2> I will. That page might have been a nice intro to the field, but there's a much smaller version of it that I'm going to remember and that I'm going to tell other people. _That's_ the elevator pitch.

It also doesn't help that the "what we do" page starts by criticizing people who call them a data mining company. They apparently do make software for use in (one definition of) data mining.</comment>


Most men would rather shock themselves than be alone with their thoughts (2014) - <AUTHOR> https://www.washingtonpost.com/news/to-your-health/wp/2014/07/03/most-men-would-rather-shock-themselves-than-be-alone-with-their-thoughts/ <comment><USER2> A version without the paywall: [http://www.sciencemag.org/news/2014/07/people- would-rather-b...](http://www.sciencemag.org/news/2014/07/people-would-rather- be-electrically-shocked-left-alone-their-thoughts)</comment>


Women and the Civil Rights Act - <AUTHOR> https://blog.longreads.com/2016/07/07/women-were-included-in-the-civil-rights-act-as-a-joke/ <comment><USER2> The Civil Rights Act was designed in the 1960s when manufacturing was a common job for example. The problem is not because it included sex, but has to do with the basic idea of proving employment discrimination in the first place. This is why the "religious freedom" laws are also flawed. I think a good compromise is to only include certain kinds of jobs like manual labor under employment anti-discrimination laws.

</comment><comment><USER3> This is a bad title. Calling it a joke is misleading and click baity.

[https://en.wikipedia.org/wiki/Civil_Rights_Act_of_1964#Women...](https://en.wikipedia.org/wiki/Civil_Rights_Act_of_1964#Women.27s_rights)

<comment><AUTHOR> How would you characterise it?

It was added at the last minute by a segregationist who did not want the bill to pass, and was greeted with laughter when he introduced it (according to your own link, as well as the article).

Joke probably doesn't go far enough as it may have been a cynical political ploy to wreck the process, but it seems a relatively fair summary to me.</comment></comment>


Apple doesnt need to make cars .Right? - <AUTHOR> http://www.businessinsider.com/apple-doesnt-need-to-build-a-car-to-have-a-great-car-business-2016-5 <comment><USER2> I pointed this very theory out elsewhere.

Tim Cook has been a master of logistics for a LONG time now. I think he is well aware that the risk of an apple car, and the cost of doing it well are far out of line with the reward. Apple isn't interested in commodity items, and thats where all the profit in vehicles resides.

Apple does have a full ecosystem of technology that you would need to "own" the dashboard of a car. Entertainment (music and something that looks like radio) and Maps for the front seat; video, books and games for the back (upfront too if it is self driving).

Is it possible or likely that apple is building MORE into this car experience, it sure is. If your going to put that much processing power into entertainment, there is probably more than enough to spare to help with other aspects of self driving. Just let the people who are going to do that tap into it.</comment>


PG&E electricity shutoff confirmed for nearly 800k Northern CA customers - <AUTHOR> https://www.sacbee.com/news/california/fires/article235904227.html <comment><USER2> Reading this I imagined their management team sitting around a table discussing: "So the litigation happy people have sued us for billions, legislators refuse to protect us and insurance is not going to cover this at any affordable cost. Best move is to shut down power, that will avoid claims and make it known to Joe the Plumber that current policy is ridiculous." Other MT member: "But Bob, we're the power company, we can't turn off the power!" and the final conclusion being that best best chess move is to actually turn off the power.

I predict that they'll win and within the next few years local politicians are going to change something to ensure the power stays on.

<comment><USER3> Exactly. Some kind of middle ground needs to be found here - either a limitation of liability at some level or some kind of agreed-upon thermal event monitoring shared between PG&E and local fire departments. Otherwise the only business-viable alternative is to keep turning off the power. Burying equipment/lines would probably cost enough to bankrupt them.

Of course, the alternative for customers is to install a Powerwall or equivalent for these situations, so maybe this is good for Tesla/distributed grid proponents?

<comment><USER4> They're already bankrupt - filed for Chapter 11 at the beginning of this year.

What they should've been doing all along is maintaining their damn equipment - the reason we have regulated public monopolies is so that they can generate sufficient revenues to afford long-term capital investments that prevent things like this. There're a bunch of systemic failures here, some on the part of CPUC (California Public Utilities Commission) and some on PG&E management. But given that we're here, blackouts are probably preferable to burning up half the state again.

It does make me want to just go off-grid with a Powerwall and solar panels. If we don't actually get reliable electricity out of the deal, exactly what are we paying the electricity company for? But that's challenging as a renter, and buying (and maintaining) a house in California is equally challenging.

</comment></comment></comment><comment><USER5> This is where an $11 Billion wildfire settlement leads. If PG&E are being held financially responsible for the actions of their transmission and distribution lines in high wind events then I would expect them to fight for the right to not transmit and distribute power in those events. What's bad for consumers is even though you may not live in a high wind area the transmission lines ultimately serving you may be in one and subsequently shut off. On a more positive note, if these actions prevent wildfires that destroy property and claim lives then isn't it worth it?

</comment><comment><USER6> This kinda sucks, but what else are they supposed to do? It's already been established that any wildfires caused by their equipment will be their fault; cutting off power in case of potential wildfires would seem to be the only logical way to respond to that reality.

<comment><USER7> It seems like the right move today, but ideally moving forward we see an investment in infrastructure. (either in more robust transmission or more localized production)</comment></comment>


The rise of the startup landing pages - <AUTHOR> http://www.naivehack.com/2011/07/30/startups-landing-pages/

<comment><USER2> Whilst I agree that a one liner teaser page is not good, I will disagree about "It's a myth that people don't read long copy. Of course they do."

They really don't. But the article is misleading, because the 'long copy' example provided, the highrise teaser page, is not an example of long copy. It's a well formatted bunch of meaningful information, strategically designed and placed carefully (flow) that keeps enticing users to read more of it.

It's a well documented fact that people DO NOT read long boring paragraphs. They DO, however, read highly entertaining webpages with a fairly big copy so as long as it breathes and attracts them.

So to wrap up, yes write more than a sentence, no don't write a book. Instead, carefully craft sentences to entice potential customers to turn into real future customers.

<comment><USER3> Sorry, but I think you're making the common mistake of expecting that most people will react to a particular sales tactic the way _you_ would react to that sales tactic. Also, the example shown is absolutely a long form sales letter.

It may be true that people do not read long boring paragraphs, but I'd bet the research to which you're referring is not addressing ad copy. If it is, I'd like to see it. It is in fact well documented that long form sales letter DO convert better than short copy in many situations.

Read here for context of the example used: [http://37signals.com/svn/posts/2977-behind-the-scenes- highri...](http://37signals.com/svn/posts/2977-behind-the-scenes-highrise- marketing-site-ab-testing-part-1)

</comment></comment><comment><USER4> What is really bad is wasting months building software no one wants. Or finding out after the fact that your cost of acquiring a customer is too high to make the idea viable.

Sure there are people doing it wrong, but done correctly its a powerful tool that raises the odds that your startup will become a success.

<comment><USER5> In a lot of cases the cost of acquiring customers is high in the beginning. Thats a business scaling issue that you solve when you determine that you have a real business.

The landing page trend is just for early adopters, I would venture a guess that it has little to no impact on the success of a startup.

</comment></comment><comment><USER6> I'm not sure I follow. How can getting (for free) a long list of people who may be interested in the product once it launches be a bad thing?

I think the OP's main point is that instead of having a landing page you should be concentrating on product/market fit by describing the product. I think startups with these coming soon pages are already doing that, just not on their public website.

<comment><AUTHOR> Perhaps I wasn't clear. Collecting email addresses is fine, but make sure you're really getting people who are genuinely interested in your product. My point is that people shouldn't focus on hoarding emails. The focus should be on testing certain message, certain angle of the product, whether they like the future vision, etc...

<comment><USER6> So you're saying startups should be A/B testing their coming soon landing pages. That sounds like good advice. I'd be surprised if that feature were not on the todo list of the LaunchRock guys...

<comment><USER7> It might also be a good way to burn in your infrastructure.

I'm just saying, if you can't get a box collecting email addresses off the ground, your own todo list will take a _very_ long time to finish.

</comment></comment></comment></comment><comment><USER8> I am currently working on my pre-launch startup and I would consider spending five minutes putting up a landing page like that. Not really to collect email addresses, but so I have something on my homepage, so I can go on worrying about the more important stuff.

<comment><USER9> I spent 5 minutes (and $4) yesterday doing the same thing for <http://jsocial.io> <\- click here and be disgusted vantran.

It's (a) a placeholder, (b) incentive for me to stick to a launch date, and (c) it might, just maybe, collect a couple of email addresses.

I'm under no illusions that it's going to generate any sort of buzz, become vital, etc. It' just better than a 404 or something like [http://www.google.com/search?hl=en&gbv=2&tbm=isch...](http://www.google.com/search?hl=en&gbv=2&tbm=isch&q=page+under+construction) :-)

</comment></comment><comment><USER10> LaunchRock is sort of a victim of its own success. Now that every startup wannabe has a hipster.com like landing page, we're all getting sick of it and looking for something better.

<comment><USER11> It depends on your target audience. Perhaps if it is HN readers, but there are many markets that are not saturated by this type of launch site.

<comment><USER12> If your initial market for your new, innovative software company is early adopters then you're definitely a part of the problem of people getting burned out by these tactics.

</comment></comment></comment><comment><USER13> So recently we've seen that anyone with a web app has a "startup". Then, anyone with a landing page has a "startup"; is it now even worse? That you don't even need to make the landing page yourself, just fill out a form, and you have a startup :P

</comment><comment><USER14> Lots of opinion, no facts in the article. I would be useful if author split- tested personal/impersonal pages and told us about what gets the actual users engaged, rather than tell us what gets one random blogger aggravated.

</comment><comment><USER15> agree with author 100%. If startups can attract users using a cookie cutter template with vague wording on what they plan on doing, then more power to them. I believe a startup should actually take a few days to think how they can best relay their product with copy, screenshots, customer proof, on their landing page, and get some genuine adopters.</comment>


Dark – the trivial topic of evolution - <AUTHOR> https://medium.com/@maulikmmodi94/dark-the-trivial-topic-of-evolution-96e7d3b501b2 <comment><USER2> second article is on the way:)</comment>


The first genome data from ancient Egyptian mummies - <AUTHOR> https://www.mpg.de/11317890/genome-ancient-egyptian-mummies <comment><USER2> The article claims ancient Egyptians are more similar to people of Near East. " _The study found that modern Egyptians share more ancestry with Sub-Saharan Africans than ancient Egyptians did, whereas ancient Egyptians were found to be most closely related to ancient people from the Near East_ "

However, there is not enough sample data to make a universal assertion. What if Egyptian Pharos were a bit like European royalties, where the Austrian princess would marry the ruler of France or German royalty would marry the Russian Tzar. And these mummified people were prince or princes from Near East empires marrying into Egyptian royalty to forge political bonds?

<comment><USER3> You'd expect the Ptolemaic Pharaohs to be Greek/Turkish, I'd have thought. Not that this covers the whole time range examined.

<comment><USER4> No Turks in the region at that point in history. Turks are related to Mongols.

<comment><USER5> Most Turks are decended from the original people of Turkey - a bit like Hungary where it is very hard to find any central asian genetic contribution in the modern Hungarian population. Genes != culture.

<comment><USER6> Are you saying that modern Turks in Turkey are just Greeks that converted to Islam?

<comment><USER7> Although culturally Turks prefer the middle asia hun and monolian origin narrative, they are genetically mostly descendants of the anatolians who happened to live and breed there already for many millenia. Those people didn't suddenly disappear. This contrast between culture and genetics is confusing to many turks (me included)

<comment><USER6> That's what I think happened to other countries in the region as well. I'm from Iraq and speak Arabic but I don't think my ancestors are from the "Arabian peninsula", we just adopted the language. It also explains why "dialects" of Arabic can be so different.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Interesting. The Afroasiatic languages are attested from long enough ago that the date of their divergence can be estimated at ca. 10,000 BCE or earlier, orginating probably somewhere around the Red Sea. [https://en.wikipedia.org/wiki/Afroasiatic_languages](https://en.wikipedia.org/wiki/Afroasiatic_languages)

Sub-Saharan Africa was marked by the Bantu expansion some time later, with Niger-Congo-speaking peoples expanding out of West Africa between about 3,000 BCE to 500 CE. This at best just takes Bantu speakers to the very peripheries of the Egyptian sphere, the modern slave trade and maritime trade with East Africa are probably likelier causes. [https://en.wikipedia.org/wiki/Bantu_expansion](https://en.wikipedia.org/wiki/Bantu_expansion)

<comment><USER9> I think you may allude to some connection between Bantu people and Egypt. It is difficult to interpret ancient Sub-Saharan Africa in our modern terms. Basically there were four broad areas that were populated at that time, the western Africa (Mande/Sao), the Niger basin(Nigeria/Cameroon inhabited since 120,000 years and place of a wonderful civilization: Nok), the Chad area (remnant of a mega lake, also inhabited since the humide Sahara period) and the Nile area (from Middle east up to Ethiopia).

It was possible to travel from the Victoria lake to the Mediterranean sea (and vise versa). At the same time there were hydrological connections between the Chad basin and the great Lakes and between the great lakes and the Congo basin. And from the Chad area to the Niger area.

From the Jos plateau (cradle of Nok culture) it is possible to reach Lake Chad via the Komadugu River.

It is also possible to travel to Cameroon and near Chad Lake, via the Benue River, which is a tributary of the Niger. From the Benue River, it is possible to reach the Logone which flows north towards the lake in Chad.

From Chad Lake it is possible to take the Chari River towards the Congo River. A recent study was published about the Congo basin, describing it as a massive swamp 4,000 years ago.

The rivers of Dja and Kadei are born in Cameroon and head south-east to throw themselves into the Sangha river, which is a tributary of the Congo River.

The Uele River has its source close to the White Nile and Lake Albert.

My points are:

1) That people could move at that time on very large distance via boats.

2) That there were already beautiful civilizations in the Niger basin at that time.

</comment></comment><comment><USER10> For those who'd not come across the term "Near East" before, it's the same as the "Middle East".

Ref: [https://www.britannica.com/demystified/are-the-middle- east-a...](https://www.britannica.com/demystified/are-the-middle-east-and-the- near-east-the-same-thing)

<comment><USER11> I believe the authors use the term Near East to describe the parts of present- day Turkey, Syria and nearby regions.

Middle-East is too broad to have usefulness in the article.

</comment></comment><comment><USER12> _" from the archaeological site of Abusir el-Meleq, along the Nile River in Middle Egypt"_

If they are from Lower Egypt that might be "Asiatics" Hyksos dynasty. From the map Abusir el-Meleq seems to be much closer to Lower (i.e. Northern part of) Egypt.

<comment><USER13> Unlikely. The first sample is from around 1400 BCE. The last king of the Hyksos dynasty was expelled 1550 BCE. Their samples go to 400 CE. They did conclude a continuity of the population for the whole time. If these were really foreigners the must have came in at a steady stream for over 1300 years, with no local intermixing.

</comment></comment><comment><USER14> I wonder how it would have gone, if they started with the dynasty called Khufu.</comment>


Cool-retro-term - <AUTHOR> https://github.com/Swordfish90/cool-retro-term <comment><USER2> This is awesome nostalgia, but tell me, for those who have never seen a CRT display, does it have any meaning to you?

Seeing this, I wonder if the world has forgotten what a computer is. Now we've got devices, for example phones, and the computer (and the Internet) is right at the surface of the device. When we used CRT displays, we knew our display was just a repurposed television screen that communicated with a separate and discreet computer, which was another (and different) kind of machine.

Same with modems. When they screeched and howled, the duration of noise and the "seeking" nature of the sounds was a clear indicator that we were connecting to other devices at a distance, devices that were not always available, over connections that were tenuous.

Now everything is immediate and ubiquitous. The computer has been subsumed into the terminal itself. And what was distant is at our fingertips.

<comment><USER3> I suspect only people who've never used a CRT would use this sort of thing ;)

I used CRTs for years (naturally... I'm in my late 30s) and, without fail, they sucked. If they weren't long-persistence, they were flickery; if they were, they were smeary, even by the standards of ancient mono laptops. If they were flat-screened, focus was inconsistent. Large ones were expensive (and by "large" I mean "19 inch"), and you lost some screen area from the bezel.

If you found one that didn't have any of these problems, it was probably enormously expensive. But even your enormously expensive one wouldn't look _quite_ pin-sharp at 1600x1200. (Unless it was truly enormously expensive, and was a 22+ inches diagonal.)

And whatever you did, they took up a huge amount of space, used a vast amount of electricity, and emitted a lot of radiation (though nobody ever seemed to be quite clear on whether this was actually bad for you).

And what nobody seems to remember is how rather unreliable they are. Failure rate for the LCDs I've owned: 0%. For the CRTs? 100%. None made it past six years.

If you like them for games, great. Enjoy your youthful ability to detect those extra 10ms of latency while you still have it, that's what I say! But for a terminal? You're nuts.

<comment><USER4> I bought a "decommissioned" Sony Trinitron monitor for $200 from a company I worked at at the time. It was 27" flat screen, and glorious, was amazing for gaming and counter-strike.

Now, carrying it up 3 flights of stairs on the other hand almost made the cheap price not worth it. That thing must have weighed 50lbs.

<comment><USER3> 27"! I never saw a monitor that large. I think 22" was the largest. Even TVs didn't go all that much larger than 27", particularly 4:3 ones.

And a Trinitron too! That must have been spitefully expensive to buy...

<comment><USER5> Sony definitely made a 24" Trinitron monitor: [http://www.amazon.com/dp/B00004YNSR/](http://www.amazon.com/dp/B00004YNSR/)

and a 34" widescreen TV: [http://www.amazon.com/dp/B0002NDFKM/](http://www.amazon.com/dp/B0002NDFKM/)

<comment><USER3> CRTs that large were pretty rare, though. Monitors tended to stop at 21" (by which point they were a good foot deep, if not more...), and I'm less certain about TVs, but I'd be surprised if even 34" ones were all that common. If nothing else, they're an absolute bugger to move. My parents' 31" widescreen CRT was an absolute monster... my back still twinges just thinking about it.

</comment></comment></comment></comment></comment></comment><comment><USER6> I used an amber CRT for 17 years. What this is missing is the mottled browning and yellowing from all the cigarette smoke on the beige plastic case. Now what you really need to be retro is a TTY printer. I used to get my work orders through one. No screen, just a seemingly infinite roll of dot matrix paper and a keyboard.

<comment><USER7> Has anyone tried a "open plan office" term yet?

So work at home people, and people in sane environments, can experience the huge performance boost of an open plan office.

So just vanilla unicode-rvxt or whatever you use, with some really special additions...

1) ghostly reflections of people constantly walking behind you and sometimes glancing at your screen as they walk by in the background as a transparency layer.

2) If you're a glossy screen in a brightly lit office you get torturous reflections causing eyestrain, make sure to include that. If you can't see what you're doing, you should just work harder.

3) A continuous mix of noise plays in the background at random levels, probably stolen from youtube type videos. So dramatic arguments, sports gossip, people asking each other questions to google for them, ringtones and other noisy beepy stuff, all mixed together continuously. If you're distracted, its your fault for being distracted.

Might have to script the background activities although an option to just mash up purely random youtube traffic would be funny. To get people to use it, you could create kind of a directed, scripted story that plays out. This lowers the technological bar to merely being a video player with high transparency and a probably very large video file.

I have no idea if this is a genius idea or mere parody. Probably a work of performance art if done well.

I am aware there are lots of sites that play background audio such as a coffee house or whatever. I'm looking for the open plan office experience, specifically.

<comment><USER8> If done right, this could actually be a pretty brilliant indie game. The first level of the game is you just doing some sort of office-work-related puzzle. The second level of the game, which takes awhile to notice, is the plot unfolding in the background, as you overhear phone calls and conversations related to the emails coming into your inbox.

Think "Gone Home", but in an office.

</comment></comment></comment><comment><USER9> For the ones looking to take this further, there's Cathode[0] (Mac only) - [http://www.secretgeometry.com/apps/cathode/](http://www.secretgeometry.com/apps/cathode/)

<comment><USER10> Cathode is closed source. How can we 'take it further'?

<comment><USER9> Apologies if my wording gave you a wrong idea. What I meant was that Cathode has a good variety of themes and customization features.

<comment><USER11> And the sounds are pretty great. The "Heavy" power-on sound is… satisfying: [https://soundcloud.com/biohazard-music/cathode-heavy- poweron...](https://soundcloud.com/biohazard-music/cathode-heavy-poweron- sound)

</comment></comment></comment></comment><comment><USER12> Skeumorphism is trendy again. If it wasn't for watts, I'd get a big CRT back, analog pixels sounds better[1]. Or maybe a Grid Compass [http://www.collectorsweekly.com/stories/54135-grid- compass-1...](http://www.collectorsweekly.com/stories/54135-grid- compass-1101-and-1139) ;)

[1] (c) Monster

</comment><comment><USER13> Now, just set it up to use the VT 220 font, and we're done.

[http://christfollower.me/misc/glasstty/index.html](http://christfollower.me/misc/glasstty/index.html)

</comment><comment><USER14> Small details: it seems from the screenshots that the screen 'glows' so that the bezel of the display has a tint of the most prominent color on screen. That's a great touch that makes it look more real than a terminal within a static frame.

</comment><comment><USER15> [https://news.ycombinator.com/item?id=8399461](https://news.ycombinator.com/item?id=8399461)

</comment><comment><AUTHOR> It's surprising to me how much narrower 40 columns is now than it was when I had a real Apple II.

</comment><comment><USER16> This looks awesome, I just wish it could go full screen on my mac. You can download the OSX dmg here, I almost missed it since it's at the very bottom of the instructions: [https://github.com/Swordfish90/cool-retro- term/releases](https://github.com/Swordfish90/cool-retro-term/releases)

<comment><USER17> What's weird on Mac is that it seems to use Command as the Control key.

<comment><USER8> Looks like a known issue: [https://github.com/Swordfish90/cool-retro- term/issues/203](https://github.com/Swordfish90/cool-retro-term/issues/203)

The Command key seems to act like the control key.

</comment></comment></comment><comment><USER18> I gotta say this is a pretty cool app. A lot of the UI seems to be declarative. Very nice, considering donating.

</comment><comment><USER19> How about actually supporting coloured text, and get new school eye candy with your old school eye candy? :)

<comment><USER20> It does. You need to go into the terminal settings enable "Chroma Color" and then tweak the value.

<comment><USER19> Sorry, I meant like xterm256 &c

</comment></comment></comment><comment><USER21> This was in the frontpage just a few months ago. Edit: On a sidenote, upvote for Skeumorphism !

<comment><USER22> I'm getting sick of flat design. But let's not go back to skeumorphism. A few years ago, when fake wood textures were all the rage, I remember being so frustrated at some of the interfaces. Lots of awkward metaphors (Oh, I'm supposed to click the inkwell to write a new document?) and poor discoverability (That's a button? I thought it was part of the background!).

</comment></comment><comment><USER23> The amount of reposts in the last few months is getting stupid.

</comment><comment><USER22> Not sure what this is supposed to be. It's obviously not meant to be functional. It doesn't look good (rather, it looks purposely bad). And no matter how close to the real thing you make it, it's not going to fool me into feeling like I'm on a CRT when I'm not. So I'm not feeling nostalgic for it either.

The best nostalgic experience I got this year was booting my raspberry pi for the first time, because you can have it boot straight to command line. It brought me back to my first DOS pc, when you had to type "WIN" to run Windows.

<comment><USER24> Oh god I hate these type of comments.

Please if you have nothing constructive to say, don't be rude and dismiss somebodies hard work. It's infinitely easier to put someone down than it is to actually produce something.

<comment><USER22> Who is that thin skinned? If you work hard on something, people inevitably shit on it. It's human nature. And someone as talented as this creator is probably used to it by now.

Besides, limiting conversation to just constructive criticism limits the scope of HN. This isn't a support group. It's a discussion forum. We should be free to criticize not only the implementation of a program, but the need to build it in the first place.

<comment><USER8> > _If you work hard on something, people inevitably shit on it. It 's human > nature. And someone as talented as this creator is probably used to it by > now._

This compliment is delivered like an engagement ring in a dog turd.</comment></comment></comment></comment>


Giant Lego MindStorms Robotic Chess Board - <AUTHOR> http://www.youtube.com/watch?v=THGtbBz1sQo

<comment><USER2> So this is what you do when you retire in your late 20's after selling your start-up? :)

<comment><USER3> Did this person sell a start up? I looked at the site, but couldn't see any reference. Curious if it was a robotics based company?

<comment><USER4> I believe he started <http://www.hitechnic.com>

</comment></comment></comment><comment><USER5> Reminds me of this joke:

"Hey guys, when you come to my birthday party, try to not land your chopper near the lake, it scares the hell out of the midgets of the chess board".</comment>


Google Account Recovery Vulnerability - <AUTHOR> http://www.orenh.com/2013/11/google-account-recovery-vulnerability.html <comment><USER2> Recently, I decided to follow-up one of the many emails I receive from a company I've never heard of, implying I have an account with them. I usually assume they are spam, but this looked like a genuine case of someone accidentally using my email address and the service not verifying it. Long story short: via their password recovery, I now have the user's plaintext password, and several personal details including address, age, phone number, and mother's maiden name.

I emailed the company (a US mobile phone company I haven't heard of; I'm based in the UK) and their response was along the lines of "call us (at your expense) and tell us your phone number and we'll sort it out". In the end, out of sheer frustration, I reset the account's email address to that of the company's WHOIS technical contact; that was the safest way I could think of getting my email address off the account.

Google, of course, handle this kind of thing properly. But for every google, there are thousands of companies who will give your personal data away without a care in the world.

<comment><USER3> I once had someone sign up for an electronic voicemail service with my email address. I was getting all their voicemail, including once about 50 in the space of an afternoon from a clearly distressed client of theirs. It took a very long email chain with customer service explaining that I couldn't log in to the account to change the email address because I didn't have the password and the account wasn't mine. A similar thing happened with a Playstation Network account.

Web developers: Please make sure to include a "Didn't sign up for this? Click here to disable/unsubscribe" option in sign up emails, rather than assuming that the person receiving the email is the correct person who knows the password.

<comment><USER4> To be fair, I have accidentally clicked on the "oh yeah, confirm this email address" when I suddenly realize "no, wait, I created that account with my _other_ email address... what the heck is this?"

More of a problem with common big-name services like Facebook and Apple ID and whatnot.

</comment></comment></comment><comment><USER5> Nice write up. While checking to see if Google's "Hall of Fame" [1] was updated yet, I noticed that their reward program is actually really active. Here are some stats compiled about the Reward Recipients and Honorable Mention pages, based off these numbers, they are dolling out a cash reward roughly every 1.8 days!

      2013
        197  Reward Recipients [1]
        168  Honorable Mention [2]

      2012
        191  Reward Recipients [1]
        147  Honorable Mention [2]

      2011
        121  Reward Recipients [1]
         68  Honorable Mention [2]

[0] [http://www.google.com/about/appsecurity/hall-of- fame/](http://www.google.com/about/appsecurity/hall-of-fame/)

[1] [http://www.google.com/about/appsecurity/hall-of- fame/reward/](http://www.google.com/about/appsecurity/hall-of-fame/reward/)

[2] [http://www.google.com/about/appsecurity/hall-of- fame/distinc...](http://www.google.com/about/appsecurity/hall-of- fame/distinction/)

<comment><USER6> Back in the day, the "Hall of Fame" for this kind of exploit would be a .txt file sent to full-disclosure, detailing the exploit and sending "greetz" to your "crew" (or if you were lucky, posted in a periodical of note like Phrack).

Now the fix comes out before anyone gets harmed by it, AND the person who discovered it gets PAID for it. Whoever thought up the rewards program is keeping people safe and still giving hackers a good reason to keep hacking. The future is amazing.

</comment></comment><comment><USER7> I always love reading writeups of these vulnerabilities.

On a related note, I love that bug bounty programs are becoming more popular. Still too rare, but great. That said, the majority of companies out there still make reporting vulnerabilities tough. I've reported a number of vulnerabilities, and all but a few companies had no security@ email address nor a security contact under Contact Us. The tech/admin contact of the DNS record often does the trick, but doesn't always work.

Please, companies, make it easier for us to report security vulnerabilities!

<comment><USER8> The problem is that if someone finds a bug in say, PHP, the exploit could easily be worth 60-100x the $1500 you'd get paid _when its fixed_.

</comment></comment><comment><USER9> > Google security team acted really fast. This issue was fixed in 10 days.

Wow I couldn't imagine how long a 'slower' response cloud be.

<comment><USER10> I have a remote DOS and possible code execution on one of the world's most widely deployed desktop applications. Their security team has been on top of it (got back an initial human response and responsible team member within 48 hours, etc), but the nature of the beast means that all subsequent steps take weeks to months. I can't remember off the top of my head, but I think we're at 4 months and counting.

<comment><USER11> Based on the description I think we can safely assume the company name starts with a letter 'M'. ;)

<comment><USER10> Professional courtesy suggests I should not confirm nor deny that. Let's just say that AmaGooBookSoft all have surface areas larger than the Death Star, and it is highly, highly unlikely that any of them have found all the exhaust ports yet.

<comment><USER2> Hey, I work at AmaGooBookSoft and I resent you calling out our poor security practices!

</comment></comment></comment></comment></comment><comment><USER12> Very interesting.

> If you rely on CAPTCHA's as CSRF protection, make it consistent.

This was discussed at today AppSecUSA [1] that it is rarely ever seen anyone use CAPTCHA as CSRF protection.

[1]: [http://appsecusa2013.sched.org/event/10d6389173e14b246720d83...](http://appsecusa2013.sched.org/event/10d6389173e14b246720d8324ddbcc64?iframe=no&w=100&sidebar=yes&bg=no#.Uo7lm_ZQ2VQ)

<comment><USER13> At first I thought it was odd and weird too. After some more thought, and correct me if I am wrong, there weren't any differences between them. They both are tokens that are generated and verified by the server, except a CAPTCHA actually requires human interaction.

</comment></comment><comment><USER14> Vulnerability Reward Programs are getting more and more popular. @homakov and @bef0rd made a script for collecting all people listed in a security "Hall of Fame":

[http://beford.net/hustlers/hustlers.html](http://beford.net/hustlers/hustlers.html)

</comment><comment><USER15> Congrats to the guy that found out. Good job.

</comment><comment><USER16> such sophisticated recovery process

very bend over to customer who loses pass

so fuck user who retains pass and cares about security

much credible company

cloud wow

2013 very XSS</comment>


How to get traffic and build an audience when no one knows you exist - <AUTHOR> http://midasmedia.co.uk/content-saturation-how-to-get-traffic-build-an-audience-when-no-one-knows-you-exist-c0/

<comment><USER2> devoid of any actual useful content, ironically...</comment>


MineRL: A Large-Scale Dataset of Minecraft Demonstrations - <AUTHOR> https://arxiv.org/abs/1907.13440 <comment><USER2> First author here! Let me know if you have any questions :)</comment>