Reflections on Rusting Trust - <AUTHOR> http://manishearth.github.io/blog/2016/12/02/reflections-on-rusting-trust/ <comment><USER2> An interesting experiment would be to see if a modern, easy(relatively) to audit compiler like tcc can still be used to bootstrap a more full-featured compiler like gcc or llvm. That would provide at least some protection against this, in that it is unlikely a backdoor in your binary version of gcc will have a trusting trust backdoor for tcc, which can then compile a clean gcc.

I know this was possible in the past, but I'm not sure if tcc can still compile a relatively new gcc.

<comment><USER3> This particular attack is done entirely in the rustc frontend, so adding another way to build the backend shouldn't matter? One requires a new implementation of the frontend to apply diversity mitigations.

<comment><USER4> Which makes me wonder if Miri ( [https://github.com/solson/miri](https://github.com/solson/miri) ) counts as an alternate implementation of the frontend. Combined with, say, Cretonne ( [https://internals.rust-lang.org/t/possible-alternative- compi...](https://internals.rust-lang.org/t/possible-alternative-compiler- backend-cretonne/4275) ) I wonder if we couldn't cobble together an alternate frankencompiler for mitigating RoTT.

<comment><AUTHOR> You need to generate the MIR though (to feed to miri); this only fixes attacks that happen in the pipeline after MIR. Doing path and type resolution is the tough part and so far we only have one implementation of that.

[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc) exists, anyway. I don't think it can compile rustc yet.

</comment></comment></comment></comment><comment><USER5> How about writing a minimal pseudo-Rust compiler that treats all invalid Rust code as undefined behavior? This would be a lot easier than reimplementing the real Rust compiler, because a lot of the complexity is in the compile time error checking (eg. the borrow checker) and the detailed error messages. The original Rust compiler could be used to check the code is valid first. Would this be any use for diverse double compiling style countermeasures? You might be able to write a backdoor that both circumvents the error checking in the real Rust compiler and exploits undefined behavior in the pseudo-Rust compiler, but this must be more difficult than a traditional trusting trust attack.

<comment><USER6> Someone has tried to do something along those lines:

[https://github.com/thepowersgang/mrustc/blob/master/README.m...](https://github.com/thepowersgang/mrustc/blob/master/README.md)

> Thankfully, (from what I have seen), the borrow checker is not needed to > compile rust code (just to ensure that it's valid)

It's not finished, though, and honestly I'm pretty sure that borrow checking isn't even that hard compared to all the other stuff a Rust compiler has to do, like generic/trait resolurion. But we'll see.

<comment><USER7> > It's not finished, though, and honestly I'm pretty sure that borrow checking > isn't even that hard compared to all the other stuff a Rust compiler has to > do, like generic/trait resolurion.

You can implement basic trait resolution via name mangling and a global map. I did this as an experiment a number of years ago to implement type class-like overloading in C. I'm not sure how far you could take that technique though. I don't think it would work for higher-kinded types, but Rust doesn't have those.

</comment></comment></comment><comment><USER8> If you really find that attack interesting, you might also find it interesting to read the paper Thompson ripped it off of. Paul Karger co-invented INFOSEC and more attacks/defenses than about anyone in the field if you're counting foundational stuff. He wrote during his landmark pentest of MULTICS that the PL/I compiler could be subverted with a trap door. Added you could even do a compiler/compiler trap. The trap doors were their favorite technique. Thompson was working on MULTICS and received that evaluation. His initial citation for his idea was "an unknown, Air Force document." They made him change it later by giving him another copy. Everyone still credits Thompson despite Karger inventing it and the original mitigations. Those became part of Orange Book class A1 requirements for security certification with all those products coming with defenses against subversion by malicious developers.

The misattribution and forcing a correction by Thompson is in 3.2.4 of their lessons learned paper:

[http://hack.org/mc/texts/classic- multics.pdf](http://hack.org/mc/texts/classic-multics.pdf)

Here's the original paper where the so-called Thompson attack is described on page 17.

[https://www.acsac.org/2002/papers/classic-multics- orig.pdf](https://www.acsac.org/2002/papers/classic-multics-orig.pdf)

Also note they were inventing both hacking techniques and INFOSEC while doing this evaluation. It was part of forerunner work happening among small number of people with little to draw on. It's why you see me say "the legendary Paul Karger" when describing the results they got. Due credit might be "Paul Karger's compiler attack popularized & further explored by Ken Thompson's paper, Trusting Trust." I keep mentioning it until more give it.

Back on topic. These days we have verified and certifying compilers, too. Even typed assembly language with correctness proofs. Lots of stuff to base it off of that's close to what most developers can understand. Basic refinement from Rust compiler code with no optimizations to macro assembly or local scripting languages is what I've been recommending outside verified compilers since any developer can do it without special tooling. I even proposed bash one time although as a compile target more than what I'd try code it in lol. I see using local scripting is in your suggestions, too. That different people are thinking on same lines here more often might mean it's worth exploring further.

</comment><comment><USER9> A way to migtate this attack is here [http://www.acsa-admin.org/countering- trusting-trust-through-...](http://www.acsa-admin.org/countering-trusting- trust-through-diverse-double-compiling/) .

<comment><AUTHOR> Yes, I mention it in the post :)

<comment><USER10> Worth linking "diverse double-compiling" there or to some other resource, if I may make the suggestion.

For other interested readers:

a) html version of David Wheeler's dissertation: [http://www.dwheeler.com/trusting- trust/dissertation/html/whe...](http://www.dwheeler.com/trusting- trust/dissertation/html/wheeler-trusting-trust-ddc.html). I read it over a week last month, and it made a big impression on me.

b) the HN discussion for the Wheeler dissertation: [https://news.ycombinator.com/item?id=12666923](https://news.ycombinator.com/item?id=12666923)

<comment><USER8> As I said there, Wheeler was exemplary for handling most of this right ahead of time. He gave credit to Karger for inventing the compiler subversion attack. He wrote the reference page on high-assurance FLOSS (for compiler verification) and high-assurance SCM (for repo security, esp distribution). He also wrote a cheat I gripe about in reproducible builds to give us something to work with if high-assurance methods get ignored. Any of his stuff on this subject is worth reading.

Here's his high-assurance and SCM pages:

[http://www.dwheeler.com/essays/high-assurance- floss.html](http://www.dwheeler.com/essays/high-assurance-floss.html)

[http://www.dwheeler.com/essays/scm- security.html](http://www.dwheeler.com/essays/scm-security.html)

</comment></comment></comment></comment><comment><USER11> This is pretty cool, and a neat demo.

For the minority of you that haven't read the original Reflections on Trusting Trust, you should do so now. It goes more in depth on this attack category, and its implications. Personally, I would say it's one of the few papers that should be required reading for programmers (along with In The Beginning Was The Command Line, and The Lambda Papers).

</comment><comment><USER12> So, technically, it is possible that there's an undetected backdoor that has lingered around since GCC 1.0

<comment><USER13> Technically it would have been in the original C complier written for the original unix by Ken Thompson and Dennis Ritchie, and been compiled in every complier and login utility since the 70s. At this point try finding a complier that doesn't trace is compiling lineage at some point reach back to a complier compiled by a complier that doens't eventually reach back to it may be pretty hard.

<comment><USER12> True, but that compiler wasn't open source. The real head-scratcher here seems to be that you can have a self-replicating security vulnerability in a completely open source stack _including the compiler_

</comment></comment></comment><comment><USER14> > "The local variable is called krate because crate is a keyword"

This is an interesting solution to a problem I often face (whenever I write a tool to in environment X to process something for environment X) . Is this a common way to handle this problem? I don't think I've seen this before.

<comment><USER15> Yes. In Ruby, 'class' is a keyword, so most people use 'klass', for example.

The other one that comes up in Rust is 'type', people tend to use 'ty'.

<comment><USER16> The Java version used to be 'klass' and 'clazz' \- haven't seen it in a few years though.

<comment><AUTHOR> I've seen it crop up quite often in JNI code (also code that uses reflection)

</comment></comment></comment></comment><comment><USER17> Say a trusting trust attack is discovered. Whats the resolution? Do you manually edit the binary? Do you rewrite a compiler in a language with a verified compiler?

Would something like randomizing memory layouts, or reversing stack direction be an easy mitigation or solve an attack like this?

<comment><USER18> you use an old compiler binary that didn't have the attack yet to compile the latest source code that it is able to compile, then use that compile the latest it can compile, and so forth.

what I mean is that I wouldn't expect a the 2012 rust prerelease to be able to compile the 2016 rust source code, but it can probably do 2013, use that to compile 2014, use that to compile 2015 use that to compile 2016.

As long as you have a single binary from any point before the attack was introduced it shouldn't be an issue. The whole point is that at no point does the source code contain the trust backdoor, so you can just work forward from any binary that doesn't have it yet.

if the very first version of rust binary already had it as an issue, as well as was written in rust, you could conceivably have a problem though. then you would need an alternative compiler, however sub-optimal it might be...

or you could simply patch and remove the backdoor from the binary and then have it compile itself without inserting the backdoor.

<comment><AUTHOR> > but it can probably do 2013, use that to compile 2014, use that to compile > 2015 use that to compile 2016.

Clearly you aren't aware of Rust's history :)

proto-Rust has been under so many rapid changes that each compiler usually only compiles with a specific hash. _Now_ stuff works with a numbered Rust release, but that's a relatively new phenomenon. This process will likely need to go through hundreds of compilation steps. Doable, but not as simple as a year-by-year process.

<comment><USER19> I believe the year numbers were used by logicallee only as an example. Of course, if somebody is trying this, they need to figure out a different (smaller) time scale that actually works.

In the worst case, you have to follow each commit in the version control system of the compiler, but I'm pretty sure you don't need to do it that fine grained.

<comment><USER18> yes. I'm pretty shocked Manishearth didn't get that I was just giving examples of the process with placeholder dates, since I started my comment _explicitly_ stating (I add emphasis here):

>you use an old compiler binary that didn't have the attack yet to compile _the latest source code that it is able to compile_ , then use _that_ to compile the latest _it_ can compile, and so forth.

in trying to find the "latest source code that it is able to compile" you can do a binary search backward from the current version of the source code. it doesn't take long to find the latest version for each one (i.e. the latest each one compiles without error, into a working binary that passes some test suite). And anyway whenever you're binary-searching forward (i.e. after any point where the binary search yields ""greater-than" because the one you just tried compiled) then you can just use the version you just successfully compiled. Let me illustrate what i mean with this binary search:

so if we're at version 1 million today, which the version 7 doesn't compile, then you try version 7 on version 500,000 (it'll fail), then on version 250,000 (it'll fail), version 125,000 (it'll fail), version 125,000 (it'll fail), version 62,500 (it'll fail), version 31,250 (it'll fail), version 62500 (fail), version 31250 (fail), versions, 15625, 7812, 3906, 1953 and 976.

Now suppose that version 7 compiles version 976 successfully. So the failure with version 7 is between 976 and 1953. But since version 976 is stronger, you can start working forward with version 976. So it's like a binary search that's restarted whenever you get a "greater-than".

Even if for some reason this were a manual process, each time you get a working version you at least halve the remaining space.

Finally, as you said above, someone could make a batch file / shell script that literally goes through every commit in the version control system (not skipping any) and always use the previously working version on the next working version. A script doing so may well run in matter of days, though, depending on how long it takes to compile a the compiler compiler. Ordinarily there are a lot of commits!

The binary search above cuts this down significantly. (However the binary search isn't theoretically _guaranteed_ to be faster; after all theoretically we can imagine that version 7 compiles version 8 but fails on version 9; version 8 compiles version 9 but fails on version 10; etc. So theoretically every single commit could be breaking. (Theoretically.)

But that's extremely unlikely to be the case. I don't imagine you'd have to do more than a few hundred compilations with the above binary-search methodology before you got one that started with version 7 but stepping through the commits in the way specified, produced a binary that compiles the latest version.

The process may have to be partly manual due to breaking changes in semantics of invoking the compiler or its dependencies, but that should be rare.

This process would also in the end allow you to do a bit-for-bit comparison of the output of the current version of the compiler when compiled using the above trusteable version, versus compiled from source code with the "trusting- trust" backdoor (where every version is backdoored and inserts a backdoor when compiling itself, without this backdoor being in the source code anywhere.

so the above process would let you tell whether there's a trusting-trust backdoor, as long as there is a single early version that for sure didn't have it yet, and you have the commit history (from which the trusting-trust has been edited out).

as I said above, if you don't have a single known-good version without the trusting-trust backdoor, then you'll have to write something that can compile version 2 or 3 (or 7) yourself, in another language.

<comment><AUTHOR> I did get that they were placeholders :)

I just wanted to note that the scale was way off. You said "I wouldn't expect a the 2012 rust prerelease to .." followed by "but it can probably do 2013", so it was clear you had an expectation of what the dates would be approximately like.

And for many compilers, this is true -- you can use really old compilers to compile the new one. But not everyone is aware of how tumultuous Rust's history is, so I thought it interesting to note.

I should have worded it better I guess.

<comment><USER18> yeah I was just trying to illustrate what I meant, like, the process. And you're right, I didn't know it was so tumultuous so with your clarification it's an interesting observation :)

(By comparison the specifications for C don't break earlier compilers often at all.)

Thanks for the clarification :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I suppose the true counter is to write a verified scheme (or forth) interpreter in assembly language, and then write a simple rust compiler in that scheme, which you use to compile the real compiler, and then you can use that to make an optimized build of the compiler.

>So you have a string containing the contents of the module, except for itself

I assume interesting versions of TT would have to avoid this trick, since someone running "strings" on the binary would notice something very suspicious, unless something strange is done to string literals.

<comment><AUTHOR> Unless your assembler, loader, OS, or microprocessor is also backdoored :)

The original article was really about this -- at the end of the day, you have to trust _someone_. Of course, we more easily trust microprocessors and assemblers over binary blobs, so

> I assume interesting versions of TT would have to avoid this trick

Pretty easy to encode the string literal into some binary format.

Alternatively, serialize and later deserialize the AST with a stable binary serialization mechanism.

A really good version of TT operating on the AST would have to backdoor not only the part where it _creates_ the AST, but also the parts where intermediate state is displayed by the compiler (e.g. where it can dump AST/MIR output).

There are things you can do. As a proof of concept, I didn't bother to do them. My current POC is toothless and I like it that way!

It's cleaner to instead operate at the _end_ of the pipeline; on llvm ir or the generated binary (but it's also harder to write). And if you can insert a trusting trust attack in llvm itself, well, that would be something :)

<comment><USER21> > Unless your assembler, loader, OS, or microprocessor is also backdoored :)

True... but it has to be backdoored for that particular system. There are many ways you can make it very unlikely that the other compiler/system is backdoored for the same target.

For more information, see my work: [http://www.dwheeler.com/trusting- trust/](http://www.dwheeler.com/trusting-trust/)

<comment><AUTHOR> Of course :)

Great work on DDC, btw, I really enjoyed that paper.

<comment><USER21> Thanks!!

I hated the idea that there could be an uncounterable attack... so I kept at it until I could show that there _is_ a countermeasure.

</comment></comment></comment></comment></comment><comment><USER22> I believe this attack featured early on in the Nexus trilogy of books by Ramez Naam.

I remember being impressed at the time. An excellent read covering many topics often featured on HN.

Edit: typo

</comment><comment><USER23> Seems to be like the best way to mitigate this would be to write a rust interpreter in assembly and use that to compile the compiler.

<comment><USER24> One of the interesting points raised in the original Trusting Trust paper was exactly this - that next level of trust can again be subverted via microcode modification, and so on and so forth. I really don't view Trusting Trust (in the original paper) as an _attack_ so much as a philosophical question being asked about trust in general and the way it propagates through supply chains. It's almost a paper more on _economics_ than anything else..

<comment><USER25> Once intelligence agencies start backdooring microcode (especially in a way that chip manufacturers can't detect), I'm throwing out my computer and living in the woods.

<comment><USER26> If you're in a situation where it matters, the safe assumption would be Intel chips have been backdoored a while, and others likely are too.

<comment><USER27> Agreed. If it matters this much to you, better move now.

I'm not even sure that the open source RISC-V initiative might prevent this, as theoretically the NSA could gain access to the manufacturing plant and insert their own core.

The only way to catch that at that point would be to X-ray the chip and look for their mod, or something. Anyway, assume the NSA has access to your shit, focus on preventing the random from grabbing your bank account access and stealing your money.</comment></comment></comment></comment></comment>


5 days of insanity in a social media startup - grey-area http://failstart.tumblr.com/post/32951762935/the-beginning

<comment><AUTHOR> Great article, though it was quite painful to read. I'm glad going in I knew she only stayed 5 days.

I'm confused why people would take an unpaid, bring-your-own-computer internship as opposed to building something themselves. Especially if you've got some experience. If you can afford to not get paid for a while, you might aswell have the pleasure of working on your own idea.

Even with zero coding skills you can put something decent together in 2 months - that's at least portfolio worthy. You even save on Subway fare!

I guess it's meant to be about working in a well managed team and learning from experienced people & maybe hopping onboard to something big. All things that this startup was lacking in.

As a collective, those interns could work together and launch something better, faster than 'Bob' will.

What's he chasing more investment for anyway? If he can't get something together on $500k (beyond social media fluff) then what's it going to take? It's the opposite of lean. The full-fat wasteful startup.

</comment><comment><USER2> If you're considering skipping this because of its length, I would reconsider. It's entertaining in a unique way and well written as well. The only downside is that there's no way to identify the company (or the author) and now I really want to know.

</comment><comment><USER3> "I've worked in the internet industry for almost 10 years... After almost 6 months of startup job fairs, Silicon Alley newsletters, digital DUMBO drinks and 2-3 applications per week I had yet to receive a single invitation to an interview."

Can any NYC tech people comment on why that might be the case? She mentions something vague about her experience being UX and it sounds like she doesn't design or do programming. Is her skill set too nebulous to get her an interview?

<comment><USER4> Considering that she didn't get a single interview, maybe the tech job scene in NYC is really just that moribund. I mean, it must be pretty bad for her to be willing to take an unpaid internship in the first place.

It sounds like her fellow interns didn't have hard skills either. They'd probably do better teaching themselves web skills or undergoing a Dev Bootcamp-like program and then applying to SV.

</comment></comment><comment><USER5> Was a fun read. Especially since I've experienced every aspect of this story (but never in one place!)

I'd kill to know the true name of the company... must see how they are going to murder Facebook, or at least get a peek at this infamous "Bob Dylan tweet"

</comment><comment><USER6> I've yet to read the whole story but I see how entertaining the narration is. If you compiled several such stories into a book…

</comment><comment><USER7> Here's their website: <http://www.doyouremember.com/>

<comment><USER8> <https://angel.co/do-you-remember-1>

</comment></comment><comment><USER9> Very funny article. I've met some clueless "entrepreneurs" during the years but Bob really tops them all.

</comment><comment><USER10> Unbelievable. Unnnnbelievable.

</comment><comment><USER11> Shame on the author for not saying something to the younger workers. Yes, it is exploitation. How could it not be?</comment>


Show HN: Minibatch – Python stream processing - <AUTHOR> https://github.com/omegaml/minibatch <comment><AUTHOR> Scenario: you really have a streaming use case, but you don't want to deal with the complexity and overhead of some of the other streaming frameworks like Apache Spark or Flink.

If so minibatch is for you

<comment><USER2> do you have a list of features? For example, implemented windowing type? Triggering?

<comment><AUTHOR> good feedback, updated the README

</comment></comment></comment><comment><USER3> Interesting I've started a project with a friend to build a simple toolkit for stream processing [https://github.com/python- streaming/dam](https://github.com/python-streaming/dam)

I'm happy to see the streaming ecosystem is getting bigger in python, Java has a lot of market share

</comment><comment><USER4> Kafka-python does python native streaming already. Why would I use this instead?

</comment><comment><USER5> Why not Apache Beam? It doesn't require Spark or Flink

<comment><AUTHOR> Thanks for the question. Beam has a more complex execution model and AFAIK also needs some executor environment like Spark to really parallelize workloads. Given a mongodb that all producers and consumers can attach to, minibatch runs anywhere.

</comment></comment><comment><USER6> Do you have any scale or performance metrics?

<comment><AUTHOR> no benchmarks yet unfortunately. While it should scale O(n) in the number of streams, there will be limitations to scale a single stream because the stream processing functions by default are executed synchronously (pending enhancement).

</comment></comment><comment><USER7> It lost me at "for humans". I'm not even kidding: it's trite, demeaning to every similar project (with the implication that everything else is obviously for weirdos, not like you and me, amirite?), and shows a kind of naivete (everything else is overly complicated, lol, and I have no idea why that would be!).

It was momentarily cute the first time I saw it but that faded quickly. By the 100th "for humans" project, it had become a distinct code smell.

<comment><USER8> I disagree. To me this term is a meaningful way to express the values of a project. It means that the abstractions will be at the highest level possible to provide the result. Whenever the library can make a decision for you, it will attempt to do so. It is like you are dealing with a human intelligence that is always guessing what you want and trying to give it to you. When I see "for humans", I expect that the api will behave like a human. This is not always desirable. Sometimes the highest level of abstraction is the wrong level of abstraction. Sometimes you need to be making all those decisions yourself, and you don't want the library to ever guess what your intention is. The human-like apis tend to work wonderfully until you need to optimize, have security concerns, or figure out you're actually doing something novel. Then you jump down a layer of abstraction and everything fits wonderfully again. Sometimes you really are just dealing with a machine and telling the machine what to do and whatever humanity is brought to the task is simply a distraction.

<comment><USER7> You say you disagree, but then go on to spell out my position quite nicely. "For humans" implies a certain level of abstraction that quite often tends to be _too_ abstract in exactly the way you describe. "We don't bother you with all the little details that the others make you handle!" frequently ignores the fact that those others make you specify all that stuff for a reason.

For example: "Do you want this database to be AP or CP?" "Don't pester me with the nitty gritty! I just want to store data." A "for humans" database that quietly made the choice for you would be very bad news if it later turns out to have chosen poorly for your own workload.

The first "for humans" thing I saw was Python's Requests library, and I think it earned the title. Having just built a web scraper on top of raw httplib a year earlier, I would have killed to have had Requests available. It's a great example of a project with a decent track record of mostly setting good defaults and letting devs concentrate on their parts of their projects. Since then, I have seen very few "for humans" projects that weren't so abstract as to become almost unusable. I mean, you could call MS Paint "Photoshop for humans", but that doesn't make it so.

<comment><USER8> Oh ok I thought you were making the point that "for humans" is a sort of meaningless marketing term, but I see you understand the nuances of this. Sometimes it is good to be "for humans" but you are saying most people in your experience who make the attempt fail.

The classic example I think is Microsoft Access (databases for humans) which is great until it can't do the one thing you need and then it doesn't work anymore. And everyone needs a different one thing.

<comment><USER7> Ah, got it! I think that's a great example.</comment></comment></comment></comment></comment>


Understanding quaternions and the Dirac belt trick (2010) - <AUTHOR> https://arxiv.org/abs/1001.1778 <comment><USER2> The best demo I ever used to understand quaternions was this editable explorable demo.

[https://eater.net/quaternions/video/intro](https://eater.net/quaternions/video/intro)

<comment><USER3> I think the best way to understand quaternions is to spend about a month curled up with a good book or two on Grasmannian/Clifford algebras.

<comment><USER4> This post is a bit highfalutin, but it has a good point. You understand quaternions by _doing math_ with them (the same way you understand complex numbers, really). There's really nothing magical about them, and I'd really push back against the idea that a 3b1b video really made you "understand" them -- other than on a very cursory and shallow semi-intuitive basis.

<comment><USER5> A cursory understanding is a good starting point, even if it's not 100% technically correct. This is especially true for people who don't consider themselves mathematicians but still have to deal with quaternions or similar entities. The biggest stumbling block to understanding math (for many people) is a lack of confidence combined with feelings of frustration. If a simple video can get you over that first step, you are on a good path to developing a deeper understanding.

</comment></comment></comment></comment><comment><USER6> Here's a GIF of the belt trick they're talking about in the paper: [https://www.gregegan.net/images/DiracAnimation.gif](https://www.gregegan.net/images/DiracAnimation.gif)

</comment><comment><USER7> I am pretty sure I have studied every interpretation and explanation of spinors and the non-simply-connectedness of SO(3) rotations, and I eventually finally understood it -- but, by ignoring explanations like the 'belt trick', rather than embracing them. I don't think this article makes it any better. As long as you're stuck on quaternions you're not going to be able to see what's going on, and the belt metaphor just adds complexity as well.

The version that currently makes the most sense to me is this:

* Quaternions are a complete distraction and should be ignored. i, j, and k are (xy), (yz), (zx) bivector rotation operators (up to a factor of -i or something like that). Pauli matrices are the same and should also be ignored.

* The factors of "theta/2" in the exponents that are used in representations of rotations using quaternions (rotating vectors with e^(R θ/2) v e^(-R θ/2)) are distracting and should be ignored.

* The best way to see what is meant by "the space of rotations in SO(3) is not simply connected", you need to think about paths in _rotation_ space carefully. More carefully than I did as an undergrad! (Although I'm sure this is obvious to people who have studied the approach math in a course?)

The wrong approach -- which I was stuck on for years -- is to think about a point on a sphere in R^3 moving around. A vector that starts at, say, +z in R^3 and is rotated by 2pi in the xz plane ends up where it started exactly.

The key insight is that 'non-simply-connectedness' refers to _paths of rotations_, rather than paths of what the rotations act on. So imagine gradually rotating that vector +z in the (xz) plane. If you go around by 2pi, you've made a path that can be modeled as an exponential operation: e^(2pi (z^x)).

The question is: can this path be deformed to the identity path? It seems like it can -- you just change from rotating +z all the way around a great circle, to a smaller and smaller circular path until it is just rotating in place (and xy rotation). But somehow when you collapse it, you still have a 2pi rotation! It's just that now it's a 2pi rotation in xy rather than in zx. No matter what you do, if you collapse the rotation path to be the identity on the +z vector, the resulting path rotates _some_ vector by 2pi, instead of keeping it at the identity.

So in physics, it's not that there is a negative phase factor _per se_ that matters for physics. It's that there are two physically distinguishable states (identity rotations and anti-identity rotations) -- so two different electron wave functions can't be identified as the same electron, because they are a 2pi rotation apart just due to how they got there. And the fact that we _model_ this is as a negative sign is entirely an artifact of our obfuscating choices of mathematics for the situation.

<comment><USER8> > _i, j, and k are ... bivector rotation operators_

Well, that's like calling the imaginary unit "a rotation operator." (I mean, sure, you can do things like that with abstract algebraic constructs, marvel for a few moments, but then you move on, searching for the _true_ meaning - which never happens to lie with any particular representation or an application.)

<comment><USER9> > you move on, searching for the true meaning

Which turns out to show up when you go beyond three dimensions. In two and three dimensions, numerical coincidence let you identify different grades of operation. In 3D space, i, j, and k are unit vectors...and unit bivectors. As soon as you hit 4D you have to separate that out, and things get a lot clearer. This is why people keep harping about geometric algebra.

</comment></comment></comment><comment><USER10> The argument against (in 3d graphics/games): "Let's remove Quaternions from every 3D Engine" by Marc ten Bosch, [https://marctenbosch.com/quaternions/](https://marctenbosch.com/quaternions/)

(And its HN threads [https://news.ycombinator.com/item?id=22200260](https://news.ycombinator.com/item?id=22200260) & [https://news.ycombinator.com/item?id=18365433](https://news.ycombinator.com/item?id=18365433))</comment>


Ask HN: What's your opinion on Shibboleth? - <AUTHOR>

My university's IT department is currently working on deploying Shibboleth [1] on campus, to replace the old mix of LDAP, Kerberos, and a homebrew solution called WRAP, at least for Web applications. I have been doing a lot of research on Shibboleth, so I was wondering: What are your opinions on Shibboleth?<p>[1]: http://shibboleth.internet2.edu/ <comment><USER2> 2nd hand opinion: ex-day job investigated using it for our universities. Result of investigation was a resounding "inappropriate for our needs." They cited a few reasons. One of them was "insufficient documentation in Japanese", which is probably not an issue for you. Others were "poor UX" and "high anticipated integration costs."

We ended up picking OpenID instead. If you've heard me talk about OpenID before, "Shib: not quite as good as OpenID" is all you need to hear.

</comment><comment><USER3> I built a system around Shibboleth at a University several years ago. We did some extra work to improve the UX. I'm not sure how installing Shibboleth itself went, but from an API use perspective I can't complain.

OpenID might be a better choice these days. It was more dream than reality when we picked Shib. If OpenID isn't an option...I'd vote for Shib over cobbling something together yourself from AD.

</comment><comment><USER4> We implemented Shibboleth at Cisco after reviwing CAS and other products, remember it lacks Single Sign Out so you need to build this thing your self. You may also want to checkout OpenSSO which is open source and free folked from Oracle (Sun) Identify Manager

<http://java.net/projects/opensso/></comment>


Securing Your Site Like It's 1999 - <AUTHOR> https://24ways.org/2018/securing-your-site-like-its-1999/ <comment><USER2> When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?"

Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know.

And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.

<comment><USER3> I've been developing web apps since .NET 3, and the only thing I understand (and can claim to guard against [1]) in the OWASP top 10 is SQL injection. I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... which, given that Google itself seems to have problems with it, is quite difficult.

[1] - claim, because you never know when someone happily calls exec_sql with a string from a stored procedure (had it happen at two different companies).

<comment><USER4> > I always try to explain to my clients that web security is a complex field > and they should hire a pro for that area...

No. Just no.

Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in.

Sell yourself as a software engineer who knows security, and watch the money rain as literally everyone tries to hire you.

<comment><USER5> No they don't. Engineers building bridges don't sit around choosing what kind of fences or security cameras the construction site needs.

<comment><USER6> The abstraction doesn't fit. Where the civil engineers would be expected to build a bridge that doesn't collapse when the wind is Just Right (key word: Tacoma Narrows Bridge), software makers are expected to build a lock that doesn't open when someone whistles Just Right (key word: SQL injection).

<comment><USER7> Bridge builders are not expected to make the bridge itself defend against saboteurs, unlike software. To painfully extend the scenario: the wind is relatively well understood and once you've learned a lesson and guarded against it as a bridge builder, a given bridge can be considered stable.

Not so with software. One vuln fix, 5 more show up to take its place over time.

Malicious actors & botnets = the wind now (bear with me please). Once the bridge no longer collapsed via a certain Just Right tune, the wind would stop blowing the old Just Right way and instead try finding a new Just Right way, like whirling in a tight circular motion in just the right spot to see if it can unscrew bolts, or attempt -ddos- to tornado itself into a waterspout to try to collapose the bridge.

Security is not a one and done operation.

<comment><USER6> Yeah, that makes sense. In other words, software is far easier to _build_ , but requires much more effort to _maintain_ \- in which security is prominent.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The article mentions creating a clear access control policy. I haven't worked on access control at all, but I've witnessed colleagues at multiple companies implementing it, something which I've only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn't already software built solely or partly for the purpose of access control.

I've recently been reading about LDAP. While I don't have any experience using it, I wondered whether you could simply use LDAP to implement your access control. Someone on Stack Overflow asked the same question: [https://stackoverflow.com/questions/3363267/ldap-for- applica...](https://stackoverflow.com/questions/3363267/ldap-for-application- access-control-how-much-should-it-control). The accepted answer mentions that LDAP can be used for high-level access information, but that the lower level should be handled by the application, as the LDAP scheme would otherwise become complicated. Fair enough.

My question is: What experience do others here have with implementing access control? Have you used LDAP? Is there another general tool built for this purpose which saves us the trouble of building our own system? Surely someone like IBM and Microsoft have built something for this. Are there any open source alternatives?

<comment><USER9> There's Shibbeloth: [https://www.shibboleth.net/](https://www.shibboleth.net/)

Not as easy as LDAP, it's designed for bigger places, like Universities

<comment><USER10> And there's Shibboleet too.

[https://www.xkcd.com/806/](https://www.xkcd.com/806/)

</comment></comment></comment><comment><USER11> It's worth mentioning that in 1999 there were already tools that helped. Perl's Taint Mode was one of them. In a nutshell, any variables containing user input could not be used for stuff involving OS paths, system calls or databases. The only way to use such input would be to "launder" the data, usually by using regular expressions to pull out the pieces that actually look plausible.

As a side-effect, this introduced some great usability conveniences, such as numerical fields (think credit cards, age, dates…) in which the user could type all sorts of junk or poor formatting, and yet get some sane validation.

Nearly 20 years later, we're still a step backwards in having what I call "Forgiving UX", and have things like rigid drop-downs to select month/year of expiration on a credit card, instead of just lifting the first 4 digits—regardless of how the user typed them—and calling it a day.

[https://perldoc.perl.org/perlsec.html#Taint- mode](https://perldoc.perl.org/perlsec.html#Taint-mode)

<comment><USER12> The thing that drives me crazy is when you have a form that tells you to enter the date, so you go MM/DD/YYYY and when you hit submit it comes back and tells you that it wants MM-DD-YYYY.

That's something the parser could just as easily do itself and avoid making more work for the user. Ideally you would use a parser that's smart enough to figure out 95% of the cases and do the right thing and only return errors if it's completely unparseable or ambiguous.

A date field should be able to accept all values like:

      2018-12-13

      12/13/2018

      Dec 13 18

      December 13, 2018

      12-13-平成三十年

      188.8.131.52.3

      1544677200

In cases where the input is ambiguous the parser can make its best guess and toss a warning. Preferably allowing the user to inspect its guess to see if is right.

<comment><USER13> Agree, it seems this is one area that inventing your own solution is tempting, yet people fail to realize the variety of cases that need to be supported and welded together. Same thing goes for IPs etc

</comment></comment></comment><comment><USER14> > _The first check you can make is to verify that a request's origin and > referer headers match the location of the website. These headers can't be > programmatically set_

Can I stop reading right here? The referer header is presumably the oftenest spoofed header on the planet.

<comment><USER15> This isn't to defend against a malicious user crafting requests, it's to defend against a malicious site tricking the user's browser into making an authenticated request. Said malicious site can't set those headers.

 _Edit:_ I think I misread your comment and you're not arguing that checking origin/referrer isn't enough for security, but rather that it will block legitimate, privacy-conscious users.

Using a CSRF token is a valid alternative, and it's mentioned just below in the article.

</comment></comment><comment><USER16> In a world of machine learning and massive breaches, "security by obscurity" is ever further from appropriate in any case at all.</comment>


Don't Blame Malaysia Airlines - <AUTHOR> http://www.nytimes.com/2014/07/19/opinion/malaysia-airlines-flight-17-the-ukraine-wars-victim.html

<comment><USER2> A rebuttal to this argument is found on the last paragraph of this [1] article:

"Malaysian officials said an airline could not be expected to have the intelligence information and other resources to make independent determinations to avoid an area where air traffic controllers were still sending planes. But some carriers had already done just that. China Airlines, the flagship carrier of Taiwan, said that it had avoided flying over all of Ukraine since April 4. Korean Airlines and Asiana Airlines also confirmed that they had not flown planes through Ukrainian airspace since March 3."

It also looks like Air France and British Airways avoided Ukraine entirely [2]

And even if all airlines had made the mistake of flying over Ukraine, it is absurd to suggest that an airline might not have the "intelligence information and other resources" to make an independent judgement about safety. A single person spending half an hour on the internet would determine that (a) the rebels were shooting down planes using surface-to-air missiles; and (b) there are some surface-to-air missiles that can reach an altitude of 40,000 feet. That is all the information you need to conclude that the area isn't safe for commercial airplanes.

[1] [http://www.nytimes.com/2014/07/19/world/europe/downing-of- pl...](http://www.nytimes.com/2014/07/19/world/europe/downing-of-plane- exposes-defects-of-flight-precautions-over-ukraine.html)

[2] [http://www.nytimes.com/interactive/2014/07/17/world/europe/m...](http://www.nytimes.com/interactive/2014/07/17/world/europe/maps- of-the-crash-of-malaysian-airlines-flight-mh17.html?_r=0)

<comment><USER3> Many other airlines continued to fly over the Ukraine, even most respected airlines like Lufthansa and Singapore Airlines:

[http://www.spiegel.de/panorama/bild-981813-726883.html](http://www.spiegel.de/panorama/bild-981813-726883.html)

</comment></comment><comment><USER4> As a Russian, I'd like to say I'm deeply sorry for the losses of passengers' families. Whoever did this is a complete monster. Many russians do not support any war or aggression against Ukraine and many are convinced, that Russian government is in some way responsible for this tragedy.

I personally believe we, as people, will never know the truth as to who did it - was it Ukrainians or the rebels or the Russians. However, this is the direct result of the existence of states and governments. We are taxed to build weapons and go to war for some private and corporate interests we have nothing in common with. Those weapons were built for our money. If each and every person was asked separately "would you like to give us 10% of your income to build these deadly weapons and support the rebels in Ukraine or would you like to keep this money for your family" nobody would give it away voluntarily. Taxation and states are at the root of this evil and it is at moments like these that I can see it as clear as ever.

<comment><USER5> I'm going to take issue with that taxation and states being the root of evil. They are an inevitable result of the way that we humans are. If anything is evil, it's human nature itself.

There are always going to be people who want to form organizations, leadership cabals, and have control over things. Even areas already under the control of a strong Government still have corporations, criminal gangs, and various types of civil organizations, all vying for a little bit of that control pie.

Essentially, there will always be some sort of government. It can be a single one that's powerful enough to be unquestionably dominant over anything it chooses to touch, or it can be dozens of little ones, all vying for control over various things in various places. That essentially looks like Somalia or Syria or Libya - total chaos, with constant risk of offending one warlord or another or some gang of bandits, and none of them will make the slightest pretense of listening to you. Avoiding that requires having one government with enough power to squash anybody like that. The best we can get is to have one dominant government, set up in such a way that it has some degree of obligation to listen to the population.

<comment><USER6> > The best we can get is to have one dominant government

You think that would resolve everything hey ? Don't you think one dominant government would actually have no incentive to listen to the population and could impose its right by might alone ?

<comment><USER7> Not really. Look at China, they have a hugely powerful government, yet even they find it easier to engage in popularism than domination. It's much easier to govern a country which supports you: logically any sustainable government should be interested in maintaining enough popularity that their position will not be undermined: but no more than that.

European history is an excellent case study in the fall of dominant rulers who failed to satisfy their subjects.

<comment><USER8> Wow, if you're looking at the Chinese government as a model for governance...

Uniting all world governments into a single state scares the hell out of me, and I think it could very well be the worst idea, but suggesting China as a pattern is the icing on the cake, quite frankly.

</comment></comment></comment></comment></comment><comment><USER5> Personally, I don't see any reason to blame them for either crash. As far as I can tell, pretty much every airline in the world thought that the corridor they were flying over eastern Ukraine was perfectly safe. That flight just had the bad luck to be there at the time some marginally-competent Ukrainian rebel in charge of a high-end anti-aircraft missile system got a little enthusiastic. Could have been any other flight just as easily.

We still don't have any idea what happened to that flight 370, either.

I don't think this will help them, though. I sure wouldn't buy any stock in anything connected to them. Even if nothing about either crash was their fault in any reasonable way, people remember stuff like that.

<comment><USER9> Most airlines were avoiding the eastern Ukraine corridor...

<comment><USER10> Many did cross - even Lufthansa and Singapore Airlines. Spiegel gathered some flight data from flight radar.com. The article is in German but you can scroll to the bottom to see the list: [http://www.spiegel.de/politik/ausland/malaysia-airlines- mh17...](http://www.spiegel.de/politik/ausland/malaysia-airlines-mh17-karte- grafiken-route-flugroute-a-981784.html)

<comment><USER11> One should note that though Air France from from Paris to Bangkok used to take the route south from the Ukraine, the KLM from AMS to Kuala Lumpur was going through the country, both later merging to the same route over Turkmenistan.

Given that Air France-KLM is a one corporation since 2004, it's pretty surprising. Paris is a bit more south than Amsterdam, but not that much.

[1] [http://cdn1.spiegel.de/images/image-726710-galleryV9-ocpi.jp...](http://cdn1.spiegel.de/images/image-726710-galleryV9-ocpi.jpg)

</comment></comment></comment></comment><comment><USER12> While it's nice to think that airlines can just rely on regulators to tell them which flight paths might be unsafe, the reality is that there's no international regulatory agency governing acceptable flight paths. There's a regulatory agency for every country and while one country might have stringent safety measures, another might not.

In such an environment it seems naive for an airlines to not include the safety of the flight path in their calculations. If all civilian flights below 32K feet are forbidden by the Ukrainian authorities, that doesn't automatically mean that flying just 1000 feet above would be safe. Also while other airlines are guilty of flying over war zones too, that doesn't mean Malaysian airlines is not.

<comment><USER13> > there's no international regulatory agency governing acceptable flight paths

I believe the ICAO is this regulatory agency.

<comment><USER12> But with no legal power of enforcement I'm guessing? I mean an airlines can always choose to follow the directives of agencies from other countries that have more stringent standards.

I guess what I'm trying to get at is that there should be definitely increased public pressure on airlines to include flight safety in their calculations. Or atleast not fly over active war zones..

<comment><USER13> The threat model was such that they thought the missiles in that region couldn't hit targets above 32,000 ft. MH17 was flying at 33,000 ft.

All rules bodies can do is make rules based on the best available information. Their information was wrong, but it's not like they didn't try.

</comment></comment></comment></comment><comment><USER14> Interesting report on the flight path on BBC news yesterday - they showed that most European airlines flew directly over Ukraine ... British Airways however, have been skirting the country entirely, either going North or South depending on available corridors.

That could just be the usual British "better safe than sorry" mentality, but I suspect they were perhaps given intelligence that suggested unstable rebels had access to SAMs.

<comment><USER15> If a British service has had intelligence on that, they have failed to protect 9 of their compatriots by just sharing it with BA.

<comment><USER16> Considering the story (true or not) about Coventry not being warned about the German bombers coming for it isn't exactly treated as one of national shame, it isn't quite clear that losing 9 citizens is a big deal to them under these circumstances.

</comment></comment></comment><comment><USER3> Interesting titbit:

One of the videos that is supposed to prove that the airliner was shot down by pro Russian rebels is one day older than the incident according to the meta data:

[https://twitter.com/ofehr_en/status/490039740595707904/photo...](https://twitter.com/ofehr_en/status/490039740595707904/photo/1)

The truth probably is that a major propaganda war is under way and we simply do not know (maybe never will know) who is directly to blame for the incident.

<comment><USER16> Let's nip this in the bud. That's a Youtube bug [1]. The reddit story [2] has some nice comments.

1: [https://gist.github.com/klaufir/d1e694c064322a7fbc15](https://gist.github.com/klaufir/d1e694c064322a7fbc15)

2: [http://www.reddit.com/r/programming/comments/2b4kpg/conspira...](http://www.reddit.com/r/programming/comments/2b4kpg/conspiracy_and_an_offbyone_error/)

<comment><USER3> Thanks, good to know! :)

</comment></comment></comment><comment><USER17> The Guardian has a data blog of the airliners flying over the region. Top 5 fliers were Aeroflot (86), Singapore (75), Ukraine (62), Lufthansa (56), Malaysia (48). Really could have been anyone. [http://www.theguardian.com/news/datablog/2014/jul/18/mh17-he...](http://www.theguardian.com/news/datablog/2014/jul/18/mh17-heathrow- top-departure-point-planes-near-east-ukraine)

</comment><comment><AUTHOR> FWIW, the NYT's news section has a more detailed examination of the politics and technicalities here...and the OP (who is writing in the opinion section)...seems kind of weak:

[http://www.nytimes.com/2014/07/19/world/europe/downing-of- pl...](http://www.nytimes.com/2014/07/19/world/europe/downing-of-plane- exposes-defects-of-flight-precautions-over-ukraine.html)

I would've posted this link had I seen it earlier...but it is interesting to see how the OP, a pilot himself, thinks MH17 didn't have much cause to change its route. I mean, the OP even acknowledges that the Malaysian Air pilots would've known about the Ukranian cargo plane that was shot down earlier that day...in the NYT news report linked above, the 32,000-ft-restricted altitude left planes exposed to rockets that could strike at twice that height.

<comment><USER18> Thanks, this article answers some of the questions that were left in my mind from the op-ed, which I was surprised it hadn't discussed. After reading the op-ed, it was unclear to me if _lots_ of airlines were flying through this space, or if Malaysia Airlines was unique in doing so. The way it was written almost made me suspect he was defending Malaysia Airlines for having made an unusual decision to fly through space that other airlines were more prudently avoiding. But the article you link here mentions that flight traffic above 32,000 feet was not much down from pre-restriction levels, so Malaysia Airlines seems to have been doing what was the norm.

</comment></comment><comment><USER19> My favorite part, right at the end:

> After each crash, disaster or terrorist episode, it is natural to point > fingers and say, Why didn't we foresee that specific threat? Thus one > attempted shoe bombing leads to a decade of shoes-off orders in security > lines. The truth is that air transportation, like most other modern systems, > could not operate if it fortified itself against every conceivable peril.

Many people like to use phrases like "one $INCIDENT is one too many". In reality, all of life is about balancing and mitigating risks. Just because a single failure happened in one case doesn't mean the entire system is faulty; given enough time, any system that is not 100% foolproof (that is, all of them) is going to have a failure. The question is whether it is actually feasible and/or reasonable to prevent those.

<comment><USER20> Not even one incident. Hence, still having to get rid of water bottles, etc.

<comment><USER21> Only to be repurchased 10ft later for an exorbitant price, because the contents of those bottles went through the most thorough examinations possible and are perfectly safe.

</comment></comment></comment><comment><USER22> Unless the plane crash was due to a software bug, this story, however important it is, has no place here. I appreciate your interest and concern but this isn't the right forum.

<comment><USER22> The point is this has nothing to do with software or anything of interest to Hacker news. Why bother reading HN if it's going to be cluttered with posts and comments that clearly belong elsewhere (Huffingtonpost.com, Disqus, Twitter whatever...) then some sour grapes crybaby who seeks attention voted down your Karma to prove a point. I'll still read HN but some participants are just trollish. I'll never hire or work with anyone with the usernames above because in my world civility and good behavior counts, even with the "little things" like respecting HN guidelines (see below) but it's your life and do what you want with it. Sooner or later you'll put your foot in your mouth in the very worst way and panic all day over your mistake.

Hacker News Guidelines [https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

What to Submit

On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.

Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off- topic.</comment></comment>


"Discuss latest changes to master before releasing" - <AUTHOR> https://github.com/jashkenas/underscore/issues/2061 <comment><USER2> If you find yourself annoyed by some aspects of Underscore, you might want to check out Lodash[1]. Lodash's API is a superset of Underscore, though you can create custom builds with only the parts you need. In general, Lodash performs better and has fewer bugs than Underscore. Unlike Underscore, Lodash has 100% test coverage. Also, Lodash has some handy things like _.cloneDeep(), and semantic versioning. That means your package.json can have "lodash": "3.x" in its dependencies without worrying about breakage.

For a more in-depth discussion of the differences between Lodash and Underscore, I recommend Ben McCormick's _Underscore vs Lo-Dash_ [2].

1\. [https://lodash.com/](https://lodash.com/)

2\. [http://benmccormick.org/2014/11/12/underscore-vs- lodash/](http://benmccormick.org/2014/11/12/underscore-vs-lodash/)

<comment><USER3> Lodash is also several times larger than Underscore. The point of Underscore is to keep it light.

And yes, you can pick and choose what modules you want. But you could do that with Mootools and it was released a decade ago. If you want a heavy framework with lots of modules, there are plenty to choose from.

Maybe if it offered a light version on the front page? The file linked from the front page is 372KB. By comparison, the file linked from Underscore's front page is 51KB.

<comment><USER4> If you're using CommonJS you can do require('lodash/category/method'), and when it gets built on the frontend it'll only include the method and its dependencies. So if you're using only 5% of lodash, you'll only get that 5%.

<comment><USER3> Right. If on node, you can also use modules via NPM ( [https://www.npmjs.com/browse/keyword/lodash- modularized](https://www.npmjs.com/browse/keyword/lodash-modularized) ).

But as I said, this is common in many frameworks. Hell, you can even do with JQuery ( [http://projects.jga.me/jquery- builder/](http://projects.jga.me/jquery-builder/) ). So having this ability doesn't make Lodash special.

This is not presented as the preferred method to use the framework on the project page either. You just get a link on the front page to the whole shebang. Probably because most developers just download the whole thing and stick it in.

What I was really hinting at was code complexity. Sometimes having something light and small that you can stick in there without worrying about anything is useful. Lodash can address that by having a light version linked off their front page, but they haven't done that.

On top of everything, Underscore is ribbing them on this very point. See [http://underscorejs.org/](http://underscorejs.org/) and bit down "(3x smaller than Lodash ;)" in bold. Seems like a really easy point to address.

<comment><USER5> If you care about filesize, you'll probably optimize as much as possible. You can do this with Lodash using modular imports.

There's little upside in hosting a light version, and fragmenting the docs. Min/max'ing on filesize lets you save 15 kB, or 0 kB. Creating a light build that saves 5 kB is a maintenance cost with a poor ratio relative to reward.

<comment><USER3> > If you care about filesize

I don't care about filesize. I care about code complexity. The more crap you add to a page, the slower it will run. You also get a higher probability of conflicts and problems in the long run.

If you need something, you need something. But if you don't and you just throw it in there, you're asking for problems down the road.

<comment><USER6> For an example of cherry-picking lodash modules see

[https://github.com/postaljs/postal.js/issues/91#issuecomment...](https://github.com/postaljs/postal.js/issues/91#issuecomment-73159144).

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I like Ramda[1] better than both underscore or lodash because of it's argument ordering (function first) and auto-currying[2]. It's 7kb minified and gzipped.

[1] [http://ramdajs.com/](http://ramdajs.com/)

[2] [https://buzzdecafe.github.io/code/2014/05/16/introducing- ram...](https://buzzdecafe.github.io/code/2014/05/16/introducing-ramda/)

<comment><USER8> [https://www.npmjs.com/package/lodash- fp](https://www.npmjs.com/package/lodash-fp)

Don't know how they compare though.

<comment><USER6> Yap, lodash v3 ([https://github.com/lodash/lodash/releases/tag/3.0.0](https://github.com/lodash/lodash/releases/tag/3.0.0)) introduced lodash-fp for auto-curried iteratee-first lodash methods.

</comment></comment></comment><comment><USER9> To be fair: Underscore doesn't follow semver, so breaking changes between versions should be expected. This thread just seems like an excuse to pile on jashkenas and promote lodash.

<comment><USER10> It is released and consumed via 2 package managers that _mandate_ the use of semver.

</comment></comment><comment><USER11> Via the Lodash CLI you can "lodash underscore". This results in 6.7kb gzipped. In my experience, jdalton is a very solid coder and the lodash package is excellently maintained.

</comment><comment><USER12> I don't follow Underscore but whoever wrote this title (currently "Underscore 1.8 makes last minute breaking changes to master without discussion") must really have an axe to grind, and it seems inappropriate for HN. Doesn't really set the tone for any constructive discussion.

<comment><USER13> Yeah, and linking to a PR risks a bunch of parties w/o a real stake in the project piling on and shitting up the PR. Really poor form, OP.

<comment><USER14> _shitting up the PR_

Good people of HN, this phrase deserves your upvotes.

</comment></comment></comment><comment><USER15> what idiot is using Underscore at this point?

</comment><comment><USER16> Welcome to JavaScript.</comment>


Learning Erlang as an Experienced Developer - <AUTHOR> https://jonalmeida.com/posts/2018/05/01/erlang/ <comment><USER2>
      Sadly, I have even less to say about OTP given my limited knowledge of it. I would really like to have another course that would focus more on it.

As an experienced programmer learning about the Erlang and Elixir ecosystem, I found Elixir in Action ([https://www.manning.com/books/elixir-in- action](https://www.manning.com/books/elixir-in-action)) an excellent next step after working through the Elixir guides and writing some small applications. The examples are written in Elixir rather than Erlang, but really it is about how to structure OTP applications.

<comment><USER3> Excellent recommendation. For the people who are considering getting this book, I would like to point out that a 2nd edition of the book is also available in the Manning Early Access Program (MEAP) [1]. OTP-wise things haven't really changed much, but the new edition addresses changes in the Elixir language over the past few years.

[1] [https://www.manning.com/books/elixir-in-action-second- editio...](https://www.manning.com/books/elixir-in-action-second-edition)

</comment></comment><comment><USER4> I've had about the same experience getting started with Erlang. It was mostly using recursive, immutable state and the functional style that was hard to get my head wrapped around.

Pattern matching was somewhat hard but you can of course program by not using them, then during code reviews, you start getting advice like "split into a separate function clause". So bit by bit I started to get patter of using patterns and guards.

A thing that helped there was watching Garrett Smith's "Beautiful Erlang" video:

[https://www.youtube.com/watch?v=IdJwECjylB4](https://www.youtube.com/watch?v=IdJwECjylB4)

On concurrency I had already did enough programming with threads before that and didn't have much difficulty understanding processes, pids and messages. Well except for being happy to get isolated heaps, smaller size threads (a few KBs) and supervision trees.

<comment><USER5> It's funny how people understand different things in different ways. For me, 00 style programming was what I could never get my head fully around. Erlang immediately made sense to me. It's my favorite language and I wish I could use it more on the job.</comment></comment>


Is there a proper etiquette for quitting your job? - <AUTHOR> I regularly see posts on HN about quitting one's job to follow dreams, join a startup, or otherwise advance one's career.  I was recently on the other end of this thread, so to speak.  An excellent young software developer that had worked in my lab for 4 years walked into my office and told me he was quitting to join a startup.  No prior warning, no explanations and just 2 weeks notice. While he did try to wrap things up in the 2 weeks, much was left uncompleted and no replacement was even planned for. When encouraging people to follow their dreams, shouldn't there be a concomitant reminder that employers deserve some consideration, too?  If you recently quit your job, how did you handle it? <comment><USER2> I've tried both ways. I tried to do the "nice sendoff" by giving a huge 2 month notice, and even trained my replacement, documented all my procedures etc. What did I get? It turned out apparently I hadn't been at the company long enough, so they revoked all the money the company had contributed to my 401K. On my last day, instead of having time at the end to go around and say goodbye to my coworkers, security shows up 2 hours early and I was escorted out of the building.

My next job I just quit without notice. The job had turned pretty sour, and I was on contract, the company had acted in some morally questionable ways, so when it was my turn to leave I didn't have too much hesitation about just up and quitting.

Now maybe I'm a little more disillusioned than most people, or maybe it's just the world we live in now -- reverse pay-it-forward.

<comment><AUTHOR> That sucks. Your disillusionment is understandable. I guess my viewpoint on this assumes the employer is honorable. Maybe too narrow an assumption in this market. But your comment shows you did take your employer's situation into consideration, which is what I'm hoping to find.

</comment></comment><comment><USER3> Professionalism is to be expected on both sides of the relationship. Two weeks notice is, in lieu of contract obligations, in most places in the U.S. not even required. It was, and I guess generally still is, considered a common courtesy.

The employer is responsible for structuring and documenting work in a fashion to control the risk of this situation. What if the employee were in a debilitating accident? Would you be complaining, in that case?

Employees see the way that employees, in general, are treated, these days. When an employer decides against an employee, they are as often as not "perp- walked" to the door. (I'm speaking of instances where no malfeasance has occurred or been alleged to have occurred.) Even if you strive to be a "good employer", you need to remain cognizant of the environment in which you exist. Employee loyalty is not rewarded the way it used to be (or at least, used to be shown -- true or not).

It was your responsibility to structure your environment to accommodate this eventuality. If a resource really is critical, write a contract with them that guarantees/incentivizes their sticking around and/or giving a longer notice of termination. If such a contract costs you more, well, that's the price of doing business.

("Time is money", and you've just asked for a greater commitment of another person's time. In a similar fashion, expect to pay more in return for an (effective) non-compete clause.)

<comment><AUTHOR> All good points. I fully agree that the employee is not responsible for ensuring that there is minimum disruption upon their departure, management is. But what I don't see is why there seems to be so much difficulty in expecting a departing employee to give more than a minimum notice. People jumping to startups (and that's what this post is about) are usually very bright and have valuable skill sets. They usually leave because they are undervalued/under- compensated or disinterested, not because of an emergency or duress. So what's wrong with giving some extra warning to help out? Isn't that part of an amicable termination? Two weeks is common, but to fill a skilled spot takes a lot longer than two weeks.

<comment><USER3> Again, look at the context.

Also, in addition to hard incentives, are you providing any soft ones? Literally saying, if you're bored or unhappy, we'd like to know. (And we're not looking to screw you over with the knowledge.)

Are you backing up such statements with actions that demonstrate your good will?

If you were taken by surprise, were you communicating effectively with this employee? ( A primary action that can demonstrate good will.)

Finally, what's the demographic in question? Young people, on average, "go off and do things". It's one reason some employers favor married, settled (even "boring") employees. They are more predictable.

(And these days, getting married and starting a family is less "the thing to do" than it used to be. It's still done, plenty, but it's not _the_ course of action that it used to be.)

If you wanted them to "do things" with you, it seems perhaps you should have been more pro-active in making that part of the assignment. Even then, there's no guarantee.

For many employees, disengagement begins long before they quit. If you want the relationship to be valued, your only course of action is to begin doing so from your end.

Too many self-interested employers (speaking generally, not necessarily of you) get their undies in a bunch when employees -- perhaps taking a cue from them -- start acting the same way.

To repeat my and others' question: What's in it for them?

<comment><AUTHOR> _To repeat my and others' question: What's in it for them?_

Nothing tangible. Just good will and (in some cases) a clear conscience.

I asked this question because I wanted to get a feel for whether my expectations were right or wrong. The clear answer from the community is that the etiquette for leaving is rather complicated and that two weeks is not unreasonable at all. I also accept that the failure to retain this gifted employee was my fault (that was not in question). So it was helpful to read the comments as it tells me I need to do a lot better the next time around. Thanks.

<comment><USER3> Understand, for my part, that I was the guy who would cut vacations short because a project was behind.

Perhaps counter-intuitively, over time this seemed to cause me trouble, perhaps in part because it did not "fit" the broader culture nor others' expectations. (People become "worried" when you do not do the expected, even when the expected is bailing on the project for the sake of your vacation.)

I tried to be "the good employee". As often as not, it burned me. Eventually, I was very much so with individuals (sometimes, 15 minutes of my time could save them a couple of days), but tried to learn to be less that way in an undifferentiated fashion towards the institution in general.

Many institutions become very rigid with regard to culture, expectations, and reciprocation. Essentially, eventually, they "train" their employees not to care. (Once again, it's what you _do_ , not what you _say_ \-- again, speaking generally and not to you specifically.)

</comment></comment></comment></comment></comment><comment><USER4> Based on U.S. expectations, I don't really see any poor form on the employee's part. The fact that it hit the supervisor out of left field is usually more indicative of a lack of ongoing communication than anything else. The implication that production employees are expected to wait while their replacement is hired and trained may be a side effect the way in which the workplace environment operates.

To put it another way, it sounds like management wanted all the benefits of employment at will without accepting the costs.

<comment><AUTHOR> My (poorly worded?) question was asking whether we should consider the employer's perspective when leaving to join a startup, and how do people most often handle this. In this particular case, there was clearly a failure to see that the developer was getting bored and so nobody expected him to leave. He had a private office, flexible hours, freedom to work on open source projects, and excellent benefits (profit sharing, pensions, etc) -- but I found after he left that bioinformatics development was just not his interest. He jumped to a startup that used the open source code he contributed to. So in this case, management was not taking advantage. Perhaps the other way around. But based on comments so far, employee management relationships seem not so good, in general, for developers.

<comment><USER4> It is not necessarily the case that the employee did not consider the employers perspective - after four years with the company it is probable that he had seen other people come and go and developed a sense of how the matter would be handled. Seeing as it is not uncommon for workplaces to be structured such that there is never "a good time" to quit because projects are endless or there is always a backlog or deadlines fall one after the other.

For an employee, the clean break often considers management practice and is done in some sense for their benefit even if it is not what they would articulate as their interest. Disinterested short-timers are a drag on moral and long notices can give management false hope that they have time to negotiate to retain the employee (the course of least resistance) rather than finding a replacement.

After my initial response I recognized another piece of management's misassessment of the situation. After four years, the "promising young developer" no longer saw him self as "promising" but as professional. It is not an uncommon oversight to keep viewing an employee in terms of their level at the time they were hired and thus not provide them with the level of challenge appropriate to their aspirations - i.e. the leadership of progressively more challenging projects or tasks.

Finally, the fact that pension was viewed as a tool to retain a young go getter is probably a fundamental miscalculation for promising developers - young people attracted by pensions wind up in large organizations or government not in dynamic teams with a high beta.

<comment><AUTHOR> _after four years with the company it is probable that he had seen other people come and go and developed a sense of how the matter would be handled_

You'd have to know the company, but I can categorically say that this was not the issue.

 _Finally, the fact that pension was viewed as a tool to retain a young go getter is probably a fundamental miscalculation for promising developers - young people attracted by pensions wind up in large organizations or government not in dynamic teams with a high beta._

It wasn't the only benefit, but your point is well taken. People wanting to join a startup (and younger people in general) are not interested in long-term stability (unless of course it is their dream job) which this wasn't.

But the question is not about why this particular person left, it's about whether good people leaving for startups should even consider the employer when deciding how to leave.

</comment></comment></comment></comment><comment><USER5> > When encouraging people to follow their dreams, shouldn't there be a > concomitant reminder that employers deserve some consideration, too?

No, there should be a clause in the contract specifying a mutual minimal time of notice for ending the employment. Also see this great post <http://www.kalzumeus.com/2011/07/08/business-psychology/>

<comment><USER6> Clause in the contract, but remember it cuts both ways.

I was recently creative director of a small software company that let their design team go. When I started the owner changed my employee contract from 14 to 28 days with the assumption that since I was in a management position with 5 reports, were I to leave the transition would have been hard to squeeze in to the standard 2 week period.

When he announced he was letting everyone go with 2 weeks severance, he was not too happy when I reminded him my contracted stipulated 28 days (he did honor it though).

</comment></comment><comment><USER7> Here's how I handled it. I went to my employeer and said, "I'm unhappy here and I'd like to move back home anyway" and he asked how I was unhappy, and I explained I didn't really like my job and I tried some different things inside the company and none of them really fit what I wanted to do.

The results were in and so we started looking for someone and I stayed on for a month after they were hired to train the person in. After that I left.

But, I would flip this around and say it had more to do with the employeer. I felt like I could do this. Do you make it so the employeer felt like they could do this? I'd avoid putting it in a contract in focus on creating a culture where this type of thing can be norm.

<comment><AUTHOR> That's cool. I felt I did, but that's subjective. But this is exactly the kind of thing I would like to have seen. Absolutely leave jobs when you feel you need to, but work with your employer if you can to make the transition easier. Fulfilling your ambitions does not need to be damaging to anyone else. As you state, good employers should make this environment the norm. But the discussions I read here about quitting and joining startups don't deal with this side of the equation. They seem to mostly emphasize quitting as a defiant act or a personal milestone (which to me implies not caring about what state you leave things in).

BTW, did your employer notice that you were unhappy and bring it up to you before you told them?

<comment><USER7> No, they didn't.

I think they should have though. I went from working basically 6 to 6 to 8:30 to 5. It was pretty obvious.

Someone wrote on my employee review that they could tell I wasn't passionate about my job and it shows sometime, but I think that was post discussion with my boss and he would have probably been notified as he was in HR.

</comment></comment></comment><comment><USER8> I'm in a very strange situation with my boss. Things have been rough for some time now and he is not going to change.

He has put incredible pressure on me to give him 6-12 months notice. Not 6-12 weeks, but he wants a full year.

That is selfish and wrong. Since you are suggesting consideration for thr employer, What is the 'right' to do?

He has every intention of using a non-compete agreement to limit my future options, how does that show that the company values me?

<comment><AUTHOR> Thanks for relating your situation. I hope I haven't come across as unreasonable. I don't think (nor have I advocated) that employees bear the full brunt of any transitional disruption. I just think that we often tell people to follow their dreams and quit their jobs without asking them to leave in an honorable way. And I define honorable as making reasonable efforts to minimize the disruption of losing a valuable employee, for example by giving more than two weeks notce. As @pasbesoin said, professionalism is to be expected on both sides of the relationship. In your situation it seems to be a worst case where your employer is using undue pressure and making the whole affair pretty one-sided (which sucks badly). In my opinion, you owe him the minimum your contract requires and no more. I'm not a lawyer, so the whole non-compete agreement is beyond where I feel like I can comment upon.

I think you and several posters have pointed out to me that not all employers are honorable nor care enough about their employees and thus it's not always possible to give them the consideration they might want. Fair enough. And it turns out to be harder to generalize than I thought it would be. Sorry, I can be naive.

For what it is worth, in my case, I didn't complain to the employee about the two weeks notice nor did I ask for anything beyond documenting procedures and critical code. We wished him well and sent him off to join a startup with a company-wide party. No strings attached.

<comment><USER8> You have done a great job of stating your case and responding to comments from the employee side. I have no doubt that your next programmer will benefit from this.

Thank you for starting this discussion.

<comment><AUTHOR> Thanks. I hope so, too. Good luck on your situation. I hope it turns out better than you fear.

</comment></comment></comment></comment><comment><USER9> I recently left a job I had just started, because a much better offer came around and I simply couldn't pass it up. I offered to keep working from home during the evenings and weekends (most of my work was done remotely) until a replacement was found, but my boss chose to cut ties that day and we both moved on, amicably, which is nice.

In this climate, I imagine that the only norms are those stipulated in a contract.

<comment><AUTHOR> Correct. But contracts stipulate the minimum. And I understand that if things go bad, the minimum is all that's necessary. But the credo of "just quit" seems to say that the minimum is al you ever need to worry about. I think taking your employer's needs into consideration (as you did) by giving advance warning or simply expressing desires to change can be enormously helpful for both parties. Employers can see deficiencies in the way they structure their jobs and their communication/observation skills. And employees can leave a trail of good relationships that could help if they ever need contacts or references. Plus, if they become employers themselves in the future, they will be better able to approach the problem of retaining employees or dealing with departures.

</comment></comment><comment><USER10> I've recently been talking a lot with a friend about how badly so many people handle 'endings'. In this case, I've been talking about personal relationships and some of the things I did that led to an amicable divorce when my lengthy, troubled marriage finally ended. But in some sense, all relationships are 'personal'.

Some observations, not in any way intended as blaming or attacking:

You indicate they had flexible hours and freedom to work on open source but also indicate that when they left, much was left uncompleted and that he left to go work with a startup that used the open source he contributed to. It sounds to me like the job was structured poorly from the perspective of looking out for the employer's needs. On the one hand, yes, you should be concerned that the work environment be a positive personal experience for the employee. You should do this out of enlightened self interest as it promotes loyalty. But this is not your child. You should not behave like their daddy, helping to pay for hobbies. Was the open source project he contributed to something your company uses? If not, why on earth was he doing it at work instead of at home (or perhaps I misunderstood)? The time, energy, creativity, interest and so on that he put into that project should have been something the company was trying to capture for it's benefit. You allowed him to fritter those valuable personal resources away. He didn't want to be frittering away his time. He wanted it valued. So he went to a company that valued the work he was willing to pour himself into.

Perhaps there needs to be better communication. Perhaps there need to be better policies. Perhaps the corporate culture of trust has room for improvement. I would examine what piece of this is in the hands of the company and use it as a means to better protect the company's interests in the future.

Also, it sounds to me like this post is motivated by feelings of hurt and a vague sense that HN and "the world out there" is part of why this person hurt you. Posts motivated by hurt are usually not very productive. But if you recognize that the culture here on HN potentially has a negative impact on your company by actively promoting the idea of "just quit", one thing you can do is make a point of quietly promoting the view that "yes, quit, but do so honorably". And then provide any evidence you can find that doing so honorably is better for _their_ career, not just for their employer. Just be careful to not be too pushy or come across as "the guy with the bone to pick". And also be understanding that if the employer is an abusive jerk, doing so "honorably" can amount to cutting your own throat. Then work at making damn sure your company is not in the abusive jerk category.

Peace.

<comment><AUTHOR> Excellent points and pretty damn insightful. Thanks.

 _Was the open source project he contributed to something your company uses? If not, why on earth was he doing it at work instead of at home (or perhaps I misunderstood)?_

Some was used directly and some was only peripherally important to the projects in the lab.

 _The time, energy, creativity, interest and so on that he put into that project should have been something the company was trying to capture for it's benefit. You allowed him to fritter those valuable personal resources away. He didn't want to be frittering away his time. He wanted it valued. So he went to a company that valued the work he was willing to pour himself into._

I think his work was highly valued by the company and myself, but his work for the company perhaps underutilized his skills or just didn't interest him. I think your point is critical, though, that employees need to feel their efforts are strongly valued.

As to the point of my post/question. Does the culture of "just quit" promote a certain level of irresponsibility? I think it does. If you have to leave, of course do so. But make efforts to minimize the disruption your departure will inevitably create (if you were good at your job). Your employer gave you a chance. Whether it worked out or not, the honorable path will leave behind less ill will. Sometimes previous employers can serve as excellent contacts, references, and even future partners.

</comment></comment><comment><USER11> If you had put in the contract time that the notice should is a month (or maybe more) you might have not have the same problem.

I only need to give one week for my current job, and when I leave, that's probably all I will give.

<comment><AUTHOR> Well, from my perspective I would want more time to prepare for the transition. But putting that in a contract unnecessarily restricts people. Our company doesn't even require the 2 weeks, so I can't complain. But not everyone leaves under duress. My point was, I _never_ see posts about quitting jobs to join startups mention any consideration to the employer. To me, unless I hate my employer, I'd want to make efforts to help out. I was curious if people usually give more than required/minimal warning. I guess not.

</comment></comment><comment><USER12> Two weeks is a common courtesy. People quit because they are either bored or their boss sucks.

Best you can do is have an honest conversation with the guy about the real reasons he's leaving and then learn from it.

<comment><AUTHOR> Yeah, that seems to be the take home message. I understand it, but I still feel that two weeks leaves most employers in the hole. I mean, you can't realistically have a list of people to fill the spot ready to go at all times. In my business (small molecular biology/bioinformatics lab) it will probably take 3 months from submitting a hiring request to accepting an applicant. Maybe more. I was curious if people give much thought to the disruption that happens when they leave, especially when it's to join a startup (elective, non-emergency move). But it sounds like two weeks is pretty much accepted as fair regardless of the reasons for leaving. Like you said, you learn from it. Thanks.

<comment><USER13> You'd like to be able to hire a new employee as quickly as possible, but you'd like departing employees to hang around as long as possible.

That seems to me to be a fundamental conflict. New employees don't appear from a vacuum and old employees don't disappear into one. Other than new entrants to the market and retirees, almost everyone is moving from one place to another, with the same pressures.

Given that companies usually only hire when they already need the staff, there's likely a fairly strong incentive to encourage the new hire to move to the new job as quickly as possible.

As someone one the receiving end of that, it sucks. But now, facing the other end of the hiring game, I'll bet you're going to encourage your new hire to start ASAP (in fact, giving preference to those that can start sooner rather than later).

It's like the passing around of electron holes.

<comment><AUTHOR> I like that! I never thought of it as electron flow. So to maximize employee retention I need to minimize the potential difference between the current job and the alluring startup. It all comes down to physics, as always.</comment></comment></comment></comment>


Judge to copyright troll: your "business model" isn't my problem - <AUTHOR> http://arstechnica.com/tech-policy/news/2011/04/judge-to-copyright-troll-your-business-model-isnt-my-problem.ars

<comment><USER2> To be clear, it's not that the judge found that the trolls don't have the right to be trolls. The decision seems designed to eliminate the use of the courts themselves as a weapon (as opposed to justice being done). It significantly reduces the amount of money that a defendant must invest to defend himself.

The money quote from the judge:

"Whether or not this case settles is not my primary concern," wrote the judge last week. "Although Plaintiff's business model relies in large part upon reaching settlement agreements with a minimal investment of time and effort, the purpose of the courts is to provide a forum for the orderly, just, and timely resolution of controversies and disputes. Plaintiff's wishes to the contrary, the courts are not merely tools for encouraging and exacting settlements from Defendants cowed by the potential costs of litigation and liability."

<comment><USER3> I see that as the judge telling the trolls to stop trolling. Without the threat of protracted legal costs the trolls have no teeth.

<comment><USER4> I agree, and I kind of have a problem with it. Regardless of my thoughts about this case and others like it, the judge is supposed to be objective; he sure sounds like he's already biased against the plaintiff.

<comment><USER5> It doesn't sound like that to me. He sounds like he's _against_ the plaintiff on that issue, for sure, but that doesn't mean he lacked objectivity. Being objective or unbiased means that you aren't influenced by external factors, so your decision is based only on the relevant facts. It doesn't mean you don't ultimately take one side or the other.

<comment><USER4> The case hasn't been litigated yet. Sure, he's eventually going to take sides... but this is way premature.

<comment><USER6> As I understand it, a judge can make a preliminary decision that a case, or elements of a case, are without merit, before hearing the complete arguments of the plaintiff.

<comment><USER2> Yes. A judge is making ... judgments ... all through the case. Every time that cliche lawyer jumps up and cries "objection", the judge has to make a decision, and take a side.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> See also: [http://blogs.library.duke.edu/scholcomm/2011/03/31/the- good-...](http://blogs.library.duke.edu/scholcomm/2011/03/31/the-good-side-of- a-bad-lawsuit/#)

This one actually came to a decision and the judge ruled against Righthaven, at least partly because of the odious nature of the copyright trolling business.

</comment><comment><USER8> Am I the only one who's more shocked about the content of the article that was allegedly infringing?

Apparently a man got arrested without bail for ejaculating while getting his genital piercing patted down ... for "sexual assault" of a federal officer. Way to go TSA

<comment><USER9> I'm surprised there aren't more comments on this. The fact that he was arrested for it that shocked me, as if it's his completely his fault his gun went off.

<comment><USER10> I've researched it, and it seems like it was a satirical news website:

<http://www.snopes.com/politics/satire/patdown.asp>

<http://www.deadseriousnews.com/?p=603>

</comment></comment></comment><comment><USER11> It's interesting to note that one of the defendant's decent laywer ended up scaring off the copyright troll. Apparently, the IP lawyer involved was going to argue RightHaven into the ground, by raising many motions, running up the copyright troll's legal bills (wrong venue, failure to make a claim, etc.) It's the penultimate case of turning the tables!

The judge said some nice things about abuse of the courts, but look at the lawyer for the real victory.

</comment><comment><USER12> This is running rampant in the adult community right now. Studios suing thousands of people for uploading to torrents. It's the new revenue model when your current isn't generating. Subpoena 1000's of IP's and send threatening letters demanding payment.

Sad.

</comment><comment><USER13> _This is the way the case ends: not with a bang but a whimper_

solid TS Eliot reference

</comment><comment><USER14> This is awful.

They're basically playing chicken with legal costs. Usually targets veer first. This time the trolls did. If neither veers, someone (maybe everyone) wastes a lots of money.

</comment><comment><USER15> Props to Judge John Kane. Take that, trolls!

</comment><comment><USER3> It always warms my heart when I see people in the legal system get it right. I think slowly more and more people are entering that profession with a modicum of understanding of modern technology and how companies have been preying on the ignorance of the previous generation to bully their way to profitability.

Note that the ignorance of the previous generation is not said as a slight. I'm sure my children's generation will be rolling their eyes at the things I say and do 20-30 years from now.

<comment><USER16> I wonder though how skewed our view of the legal system is? We rarely hear success stories like there where rulings are made in what is seen in favour of the greater good. Is that the result of either selective news reporting or consistent bad judgement alone or a mixture of both?

<comment><USER17> Your view of everything is skewed. As a rule, almost everything works "well". Crime is rare, legal disputes are usually settled sensibly, politicians work hard etc.

News is about the _exceptions to the rule_. "Everything Normal" does not make an interesting headline.

<comment><USER6> Yes, averaged across the entire population thinks work reasonably well, but among critical subsets of the population (like the technologically savvy) the picture isn't so rosy. For example, does almost everything work well in the realm of P2P mass lawsuits and college student settlement shakedowns? Are there millions of college students successfully defending themselves against shakedown letters not getting any news attention?</comment></comment></comment></comment>