CellScope: Your Cell Phone Just Got a Microscope - <AUTHOR> http://singularityhub.com/2009/09/03/cellscope-your-cell-phone-just-got-a-microscope/

<comment><USER2> The idea of diagnosis by phone is pretty amazing. But how many people in third world countries have cells phones?

<comment><USER3> You obviously don't get out much (no offense). But mobile growth in third world countries is huge. Being able to make a diagnosis with a simple phone instead of with expensive medical equipment (which third world countries don't have) is a fascinating idea. This is really a game changer.

<comment><USER2> Was just asking, no need to infer about me personally.

I'm surprised they have the infrastructure needed to support cell towers on a large scale.</comment></comment></comment>


Stripe: Redesign status page as part of job application - <AUTHOR> http://finejobs.co/082813-designer Read the last paragraph. Also on their official site too; https://stripe.com/jobs#designer <comment><USER2> This reminds me of the "I will not do your tech interview." post. [1]

There's a good chance if you're applying you're either a. unemployed, looking for a job, or b. you really want to work at stripe.

If you're passionate about what you do, you're going to enjoy designing anyways, so what better way to make you stand out than doing something that benefits the company you're applying for -- working on something you'd actually be working on.

Anyone can copy designs from dribbble to make themselves look like an amazing designer.

It's not like they're going to take your design, implement it and never reply to your email.

1\. [https://medium.com/lessons- learned/80ba19c55883](https://medium.com/lessons-learned/80ba19c55883)

<comment><USER3> It does sound like a good way to filter for people that really want to work at Stripe, and I don't really see anything wrong with that.

<comment><USER2> Exactly. Sending a resume is cheap -- sending a design takes some time.

</comment></comment></comment><comment><USER4> I always wonder when I see things like this -- are there actually people who will work for free just to apply for a job?

I do not mean this as snark. And I certainly would be open to the idea of a trial period or working on an in house project after the interview. But to ask someone to put in hours just for the possibility of an interview seems like a very asymmetric request. Am I off base here?

EDIT: It's probably worth noting that I work more on the software side than the design side.

<comment><USER5> You're on base. I guess this would work for certain companies like Google, or Apple, but if you're an average company (no offense, but Stripe is nothing special), then you probably won't get many candidates, maybe not even 4 or 5.

<comment><USER5> In other words, Stripe is just like every other boring, trivial corporation!!!

</comment></comment></comment><comment><USER6> This is just silly. Any good web designer should be able to point to a body of work and that should be enough to test their skills.

</comment><comment><USER7> Stripe, I'm curious how 80% of your downtimes are bound to 60s intervals, and the two that aren't were only 1-2s above that interval. I would hazard a guess that you check these services on a one-minute interval or only report home on that interval -- checks may be much more rapid, and the two cases were simply an example of the interval scheduler not being perfect.

</comment><comment><USER8> Maybe this would work better if it came after a phone screen or in person interview, so there's less chance of wasted work. I think the general idea is good though.

<comment><USER9> Design hiring pipelines often include a project stage. I guess the difference here is self-selection.

</comment></comment><comment><USER10> This feels so unfair to an applicant.

A better way would be to go through the normal filtering process of accepting applications. Choose several designers, then offer them this same task _with proper payment_ for their time.

<comment><USER11> The idea this is unfair or "spec" work seems silly to me. As a professional, you do a ton of stuff that you don't get paid for: attending classes, building your skillset, designing your portfolio, writing your resume, creating concepts, etc., etc. This is simply a fact of life.

<comment><USER12> It's not simply a fact of life. These types of application processes are no different than saying "There is a $200 application fee."

</comment></comment></comment><comment><USER13> Stripe: Do work for us for free, maybe we'll hire you.

<comment><USER14> The more I see about Stripe the less I like them.

<comment><USER15> Agreed, this is going to anger the design community

<comment><USER16> Is there anything that doesn't?

</comment></comment></comment></comment><comment><USER17> IIRC, this has always been on stripes job page. Always thought it was a clever idea.

</comment><comment><USER18> Who owns the submitted design, the designer or Stripe?

<comment><USER19> The designer does.

</comment></comment><comment><USER20> It's not exactly spec work - there isn't an explicit understanding that they'll use somebody's work if its good enough; it's not commissioning a one- off project with vague promises of future work - but it's also definitely not standard practice, at least for design gigs, since it's so easy to get a feel for their work by flipping through a portfolio.

If the concern is whether they can strike the same tone and style, hiring people on a temp contract is usually a better way to go, plus then you also test if they're fast, present their work with a strong rationale, play nicely with others, etc.

</comment><comment><USER21> Yay for spec work!

</comment><comment><USER22> I get how controversial it is to ask for "free work" but on the other side of the coin:

a) I've found that lots of design applicants will put stuff in their portfolio that they contributed to, rather than built end-to-end. This solves that problem.

b) Tracking on the statement above, they're looking for a designer that has a "deep understanding of how applications should work". In an online design portfolio it's easy to misinterpret application design skills w/the ability to take a design spec from a product manager and make it pretty. Stripe is looking for a unicorn - a designer that is also a product manager / UX talent.

c) Design, especially UX design, is not just a "show me your portfolio" \- it's a "what is your process to build the right UX." If a candidate submitted several iterations of design + maybe a "let's test these two things because I'm not sure" I would be 100% more likely to prioritize their app vs a "look at how pretty this is"

So I don't know, I get the argument that this is taking advantage.

But on the other end it makes them a lot more likely to find an awesome candidate who actually wants to work there, and has the talent to deliver the goods.

<comment><USER23> > a) I've found that lots of design applicants will put stuff in their > portfolio that they contributed to, rather than built end-to-end. This > solves that problem.

Effective designers (and effective hiring managers) have already solved this problem by describing their role in projects (or asking about specific roles in the interview process). Don't hire designers that have a portfolio full of nothing but sex-shots.

> "what is your process to build the right UX."

I agree that is the intention of this sort of application requirement, but I'd be surprised if it consistently worked. These sorts of requirements force designers to work in a vacuum. It is impossible to make an effective solution without having a deep understanding of the product—the hiring company will get a tepid/run of the mill/boring design. (Though perhaps a beautiful design, which often works for these sorts of interviews)

> But on the other end it makes them a lot more likely to find an awesome > candidate who actually wants to work there, and has the talent to deliver > the goods.

It's maybe likely to find them someone that wants to work with them (especially if we define "wants to work here" as "willing to do spec work" which may be fair) but in my experience, talented designers are busy working on cool projects and students/young designers are the ones with time to dedicate to this sort of application.</comment></comment>


Ask HN: Simple Linux Machine - <AUTHOR> Is there an SBC that just works and works well with the Linux kernel?
I'm looking for something low in price ($100-$200) with mainline kernel support.  I hope for stable and accelerated X11 with video and sound playback.  I'd like to be able to drag windows around at full frame rate.
Architecture doesn't matter.
I've been trying really hard to get Pine64's RockPro64 to work as a nice little dev / office-work machine.  It just doesn't seem to be working out.  Manjaro (Arch) Linux on multi core ARM, even at 1080p on a ARM's Mali T860 GPU, is just not smooth at all. <comment><USER2> AMD Ryzen 4000 desktops are coming soon, using the mobile APUs rather than the desktop line of 4000 processors. They are a little bit over budget at $300+ but they are going to perform excellently ranging from 4 cores / 4 threads up to 8 cores / 16 threads and very decent iGPU. If necessary this could be repurposed to suit a number of uses like a modest workstation or 1080p gaming or some virtual machines or a media PC etc.

[https://www.cnx-software.com/2020/06/16/asus-pn50-the- worlds...](https://www.cnx-software.com/2020/06/16/asus-pn50-the-worlds-first- amd-ryzen-4000u-mini-pc/)

There are a lot of older, competent dual core machines available on Amazon very cheaply too. These are much cheaper but if you ever needed even one virtual machine it would be quite taxing. These machines are 4 or 5 years old so linux support is likely excellent.

[https://www.amazon.com/s?k=small+form+factor+pc&ref=nb_sb_no...](https://www.amazon.com/s?k=small+form+factor+pc&ref=nb_sb_noss_2)

These aren't strictly "SBC" but they're very similar. Basically laptop motherboards and soldered chips with potentially upgradeable storage/ram.

<comment><AUTHOR> The thin client corporate PC idea is a good one.

What would be fantastic would be to have a recommendation where someone has a really good existing setup.

<comment><USER2> You might like asking on this subreddit, they use everything from little raspberry pis to large rack servers, often acquired at a very low cost:

[https://old.reddit.com/r/homelab](https://old.reddit.com/r/homelab)

</comment></comment></comment><comment><USER3> I probably don't know what I'm talking about, but maybe a high-end Raspberry Pi?

<comment><AUTHOR> These platforms work in theory. In practice I think it's still only been a few months since OpenGL ES 3 worked in RPi4. Things like this make me worry it's not the best platform for a performant workstation.

I'm fussy. I want my windows to drag / resize / scroll at 60 FPS.

</comment></comment><comment><USER4> Does that include open or closed GPU drivers?

<comment><AUTHOR> Closed would be fine

The real sweet spot I'm looking for is a platform that's supported entirely in the mainline kernel because this just seems to make life so much easier.</comment></comment>


The Ugandan love of grasshoppers – and how to harvest them - <AUTHOR> https://www.bbc.com/news/world-africa-46357020 <comment><USER2> I traveled to Kampala during grasshopper season about ten years ago. I had never seen anything like the harvest before, it was a great experience. And the fried grasshoppers are delicious!</comment>


Tips from Hipmunk's iPhone app launch to help you rock your next demo - <AUTHOR> http://blog.hipmunk.com/hipmunk-at-launch

<comment><USER2> Anyone else getting a 404?

<comment><AUTHOR> Oh dear, posterous :(

</comment></comment><comment><USER3> Yep, 404.</comment>


Was the iOS SSL Flaw Deliberate? - <AUTHOR> https://www.schneier.com/blog/archives/2014/02/was_the_ios_ssl.html <comment><USER2> Another sad indicator of the level Schneier is playing at today, in the same vein as "avoid elliptic curves, we don't trust the math".

Once again: the only reason this bug got so much attention and press is that it's easy for laypeople to get their heads around. All you have to understand is how "goto" works. The bug is vivid, and so (paradoxically) seems scarier.

Significantly worse bugs are found every week. Within a few days of the announcement of this TLS bug, a Flash bug was announced, after being detected in exploits in the wild, that enabled reliable drive-by hijackings of browsers --- multiple browsers. It was off the HN front page within an hour.

TLS bugs aren't even unusual. We get a new one every few years ago. Firefox managed a PKCS1v15 parsing bug that allowed anyone with a Python script and 30 milliseconds to generate a certificate for any domain. Other browsers have screwed up certificate chaining, so that any domain could sign any other domain. But nobody understands PKCS1v15 padding, nobody understands certificate chaining, and so nobody writes stories about these bugs. But their impact is identical to this one.

<comment><USER3> >Once again: the only reason this bug got so much attention and press is that it's easy for laypeople to get their heads around. All you have to understand is how "goto" works.

I don't agree. Most people don't even have a basic understanding of coding. I think that it has more to do with the fact that there are about 500 million vulnerable devices out there, and that we are talking about Apple. Remember Antennagate, it wasn't even that big of a deal and look at what the press made of it.

<comment><USER4> Most people on HN know what a "goto" is. We're talking about attention on the HN front-page after all.

[edit]

Also I bet most readers of Schneier's bug know what goto is as well.

<comment><USER3> He said laypeople though, not HN readers.

</comment></comment></comment></comment><comment><USER5> Often when things like this happen there's a large conspiracy at play in some peoples minds, "Apple _deliberately_ left a security vulnerability". But it falls apart pretty quickly, it's in an open sourced package, so the assumption is _someone_ is eventually going to see it, so it's not going to remain a secret and thus is useless as a stealth backdoor.

The likelihood is pretty simple, someone fucked up. On a potentially _huge_ level, but a fuck up none the less. These things do unfortunately happen, and no doubt it'll prompt an internal review of their change management process, and their build chain, and what they can do to isolate issues like this in the future.

<comment><USER6> While I believe that it was just a screw-up that wasn't caught because of gaps of process (the code essentially repeats blocks with minor changes, so I can envision someone doing some refactoring -- removing the passing of the context -- and trying to save time by copying the first changed block to the second, failing to overwrite that single additional line), considering the possibility that it was intentional in no universe suggests that it was Apple the organization that chose and instituted the vulnerability.

A single employee receiving a second paycheck from a three-letter organization could have been responsible. A vulnerability could have been used to plant it. And so on. Remember when everyone was railing about Google giving NSA a backdoor (cue a thousand "don't be evil" cries) when in reality the NSA and friends were simply exploiting a weakness of Google's network. The net effect was the same.

It could be intentional and still entirely unintentional as far as Apple the company is concerned.

And to the open source thing -- it sat there for 18 months. Indeed, it was caught [EDIT: Actually I don't know how it was caught. I faintly recall someone posting an issue someone submitted to Apple detailing some weird behavior with invalid private keys, but can't find it now]

<comment><USER7> "And to the open source thing -- it sat there for 18 months." !!! Just .. wow. If it was the first time we heard such stories. But it happends many time with the linux kernel source code and all. I definitively conclude that source code begin open to everyone is not a mark of higher quality.

</comment></comment></comment><comment><USER8> As noted in the article, _plausible deniability_ is a key criterion for thinking of this as a possible NSA insertion.

In other words, it's only possible that it's an NSA job if it's also possible that it isn't. Something tells me therefore that we're unlikely ever to know for sure.

<comment><USER9> Doesn't it strain credulity that the NSA would (bother to) insert a flaw that would be detected by many commercially available analysis tools (or the right compiler flags)?

(I certainly shouldn't pretend to know much about C, but the above matches my understanding of the situation)

<comment><USER10> Who's to say the NSA doesn't know what analysis tools Apple runs as part of their builds?

</comment></comment></comment><comment><USER11> If I were at the NSA and wanted to introduce a bug like this, I'd get access to Apple's build servers (either through an exploit or by just talking to an employee who has access) and arrange for a binary patch to be applied to the generated object files at build time. It would be basically undetectable, as no amount of source code auditing would reveal it. Could probably make it look like a compiler bug without too much difficulty.

Of course, this presumes that the NSA _needs_ to introduce bugs like this. I imagine they do just fine for now merely taking advantage of naturally occurring bugs.

<comment><USER12> Again I think this was just a mistake, but there are other groups that could want to add something like this other than the NSA where it would be more plausible for them to have such a need. It shows that Apple needs to reconsider its processes though, and I guess they are now, which should make the likelihood of something like gotofail for nefarious means working very small from now on.

<comment><USER11> I'm hoping that their security folks are now going through and writing extensive automated tests for all of this code, and anything similar, and turning on lots of automated static analysis to go along with it.

I fear that it may end up as, "we already found the bug, we don't need tests now". But that's probably pessimistic of me.

</comment></comment></comment><comment><USER13> Well, [http://www.opensource.apple.com/release/os-x-109/](http://www.opensource.apple.com/release/os-x-109/) has the list of open sourced code from Mavericks. Let the code analysis begin, it would help everyone out.

<comment><USER14> Honest question, what are decent tools to find bugs like this in C code nowadays? I was saddened to read that gcc cannot check for unreachable code.

<comment><USER15> The -Wunreachable-code flag does work in clang, to some extent at least (I have a rather old version here so YMMV). Other tools that may help:

The clang static analyzer: [http://clang-analyzer.llvm.org](http://clang- analyzer.llvm.org)

Valgrind: [http://www.valgrind.org](http://www.valgrind.org)

Address Sanitizer: [http://clang.llvm.org/docs/AddressSanitizer.html](http://clang.llvm.org/docs/AddressSanitizer.html)

The various -fsanitize options in clang (undefined behaviours, integer overflows etc): [http://clang.llvm.org/docs/UsersManual.html#id28](http://clang.llvm.org/docs/UsersManual.html#id28)

<comment><USER12> There is a list here:

[http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...](http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis)

Also there is oclint not listed there, which is pretty amazing, but it has a strange notation for ignoring wqrnings. splint is pretty good too though and still supports the legacy lint stuff like /* NOTREACHED _/

BSD lint seems to work still (though it looks like the lintlib is no longer built on FreeBSD and stdlib is not lint clean!) but even it would have caught this gotofail:

      01: #include <stdlib.h>
      02:
      03: int
      04: main(int argc, char *argv[])
      05: {
      06:   if (argc == 0)
      07:           goto fail;
      08:           goto fail;
      09:
      10:   exit(0);
      11:
      12:
      13: fail:
      14:   exit(1);
      15: }
      $ lint a.c
      a.c:
      stdlib.h(286): warning: ANSI C does not support 'long  long' [265]
      stdlib.h(287): warning: ANSI C does not support 'long long' [265]
      stdlib.h(287): warning: ANSI C does not support 'long long' [265]
      a.c(10): warning: statement not reached [193]
      a.c(15): warning: function main falls off bottom without returning value [217]
      a.c(4): warning: argument argv unused in function main [231]
      _types.h(61): warning: struct __timer never defined [233]
      _types.h(62): warning: struct __mq never defined [233]
      lint: cannot find llib-lc.ln
      Lint pass2:
      exit used( a.c(10) ), but not defined
      $ cc a.c
      $ ./a.out
      $ echo $?
      1

edit: grrr, sorry small copy/paste mistakes before.

</comment></comment></comment></comment><comment><USER16> It's not just an "iOS" flaw. It's a "latest, greatest Apple OS" flaw.

And anyone who given a choice between SSL and TLS relies on TLS is not putting security as a top priority.

And why would anyone who cares even the slightest about security use Flash? Are you serious?

I guess this is why security consulting could be easy money... clients want to use Flash and "stay secure". Yeah, sure, we can handle that for you.

Well, now you cannot even use a Mac without the potential for HTTPS authentication not working. Better make sure the OS is updated. Sounds a lot like Microsoft. Maybe you could start a business updating Mac OS's.

"Does anyone know what's going on inside Apple?"

If they did they couldn't say. All employees are sworn to secrecy.

I blackhole all traffic from Apple devices to *.apple.com

You would not believe (or maybe you would, if you are a "security consultant" or some such)... you would not believe the amount of "phoning home" that these devices do.

I agree you can't trust "security consultants" who do their marketing via blogs and forums.

But you surely cannot trust Apple either.

The flaw was one line of code.

I'm curious. What is the size on the update?

Imagine if you could make the change yourself, recompile and dd an image to your device.

</comment><comment><USER17> I'd like to believe Apple simply as no code review but it's odd they removed a specific check -- was it not suppose to be there? Does anyone know if the patch added the line back in or if it removed the duplicate goto?

The one thing that points to it not being a backdoor is I doubt Apple would open source the code. Surely they'd maintain a separate branch or something?

<comment><USER18> They could have made it open source because they knew they were under pressure to backdoor it, so wanted people to see what happened without explicitly telling the world... Or not. It's a fun theory though.

<comment><USER19> You think a billion dollar, cash-rich company known for software excellence would understand testing and hardening? A company known for draconic quality assurance, would skimp? Silly me. HN must be right.

</comment></comment></comment><comment><USER20> I really hope Apple will disclose its findings on this matter, in name of the transparency they're advocating. Imagine if Apple itself states something along the lines of "we found out that the line of code responsible for the bug was planted on purpose". Should they make such a statement? Better: COULD they make it?

<comment><USER21> I fear they'd be too concerned about the potential impact on their business.

</comment></comment><comment><USER22> Why is is so important to know wether this bug was left deliberately or not, or even sneaked in by the NSA?

To the more important questions 'Did the NSA almost immediately discover this bug' and 'Did they exploit it', I answer with a resounding yes.

</comment><comment><USER23> I think I'll apply Betteridge's law[1] to this one.

[1]: [http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

<comment><USER24> Also: [http://en.wikipedia.org/wiki/Hanlon's_razor](http://en.wikipedia.org/wiki/Hanlon's_razor)

<comment><USER25> Hanlon's razor is just the worst. Systematic incompetence _is_ malice.

Here's my alternative but equally reasonable platitude: "Never attribute to incompetence what could be attributed to malice with plausible deniability."

</comment></comment></comment><comment><USER26> I honestly think it was deliberate. What class of Operating System developer ships their OS releases without 100% CODE COVERAGE? Apple do code coverage testing, surely? I mean, more than the "-warn-dead-code" args that get flung around. I can't understand how this would have gotten released into the wild if they were doing industry-standard code coverage tests. And .. if they're not doing industrial-strength code-coverage testing on their iOS/OSX release builds, thats the real news here ..

</comment><comment><USER27> It looks like the sort of bug that can be introduced by an erroneous merge in source control.

</comment><comment><USER28> I don't think the bug was deliberate, could of been just an honest mistake.

But on the other hand, why didn't the compiler generate an "Unreachable Code" warning during build?

We have explicitly set this warning to "Treat as Error" during our builds.

<comment><USER29> Gcc doesn't have such a warning. Clang has it, but it has to be explicitly enabled. (It's not even in -Wall or -Wextra.)

<comment><USER30> It appears that -Wunreachable-code was removed from gcc due to optimizer issues

[http://gcc.gnu.org/ml/gcc- help/2011-05/msg00360.html](http://gcc.gnu.org/ml/gcc- help/2011-05/msg00360.html)

</comment></comment></comment><comment><USER31> Where am I mistaken that having this bug deliberate is meaningful only if you control most of the networks? In which case there are a lot scarier things to worry about.

</comment><comment><USER32> I prefer always using brace brackets for if's...

if (cond) { goto fail; }

instead of:

if (cond) goto fail;

<comment><USER33> Yes, and this is actually a sane coding rule. Without it, badly written macros (using several ;-separated lines for example) will cause subtle bugs like this one.

<comment><USER34> I would argue that in this case the problem lies in the macro, not the lack of braces. You can't program defensively against broken macros.

I've seen quite a lot of discussion surrounding the coding style around this "goto fail" vulnerability, but IMO that's missing the forest for the tree. If this coding error was truly a mistake (which I tend to believe) it was probably the result of a bogus copy/paste. Shit happens, no matter the coding style.

In my opinion the real problem is: why wasn't this code properly tested and audited? For crypto code it borders on gross negligence.

In particular, I disagree with TFA that "The flaw is subtle, and hard to spot while scanning the code". When you're used to read properly indented C code the 2nd "goto fail" with its weird indentation jumps to the eye IMO. Also the fact that the same statement is repeated twice in exactly the same way. I'm used to reading a lot of kernel code using the same kind of error handling and it really stands out IMO.

</comment></comment></comment><comment><USER35> I don't think the NSA is nearly as technologically capable as people think they are. If they want info from someone all they have to do is detain them and bust open their kneecaps with a hammer. No one would ever find out. So there's really no reason to go through all the shadow games.

If this is an intentional bug, I think it's likely a hacker or just a disgruntled employee. But I'd be willing to wager that it was a tiredness error, rushed to implementation by an overworked and likely underpaid engineer deep within Apple.

<comment><USER26> You're absolutely wrong on this. The NSA are far, far more technologically competent than we've been giving them credit - and that is _precisely why the NSA releases have been so imporant, and chilling, to the computer industry and hacker community_. The NSA are way ahead of the pack. To think of them as a stupid bungling agency, the way most people associate government TLA's, is doing the world a disservice. Their competence is terrifying - as in it literally _induces terror_.

<comment><USER35> I think they are paranoid and have a blank check budget. But I don't think they are competent. If they were competent then they would know that no serious threats will be discussed in world of Warcraft or over yahoo messenger. The supposed enemy in the shadow is at least smart enough to know better. If they aren't, then they aren't smart enough to warrant the invasion if basically everyone's privacy. It just doesn't add up to me. If we are fighting super technical enemies, we must assume they are smart enough to not use basic, consumer grade chat. If they are not technically capable enough to know better than to use something like yahoo, then just send them an email with Sub7 in it. Either way, spending billions of dollars of my money to watch some millionaire banker sext with his secretary is a waste of money and of time.

<comment><USER36> > If they were competent then they would know that no serious threats will be > discussed in world of Warcraft or over yahoo messenger.

No, that would be a sign that they were incompetent, because secretly communicating groups do use unusual chats, such as graphical children's chat applets, in-game communications, shoutboxes and such. Why wouldn't they?

</comment></comment></comment></comment><comment><USER37> Wouldn't it be way safer and easier for any attacker (NSA or otherwise) to compromise a trusted CA than to compromise the Apple SSL code?

<comment><USER38> It might be easier, but I wouldn't say that it's safer. Fake certificates leave a paper trail -- that's how hacked CAs have been discovered in the past.

<comment><USER37> Good point!

</comment></comment></comment><comment><USER39> I was wondering if this was going to be one of those pages that just says "Probably." or similar in large text.

</comment><comment><USER40> ...There are goto statements in the code that is running on my laptop and phone? I feel dirtier now.

<comment><USER41> Did you ever read assembly?

<comment><USER40> I know that function calls are fundamentally just jmp calls underneath, and that's exactly what a goto is too, but we built high level language compilers (including C compilers) so that we didn't have to deal with goto-centric spaghetti any more.

As with everything, gotos work just fine if you restrict yourself to a few specific uses. At that point, however, you've basically just invented function calls, switch statements, and maybe exceptions if your rules aren't strict enough, which can all be managed by a compiler which _always_ generates the correct number of jmp's to do the job.

EDIT: you could more accurately replace each instance of "function call" in the above with "subroutine" as FORTRAN defines them, which is closer to what you get for free with gotos than a function call with an actual stack pointer.

<comment><USER42> > I know that function calls are fundamentally just jmp calls underneath, and > that's exactly what a goto is too ...

No, this is false, both at the high-level-language and assembly-language level:

[http://en.wikipedia.org/wiki/X86_calling_conventions](http://en.wikipedia.org/wiki/X86_calling_conventions)

A function call transparently returns to the point at which the call originated and resumes execution. A GOTO departs from the original location, never to return. That is a crucial difference.

> EDIT: you could more accurately replace each instance of "function call" in > the above with "subroutine" as FORTRAN defines them, which is closer to what > you get for free with gotos than a function call with an actual stack > pointer.

Still wrong -- you're confusing two very different things. A function call, in both the assembly and high-level sense, is completely different from a GOTO instruction.

<comment><USER40> I feel that your answer proves the point my original comment - that there is literally Silicon level support for completely avoiding gotos. I stand by my disgust at finding that they exist in any non-legacy code, especially in something I generally think of as high quality (iOS[1]/OS X).

(combined with a global pointer to a stack, a few instructions and a jmp should be enough to reimplement functions, including storing the return jmp address somewhere, obviously. As I think I made clear, I believe we invented compilers so that we don't have to know how this stuff is actually implemented. I do realise that I'm never going to know more about assembly than the set of HN readers who will pounce on this kind of comment - I was just trying to show that I have heard of jmp, and that I know it is spat out by compilers to implement high level language features, and that any nontrivial compiled program will contain many jmp instructions. A bug from using goto where a switch or if/else statement would have worked is inexcusable, and also nothing to do with assembly instructions.)

[1] actually, iOS 7? I take that back.

<comment><USER42> > I feel that your answer proves the point my original comment - that there is > literally Silicon level support for completely avoiding gotos.

Yes, and there's a reason -- chip design should reflect how computers are programmed at a higher level, and function calls produce code that's easier to understand, create and maintain. The reason is that function calls obey a logical hierarchy that often reflects the meaning of the algorithm being executed.

To see the point, try creating a recursive-descent parser that uses GOTO and avoids function calls.

This understanding isn't limited to an HN gaggle of nattering bystanders:

[http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...](http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html)

> I was just trying to show that I have heard of jmp, and that I know it is > spat out by compilers to implement high level language features, and that > any nontrivial compiled program will contain many jmp instructions.

Yes, but what a compiler does, and what a high-level language does, are often completely different. As one example, many recursive algorithms are compiled into functionally equivalent loops, to make them more efficient and to keep from blowing up the stack.

My point is that a compiler's output doesn't have to be read by a human, so it can break every rule. Not so for a high-level code listing that might have to be understood and maintained over decades.

<comment><USER40> Then I think we agree on everything, my ignorance of the details of x86 assembly language included! :)

<comment><USER42> Not if you think using GOTO in modern code represents acceptable programming. Remember? The topic?

<comment><USER40> ...I don't. I was never arguing that. See my first comment.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> > The flaw is subtle, and hard to spot while scanning the code

The author can't be serious. This particular bug has made the rounds and is understood even by non-programmers.

<comment><USER11> The ability to understand it when it's pointed out is unrelated to the ease of spotting it among a thousand lines of other code when you don't know what you're looking for.</comment></comment>


Interviews on Skype: Test candidates using a real-time code editor over Skype - <AUTHOR> https://www.skype.com/en/interviews/ <comment><USER2> This will potentially kill companies like Codility and Remoteinterview.io.</comment>


Hands-on: Microsoft's HoloLens is flat-out magical - <AUTHOR> http://arstechnica.com/gadgets/2015/01/21/hands-on-with-hololens-making-the-virtual-real/

<comment><USER2> What Microsoft is attempting to do with HoloLens is nothing short of amazing. While Oculus and other companies focus on virtual reality headsets for mostly gaming and 3D purposes, Microsoft are developing something truly unique in that HoloLens can be used for more than gaming. While I am excited for virtual reality headsets, I think augmented reality is more exciting in that real world objects and environments are used, not replaced.

I can see a future where a learning platform like Udemy exists for HoloLens, you can sit across from someone and learn a skill like guitar, drawing or sewing. Imagine the applications this could be used for in third world countries like training and medical purposes? Being able to save someone's life because a surgeon could guide someone step-by-step and appear as though they are in the same room.</comment>


Cache is the new RAM - <AUTHOR> http://blog.memsql.com/cache-is-the-new-ram/ <comment><USER3> A couple points I would make with respect to the article:

\- In-memory databases offer few advantages over a disk-backed database with a properly designed I/O scheduler. In-memory databases are generally only faster if the disk-backed database uses mmap() for cache replacement or similarly terrible I/O scheduling. The big advantage of in-memory databases is that you avoid the enormously complicated implementation task of writing a good I/O scheduler and disk cache. For the user, there is little performance difference for a given workload on a given piece of server hardware.

\- Data structure and algorithms have long existed for supercomputing applications that are very effective at exploiting cache and RAM locality. Most supercomputing applications are actually bottlenecked by memory bandwidth (not compute). Few databases do things this way -- it is a bit outside the evolutionary history of database internals -- because few database designers have experience optimizing for memory bandwidth. This is one of the reasons that some disk-backed databases like SpaceCurve have much higher throughput than in-memory databases: excellent I/O scheduling (no I/O bottlenecks) and memory bandwidth optimized internals (higher throughput of what is in cache).

The trend in database engines is highly pipelined execution paths within a single thread with almost no coordination or interactions between threads. If you look at codes that are designed to optimize memory bandwidth, this is the way they are designed. No context switching and virtually no shared data structures. Properly implemented, you can easily saturate both sides of a 10GbE NIC on a modest server simultaneously for many database workloads.

<comment><USER4> > In-memory databases offer few advantages over a disk-backed database with a > properly designed I/O scheduler.

Hmm...Michael Stonebraker would probably disagree with you on that. For his different newer projects, he claims and somewhat convincingly shows 10x or more performance improvements. The analysis is that ~10% of a typical disk- based system is useful work. By radically simplifying as a result of doing away with the disk-store, you remove those overheads.

A similar argument (also with benchmarks) is made by the RAMCloud people, they claim up to 1000x perf. increase over disk-based storage for a data-center.

Since I am mostly a dabbler (but have also managed to outperform RDBMs by factor of 1000 or more using RAM-based techniques), I would be curious as to what these papers get wrong.

[http://downloads.voltdb.com/datasheets_collateral/technical_...](http://downloads.voltdb.com/datasheets_collateral/technical_overview.pdf)

[http://cs-www.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf](http://cs- www.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf)

[https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud](https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud)

<comment><USER5> It's not just the disk store, also avoiding the time spent locking and unlocking in row-based architectures (i.e. using lock-free algorithms)

[http://www.se-radio.net/2013/12/episode-199-michael- stonebra...](http://www.se-radio.net/2013/12/episode-199-michael-stonebraker/)

<comment><USER4> "...single-threaded, lock-free, doesn't require disk I/O in the critical path, ..."

IIRC, the single-threadedness is made possible in large part by not having I/O on the critical path. (When you wait on I/O, a single threaded design stalls completely, so either you multi-thread somehow or your throughput dies).

:-)

</comment></comment></comment></comment><comment><USER6> The database I want still doesn't exist.

Here's what I want:

\- Easy sharding, a la Elasticsearch. I want virtual shards that can be moved node to node and an easy to understand primary/replica shard system for write/reads. I want my DB nodes to find each other with an easy discovery system with plugins for AWS/Azure/Digital Ocean etc.

\- Fucking SQL. I don't want to learn your stupid DSL. I want to give coworkers a SQL client a say "go! You already know how to use this!". If I want a new feature, then dammit, build on top of SQL the way PostgreSQL has. Odds are, regardless if its some JSON API or SQL, my language will have a client for it that will be superior than writing raw queries anyway.

\- Easily pluggable data management systems. For example, if I do a lot of SUMs and I know I'm not doing writes very often, I want to use CStore. If I'm storing a bunch of strings, I want to able to index it anyway I please - <USER2> one index with Analyzer/Tokenizer X and another with Analyzer/Tokenizer Y - all in a nice inverted index. Good, I can make an autocomplete now. Oh, and sometimes I want a good ol' RDBMS.

\- Reactive programming! It works well in the front end and it'd be amazing in the backend. For example, I want to make a materialized view that's the result of a query, but that gets updated as new rows get inserted or as the rows it uses gets updated. Let's call it a continuous view or something. Eventual consistency is fine. Clever continuous views can solve a lot of performance issues.

\- I want to be able to choose if a table/db is always in memory or not. I don't care about individual rows - that sounds like someone else's problem.

\- Easy pipelining - these continuous views mean that an insert can span a lot of jobs because one continuous view can be dependent on another. I want my database to manage all of this for me and I want to forget that Hadoop ever existed. I want to be able to give my database a bunch of nodes that are just for working jobs if need be. Maybe allow custom throttling for the updates of these "continuous views" so the queries don't get re-run every update if they're too frequent.

\- While I'm at it, I want a pony, too. But I'd settle for this being open source instead.

There's a lot of possible directions for the DB world in the next decade. Me, I think the line between DBs and MapReduce/ETL/Pipelining is going to be blurred.

<comment><USER7> I have a LOT fewer requests than you, but this one is just so irritating:

>\- Fucking SQL. I don't want to learn your stupid DSL. I want to give coworkers a SQL client a say "go! You already know how to use this!". If I want a new feature, then dammit, build on top of SQL the way PostgreSQL has. Odds are, regardless if its some JSON API or SQL, my language will have a client for it that will be superior than writing raw queries anyway.

It pisses me off to no end these developers have to out-think SQL and re- invent the whole damn new wheel for "efficiency's" sake. It seems that no one takes into account friction costs and instead just waggles their dick around saying "Look how smart this new language is or how I co-opted [erlang,perl,JS,etc] into being the query language!" Just stop it. Some people making less than $150k/year are going to have to use this and they are good at DB analysis but not bullshit esoteric language writing.

Good lord this makes me so mad. I feel your pain.

<comment><USER8> That's an amusing (and incorrect) assumption that the smartest people are making >$150k.

<comment><USER7> That's also not the intent of the sentence, but thanks for putting words in my mouth.

<comment><USER8> Fair enough. What was the intent? That's certainly what it sounded like.

</comment></comment></comment></comment></comment><comment><USER9> > It pisses me off to no end these developers have to out-think SQL and re- > invent the whole damn new wheel for "efficiency's" sake.

Worked with someone who did this a couple years ago. I keep trying to get him to explain why he was reinventing sql, and never did get a clear answer to that.

> just waggles their dick around saying

Sorry to be the one to say it, but I don't think that part was necessary or appropriate to this community. Also, using the collective gender-neutral "their" in conjunction with dick waggling is just funny, now that I think about it.

<comment><USER10> There seems to be a culture clash on HN.

On one side there is California, where "dick wagging" is an unnecessary instance of gendered language, certain to drive women out of the tech industry.

On the other side there's the rest of the world, where being offended by "dick wagging" seems dazzlingly childish. It's just a penis, most grown men and women know what they are and observe their motions on a daily basis.

In Bhutan they draw penises on things for good luck. [http://en.wikipedia.org/wiki/Phallus_paintings_in_Bhutan](http://en.wikipedia.org/wiki/Phallus_paintings_in_Bhutan)

<comment><USER11> Avoiding gendered words as a recept for more women in IT seems very funny to me.

My language forces you to add gender-dependent postfixes to every verb and noun. Nobody have a problem with that, and I think there's more women in IT here than in US.

It's obviously not the source of problem. The source is people being jerks. You don't fix that by changing the non-jerks language (jerks won't care).

In fact nonjerks weren't jerks because they treated women the same as everybody. When you embarass them into treating women differently (more carefully) it becomes more awkward and reminds women more often they are different here. Counterproductive IMHO.

Regarding unnessesary vulgarity - it seems weird for me, no matter if it's gendered or not. But people use different styles of communication, that's the diversity people are so proud of.

Regarding SQL - yes please. It's a perfectly good wheel, don't reinvent it without a really good reason.

<comment><USER12> >My language forces you to add gender-dependent postfixes to every verb and noun.

If there's truly no gender neutral way of saying something, then I'd imagine that people always use one gender for generic cases, and as such it's not exclusionary. Which is different from having the option and not using it.

>The source is people being jerks.

Non-jerks being exclusionary is arguably far more of a problem than isolated jerks. If one person says "lol women suck at computers", they're obviously a moron, and can be dismissed. Whereas if everyone around you subtly assumes that all programmers are male, it's far more hurtful, because they're people that you respect.

>When you embarass them into treating women differently

Asking for gender neutral language isn't asking people to treat women differently.

<comment><USER11> > If there's truly no gender neutral way of saying something, then I'd imagine > that people always use one gender for generic cases, and as such it's not > exclusionary. Which is different from having the option and not using it.

Well, the option is always there, you can use "The person that is using this application clicks the button X" instead of "User clicks the button X". "Person" is female so you then use female for every verb. It's just longer, inconvenient and sounds like legal text so nobody does it. People just write everything in male versions. Even "Are you sure?" is different depening on gender of "you", and I'm yet to see application that uses anything other than the male version for dialogs (except for the applications that know your gender somehow).

I think the distinction beetween using defaults without assuming gender, and assumming gender is important, but some people argue for using the contrived language to not be exclusionary, and that's what I'm against, and what I think is counterproductive.

Imagine if everybody talked in legalese when you aproach them, and switched to normal language otherways.

<comment><USER12> Humans are pretty flexible when it comes to language, what sounds awkward or verbose can often become completely natural over time. That said I agree that it's easier to make smaller language changes stick.

There might be an alternative way to phrase things neutrally that's easier to say though. (passive?)

<comment><USER10> Yet if neither men nor women wish to change their own language, why must it be changed?

Sometimes HN reminds me of Christian missionaries: interposing themselves into foreign cultures that they do not understand and saying "No! No! It's all wrong! You do it our way."

It is an ugly kind of imperialism.

<comment><USER11> Meh, nobody is using guns, and the discussion is interesting. I just don't like the assumptions some people make (I've heard that my culture is inherently sexist for example).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> This article is full of so much logical fallacy I'm surprised it made it here. And it's an advertisement none the less.

Creates a red herring by stating he's been doing this a long time and has seen it all.

Creates straw man after straw man in the trashing of memory caches (avoids their use cases), Dynamo (there's a good reason tons of people use various NoSQL Databases) and Hadoop (C'mon, now).

He also creates more logical fallacy in calling various concepts silver bullets that ended up having problems. I don't think anyone serious about technology thinks replication, sharding, load balancing "solves everything". Nothing is a silver bullet and anyone who says something is is selling you something...

And then he fails to really address the MemSQL uses replication, sharding (in a limited sense since the core SQL concept of a JOIN is wrecked here and they have a big warning on their troubleshooting page about an error you users must see often).

SQL is great but I have plenty of great reasons to use other data stores. SQL isn't a silver bullet for data.

Point is, he is calling MemSQL a silver bullet and is obviously trying to sell something while ripping plenty of great ideas and concepts by picking the worst implementations of them and largest misunderstandings of them.

</comment><comment><USER14> Yes. Or as I've said: memory is the new disk. This is why PMCs (performance monitoring counters) are more important than ever, to provide observability for cache and memory analysis. (I'd like some PMCs made available in EC2. :)

</comment><comment><USER15> > It's been 65 years since the invention of the integrated circuit, but we > still have billions of these guys around, whirring and clicking and > breaking. It's only now that we are on the cusp of the switch to fully > solid-state computing.

Am I missing something, or should it read "hard disk" rather than "integrated circuit" here?

<comment><USER16> He's referring to the picture of the hard drive above that line when he says "these guys". It took me a couple reads through that sentence to grasp the meaning = "Why are we still using spinning metal contraptions to store data 65 years after the invention of the integrated circuit?"

</comment></comment><comment><USER17> Amazon doesnt expose much of these statistics (how fast of ram do i get with a M3.large or a c3.med etc) . Does this mean real performance is for those who own their servers?

<comment><USER18> RAM performance is the same for VMs and bare metal. And the ~1.5x performance difference between different grades of DRAM (e.g. 1333 vs. 1600 vs. 2133 MHz) is negligible compared to the massive cache-RAM and RAM-flash gaps.

And speaking of cache, lstopo (from the hwloc package) does work correctly under EC2.

<comment><USER19> It may be the same in the sense that hypervisors don't explicitly limit it, but on a multicore host you're sharing memory bandwidth with the other guests, in the common(?) case when the host has more cores than a guest. You can also experience increased latency when there is access contention.

<comment><USER18> True, if you want full and predictable memory/cache performance you need to rent a full-machine VM (usually 8xlarge) or bare metal.

</comment></comment></comment></comment><comment><USER20> That's how it has always been. We take different storage/memory technologies, sort them by their speed and price, put the fastest but most expensive closest to the CPU and the slowest but cheapest as far as possible. Minimizing memory footprint allows us to do more work on the faster end while minimizing storage cost allows us to store terabytes of data on your bookshelf.

There might have been just two or three levels initially: cpu register(s), system ram, and external storage. Now the spread has several more steps: registers, L1 cache, L2 cache, maybe L3 cache or part of memory as disk cache, SSD (either as a standalone drive or as an on-disk cache inside a traditional hard drive), and the good old spinning platter. We've mostly let go of tape storage by now but those are still sold for their capacity.

However, from the programmer's point of view, nothing has necessarily changed.

We have several levels of storage, more than before, ranging from the fastest on-chip cache ram to the mechanical storage and we still optimize our programs to run mostly in the fastest tip of this memory pyramid. What has changed is the size of the spread itself: the gap between the fastest and the slowest is huge in numbers. But relatively, not so much.

A quick guesstimate of the ratio of microseconds needed for a zero-page read in C64 vs. reading a byte from the 1541 floppy drive versus a read from cpu cache vs. a read from a spinning platter tells that the relative difference still roughly on the same order of magnitude. From various sources, I get a figure between 50-100 million times faster between the fastest and slowest read.

That is also what makes programming so much fun: everything gets redone all the time and the pace of advancements is crazy yet some things don't change. We just do more complex things but still bump into essentially the same tradeoffs.

</comment><comment><USER21> Database vendor frames history of computing in database evolution, makes snide remarks about competing technologies, admits it has no idea where the world is going while invoking the 'history repeats itself' notion. Well, duh.

OTOH, databases are only one component of modern architectures, which the article correctly asserts are largely limited in terms of scalability by throughput and latency. However, scalability is often secondary to functionality. And in terms of functionality, the long list of database types trawled out through the article only serve to highlight the real chokepoint: cognitive overhead.

Perhaps what we really need are tools that enable us to more easily stop and think about the problem. Ideally, tools to test, profile, compare and switch between storage or other subsystem architectures without having to delve in to infinitesimal intracacies of each.

 _Success really depends on the conception of the problem, the design of the system, not in the details of how it 's coded._ \- Leslie Lamport

</comment><comment><USER22> Laughing so hard at this line:

"Bringing you yesterday's insights, TOMORROW"

</comment><comment><USER23> I once learned, in the good old mainframe times, that there are 3 sizes of databases: Small size that fit into RAM, medium size that fit on one computer, and big databases, that require a cluster of computers.

The relational model, and SQL databases play their strong roles in medium size databases, but are to much overhead for a fast small database, and do not scale well for big databases.

It was hoped at that time, that Moors law will beat Wirths law (who claimed this law much later), that big databases will soon be medium sized, nobody would care about performance of small databases that much, and we could happy use SQL for all problems. This was true for surprisingly long time, and still is, if your problem fits into a medium size database.

Unfortunate, computer history turns in cycles, and tends to forget lessons from the past. Coding access to a bunch of different databases was at least standard under COBOL. Coding for half a dozen NoSQL databases now, is a complete mess.

<comment><USER24> That is a nice scale to think about. When I look back most systems I've been involved with are small with todays servers. Rarely more than 50 GB and that actually fits into memory. How many systems actually needs more than about 1000 GB of database data? Things like images and videos can be stored separateley anyway, I'm talking about other data together with metadata about images/videos/files.

</comment></comment><comment><USER25> I have been saying this since the late 90s.

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

Small code & data fit in cache, and run full speed. Fortunately, I can get at the GB that used to be (mainly) on my hard drive faster, now.

</comment><comment><USER26> Okay, if the title is correct, then to heck with traditional RAM and, instead, have _very long addresses_ , say,

         a(i).b(j).c(k) ...

stored in, say, a key-value store. Then, as usual for caching, just hash that long address.

Why do that? Mostly no one really wants the sequential addresses, and a lot of work in software and the processor is calculating those sequential addresses nearly no one really wants anyway. So, e.g., software collection classes, just let the keys be the long addresses and f'get about AVL trees, red-black trees, etc. And for sparse matrices, just use the row and column indices as the addresses and f'get about all the tricky addressing for sparse matrices. Etc.

</comment><comment><USER27> _It means that caching is often more trouble than it's worth._

</comment><comment><USER28> I've always found very unfortunate that memsql is not open source. It looks very interesting. VoltDB seems to fill a similar niche. Has anyone tried both?

<comment><USER29> I have tried VoltDB, it's nice for scaling low latency data access (realtime bidding / adserving is one use case it shines)

</comment></comment><comment><USER30> [http://crate.io](http://crate.io) is pretty much the system described towards the end of the article.

</comment><comment><USER31> how come nobody noticed qwantz.com's T-Rex yet!</comment>


Ask HN: Where can I find a good tl;dr of the different open source licenses? - <AUTHOR>

I'm trying to figure out what license to put on some of my projects, but so far all of the pages I've read are too long and complicated for my (student) brain to understand! <comment><USER2> <http://www.tldrlegal.com/>

<comment><USER3> Very helpful. Thanks! Any thoughts on how accurate the descriptions are.

</comment></comment><comment><USER4> I have used <http://www.tldrlegal.com/compare> and found their descriptions quite accurate.</comment>


Ask HN: What advice would you give to a self-learn programmer just starting out? - <AUTHOR> I am self-learnt and will start applying to the new-grad tech jobs in around four months. What advice do you have for me? <comment><USER2> * Assuming you are a good coder, your biggest problem will be convincing others of that with neither work experience nor academic credentials. Smart employers won't care, and will ask you to do some small piece of take home work to establish your abilities. Shitty employers will ask you about bigO notation, and silently wonder how you ever tied your own shoe laces every morning without an Ivy League degree (often, I believe, because that's what they went to college to learn).

* Build stuff you can show people.

* Don't get caught up in formal learning systems such as courses, lectures and classes. They are incredibly useful, yes, and certainly you should use them, but many people cling to them because they are easier than actually teaching yourself to code, and provide sense of security and accomplishment. When I point out to people that they haven't been actually coding, I'll often be told, 'well, this is how I learn,' and then they go on to show me how little they did.

* Don't fetishize the libraries and tools you are learning now. You will throw away many toolsets in your life: get used to learning new things as a permanent part of your job. I had one coworker who came through a bootcamp, and he tried just about anything to get us to add jquery to our dependencies, because he'd spent so much effort on it and felt so comfortable with it. He was more comfortable adding the entire jquery module to our app than bothering looking up the argument structure of the already included helper method from lodash: not because he was lazy, but because he was scared of the trouble involve in learning something. Neither you nor he can afford that.

<comment><USER3> Id say, learn about bigO notation rather than assume that it's useless. It doesn't require a university degree but it really does help, the more people that have an idea of algorithmic performance both regarding memory and CPU resources the sooner we can get away from all these "web-applications" that barely work but still loads a few mb of unnecessary js libraries. Apart from being annoying this also often leads to unoptimized code that causes wastes large quantities of cpu cycles draining the already feeble batteries of our mobile devices..

So please learn about and/or think about the concepts of bigO even if you refuse to use the math's involved.

<comment><USER2> >It doesn't require a university degree but it really does help, the more people that have an idea of algorithmic performance both regarding memory and CPU resources the sooner we can get away from all these "web-applications" that barely work but still loads a few mb of unnecessary js libraries.

IMHO, this is exactly the kind of academic fetishization that makes these terrible interview questions so common in the first place: Knowing CS theory isn't going to slim down your build size or resource usage - knowing how to slim down your build size and reduce resource usage will do that.

And besides: no junior developer is going to be handed the kind of task where CS knowledge is remotely applicable. They are going to be building React/Angular/Etc components making backend CRUD APIs. They aren't going to be rewriting searching or sorting algorithms. For that matter, they aren't even going to be deciding what libraries to include that overload your phones resources.

I know more than enough CS theory to play the interview games. How much have I used it on the job? Maybe a couple of times a year, if that. In the first few years, never at all.

<comment><USER3> I do kind of see your point at least regarding the usefulness of those types of questions in an interview. I would however still maintain that understanding of fundamental CS theory is and always will be a great benefit.

You say that you "never" use your CS knowledge if that's the case how to you decide if you are going to use a bogosort or a quicksort? I know that javascript simplifies a lot of these things, but you still need to be able to make informed decisions about performance trade-offs in your applications. And we still have a fairly large tech job market that does not involve any javascript at all, forcing developers to have at least some minor knowledge of datatypes.

Finally even if your target is to be a javascript(Angular/react/"whatever is cool right now on the web") developer at some flashy startup, I can't believe that some knowledge of design patterns, algorithms and datatypes would be considered anything other than beneficial.

And I would maintain that the internet as a whole would be a lot better if it was possible to view a page designed to display some text without having to download every framework created.

Sorry for the rant, I do really agree with you that there might be an unnecessary bias towards actual University degrees, this does not mean that the knowledge they represent (that can be learned without ever stepping a foot outside your door thanks to eh internet)is useless or not beneficial to any tech career.

How does stating otherwise differ from stating that civil engineers don't need to know math the have calculators.

</comment></comment></comment></comment><comment><USER4> From my experience:

>> decide what are of programming is in your focus i.e. mobile, embedded, web. Choose desired language. Here from my perspective, there is no language which fits for all solutions. Solution can be created almost in every language, but level of struggling with certain sub-task (functions/actions) might be huge.

>> Read a books about software engineering - how to write code effectively. This will teach you how to organize your code, how to write function, how to write readable code, how to write psuedocode.

>> Read a books about software architecture - here you can learn how to think about application, functionality, usability.

>> Learn basic principles like pointers, memory management, loops etc.

In parallel you have to write code regularly. It's much better to have real world problem which you are trying to solve. It's very important choose suitable level of difficulty. So do just small steps.

I can say programming task at universities are focused on certain aspect of programming or CS. If you are self-learner you have to keep motivated for a long time, so would be fine to have task where you can see and use results. So wouldn't try to solve university home-works. I don't want to struggle with matrix transpose if I don't it at all. I would rather create something which can help me verify my daily outcomes of current full-time job.

Or another (my personal) example... I am working with databases, documents, excel sheets, configuration files etc. I hate repetitive tasks. In case of I have to do the same thing at least a three times per week, I am trying to get everything automated, especially in case if it help me minimize effort, shorten time, reduce errors and typos, validate something, make better decisions.

It is also good points for my promotion in current or next jobs. HR and manager than look at me as "able to solve business/work issues through programming" than just "be able to program something".

(out-of-topic: it's good to have some hard number how you improved something, HR and managers loves story, numbers and savings, but this is another topic)

</comment><comment><USER5> Get a mentor. Seriously. I taught myself some programming for about two years, but this last year, I connected with a good mentor and really grew with his help.

I now work for him. I guess it's networking in action.

<comment><USER6> In what languages do you work? Would you like to be a mentor? Like for me.

<comment><USER7> I'm interested in finding mentors as well. How did you find one?

</comment></comment></comment><comment><USER8> "Stay calm and keep coding."

Just keep doing what you like doing. If what you like doing is coding (and you can keep your work organized, do back and fix things, pay down technical debt as it arises) then you'll have no problem churn out successful projects -- and attracting people and job offers to you on that basis.

</comment><comment><USER9> It's hard to get a programming job without having practical experience. It might be easier to apply to a Testing/QA job and gradually transition to programming when opportunities arrives (test automation -> small tools -> small features -> bigger features...)

</comment><comment><USER10> Read job descriptions for the companies you're interested in. Learn as much as you can about the technology and terminology they use.

</comment><comment><USER11> Never give up! I know it's cheesy but it is true. Just don't quit and you'll be successful.

</comment><comment><USER12> Practice interview questions.

<comment><USER13> really ?

</comment></comment><comment><USER14> Write code.

Write some more code.

Write code again.

Do it everyday.

Do it until you can't live without doing it.

</comment><comment><USER15> If you don't have a degree give up now. Nobody will hire you without one. Your application goes straight into the bin.

<comment><AUTHOR> Sarcasm, I suppose?

<comment><USER15> Not in the slightest. Completely based on first hand experience.</comment></comment></comment>


Twitter follows Facebook down the walled garden path - <AUTHOR> http://www.theverge.com/2012/7/9/3135406/twitter-api-open-closed-facebook-walled-garden

<comment><USER2> This is the current consensus among the best performing tech companies. Close off your ecosystem and own you content end to end. That is the best way to monetize.

Not saying I agree, just saying that is the emerging zeitgeist.

<comment><AUTHOR> Did you read the "What Twitter could have been" Dalton Caldwell blog post¹ last week?

¹ <http://news.ycombinator.com/item?id=4185757>

<comment><USER2> Yes, but I disagree. I think it is actually better positioned than Facebook to build a big business. Twitter can advertise against breaking news, sports, celebs - a ton of eyeballs. And they don't have the obstacles around privacy and personal data that FB does.

That being said, I think they are making a myopic decision by shutting out their third party clients. A ton of innovation has come from those developers and they could easily find ways to integrate them into their advertising plans.</comment></comment></comment>


Timeouts and cancellation for humans (2018) - <AUTHOR> https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ <comment><USER2> Yes, properly handling timeouts and cancellation is the next frontier for programmers to conquer. I was just thinking about this the other day because some program I was using locked up, and of course it worked fine when restarted, and I began to wonder why this happens so frequently. A lot of obscure things can cause hangs, but if every blocking operation has a timeout, the number goes way down.

I think it's unfortunate that even new languages still treat timeouts and cancellation as an afterthought. For example, every Go program I've ever written says:

        select {
            case <-ctx.Done():
                return nil, ctx.Err()
            case thing := <-thingICareAboutCh:
                return thing, nil
        }

Instead of:

        return <-thingICareAboutCh, nil

The language designers thought about needing to give up on blocking operations, and then said "meh, let the programmer decide on a case-by-case basis". And that's the state of the art.

(Getting off topic, this is why I avoid mutexes and other concurrency operations that aren't channels; you can't cancel your wait on them. Not being able to cancel something means that if there are any bugs in your program, you'll find out when the program leaks thousands of goroutines that are stuck waiting for something that will never happen and runs out of memory. Even if the thing they're waiting for does happen, the browser that's going to tell someone about it has long been closed, and so you'll just die with a write error when you finally generate a response. If you have a timeout and a cancellation on every blocking task, your program gives up when the user gives up, and will run unattended for a lot longer.)

<comment><USER3> Go is very much not the state of the art in anything. It's really based on 1980s ideas.

<comment><USER4> more like 60s: Go vs Brand X [1]

[1] [http://cowlark.com/2009-11-15-go/](http://cowlark.com/2009-11-15-go/)

</comment></comment></comment><comment><USER5> I think that this is a good example of where dynamic scope is helpful.

We're used to lexical scope: it's easy to reason about, and it is a really good default. But sometimes it makes sense for one function to apply settings for all the functions it calls, without interfering with _other_ functions, scopes, threads or processes (like setting a global would).

It'd be nice to be able to say 'this function should timeout within 10 ms' and then any function called will just automatically timeout.

Go's contexts integrate timeouts and cancellation, and permit one to add _any_ value, should one wish to, but you have to be disciplined and add a context argument to every single function. It'd be better, I think, to support it natively in the language. Lisp does this: any variable declared with DEFPARAMETER or DEFVAR is dynamic, and you can locally declare something dynamic too.

One can fake dynamic scoping with thread-local storage and stacks or linked lists, if one needs it, but it can get ugly.

Dynamic scoping doesn't get the attention or respect I think it deserves. It's arguably the wrong thing by default, but when it's useful, it's _really_ useful.

<comment><USER6> I think that what you're describing is how Trio's cancellation scopes work [1]. Trio is an alternative async library for Python [2] (as opposed to asyncio). It's pretty neat.

[1] [https://vorpus.org/blog/timeouts-and-cancellation-for- humans...](https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)

[2] [https://github.com/python-trio/trio](https://github.com/python-trio/trio) [2]

<comment><USER7> It's possible to implement the concept in asyncio as well, just not enforce it for dependancies due to ensure_future().

See ayo for a very rougth draft of the idea: [https://github.com/Tygs/ayo](https://github.com/Tygs/ayo)

</comment></comment></comment><comment><USER8> This is something that is really nice in gevent. Under the hood it's doing something similar to what the article says - every time you make a blocking call (in gevent, this means yielding to the event loop until your event occurs), you might have a gevent.Timeout raised.

Since gevent is generally used by monkey-patching all standard IO, most code doesn't even need to be aware of this feature - it just treats a timeout as an unhandled exception.

From the user's perspective, it can be used simply as a context manager that cancels the timeout on exit from the block:

        with gevent.Timeout(10):
          requests.get(...)

By default this will cause the Timeout to be raised, which you can then catch and handle. As a shorthand, you can also give it an option to suppress the exception, effectively jumping to the end of the with block upon timeout:

        response = None
        with gevent.Timeout(10, False):
          response = requests.get(...)
        if response is None:
          # handle timeout

</comment><comment><USER9> If you think this is difficult, then try designing an abstraction that can reliably (best effort) report progress of any operation in your program.

There is a reason why most progress indicators suck, and it's because it is in general surprisingly hard to write one.

</comment><comment><USER10> I often wonder why SO_RCVTIMEO/SO_SNDTIMEO avaiable for sockets but not for file descriptors. Setting timeout once then using classic read/write on blocking FDs is easy, meaning error code handling is appropriate.

<comment><USER4> I think it is because network is inherently different from disk. A disk might be slow, but data will eventually arrive (bad disk or network mounts being the exception of course).

<comment><USER11> > bad disk or network mounts being the exception of course

That's kind of the point. Programs shouldn't assume that any particular file is local. Any file may be hosted on a network mount, and that means network- style asynchronous interfaces should be used to access the data.

</comment></comment></comment><comment><USER12> I definitely assumed this would contain clever tips about how to handle it when coworkers don't respond to your emails, don't accomplish things they promised, or don't follow-through. Maybe some automation methods to handle those situations.

</comment><comment><USER13> Very systematic and accessible description of the problem and various alternatives including their origins. I learned a lot reading the post, thank you!

</comment><comment><USER14> I'm not convinced the task-based approach doesn't work. Perf-wise there's no reason that tasks have to have the overhead of threads.

Syntactically, I think it is worth distinguishing between things that can time out and things that can't, because you usually need to do some sort of cleanup on timeout.

In fact as far as I can tell, the cancel scopes provided by Trio with the async await syntax are exactly isomorphic to Scala's tasks from the cats library (where they are called IO).

Also I'm not sure I understand the author's preference for thinking of timeouts as level-triggered rather than edge-triggered. While it's an interesting way of thinking about the problem, and would be the natural way a timeout is implemented in an e.g. FRP system (a lot of flavors of FRP are essentially entirely level-triggered systems), it doesn't seem like the way you'd implement things in a non-reactive system. What's wrong with just killing the entire tree of operations (as is usual when you propagate say, an exception) on a timeout, or from a top-down manner when you put a timeout on a task?

Timeouts are fundamentally tied with concurrency (they are a concurrent operation: you're racing the clock against your code and seeing who wins) and to me the tricky thing about timeouts is exactly the same trickiness that you face with concurrency, namely shielding critical sections. How you decide to pass timeout arguments seems like a secondary concern. Just like with normal concurrency, you need to make sure that certain critical sections are atomic with respect to timing out, either by disallowing timeouts during that critical section (you therefore need to make the critical section as small as possible, ideally a single atomic swap operation) or implementing a reasonable form of rollback. (Of course you can always take the poll-based approach where you poll for timeout status, but again this is just a specialization of a general concurrency strategy)

</comment><comment><USER3> FP libraries have pretty much solved this IMO. You create a value that describes what you want to happen and that description can include cancellation if some condition is met (e.g. it takes too long). There are limitations imposed by the runtime on what you can actually cancel (e.g. I don't believe all OS calls can be interrupted) but beyond that it works as specified.

Here's one example of such a library, though without a bit of FP background it probably doesn't make a great deal of sense:

[https://typelevel.org/cats- effect/typeclasses/concurrent.htm...](https://typelevel.org/cats- effect/typeclasses/concurrent.html)

<comment><USER15> I dunno. As bad as Haskell's exceptions are, I still didn't see anything better.

On a sane system, every little thing must be cancellable, otherwise nothing really is. This interface fails because of this.

</comment></comment><comment><USER16> Boost.ASIO (C++) does not expose the SO_RCVTIMEO socket options and instead makes you use a deadline_timer explicity. It's very annoying but this article kind of explains why it is that way.

</comment><comment><USER7> My first though was "oh, another covid-19 article". The human mind is funny.

<comment><USER17> We're all on timeout and everything is cancelled. Makes sense.

<comment><USER18> sudo killall -19

</comment></comment></comment><comment><USER19> I have spent way too much of my time as a developer over the years hacking on software to remove ill-conceived timeouts where some developer said--sometimes not even in one place but for some insane reason at every single level of the entire codebase--"this operation couldn't possibly take longer than 10 seconds"... and then it does, because my video is longer than they expected or I have more files in a single directory than they expected or my network is slower than they expected (whether because I have more packet loss or more competition or more indirection) or my filesystem had more errors to fix during fsck than they expected or I had activated more plugins than they expected or I had installed more fonts than they expected or I had more email that matches my search query than they expected or more people tried to follow me than then expected (for months back when Instagram was new I seriously couldn't open the Instagram app because it usually took more than the magic 10 seconds--an arbitrary timeout from Apple--to load my pending follower request list for my private account; the information would get increasingly cached every load so if I ran the app over and over again eventually it would work) or my DNS configuration was more broken than they expected or I had a more difficult-to-use keyboard than they expected or I had more layers of security on my credit card than they expected or _any number things that they didn 't expect_ (can you appreciate how increasingly specific these examples started becoming, as I started having horrifying flashbacks of timeouts I had to remove because some idiot developer decided they could predict how long something could take and then aborted the operation, which seems like the worst possible way of handling that situation? :/). Providing the user a way to cancel something is great, but programming environments should make timeouts maximally difficult to implement, preferably so complex that no one ever implements them at all (and yes, I appreciate that this is a pipe dream, as a powerful abstraction tends to make timeouts sadly so easy people strew them around liberally... but certainly no timeout arguments should be provided on any APIs lest someone arbitrarily guess "10 seconds"): if the user, all the way up at the top of the stack, wants to give up, they can press a cancel button. And to be clear: I don't think timeouts are something mostly just amateur programmers tend to get wrong and which can be used effectively by experts (as is the case with goto statements or random access memory or multiple inheritance)... I have _never_ seen a timeout--a true "timeout" mind you, as opposed to an idempotent retry (where the first operation is allowed to still be in flight and the second will, without restating, merge with the first attempt as opposed to causing a stampede; these make sense when you have lossy networks, for example)--in a piece of software that was a feature instead of a bug, where the software would not have been trivially improved by nothing more than simply deleting the timeout, and I would almost go so far as to say they are theoretically unsound.

<comment><USER20> It's a double edged sword. A lot of system failures happen because every single thread winds up accidentally blocking on something that is never going to return for one reason or another. In such cases a timeout is able to unblock the threads.

Maybe the developers collected lots of data and said p99 latency is X, so let's set the timeout X+alpha. If something takes drastically longer than most requests it's probably something going wrong. Maybe your latency was the 99.99999 and the timed you out.

Or yeah the devs just guessed and guessed badly and the timeouts cause more problems than they solve.</comment></comment>


Oracle Whitepaper: The Department of Defense and Open Source Software - <AUTHOR> https://blogs.oracle.com/WebLogicServer/entry/whitepaper_the_department_of_defense

<comment><AUTHOR> direct link to the whitepaper: [http://www.oracle.com/us/products/middleware/cloud-app- found...](http://www.oracle.com/us/products/middleware/cloud-app- foundation/weblogic/dod-and-open-source-software-2012277.pdf)

Oracle argues that open source for military applications would be 1) more expensive and 2) less reliable than commercial software. The whole paper is a rehash of an old oracle whitepaper from 2009 [1]. Ironically both points are refuted by the DoDs own FAQ on Open Source Software [2]. It's noteworthy too, that the DoD has long years of experience using open source software and has published its take away lessons [3].

So what's the reason for Oracle to rehash its old FUD right now and picking a target that obviously knows better?

[1] [http://www.oracle.com/us/industries/046045.pdf](http://www.oracle.com/us/industries/046045.pdf)

[2] [http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx](http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx)

[3] [http://dodcio.defense.gov/Portals/0/Documents/FOSS/OTD- lesso...](http://dodcio.defense.gov/Portals/0/Documents/FOSS/OTD-lessons- learned-military-signed.pdf)</comment>


Initial Validation of an Idea for an Enterprise Marketing Platform - <AUTHOR> https://surveyplanet.com/5902452488b01e302d0b7950 <comment><AUTHOR> Having stated before that I have been tasked with building a website for a "portfolio course" as part of my Web Development B.S. degree and that I have decided to build an enterprise marketing platform similar to Product Hunt, Beta List, and Indie Hackers I decided it would be best to create a survey for gathering everyone's feedback about the platforms and somewhat about the platform I am working on. Thank you in advance for your time and consideration!!</comment>


Phys Ed: Does Music Make You Exercise Harder? - <AUTHOR> http://well.blogs.nytimes.com/2010/08/25/phys-ed-does-music-make-you-exercise-harder/

<comment><USER2> When running, music seems to keep me energized. The playlist I have now starts at a fairly quick tempo and increases slightly toward the end. Since I tend to stay in rhythm with the music, I find myself running faster without realizing that I'm putting in extra effort.

</comment><comment><USER3> This bit I think is particularly interesting:

 _But there are limits to the benefits of music, and they probably kick in just when you could use the help the most. Unfortunately, science suggests that music's impacts decline dramatically when you exercise at an intense level. A much-cited 2004 study of runners found that during hard runs at about 90 percent of their maximal oxygen uptake, a punishing pace, music was of no benefit, physiologically_

Listening to music can get me pumped up for lifting weights, but it's a distraction when I'm actually doing it.

</comment><comment><AUTHOR> Writing code to any fast-paced song (instrumentals only, though) tends to up my mental energy toward coding. Take away my chair and let iTunes pick the proper song and plenty of stuff gets written. It's a mood modulator for me, if anything and that helps with code.</comment>


Ask HN: Why Do Airlines Board From Back To Front? - <AUTHOR>

<comment><USER2> Mostly, they don't. Boarding priority is governed by a few factors, most prominently giving the frequent fliers and first-class ticket holders the feeling like they're getting their money's worth. Coach is boarded back to front because a) coach is (semi-intentionally) treated like luggage which moves itself and b) boarding back-to-front is faster that front-to-back, in that it has less "person stowing their bag blocks the aisle" moments. Saving 10 minutes on boarding per plane per trip is worth, literally, hundreds of millions of dollars.

</comment><comment><USER3> Remember, if boarding is screwed up and slow (and studies have suggest that it's significantly faster to board window, middle, aisle, all things being equal), then early boarding is a privilege/perk they can sell.</comment>


C/C++ Array Size - <AUTHOR> https://leimao.github.io/blog/CPP-Array-Size/ <comment><USER2> This isn't a notable enough topic to feature on Hacker News IMO, it's more like a stack overflow answer. Even if it were, to be honest it's a very poor article on the subject:

* Mixes up C and C++ in the same article. These languages obviously have a shared heritage and some topics apply to both, but this is certainly a case where they're different enough that separate articles would be better: C has VLAs (actually g++ might also have them as an extension) and C++ has templates and the container concept.

* Had discussion of malloc which is basically irrelevant to C++ except for historical discussion or interoperability with C, both of which are irrelevant here. Basically this is a symptom of the previous point.

* Doesn't mention that the sizeof(array)/sizeof(array[0]) trick can be put in a macro in C, and usually is, or why this is frowned upon in C++.

* Doesn't mention the risk of using sizeof(array)/sizeof(array[0]) on a raw pointer, specifically that array[0] will compile, which would surprise some people.

* Doesn't mention that in C++ you can use templates to create a completely safe array size function.

* Doesn't mention that the C++ library has such a function in it! If the article is about C++ then this should actually be the leading point, with discussion about how it works as the following content.

* Doesn't discuss how that function also works for STL containers, and what error you can expect if you pass a raw pointer to it.

* There are more subtleties but I'm on my way to writing a blog post myself here so I'll stop.

* On a stylistic note: there is way too much text and code before you get to the actual point, which is hard to find if you don't already know what to look for. And it's jarring to use "please" in instructions, I know it seems like it's being polite but it actually turns a fact (if you want to X then you can do Y to accomplish it) into a request (please do Y).

I hope you're the blog author or that was a bit of a waste!</comment>


A Day on the London Underground - <AUTHOR> http://wgallia.com/#!underground

<comment><USER2> Very nice job! I would like to see how each station is hit by arrivals and departures. There are stations that have much more traffic than others and it could be cool to see it in real time. For example people arriving to Oxford Circus at 9 am and departing at 5. I don´t know how it could be done and don´t clutter the map, maybe highlighting the name somehow..

Also how do you display line changes? do you create an optimal default route?

</comment><comment><USER3> This website keeps trapping my text cursor, so I can't scroll with anything other than my mouse. Very obnoxious.

<comment><USER4> Look at the very top of the page: "you can navigate this site with your keyboard".

So to make the site navigable by keyboard, they break keyboard navigation? What the hell. Any time you start typing your cursor ends up in that stupid box.

I clicked the help link and it lets you know that you can get normal keyboard functionality by pressing "ESC". That's nice.

There is a small list of commands that are supported and it suggests using tab to autocomplete. But that just tabs to the next input element for me.

WTF is this crap? It breaks the web and adds no additional functionality.

</comment></comment><comment><USER5> Where did you get the TFL dataset?

<comment><USER6> Search for "Oyster card journey information" on this page: [http://www.tfl.gov.uk/info-for/open-data-users/our- feeds](http://www.tfl.gov.uk/info-for/open-data-users/our-feeds)</comment></comment>


One day after winning $532M award, Smartflash hits Apple with fresh patent suit - <AUTHOR> http://setexasrecord.com/news/301909-one-day-winning-532m-award-smartflash-hits-apple-fresh-patent-suit <comment><USER2> This case is great for startups, incidentally. Apple has been distinctly reluctant to support patent reform that would threaten their own mountain of garbage software patents.

A few billion dollars in bogus jury verdicts -- especially if they have to actually pay them -- might make Apple reconsider taking the trolls' side in Washington so often. All we need after that is to get IBM and Microsoft back on the side of ending software patents as they once were before getting so many themselves.

</comment><comment><USER2> "Smartflash is represented by Bradley W. Caldwell, Jason D. Cassady, John Austin Curry, Daniel R. Pearson and Hamad M. Hamad of Caldwell Cassady Curry P.C. in Dallas; and T. John Ward and T. John Ward Jr. of Ward & Smith Law Firm in Longview."

T John Ward is the entrepreneurial federal judge that created the Troll haven in Eastern Texas by changing the rules to make accused infringers almost helpless against plaintiffs and drive up costs.

Cashing it in.

<comment><USER3> He has even the Wikipedia entry:

[http://en.wikipedia.org/wiki/T._John_Ward](http://en.wikipedia.org/wiki/T._John_Ward)

</comment></comment><comment><USER3> More about the Smart-Flash:

[http://arstechnica.com/tech-policy/2015/02/company- without-a...](http://arstechnica.com/tech-policy/2015/02/company-without-a- product-wins-533m-verdict-vs-apple-says-its-no-patent-troll/)

I've checked some dates:

The first patent Smart-Flash claims ([https://www.google.com/patents/US7334720](https://www.google.com/patents/US7334720)) has the filing date of Jan 19, 2006.

Apple's iTunes exist in public since January 9, 2001.

The "priority date" of the patent is "Oct 25, 1999." It can be that the original application was "something-mumble-something" and that the later filings inserted the details really developed by others.

More than that, the patent doesn't appear to have the real invention details relevant:

"At step S10 a _smart Flash card is inserted into a content access terminal smart Flash card interface_. The system owner web page is then loaded onto the content access terminal and displayed to the user (step S11)."

It's about (surprise) the Flash cards carried by the users and "inserted" around?

</comment><comment><USER4> Smartflash, not Smartfish! For a second there I was like, WTF, when did Superfish sue Apple, and how the hell did they WIN?!

<comment><AUTHOR> /facepalm

I am not a smart fish :(

</comment></comment><comment><USER5> First patent in list: [http://www.google.com/patents/US7334720](http://www.google.com/patents/US7334720)

Reads like brilliant legal satire.

</comment><comment><USER6> Just a small typo in the title: it's Smartflash instead of Smartfish.</comment>


Machine learning algorithm benchmarked in Matlab, R and Scala - <AUTHOR> http://blog.brusic.com/2011/08/machine-learning-ex2-benchmarks.html

<comment><USER2> As it says in the post, this is just the benchmark of a for loop, and the author rightly says that nothing can be inferred from it.

When it comes to prototyping, using languages such as scala brings nothing for such type of mathematical algorithms as it is basically only loops and double operations. You are better off with languages such as R/scipy where most of the core is written in C/C++ and handily wrapped (there are many heavily optimized packages in R to do gradient descent).

For production code, well, you know the correct solution ;)

</comment><comment><USER3> None of this is as fast or efficient as implementing most of the stuff in python/scipy and reimplementing the occasional hot spot in C++ :)

<comment><USER4> I've found Matlab to consistently outperform numpy (the gap growing in recently releases adding multithreading supprt to Matlab), and the C++ interface is pretty much equally convenient. (Weave is awesome for python, but only really usable in small toy problems.)

</comment></comment><comment><USER5> I wonder if in his installation of R he has ATLAS build in as the linear algebra workhorse. That seems to be optimized for something like this- I wonder how this would affect R's speed.

</comment><comment><USER6> This post compares Octave, not MATLAB. Similar languages, but completely different implementations. I'd bet that if it were tested in MATLAB, it'd be much faster.

<comment><USER7> Just joined hacker news in order to comment.

You are correct, the MATLAB code was tested in Octave. I would not have worded the title HN is such a way. The goal is to learn the algorithms involved, not trying to come up with the fastest version possible. The interesting part is actually the performance of the JVM, not the comparison between languages.

</comment></comment><comment><USER8> Good luck spending thousands of man-years reimplementing all of statistics and numeric computing in Scala.

<comment><USER9> But how about reimplementing R in Scala? Or, better yet, in Clojure? The best of both worlds.

<comment><USER10> I'm sure you're already aware of this, but just in case:

<http://incanter.org/>

<comment><USER9> Indeed, Incanter is a famous project and for a while was one of the best showcases for Clojure.

What it does is it implements some of the functionality of R in Clojure. What I am talking about is instead compiling R to Clojure (or Java runtime; there are portions of R projects implemented in C which may not map to Clojure efficiently). This way, the R community does not lose the extensive library of projects it has been producing for years.</comment></comment></comment></comment>