Accused British hacker, wanted for crimes in US, won't give up crypto keys - <AUTHOR> http://arstechnica.com/tech-policy/2015/02/accused-british-hacker-wanted-for-crimes-in-us-wont-give-up-crypto-keys/ <comment><USER2> They could use the RIPA powers to compel decryption, but they haven't, possibly because of the extradition context.

In which case I think this is just covered by PACE: [https://www.gov.uk/police-and-criminal-evidence- act-1984-pac...](https://www.gov.uk/police-and-criminal-evidence- act-1984-pace-codes-of-practice) ; but that allows items to be retained so long as an investigation is ongoing. Which would be until the US give up trying to extradite him. Given the Gary McKinnon fiasco, that's about a decade and the intervention of several Home Secretaries.

<comment><USER3> > They could use the RIPA powers to compel decryption, but they haven't, > possibly because of the extradition context.

We don't actually know that with certainty. The Act contains a provision whereby someone can be forbidden from revealing that he's received an order to disclose an encryption key.

</comment></comment><comment><USER4> I know in theory you can do so, but representing yourself is often code for "I was unable to find a lawyer willing to agree with my crazy legal theory". Dropping phrases like "convert chattel" makes me think that's even more likely, because even lawyers don't talk to the press like that.

<comment><USER5> Modern law is effectively a cartel. There is no reason that an educated, intelligent man shouldn't be able to represent himself in most cases with fair preparation - so the bulk of modern law consists of creating obscure procedures and technicalities to make the former especially difficult, thus allowing the elite and privileged class to have an all-together different experience and preferable outcomes within the law which is only theoretically supposed to be applied in equal measure to all.

<comment><USER6> A fair justice system is by necessity complex, and a complex system necessarily requires guidance from an expert.

<comment><USER5> What does it mean to be an _expert_? The cartel-aspect is that it's _not good enough_ to know the relevant law (it's not any harder to read legal documents than manuals) or to be able to emphasize it's relevance and logical coherence relative to the case.

This is precisely the kind of mystical nonsense notion that I was referring to. In their view a qualified defense must be made by a lawyer precisely for the sake of it being made by a lawyer, and for preserving the power-structure of the institution.

<comment><USER6> No. A qualified defense must be made by someone with requisite legal knowledge, and while not everyone with that knowledge must necessarily be an attorney, of course the courts use a law degree and the bar exam as heuristics.

The simple fact that you think legal documents are no more difficult to understand than manuals is a perfect example of how woefully unprepared for the legal arena certain members of the general public are.

It takes a _long time_ to learn statutory law, case law, common law, constitutional law, regulatory law, and their interconnections about even a _single subject_ , and it is assumed throughout that you will have knowledge of legal concepts that aren't contained in those documents.

Is it possible to represent yourself and win? Yes. If you really know the law that well, you won't have a problem, even pro se.

The issue is that many pro se litigants are like you.

They hubristically believe the law is like an IKEA instruction booklet, advance wildly incorrect theories due to lack of foundational knowledge, end up wasting vast amounts of the court's time at taxpayer expense, and then bitterly complain that the judge didn't follow the law when they lose.

<comment><USER5> > The issue is that many pro se litigants are like you...hubristically > believe...advance wildly incorrect theories

Thank you for the ad-hominem attacks. Usually these come when the interlocutor has little left to say of merit.

> A qualified defense must be made by someone with requisite legal knowledge.

And the key part of this statement is the _mystical belief_ that _requisite legal knowledge_ is something intangible to the case and which defies normal logic. So you'll accept a guy working in a patent office solving a difficult problem in physics, but heaven forbid he should feel qualified to represent himself in court.

>it is assumed throughout that you will have knowledge of legal concepts that aren't contained in those documents.

More mysticism?

You would be surprised how many lawyers I've talked to that would have failed out of a first semester course on formal logic.

>advance wildly incorrect theories due to lack of foundational knowledge, end up wasting vast amounts of the court's time at taxpayer expense, and then bitterly complain that the judge didn't follow the law when they lose

Actually I have had the occasion to defend myself in court. For what it's worth it took me three court appearances, because the prosecutor was completely oblivious to how groundless the case was; thus happily wasting three days of my economic productivity (which cost more than the fine would have) as well as tax payer money.

<comment><USER7> > So you'll accept a guy working in a patent office solving a difficult > problem in physics, but heaven forbid he should feel qualified to represent > himself in court.

Citing Einstein as a prototypical example is somehow conceding the parent's point, don't you think?

> You would be surprised how many lawyers I've talked to that would have > failed out of a first semester course on formal logic.

This I can believe; but then, law has very little to do with formal systems and the sort of informal "logic" used in legal reasoning is absolutely uninformed by anything but the first week or so of a standard intro to mathematical logic course (most legal theory/systems pre-date the advent of modern logic in the late 19th century).

<comment><USER5> > Citing Einstein as a prototypical example is somehow conceding the parent's > point, don't you think?

I'm not citing Einstein as a prototypical example by any means, but I'm citing the _idea_ about how we verify knowledge in a subject.

If a guy from a Burger King comes and says, hey I've got a result in theoretical physics, or hey hire me as a developer - we have a method to _verify_ whether they can do those things in a practical way and this shouldn't require platitudes about _complexity_ and _history of jurisprudence_ etc. (or the equivalent for those fields).

>This I can believe; but then, law has very little to do with formal systems and the sort of informal "logic" used in legal reasoning is absolutely uninformed by anything but the first week or so of a standard intro to mathematical logic course (most legal theory/systems pre-date the advent of modern logic in the late 19th century).

Formal logic logic as far as reasoning about non-mathematical subjects is probably not that far from where it was in Aristotle's days. I don't know about the actual application of law - indeed your average jury may very well be swayed (I'll quote from yesterday):

 _" Ladies and gentlemen of the jury. We will show you how the defendant used the notorious hacker tool known as 'strings' to facilitate his vendetta against Lenovo."_

But that a Jury would be swayed by something like that and that it's the business of prosecution to make such arguments (hypothetically) is I think precisely in support of my point about the law.

On the other hand the authors considered to be authorities Jurisprudence are, I think, _very well_ informed in formal logic.

<comment><USER7> > we have a method to verify whether they can do those things in a practical > way and this shouldn't require platitudes about complexity and history of > jurisprudence etc.

The author explicitly stated it's _not_ impossible to represent yourself adequately, it's just very rarely done well.

Your theory about how judges should act only makes sense if evaluating arguments is free. But evaluating arguments -- especially unconventional ones -- is _really_ expensive!

There is significant cost associated with evaluating an "out there" legal theory (in terms of research, opinion writing, etc.); it's entirely reasonable for judges to not invest public time/money into a point-by-point analysis of an unorthodox legal theory, especially if that theory comes from someone without formal training.

Most professionals know that certain non-professionals _are_ capable of doing their jobs, but also know that in the general case hubris is far more common than untrained competence.

The parent's point was essentially this -- it's not impossible to represent yourself, but it's much harder than most people realize. Most judges aren't willing to invest the time necessary to investigate/help articulate apparently crazy legal theories, and that's both rational and justified. Explaining point-by-point why a crazy legal theory is crazy is not a good use of public time and money.

> Formal logic logic as far as reasoning about non-mathematical subjects is > probably not that far from where it was in Aristotle's days.

That's my point -- typically "formal logic" means exactly deductions in/about formal systems. Wikipedia _redirects_ "formal logic" to "mathematical logic".

Law has no formal logic, and (edit: a lot of) what's taught in law school pre- dates the advent of formal logic (late 1800s) by a hundred years.

The ability to prove soundness or completeness or first order logic (the sort of thing I would expect to appear in an introduction to formal logic course) is really completely irrelevant to the practice of law.

> the authors considered to be authorities Jurisprudence are, I think, very > well informed in formal logic

This is simply not true, or else you have an uncommon definition of "formal logic".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> After your equipment has been in the hands of a government, wouldn't it be wise to simply abandon that hardware? Who knows what kind of crap they've installed on it that is nearly impossible to remove.

<comment><USER9> You can likely just get the raw data from your drives without actually keeping anything executable. Text files and images are fine, but I'm sure there are some formats that you'd have to be extra-careful about.

<comment><USER10> Text and images can easily be tampered with to exploit. In fact, that's a common malware vector. If you have reason to not trust your files, then it's fairly black and white.

<comment><USER11> That is why you need to make sure you do not give them your decryption password for your file container. And hope they were not able to compromise your encrypted container in such a way.

</comment></comment></comment></comment><comment><USER12> I know it hasn't been requested yet but I find it interesting that the US could seek extradition of a suspect for hacking into their systems while facing no repercusions for doing the same to Gemalto.

</comment><comment><USER13> Was this guy affiliated with HTP? They were notorious for the ColdFusion exploit, for hacking Linode, and for hacking DARPA (or something like that).

Edit: Some Googling turned up a pastebin result [1]. Also relevant are [2] and [3].

[1]: [http://pastebin.com/d0ni33Hx](http://pastebin.com/d0ni33Hx)

[2]: [http://krebsonsecurity.com/tag/zeekill/](http://krebsonsecurity.com/tag/zeekill/)

[3]: [https://encyclopediadramatica.se/Zeekill](https://encyclopediadramatica.se/Zeekill)

<comment><USER14> Lauri wasn't involved with HTP, he was involved with a HTP member that gave him the CF exploit he used.

</comment></comment><comment><USER15> Some advice for the accused; not that I condone your actions _(based on the article, you seem guilty)_ but if you get the devices back you should probably assumed they've been compromised. You should just destroy them complelety. Or maybe investigate and document any tampering. But please don't login to any sensitive accounts on them. Don't decrypt the files on those devices either. Mount the filesystems and copy the files to a known trustworthy device.

<comment><USER16> > _Mount the filesystems and copy the files to a known trustworthy device._

At this point, can we even be certain that that's safe? If the hard drives themselves have been compromised, what's to prevent them from copying out arbitrary data?

<comment><USER17> I guess it depends on value (to him) of retrieving the data and the sophistication of your adversary (and if his reported/alleged boasting on irc is to be believed, and collusion/cooperation between the UK's NCA and the US, you'd need to assume the most sophisticated of adversaries is a distinct possibility).

It's too late to keep encrypted copies of the data out of his adversary's hands - they'll have imaged everything as their first step - so presumably he's either doing this because there's data there he wants, or he's just being a pain in the ass over a few hundred bucks (or pounds) worth of hardware (and more power to him if that's what's really gong on!).

If _I_ needed data off those drives, I'd get a "burner" computer that's not connected to the internet or any sort of local network, plug the drives into that and decrypt them, then get those files off the machine in the least technical way possible - transcribe them by hand, take photos of the screen, print to a usb connected (burner) printer, if the data is too big for those sort of options (or binary blobs) I'd use a serial port connection to a second trusted machine.

Then I'd melt down the drives and the burner machine.

But mostly, I'd avoid becoming a target of the NSA's attention in the first place - if I were him I'd be suspicious of any hardware known or suspected by the NSA to be used by him ever. I'd assume supply chain exploitation of any new hardware with deeply embedded firmware/hardware layer exploits. I'd only ever use (for "private" purposes) 2nd hand hardware bought for cash from strangers... If you can get "targeted" for surveillance and exploitation just for occasionally using PGP and working at the wrong company (like the Gemalto guy from Thailand), how much scrutiny would you have to expect to live under if the US military thought you'd rooted their internal networks?

Glad I'm not him...

<comment><USER17> And, in a late update:

[http://www.wired.com/2015/02/nsa-firmware- hacking/](http://www.wired.com/2015/02/nsa-firmware-hacking/)

I don't know if he's considered worth this much to "the authorities", but how'd you like _that_ done to your disks?

(If I'm reading that right, by non network connected burner machine would _probably_ be safe against that, but it's clearly half decade old NSA tech. Assuming their capability hasn't improve beyond that is ... foolish...)

</comment></comment></comment></comment><comment><USER16> > _He exploited similar types of vulnerabilities in sites that used > ColdFusion, the Web application software whose full source code was recently > found on a server operated by hackers._

I have no idea why, but I always assumed that the ColdFusion source was as freely available as Apache's or PHP's.

<comment><USER17> I'd guess that the source for Cold Fusion is probably fairly well secured by Adobe, and was never available on any of the exploited servers, the same way that very few webservers actually have the Apache or PHP _source_ code lying around, just the complied binaries. What was probably found on "a server operated by hackers" would have been the web-app written to run on Cold Fusion, so in your analogy it's more like they exfiltrated the WordPress php source files.

(assuming, perhaps foolishly, that a logical interpretation exists for the hints dropped by a journalist who either doesn't fully understand, or who strove to lower his wordcount as a higher priority that technical accuracy...)

</comment></comment><comment><USER18> They will decrypt it in time</comment>


Plaintiff in SV Wage Suit Asks Judge to Reject Settlement - <AUTHOR> http://www.nytimes.com/2014/05/12/technology/plaintiff-maligns-deal-in-silicon-valley-suit.html

<comment><USER2> It's worth clicking through and reading the formal letter sent by Mr. Devine (a class representative) to the judge.</comment>


"What the Hardware Does" Is Not What Your Program Does: Uninitialized Memory - <AUTHOR> https://www.ralfj.de/blog/2019/07/14/uninit.html <comment><USER2> When K&R invented C, and when ISO/ANSI standardised C, I don't think this is at all what they had in mind for UB. Whenever discussions like this come up, I like to quote the C standard itself on its definition:

"NOTE: Possible undefined behavior ranges from [...] to behaving during translation or program execution _in a documented manner characteristic of the environment_ "

The whole point of C as K&R and ISO is to let you do "what the hardware does". They left parts of the standard purposefully undefined, so it could remain applicable to a wide variety of implementations. The intention was definitely NOT "screw the programmer" as a lot of the compiler writers seem to have interpreted it, but to allow them to do something that makes sense for the environment.

Now we have, mostly academics from what I've noticed, that are taking the language farther and farther away from reality; focusing only on something uselessly abstract, completely ignoring the practical consequences of what they're doing. Compilers are becoming increasingly hostile to programmers. A programming language that had humble and very practical uses, with straightforward and easily understood behaviour, has been perverted into theoretical quagmire of uselessness.

Something very very odd is going on, and I don't like it one bit. It's very WTF-inducing.

(I don't know much about Rust, hence why I didn't say anything about it. But I've been using C since the late 80s.)

<comment><USER3> > Now we have, mostly academics from what I've noticed, that are taking the > language farther and farther away from reality; focusing only on something > uselessly abstract, completely ignoring the practical consequences of what > they're doing. Compilers are becoming increasingly hostile to programmers.

I don't think it's the academics, it's the compiler implementers - driven by wanting to win at benchmarks. Our industry is absurdly focused on "performance" over all else (even correctness). But then again, those who care about other things moved on to non-C languages years or decades ago.

<comment><USER4> Indeed, it's compiler implementors, not academics.

However, the performance impact of optimizations that take advantage of UB is not known, and is potentially very large. It would be a very interesting experiment to modify a C/C++ compiler so that every C/C++ program has defined semantics in terms of a simple array-of-bytes abstract machine, and see how much slower the generated code is compared to the regular compiler.

<comment><USER2> _It would be a very interesting experiment to modify a C /C++ compiler so that every C/C++ program has defined semantics in terms of a simple array-of-bytes abstract machine, and see how much slower the generated code is compared to the regular compiler._

Alternatively, look at compilers like Intel's ICC --- it has historically been one of the best at code generation, yet it's not known for having anywhere near the same level of UB-craziness as Clang (or GCC, to a lesser extent). The same has been my experience with MSVC, at least the earlier versions.

<comment><USER5> On the contrary, ICC _doesn 't even implement IEEE 754 correctly_ by default [1], for performance. This is way more aggressive than GCC or Clang.

[1]: [https://hal.archives- ouvertes.fr/hal-00128124v5/document](https://hal.archives- ouvertes.fr/hal-00128124v5/document)

</comment></comment></comment></comment></comment><comment><USER6> > the Rust program you wrote does not run on your hardware. It runs on the > Rust abstract machine

Excellent point, and very well made… Thank you for writing this!

There is a constant back-and-forth here on Hacker News about whether or not "undefined behavior" is the root of all evil or the root of all real-worls optimizations… And your article does a great job of explaining, in real-world terms, what UB really (in-part) is.

<comment><USER7> I don't like this formulation much. I would rather say that the program does indeed run on your hardware, but the program that runs is not the program you wrote. It's the program into which program you wrote has transformed by the compiler - better yet, it could be any one of the programs into which the compiler is allowed to transform the program you wrote.

I prefer this because it is more open about the fact that all the weird and counterintuitive behaviour happens because the language specifiers and compiler implementers decided to make it that way (usually, with good reason!). It's not some unavoidable property of the universe, or the machine.

The idea of an abstract machine is still really useful, because it lets you reason directly about the code you are writing, rather than having to express and reason about what the compiler might do with it. But i think we should be clear that it's a tool for thinking, not a truth.

The idea that you can ignore the real hardware is particularly unhelpful in Rust, because it's a great fit to low-level problems where the real hardware is a big deal. For example, at work, we have a Rust program where we routinely need to think about NUMA placement and cache coherency protocols. Those don't exist in the Rust abstract machine at all!

<comment><USER8> > The idea that you can ignore the real hardware is particularly unhelpful in > Rust, because it's a great fit to low-level problems where the real hardware > is a big deal. For example, at work, we have a Rust program where we > routinely need to think about NUMA placement and cache coherency protocols. > Those don't exist in the Rust abstract machine at all!

If I understand Ralf's overall model here, I think they'd argue that this sort of reasoning must be done within the context of the abstract machine's behavior for std::ptr::{read,write}_volatile, no?

<comment><USER7> The kind of reasoning we do is "if thread A writes to this location, then next time thread B writes to this location, it will have to take ownership of the cache line, which will take N cycles, so let's not do that". I don't think that kind of performance reasoning maps on to anything in Rust.

</comment></comment></comment></comment><comment><USER9> Would have liked to see the machine code generated by the example function, and a deeper dive mapping compiler choices to the unintuitive results.

The article (indeed the point of it) abstracts that all away behind "undefined behavior" and a mental model sitting between your code and its resulting executable. Which is fine, but it leaves a loose end which fails to sate my curiosity.

<comment><USER10> It depends on whether you generate using rustc 1.28 or rustc 1.36, and whether you're compiling with or without optimzations. This does not crash in unoptimized rust (either 1.36 or 1.28) but it will crash in optimized rust 1.36.

[https://godbolt.org/z/8Yxl2c](https://godbolt.org/z/8Yxl2c)

I think though (as your question indicates); that the author misses the point of why people care about "What the hardware does". At the end of the day, assembly code is going to execute, and that assembly code is going to (despite the authors protestations to the contrary) have well defined memory of one value or another. The moment you start saying "Rust has a third value of uninitialized" the question comes up "How is that abstraction enforced by the hardware?" This is valuable information for understanding how the language works.

From the authors discussion, I was expecting some sort of sentinel value being checked; however, instead, the uninitialized memory access is detected by the compiler and it panics uniformly regardless of the actual memory state.

The idea that one should only worry about the abstract virtual machine of rust seems like an encouragement of magical thinking. "Don't worry about how any of this works, the compiler will just make it happen". This will not go over well with many people who are curious about learning Rust.

However, if the author is arguing "Don't let the behavior of a naive enforcement of a Rust safety construct dictate how the optimized version should work" this seems like a more interesting position; but it's not clear that is the argument being made here.

<comment><USER11> > However, if the author is arguing "Don't let the behavior of a naive > enforcement of a Rust safety construct dictate how the optimized version > should work" this seems like a more interesting position; but it's not clear > that is the argument being made here.

This is exactly the point the author is arguing. The focus of all their work on UB is to make sure safe Rust can do all the optimizations we would like, by careful design of the abstract machine.

The immediately visible outcome of this work is a set of rules for what you can do in _unsafe_ Rust, which taken together amount to this weird-looking abstract machine with its extra "uninitialized" values- something that can be implemented efficiently on real hardware _assuming no UB_.

The point here is that this abstract machine is a better, simpler, easier way to convince yourself whether or not an unsafe Rust program is well-defined, and that "what the hardware does" is too many layers removed to be a good tool here. You can think about "what the hardware does" another time, for other purposes, but trying to do so in this context is actively unhelpful.

<comment><USER10> _shrug_. There's a difference between saying "This is a useful abstraction" and saying "understanding what assembly is generated is irrelevant in understanding what your program does so I will try to end all discussions where it comes up".

I mean, the latter seems quite a bit more extreme, and is what the author explicitly is calling for.

<comment><USER12> The issue is that there are no guarantees on the generated assembly, and what your compiler of today may do is not necessarily what tomorrow's will.

<comment><USER10> There are most certainly guarantees on the generated assembly. The assembly has to enforce the abstract machine. I want to know how it does that. It can change, that's fine, it can be improved, it can be made worse, but the idea that the rust program doesn't run on physical hardware, as explicitly stated in the article, is pure bullshit.

<comment><USER13> > The assembly has to enforce the abstract machine.

The assembly has to implement the abstract machine _only if your program has no UB_. The assembly never has to check if memory is "initialized" or not even though that distinction is real on the abstract machine, because if the difference would matter, your program would have UB.

To determine _if_ your program has UB, looking at the assembly is useless. The only way is to consider the abstract machine.

<comment><USER10> When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.

<comment><USER12> No, because the compiler will not generate code that is consistent in this case.

<comment><USER10> So? What do you think I'm arguing for here?

<comment><USER12> There is no standard mapping between "your C code" and "what your computer will do" if your code has undefined behavior. Your compiler will produce some assembly, which you cannot rely on, and _that_ will be "what your hardware does". If that's what you're trying to say I think we agree.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Is there an example of actually helpful and practical enabled-by-undefined- behavior optimization in C/C++? All I can remember are discussions of its pitfalls, like this.

<comment><USER15> One classic helpful example that gets brought up is integer overflow and loops. Because overflow is undefined in C and C++, the loop doesn't need to check for it on each iteration.

<comment><USER16> [https://d.godbolt.org/z/_r6C9N](https://d.godbolt.org/z/_r6C9N)

Example of an Integer overflow based optimization

<comment><USER17> Wait, how does that work? Without overflow, how does the compiler prove that eventually x == 7?

<comment><USER18> If x <= 7 then the answer will be 420, but if x > 7 then behavior is undefined because x will overflow, and x is signed, and signed integer overflow is UB in C, so the compiler is free to, for example, conclude that blazeit() is never called with x > 7, thus it can prove that blazeit() always returns 420. Besides, if the compiler chooses to implement signed integer overflow much like unsigned integer overflow, then x will eventually come around to 7 anyways, so the answer must be 420.

<comment><USER14> Then later, after some minor unrelated change, compiler stops optimizing and it suddenly starts overflowing the stack.

How can anyone put up with that?

<comment><USER18> I expect the compiler would optimize the tail recursion into a loop, so the likely worst case is not that you blow the stack but that you spin for a while.

<comment><USER14> Not really, any expectations here are unsupported by C standards. Compiler is, by spec, allowed to do anything here.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I disagree that bit and byte level uninitialized models are equivalent. Consider a program that uses one bit of a bitfield in a stack allocated strict. The compiler is free to preserve the value of that bit however it pleases --- e.g., in the carry flag --- and randomize the rest of the bits if you ever read the whole byte.

<comment><USER13> Hm, good point about the bitfields. The paper I cite [1] actually talks specifically about bitfields as their precise semantics in the presence of "poison"-style uninitialized memory is not entirely clear yet.

[1]: [http://www.cs.utah.edu/~regehr/papers/undef- pldi17.pdf](http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf)

</comment></comment><comment><USER20> Why aren't undefined bytes like these treated in the same way as I/O data? That is, arbitrary but fixed data? This seems to align fairly well with how I think about uninitialized data.

<comment><USER3> If you're asking why the C standard didn't originally define it that way, it's because some architectures might use a trap/invalid representation (that traps when accessed) and we want compilers to be free to reorder memory accesses.

<comment><USER20> I think I'm mostly asking why this isn't a good solution for Rust, as I think C and C++'s design decisions should be absolutely irrelevant for it's development. However, since rustc uses LLVM, this seems to be difficult :(

I suppose it could be enlightening to understand why it wasn't a good decision for C or C++ at the time either.

> some architectures might use a trap/invalid representation

Traps on what? Access of an invalid representation? What if such representations doesn't exist?

<comment><USER3> > Traps on what? Access of an invalid representation?

Yeah - certain bit-patterns are just "invalid" rather than representing any given value. It's much nicer to debug, because you get an immediate failure (at the point where your code tries to access the uninitialized variable) rather than having a corrupt value propagate through your program.

> What if such representations doesn't exist?

Then you can't implement that strategy (other than by emulating it with considerable overhead, e.g. by having an extra marker byte for each variable in your program and checking it on every access). Hence why the C standard doesn't require you to do this.

As originally intended, C left the behaviour undefined so that users on platforms that did have trap representations would be able to take advantage of them. (It's very hard to rigorously specify what accessing a trap representation should do without impeding the compiler's ability to reorder memory accesses). Unfortunately it's ended up being used to do the opposite by modern compilers - not only do they not trap on access to uninitialized values, they abuse the undefined behaviour rules to propagate unexpected behaviour even further from the code that caused it.

<comment><USER21> But then this should be documented in the types definition. I don't see this "can also be something else than 0-255" in the in the types documentation (that is arguably not at all detailed).

We use types to restrain complexity. It was a mistake in C# to allow every object to be null. A better type system would allow devs to make a contract to easily disallow this and they try to fix this. Now here we have a blog post that seems to be fine with a function parameter of type u8 not actually being of 0-255. That's a huge change I always understood the type. Do I now have to do implement a null-check equivalent?

Undefined behavior for unsafe code is fine. But there has to be a transition were we go back to classical behavior. And in the blog posts example, this should be somewhere in _main_. Certainly not the seemingly safe _always_returns_true_.

<comment><USER3> > But then this should be documented in the types definition. I don't see this > "can also be something else than 0-255" in the in the types documentation > (that is arguably not at all detailed).

It's not a valid value of that type - it's not a value you'll ever see if you're using the language in accordance with the spec (and, in the case of Rust, not a value you can ever see in safe Rust). It's an uninitialised value.

> We use types to restrain complexity. It was a mistake in C# to allow every > object to be null. A better type system would allow devs to make a contract > to easily disallow this and they try to fix this. Now here we have a blog > post that seems to be fine with a function parameter of type u8 not actually > being of 0-255. That's a huge change I always understood the type. Do I now > have to do implement a null-check equivalent?

The point is for the language to do the null-check equivalent for you. A trap representation is null done better. Silently defaulting to a valid value is even worse than silently defaulting to null, because the value propagates even further from the point where it's wrong - imagine e.g. a Map implementation that, rather than returning null for a key that isn't present, returned an arbitrary value.

(Of course in the case of a Map, returning Maybe is better. But there's no way to do an equivalent thing for uninitialized variables, unless we made every single field of every single struct be Optional, and that's actually just equivalent to reintroducing null - the advantage of using Optional is the ability to have values that aren't Optional, at least in safe code).

> Undefined behavior for unsafe code is fine. But there has to be a transition > were we go back to classical behavior.

Unfortunately no, that's not and has never been how undefined behaviour works. Undefined behaviour anywhere in your program invalidates the whole program and can lead to arbitrary behaviour anywhere else in your program (this has always been true with or without trap representations).

Pragmatically, what you want in the blog post's example is to get an error that tells you that the bug is that x was uninitialized, as soon and as close as possible to the point where x is actually used uninitialized. Ideally that would be on the "let x = ..." line (and if you didn't use "unsafe", that line would already be an error), but given that you've made the mistake, you're better off having an error as soon as you touch x (which happens in always_returns_true). Then you can see what the problem is and what's caused it. If always_returns_true runs "successfully", returning false, then you don't actually find out there's a bug until later (potentially much later) in your program, and have to do a lot of detective work to find out what went wrong.

<comment><USER13> > Unfortunately no, that's not and has never been how undefined behaviour > works. Undefined behaviour anywhere in your program invalidates the whole > program and can lead to arbitrary behaviour anywhere else in your program > (this has always been true with or without trap representations).

I even have a post about this. :D [https://www.ralfj.de/blog/2016/01/09/the- scope-of-unsafe.htm...](https://www.ralfj.de/blog/2016/01/09/the-scope-of- unsafe.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> > So each time an uninitialized variable gets used, we can just use any > machine register—and for different uses, those can be different registers! > So, one time we "look" at x it can be at least 150, and then when we look at > it again it is less than 120, even though x did not change. x was just > uninitialized all the time.

Is this actually true? I thought these would just be poisoned and then the optimizer would just do whatever it liked in the presence of undefined behavior (like optimize the function to return true).

<comment><USER22> It could do that, but it doesn't have to. A common example is "a variable is set inside a loop and used outside it"; if the loop runs zero times, the variable will be used uninitialized, but the fastest compilation will assume that the loop runs at least once and read the value from whatever register/memory location the loop writes into.

</comment></comment><comment><USER23> This poison thing is interesting because it seems like one poison value could have the capability of poisoning all the data in your program. You could imagine a faithful implementation of the rust abstract machine after hitting one code path would cause your program to start generating complete nonsense.

</comment><comment><USER24> I appreciate the attempt to explain low-level stuff, but I think this is a high-level language programmer trying to understand herself/himself an issue without a clear idea of what he/she is talking about

>> The answer is that every byte in memory cannot just have a value in 0..256,

0..256?? Is this still 8-bits bytes??

>> it can also be "uninitialized". Memory remembers if you initialized it.

This is plainly wrong.

>> So, one time we "look" at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change. x was just uninitialized all the time.

You might be dealing with a bug on a non-volatile variable. It has nothing to do with allocated but uninitialized memory.

<comment><USER25> The problem here (and I caught it too and sort of recoiled at it) was they were using their logic and worse language/word choice regarding the "abstract machine" being the actual thing we should think about when reasoning about a programming language before they actually went out and were explicit that's what they were doing. They saved the explicit thesis until the end of the piece. They should have traded the writer's desire to be witty and hide the lede and just lead with it upfront.

Of course you're right in part that their idea of "memory" is an abstraction, but it isn't too wrong. A "variable" in C or any compiled language on a modern machine is an abstraction that could refer to a register one moment, be a place in the cache in another, be a place in memory in the next, and be on a swapfile after. The "variables" are abstractions which lie in "memory" which is another abstraction because it need not be in one place.

<comment><USER13> Good point, I should have at least mentioned that there is an "abstract machine" when I introduce this strange kind of memory. Thanks for the feedback!

</comment></comment></comment><comment><USER26> I don't think this is really right. He claims that uninitialised memory is not just random bytes, but it is!

It's just that there is a compile time optimisation that allows the compiler to assume you will never read from uninitialised memory.

It would be perfectly possible to make a language (or even a C++ compiler) that didn't perform that optimisation.

<comment><USER13> > I don't think this is really right. He claims that uninitialised memory is > not just random bytes, but it is!

No it's not. To describe the behavior of a program involving uninitialized memory (like the example in my post), at no point in time to you need to talk about arbitrarily chosen bytes. The "abstract machine" on which a Rust programs runs (of which your hardware is a fast implementation, but _only accurate for UB-free programs_ ) does not "pick random bytes" when you allocate new memory, it just fills it all with `None`.

You should not think in terms of optimizations when thinking about what your program does. The optimizations the compiler performs can change from version to version and are affected by seemingly random changes at the other end of your program.

> It would be perfectly possible to make a language (or even a C++ compiler) > that didn't perform that optimisation.

Sure. That would be a different language though, with a different abstract machine. C/C++/Rust behave the way I described (and that behavior is not defined by what any particular compiler does).

<comment><USER26> You missed my point. _Rust_ and _C_ may treat uninitialised memory in a special way, but that doesn't change what uninitialised memory _actually is_.

Think about assembly. What is uninitialised memory there? It's just memory with an unknown value.

</comment></comment></comment><comment><USER27> Sounds like a lot of excuses for what is really a compiler bug that found its way into the spec.

<comment><USER12> Undefined behavior is _not_ a compiler bug: it's a necessity that is required to have language constructs that give you a way of doing things for which there is no good way to define the behavior of. Your compiler optimizes your code every day by concluding that you're not doing anything illegal: it would have a rather miserable time if it couldn't make these assumptions.

</comment></comment><comment><USER28> The real issue is the C and C++ languages are horrible languages. They're too high-level to correspond to any real machine, yet so low-level so as to make such an abstract machine useful. The C language leaves the precise lengths of types up for grabs, as merely one example. As for Rust, I'd figure it's poor as well, considering it follows in the footsteps of C++.

I can compile an Ada program that has an uninitialized variable and use it, but I get a warning; there's also a _Valid_ attribute that acts as a predicate for whether a scalar value has an acceptable value or not.

To @userbinator , you're mistaken to believe the C has much design behind it. There are many things where one requires a certain range of values and C forces the programmer to use a type that's much larger than necessary and cope with unwanted values. The C language leaves details to the underlying machine, so long as that machine is determined to pretend it's a PDP-11. Most languages that have a standard expect the programmer to follow it; since most C programmers don't know what the standard says, having been lied to about it being a simple and base language, they're offended when they do something they never should've done; they shouldn't be using C anyway, however.

Abstract language details are necessary for a high-level language and can work quite well if the language is designed well; this then leaves high-level features to be implemented in whichever way is best for the machine; the C language doesn't do this well at all, however, and precisely specifies the nature of irrelevant details and so hinders the machine and implementation possibilities.

The C language doesn't even have true boolean values or arrays thereof. You're expected to use an entire integer that's zero or not and you're left to your own devices if you want an array of these values that isn't grotesque in its wastefulness. Meanwhile, most proper languages have the concept of types that only have two values and can easily use an underlying machine representation for efficiently representing these, without involving the programmer.

In closing, you may argue that C is necessary because it permits specifying these low-level details, albeit required in every case instead of only where necessary. To that, I direct you to look at Ada, which permits the programmer to ignore such details wherever unneeded, and so leave them to the compiler's discretion, but allows size, address, representation, bit-level organization, and more to be specified in those cases where it's truly necessary.

Here's a link others may like for learning more about Ada and the deficiencies of C:

[https://annexi-strayline.com/blog](https://annexi-strayline.com/blog)

<comment><USER29> > Meanwhile, most proper languages have the concept of types that only have > two values and can easily use an underlying machine representation for > efficiently representing these, without involving the programmer.

Don't other languages still use an entire byte to represent a bool though, since memory access is at the byte level? Having a bool type in the type system is really a language usability concern, I don't think it's at all a performance optimization. And stdbool.h exists now, so that concern has been addressed. When you want a bitmap, you can just use an int of the appropriate length and do bitwise operations on it, instead of wasting space with an array of ints.

<comment><USER28> >Don't other languages still use an entire byte to represent a bool though, since memory access is at the byte level?

While at the discretion of the implementation, Common Lisp is a language that can easily and transparently perform this optimization. Common Lisp even has a specialized array type, BIT-VECTOR, which can only hold values of zero or one, which is more likely to be optimized for size than other types. Ada allows the programmer to specify data structures be optimized for size, which is nice.

Now, representing a lone true or false value is a different matter and I'd expect it to consume an entire register or whatnot under most anything, since you probably wouldn't be able to store anything else with the remaining space.

>Having a bool type in the type system is really a language usability concern, I don't think it's at all a performance optimization.

Ada has a boolean type because there are clearly boolean situations, such as predicates, and having a dedicated type reduces use errors. Programmers are encouraged to define their own boolean types, though, such as (On, Off), say.

>And when you want a bitmap, you can just use an int of the appropriate length and do bitwise operations on it.

That's what I was describing. Why should a high-level language have you making your own arrays? Don't you agree that programs would benefit from a specialized type for this that can more easily be optimized and specialized for the particular machine and whatnot?

</comment></comment></comment><comment><USER30> This is just terrible. I'm really sad that it's 2019, and not only are we _still_ talking about undefined behaviour, but there are also blog posts arguing _for_ undefined behaviour! I expect a good (programmer-friendly) compiler to _at least_ warn the programmer in any case of provable, or potential, undefined behaviour, or ideally, refuse to compile/use _implementation_ -defined behaviour (i.e. exactly "what the hardware does"). Anything else is basically just inviting security bugs in your code.

But, for a counter-point: what is an example of a code/algorithm that not only _uses_ undefined behaviour (i.e. relies on it in order to compile to fast, optimized code), but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

<comment><USER31> > But, for a counter-point: what is an example of a code/algorithm that not > only uses undefined behaviour (i.e. relies on it in order to compile to > fast, optimized code), but also couldn't possibly be rewritten to eliminate > undefined behaviour (while keeping the same speed)?

Any code that handles signed integers is going to assume that overflow/underflow does not happen.

<comment><USER32> Spent the week trying to figure out how to reimplement __builtin_add_overflow (et al) on Windows and boy is it a chore. The previous implementer had literally just used operator+ in a function called "safe_add" and I was dumbstruck.</comment></comment></comment>


Loopt Tries a Groupon in Reverse - <AUTHOR> http://blogs.wsj.com/digits/2011/06/22/app-watch-loopt-tries-a-groupon-in-reverse/ <comment><USER2> While it's a theoretically cool concept, the actual implementation doesn't appeal that much to me as a consumer and I'm not sure it'll really appeal to businesses. Would I want to get $20 at a nearby pizza place for $10? Sure. But how useful is it if I have to wait an indeterminate amount of time (if ever) to get the deal? I'm likely to only suggest local businesses that I frequent a lot anyway, and how useful is it to them to offer discounts to mostly regularly paying customers?

That being said, I do think this is moving the industry in a direction for variable prices for local businesses. Imagine a real-time feedback loop where it's 4pm and you could ask your local pizza place for a discount and they could instantly reply whether they granted it or not. It's a lull before dinner and they have some pizzas from lunch they've just kept warming up, so they grant you the discount. Or actually a kids' soccer team shows up and takes over the place so they decline the discount.

This doesn't work so well with resellers (which is pretty much any restaurant), but it could definitely work with service businesses that have to pay their staff whether clients show up or not. We'll see if companies like Loopt have this vision in mind and whether they can make it possible.

<comment><USER3> A friend of mine has a company in Japan which pretty much solved this. Solution: big digital billboard in mall which aggregates tweets from mall merchants. If nobody is getting their hair cut, they tweet "$5 off for next person at Cheap Cuts" from cell phone. Merchants/mall apparently think it is a gift from God.

<comment><USER4> _Solution: big digital billboard in mall which aggregates tweets from mall merchants._

A virtual billboard in the form of a smartphone app might be preferable in different kinds of public spaces. It might also be a good adjunct to the digital billboard.

<comment><USER5> If twitter added geo-location specific streaming search results, they'd have this.

</comment></comment></comment></comment><comment><USER3> That seems strictly inferior to Groupon: it cannibalizes existing customers by design, but to get there, you need to nondeterministicly charge people's credit cards. So it is a reward card, with the restaurant paying 50% of reward values to, um, not reward their customers except weeks after the fact some of the time.

</comment><comment><USER6> Honest question... Does anyone on HN use Loopt? I've tried it a few times over the years and it never really comes to close to making me want to continue using it.

<comment><USER7> I tried, but it was before iPhone had any kind of push notifications, live in a low population area, not a lot of my friends are early-adopter social tech types, and I'm too old to want to hang out with random people I saw on Loopt -- so, it didn't work for me. I'd be willing to give it another try.

Interestingly, in the meantime, there was a lot of foursquare adoption among friends and in the area -- enough to get network effect benefit. I don't think many of my friends have heard of Loopt.

</comment></comment><comment><USER8> I doubt this will work because it doesn't take into account Zipf's law. The problem is that we live in a world where 1% of the population creates 90% of the content, so it'll be impossible to get enough people actively participating except for maybe with places like Shake Shack that don't need it anyway. If they created a new service specifically designed just for this then it might work with a few tweaks, but creating something just for the Loopt user base seems like a dubious decision.

</comment><comment><USER9> I can't see this variation of the model working because usually when you are near a store, the deal or offer is something that needs to be acted on within a few minutes

Imagine you are going out to get lunch. In the GroupOn model you have already pre-purchased a deal and you can plan ahead. In this Loopt model you can't make an instant decision based on where you are since it involves going back to loopt, etc. etc.

This would be more interesting if vendors could list their deals or vouchers on loopt and it would alert you when you are near one (based on location and/or time)

Ten years ago there was a trial of a similar system - the name of which I cannot recall. But it involved sending bluetooth alerts to your phone when you were near a store that was running a promotion or deal. I used it once to grab lunch and it worked well (you would give your phone number at the counter, the discount was ~30% IIRC).

Vendors would likely be interested in a system where they could specify something along the lines of: send me a thousand customers over the next month between 2-4pm who are within 2 miles of my location and are interested in 30% off a pizza. Do not send me customers who have already redeemed a coupon in the past x months. The problem is that type of system would involve a large upfront investment from loopt in going out and getting the customers onto the system.

Loopt have the location users, but not the deals. On the other hand GroupOn have the deals, the vendors and the users but do not have the location system. One of these is easier to build than the other

</comment><comment><USER10> I think this is interesting -- I'd probably use it in high density areas with lots of options, only. For instance, there are ~50 restaurants in Castro St in Mountain View. I've been to 15. I'd like to try about 20 of the others, so signing up for all of those would make sense.

It's probably best suited for finding new service providers for recurring needs (gas, car washes, oil changes, ammunition, range time, food) and less suited for one-offs (funerals, weddings, ...).

</comment><comment><USER11> The key here is timing. Its easier for Priceline to check on the bids with airlines because most of the airline systems support rapid data transfer. In the case of restaurants, it is difficult to predict and build a automated way to get 'approvals'. Therefore, the time it takes for them to get answer back from the restaurant will determine the success of uDeal.

</comment><comment><USER12> Taking the immediate gratification away from the consumer and giving it to the business, combined with surprise credit card charges, makes this pretty unappealing. At least to me, as a consumer.

</comment><comment><USER13> Have any of these customer-generation people actually run a brick-and-mortar business themselves? How does anyone expect a business model to be sustainable in the long term when it relies on companies selling their goods at _a quarter_ of their typical price?

A business wants a reliable stream of customers, with predictable peaks in activity. When a startup addresses _that_ at a price that businesses can actually bear, then I'll believe the company is going somewhere.

</comment><comment><USER14> sounds like a good idea in theory, but the reason some businesses tend to like groupon is that it brings NEW customers in the door. it's a marketing platform and businesses know that can be expensive. 50% is a lot to pay for a customer rewards program.

<comment><AUTHOR> our hope here is that this will bring a higher quality set of new customers in the door. word of mouth referrals tend to be pretty good. if i create a deal at a place and share it with my friends to get critical mass, that may be a better crowd that a daily deal email list.

<comment><USER15> But given a deal is contingent on your salesforce convincing the merchant to work with you (on a very tight timeframe / compressed sales cycle), doesn't this mean that by definition, most of the deals desired by users will not come to fruition? Won't this result in a poor experience for the majority of users?

</comment></comment></comment><comment><USER16> Hmm, I request a deal from a business nearby. I am already there physically, but I don't get anything at that time, for all the effort I've put into getting there.

I have moved on, it is three months later - I might be in a different country for all you know - and voila, a credit card transaction tells me that I've purchased some deal that I probably have no longer any interest in.

Seems like it could have worked in 1980, but for today, I see gaping holes in user experience.

</comment><comment><USER17> "Hi, I have 15 customers I've led along to believe they might get a half off deal at your restaurant, are you game or should I just tell them your word is no good?"

<comment><USER18> This is actually quite an interesting (if somewhat poignant) argument. In a way your name as a merchant might suffer even if you didn't add yourself to the system. This might be the Achilles heel of the whole operation.

Edit: typo. 'Achilles Hill'? Really?

</comment></comment><comment><USER19> If they start offering reverse deals, will everything become like a turkish Bazaar, with everything basically being haggled on the fly?

</comment><comment><USER11> When I read this article, it screamed Priceline to me. Its essentially doing the same thing that Priceline does for the travel industry. Its asking customers to select a deal or 'bid' on a deal and then uses that knowledge to close the deal with the restaurants. Like Priceline, Loopt will already have the credit card info and I am guessing the customer will be charged automatically.

The key here is timing. Its easier for Priceline to check on the bids with airlines because most of the airline systems support rapid data transfer. In the case of restaurants, it is difficult to predict and build a automated way to get 'approvals'. Therefore, the time it takes for them to get answer back from the restaurant will determine the success of uDeal.

</comment><comment><USER20> This sounds like enabling haggling in markets where traditionally it hasn't been done (even in Asia where haggling over price for any product is quite common).

If I say I will go to a restaurant on the condition that I get a 50% discount, I'm probably not going to spend much more there or go back again without a discount. Not sure this is a winner for businesses.

</comment><comment><USER21> Too much time between the request and delivery. There needs to be some sort of instant gratification for this to fly, otherwise it's essentially asking users to do free market research. Profit sharing with the users should the deal come into fruition would certainly inspire them to continue populating the merchant database.

</comment><comment><USER22> It sounds good that using loopt to search some kind of stuff which you need it instantly(like cafe,bar..) in a local place you are not familiar, rather than using it like Groupon's vision.

The most importantly, local markets should feed back the system instantly and people can make proper decisions at that moment.

I think, mainly idea is cool.

</comment><comment><USER23> Sounds stupid for the small businesses, because only people who already know about a place will ask for a deal there, so they won't be getting any new eyeballs and probably no new customers either. It will just be people wanting deals at places they already go to.

</comment><comment><USER24> But just imagine that they can implement something even cooler: I can actually see menus of these pizza places with prices - and information whether they are open or closed? Really...

</comment><comment><USER25> As described, that's just way too complicated. It also fails completely as advertising since the people have to start out wanting to eat or shop at the place.

<comment><USER18> You are missing the point: if it helps you fill tables with customers, it is good advertising regardless of the customers being new or not. Also, how is an offer based on what you _know_ people want worse than one published to the general public in, say, a newspaper ad?

<comment><USER25> Customers proposing that a store they know about and already wish to shop at lower their prices is not the same thing as "advertising". To call this advertising as you just did is a misnomer.

</comment></comment></comment><comment><USER26> This is wrong on so many levels.

The first one is that as a business you are supposed to use deals to bring in new customers, not to let the ones that already know you have a discount

The second one is how it'll be marketed to business owners, I understand that a fool is easily parted with this money but this is borderline stupid

</comment><comment><USER27> Good idea, but u-Deals is a dumb name.

</comment><comment><USER28> It sounds like blackmail. I'd be just as embarrassed using Loopt as I would be using Groupon.

<comment><USER29> I don't understand, how is it blackmail? It sounds useless to the store owner, because people basically say "I want cheaper things, give them to me", but it doesn't sound at all like blackmail.</comment></comment>


Has Elon Musk ever fired a great employee that missed a deadline or budget? - <AUTHOR> http://www.quora.com/Elon-Musk/Has-Elon-Musk-ever-fired-a-great-employee-that-simply-missed-a-deadline-or-budget?__pmsg__=+R1dVTWRSLU9ub1JKbzFOSW5KV3Y6YS5hcHAudmlldy5wbXNnLmFsbC5Mb2dnZWRJbkZyb21MaW5rOltbNTk0NjMzNV0sIHt9XQ**

<comment><AUTHOR> Interesting answer by the Anonymous User:

 _I regularly worked with Elon while a part of his electric car company - Tesla. At first, I hesitated to write a response, but as I thought about what I'd say, it was overwhelmingly positive. So here we go:

Amazing visionary: During one of my first meetings with Elon, he made a request that I thought, frankly, was crazy. I asked my coworkers after the meeting if we really were going to do that. I was told "if Elon says to do it, we do it. Give it time, you'll understand." Sure enough, each seemingly crazy request was grounded in a logic only Elon understood at the time. But we trusted him and I ultimately found myself in agreement - sometimes it took six months or longer to get there.

Crazy smart: No matter how tired he was or how many times he'd travelled back and forth across the country in the last few days, or how many fire-drills were running simultaneously, he understood what you were saying. He'd sit there with his famous "uh huh" and a head nod, acknowledging that he understood. And his followup questions were target and relevant.

No tolerance for bullshit: When we met with Elon, we were prepared. Because if you weren't, he'd let you know it. If he asked a reasonable follow up question and you weren't prepared with an answer, well, good luck... Our discussions were efficient, to the point, and based in fact. He expected to see progress.

Execution: You always need to be making progress. And if you weren't, you needed to escalate or find a solution to the deadlock. It was unacceptable to keep problems to yourself.

Willingness to help us get "unstuck": Sometimes we'd get stuck dealing with a vendor or making a decision across departments. He often tell us "Get me on the phone with the CEO of <insert company here>. I don't care what the problem is. We need it resolved now." Or if it was a company decision, he'd just assert the answer and we'd move on.

No fear of making the hard decisions: When you're in the trenches working on a hard problem, it's natural to convince yourself it can't be done. You start to compromise. Elon had no tolerance for this and rightly so. We'd exceed our goals, because we had to. It was how the company would survive and he reminded us of this if we drifted too far. If market conditions prompted us to change course, we would. If we needed his sign off on a large project or spend, as long as we did our homework, it was logical, and we laid out a plan, he'd be ok discussing. But he'd often send us back to rethink the proposal if it didn't jive. He wasn't afraid to spend money when needed.

Drive to do the "right thing": It doesn't matter what the status quo is. Never tell Elon "well, that's how we did it at Ford." He pushed us to always do the right thing for the customer. Making money is important to keep the company running, but it's not the most important thing. He pushed us to make a great product that is uncompromised in solving the needs of our customers, even if it goes against the automotive norm and the critics on Wall Street.

Hands on: We'd frequently see him looking at a CAD drawing at an engineer's desk. He has all vehicle engineering changes first installed on his Model S or Roadster so he could personally approve it before it goes to customers. His expectations were high. If we couldn't meet them, then he'd rather scrap the work than build a mediocre product. He wasn't afraid to get down in the details.

Personality: Sometimes he'd be in a really good mood. Sometimes not. But for the most part, I found him to be easy to get along with and supportive when progress was being made. But if too many bad meetings took place in a row, then beware... And be careful disagreeing with him. He frequently knew more than we expected, so it was risky to tell him he was wrong because he might not be.

All in all, Elon has a dedicated and loyal following. It's because we believe he knows what he's doing. He doesn't inspire us through big speeches and eloquently written emails. He focuses on getting work done, executing to plan, and driving positive change. And nobody at Tesla had more skin in the game than Elon. I'd choose to follow him over any big talker with empty promises. His push to improve the auto industry is refreshing. His dedication to improving the quality of the world we live in is inspiring. It's a rarity in the business world. I hope we each do our part in making his vision a reality, as it's ultimately in our best interest.

Edit - Response to comments:

Negatives of working with Elon: Very demanding, he's not afraid to fire poor performers, you do what he says (if you disagree, be thoughtful about whether it's worth the risk, most of the time it's not...), not everyone works well with such a strong authoritative figure, most people are scared of him, his ambition can be exhausting - there's always another huge problem we have to solve, long hours.

Why post anonymously: So I could write the above paragraph._</comment>


Looking Glass – A new type of holographic interface - <AUTHOR> https://www.feld.com/archives/2018/07/the-holographic-display-of-the-future-is-here.html <comment><USER3> I played with the large size version of Looking Glass at AR in Action conf this January at MIT. It's really cool, and the coolest part is the interaction is intuitive. You really can just touch a point on the hologram and have it react at that point.

As others have mentioned, it requires pushing quite a number of simultaneous views of the hologram through a hidpi display, the experienced resolution is not very high as a result and the holograms look a bit fuzzy.

It is right now probably the best out-of-the box way to interact with Holograms, especially in a shared environment. Hololens can't share holograms by default, and even if the app has implemented sharing, the holograms can't be touched. Meta glasses have some touchability thanks to their depth sensor, but again there's no easy shared way to interact with a hologram.

I think AR like Looking Glass is underrated, they were very smart to use natural interaction instead of gestures or a mouse/wand. That being said, I don't see it competing with AR glasses longterm.

<comment><USER4> Do you remember if the image varies in the vertical plane as well as the horizontal? The demo videos only move the camera horizontally.

<comment><USER5> if it is stacked screens, I don't see any reason it will work horizontally only. I believe the view angle is still very limited. I'd love to use this for Skype chat or something.

<comment><USER6> If the lenticular lens is made of columns (as those fake 3D postcards are) then only horizontal shift is 3D-able. To display verticality, the lenticular lenses could be hemispheres. However, to encode vertical 3D-ness you would need 45 images for each 2 degrees off the horizontal so as your head bobs up and down, it can pick up the off axis images. So that's 45 images x 45 axes = 2025 images per frame.

</comment></comment></comment></comment><comment><USER7> These lenticular autostereoscopic displays have been around for a long time and never quite took off. There have been even 3D TVs (Philips) using this idea. I am not quite sure what is "new" apart of yet again abusing the "holographic" term (hint, it has zero to do with holograms or holography).

The major issues with these are the limited viewing angles and the enormous bandwidth needed to both render the individual points of view and to actually transfer them to the screen. Heck, a lot of computer games have problems to generate stereoscopic (i.e. _2_ images) content at 60 or 90fps required by the VR helmets such as Rift or Vive these days. And these guys want to push 45 distinct images at 60fps?

Good luck with that, especially for that ridiculous price for a tiny screen.

These guys offer a 4k, 50" screen: [http://www.ultra-d.com/](http://www.ultra-d.com/)

<comment><USER8> This isn't quite the same as what you're talking about. The lenticular displays only vary in the x-dimension, but this display seems to work in both dimensions, which would probably create a noticeably better 3D effect.

<comment><USER9> looking glass is also x-dimension only: [https://www.kickstarter.com/projects/lookingglass/the- lookin...](https://www.kickstarter.com/projects/lookingglass/the-looking- glass-a-holographic-display- for-3d-cre/comments?cursor=21131425#comment-21131424)

</comment></comment></comment><comment><USER10> "I think most people don't want this 1984 vision of the future, where everyone is geared up 16 hours a day."

I assume the author means the book '1984' by George Orwell and I come to the conclusion that the author has never read the book and does not know what it is about. Not every dystopian story is 1984. A far more logical reference would have been to 'Ready Player One' by Ernest Cline which is in fact about a dystopia in which people _are_ 'geared up' all the time.

I recommend both books, the first is a work of genius and is, sadly, very relevant today and the second because it is very entertaining and might offer insights into the development of VR in the near future.

<comment><USER11> "1984" also just means 'dystopian'. It's not always a literal reference to that specific work.

<comment><USER12> I think it really only means 'dystopian' to people who have not read 1984. Otherwise there is a perfectly good word:'dystopian'.

<comment><USER11> '1984' is a particular type of dystopian; it has specific connotations, associations, etc.

</comment></comment></comment></comment><comment><USER13> Holography is a very particular set of 3d image rendering technique. This volumetric display is not holographic. To me it's a frustration. Microsoft's highjacking of the word holography is also frustrating. Such abuse does not server the product and it's inventors.

Truly holographic displays will emerge once we can control ligth interference in the display.

<comment><USER14> > Truly holographic displays will emerge once we can control ligth > interference in the display.

Could you explain this a bit more please to give an idea of the path to get there?

<comment><USER15> Not the poster above, but I will try a short explanation. You see an object, because light goes from its surface (either emitted or reflected ambient light) to your eyes. You see it in 3 dimensions, because the light differs by the viewing angle. Holography is a technology of recording the light "emitted" by the object. The light has to be recorded in direction and intensity. This is done via interference between the object light (waves) and a reference light wave, which usually is a planar wave of light.

This interference creates an interference pattern, which can be recorded by film. The trick is, that if you develop the film to get the black and white pattern, you can shine the reference wave onto the film and it interacts with the interference pattern such that the object wave is reconstructed. A hologram such is an exact recording of the light emitted by the object. This is something the display tries to emulate by offering 64 different images, but not quite the same. As the interference pattern is just a greyscale image, one could use an ultra-high resolution lcd display to synthesize that - there have been demonstrators of that, but I am not aware of a large holographic display so far.

<comment><USER14> That's a great explanation, thanks.

For the way you described it, to me, it doesn't sound that hard.

\- Create interference pattern

\- Record interference pattern

\- Shine ref light onto pattern to recover emitted light

If done perfectly would this yield a convincing hologram (what I might try to describe as "visual sense impression of real 3D object being present" ) ?

What are the major limitations in the current technology? You said it might be possible for high end screen, does that mean there is hologram tech out there? I have never seen any demonstrated.

Is there some sort of information processing problem that software could solve on the interference pattern? Or is this more a physics problem -- maybe we do not have the materials that can do the steps required?

<comment><USER15> The catch is, that the patterns have the resolution of the wavelength of light. You cannot take plain black and white film for this, you would need extremely high resolution film material. Agfa actually produced special film for holograms for a while, high contrast and very high resolution, but with a sensitivity like ISO 10. The resolution is far higher than normal LCD screens offer and that would be the main impediment. The math for calculating the interference patterns is almost trivial, but the scale is massive. Doing it in real-time would still require quite high-power setups, as you would have to calculate hundreds of rays per "pixel".

<comment><USER14> This is so interesting, thanks.

From my photog background, yep ISO 10 would be very tough to work with.

</comment></comment></comment></comment></comment></comment><comment><USER16> I've played around with some of Looking Glass's earlier prototypes and was impressed with the effect. It's one of those technologies like VR - <USER2> different in-person than seeing it in a video.

</comment><comment><USER17> It's not a hologram, of course. It's a stack of flat displays.

That's been tried before, in many ways. The first try was a vibrating mirror.[1] There's a flat rotating mirror system from FakeSpace.[2] It's not bad; you can walk around it. Move vertically, though, and the illusion breaks down. There's a scheme with gas ionized by intersecting laser beams. That's very low-rez, but truly volumetric.

Eventually, someone may come up with a real hologram system with decent resolution. A research group at MIT built one, but it was very low resolution and single-color. It's not impossible. But this isn't it.

[2] [https://www.youtube.com/watch?v=8gvPS1m40gw](https://www.youtube.com/watch?v=8gvPS1m40gw)

<comment><USER18> I'm pretty impressed by what FOVI3D [1] has been doing w/ their light field displays. Here's a recent interview from SID Display Week this year [2] that's refreshing because the CTO (in the interview) goes into some of the details of the challenges they face and isn't unrealistic about how hard it'll be to overcome them.

[1] [http://www.fovi3d.com/](http://www.fovi3d.com/)

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

</comment></comment><comment><AUTHOR> I've wanted to watch a Broadway play in my living room that was indistinguishable from being in the theater for close to thirty years. I'm excited because this is the closest technology that I've seen that could make this possible.

But I'm saddened if this is really the Apple II version of this technology because if it takes another forty years I probably won't live to see it. Always imagined that there would be sensors on the floor and ceiling, not watching it in a glass box but if that's how it has to be I'm OK with it.

<comment><USER19> In 40 years since Apple II, technology has doubled roughly 26 Moore's, or moresies.

The same shift now-a-days should take only a year and half (40 / 26), which is about how long it would take if you bought 64 Looking Glasses and built a DIY array, and used ML to construct a 3D video from a 2D one, a la [https://en.wikipedia.org/wiki/3D_reconstruction_from_multipl...](https://en.wikipedia.org/wiki/3D_reconstruction_from_multiple_images)

</comment></comment><comment><USER20> "The Looking Glass generates 45 distinct views of a three-dimensional scene"

Now that GPUs can reliably generate 60 FPS, this is the next step to push that technology. Because you'll need 45x60FPS for the same quality. And then you'll push the 45 number higher. (yes, I know the 60 isn't visible and has to do with control input).

<comment><USER21> I'm not sure I get your comment.

In my mind you can render $x pixels at 60fps. So the number of pixels for each distinct view is: $x / 45.

<comment><USER22> I think it's a little more complex than that. In addition to rasterizing a large number of pixels, the entire vertex pipeline has to run 45 times to generate 45 projections of the scene's geometry. You're correct though in that the rest of what happens in a frame (physics, animations & other state updates) do not have to run 45x.

<comment><USER23> This is an application where ray tracing for primary rays should shine. Instead of having to project thw scene 45 times you only need 45 sets of ray bundles, which is really efficient. The acceleration stuctures are shared between views. With a few pixel reordering hacks you can essentially generate all viewpoints as a single high resolution frame.

<comment><USER21> This is exactly what I was thinking about.

With raytracing you will almost get this for free.

</comment></comment></comment></comment></comment><comment><USER24> I really want this in an arcade cabinet for a streetfighter-esque game, or side scroller!

<comment><USER25> I couldn't stop thinking of [0] after reading your comment

[0] [https://en.wikipedia.org/wiki/Time_Traveler_(video_game)](https://en.wikipedia.org/wiki/Time_Traveler_\(video_game\))

</comment></comment><comment><USER26> My first inclination was to dismiss it as a gimmick, and really it is a gimmick, but it is so damn cool that I want one, especially if the Api's are relatively good.

<comment><USER27> Even if it's a bit of a gimmick in its current state, it's a great step towards something truly useful. Technology like this could be amazing in fields like medicine and education.

</comment></comment><comment><USER28> This sounds cool and all but it's not worthy of the name until you can flip windows over and write on the back of them.

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

</comment><comment><USER29> The kickstarter page for it: [https://www.kickstarter.com/projects/lookingglass/the- lookin...](https://www.kickstarter.com/projects/lookingglass/the-looking- glass-a-holographic-display-for-3d-cre)

</comment><comment><USER30> I wonder if it's a 4k screen generating 45 different views in alternating locations on the screen. Thus your new resolution is like 720x256.

From the videos they look higher res than that.

<comment><USER30> If you were smart you could encode multiple views into a single pixel to get a higher resolution, but then I figure that would limit your colour depth availability.

<comment><USER22> How would encoding multiple view into a single pixel work with a lenticular display? There needs to be a physical distance between each of the views.

<comment><USER31> This is not a lenticular display. It's a stack of 45 independent transparent TFTs.

</comment></comment></comment></comment><comment><USER32> This is only really valuable for multi-user scenarios. Just going with head tracking would likely be much easier to introduce, as you don't need specialized hardware (albeit it helps to improve quality). I remember this from a years and years old demo made on PlayStation I think, anyhow here are top results on this tech from Google:

[http://www.anxious- bored.com/blog/2018/2/25/theparallaxview-...](http://www.anxious- bored.com/blog/2018/2/25/theparallaxview-illusion-of-depth-by-3d-head- tracking-on-iphone-x) [https://www.wired.com/2011/05/3-d-ipad-head-tracking- app-now...](https://www.wired.com/2011/05/3-d-ipad-head-tracking-app-now-in- app-store/)

<comment><USER33> I can immediately imagine how several doctors could use such a display for e.g. a tomogram or stereo-microscope output during a surgery, or something like that.

It could also make a good in-store display.

</comment></comment><comment><USER34> A couple of years ago I worked with the 3d engine for an autostereoscopic display at Setred ([https://m.youtube.com/watch?v=zkwq_cQNLU8&feature=youtu.be](https://m.youtube.com/watch?v=zkwq_cQNLU8&feature=youtu.be)).

For us the DVI bandwidth was the limiting factor to deliver 40-50 views at reasonable framerates (besides raw GPU computing power), so our display actually had 8(!) DVI inputs. That also gave us a natural interface to add distributed rendering, supporting up to 8 GPUs for rendering. In most cases though, one monster PC with 3 GPUs and 5 DVIs was enough to produce interactive framerates.

</comment><comment><USER35> Looks like a lenticular display with some filtering and refraction to expand the perceived focal plane outwards.

It also looks like it works best with a black background.

[https://blog.lookingglassfactory.com/introducing-the- looking...](https://blog.lookingglassfactory.com/introducing-the-looking- glass-a-new-interactive-holographic-display-8733cdaea40e)

</comment><comment><USER36> Unfortunate name collision with Wendle's (level1techs) and crew's Looking Glass for sharing a frame buffer with a vm

<comment><USER37> It was also the name of a 3D desktop environment from Sun showed off in 2003. [https://en.wikipedia.org/wiki/Project_Looking_Glass](https://en.wikipedia.org/wiki/Project_Looking_Glass)

</comment></comment><comment><USER38> Seems to be a direct successor to the 'HoloPlayer One' dev kit, shown off last year by the same team - [https://www.youtube.com/watch?v=zJZj9Iy8Vck&feature=youtu.be](https://www.youtube.com/watch?v=zJZj9Iy8Vck&feature=youtu.be)

</comment><comment><USER39> Sounds like a cool idea but if you use the first name that comes to mind you're bound to not be the first one who thought of it. So there already are a ton of things called Looking Glass.

</comment><comment><USER40> this is similar to what I imagined when I first read the initial press release for Magic Leap (years ago now) albeit on a smaller scale. This looks far more promising for the entertainment industry than vr/ar goggles. My only nit is that they didn't use the dancing baby (from ~1998/99) for the demo video

<comment><USER41> all you had to do was ask [https://youtu.be/V4vVUXNotI0](https://youtu.be/V4vVUXNotI0)

<3

<comment><USER40> this is awesome :)

</comment></comment></comment><comment><USER42> This would be great for voxatron.

</comment><comment><USER43> Reminds me of Zebra Imaging. Does anyone know what happened to it?

<comment><USER44> FoVI3D.

</comment></comment><comment><USER45> Pretty cool, and probably will be useful in certain industries, but the title is extremely clickbait-y. The movie holograms that are listed don't live inside a glass box.</comment>


OpenFaaS on DigitalOcean Kubernetes Without Tiller - <AUTHOR> https://github.com/openfaas-incubator/install-doks/ <comment><USER2> I understand using server-less infra on aws, gcp or azure but what are the cost benefits of doing this on a self managed instance? You still have to provision a node or nodes and maintain a consistent uptime. Don't you also need to make sure that you have failover nodes etc?. Or maybe i am missing something

<comment><AUTHOR> I explore the differences between Serverless 1.0 and 2.0 in this video -> [https://www.youtube.com/watch?v=JvXm- oHi5Mg](https://www.youtube.com/watch?v=JvXm-oHi5Mg)</comment></comment>


Why you should use a BSD style license for your Open Source Project  - <AUTHOR> http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html <comment><USER2> _The GPL is a complex license so here are some rules of thumb when using the GPL:_

 _you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself._

I don't believe this is correct. You can sell the software.

<comment><USER3> Yes I think you can sell the software but you must make the source available. I'm not sure how this is different from charging for distribution, from a practical standpoint.

<comment><USER4> Make the source available to the purchaser, not necessarily public I think, right?

<comment><USER5> IANAL, but my understanding is that anyone who obtains a GPL'd binary is entitled to receive the source as well, from the source that provided them with the binary.

If you are careful with who you distribute the binary to, you could in theory keep the source sort of "secret", though I don't think it's a good general approach to GPL software.

<comment><USER6> And after receiving that "secret" source the customer can just upload it to its website and give away to the world for free.

</comment></comment></comment></comment></comment><comment><USER7> I believe that a BSD-style license is generally good (personally I even prefer the WTFPL). In an ideal world, we wouldn't need licenses because nobody would be stupid enough to make proprietary software[1] or otherwise try to restrict the user's freedoms. We'd pretty much have implicit CC-BY or -Zero for everything and be done with it.

For now, we need the GPL to _force_ change. BSD-style does not slowly force the ever-stuck-in-the-past industry to stop making inferior unfree[2] software. It will not prevent the same people from leeching off the efforts of the FLOSS community without giving anything in return (or even trying to sabotage our efforts with patents or similar nonsense).

[1] Yes, proprietary software is and always was an enormously stupid idea, probably up there with patents and copyright on the list of _Most Ridiculous Bullshit In Human History_.

[2] Free as in Speech.

<comment><USER8> Your comment is a good one. People are downvoting not because you aren't contributing, but because they disagree with you and are trying to silence your opinion. They forget that upvotes should be used to encourage discussion, and down votes used to remove comments that don't contribute. Hopefully, posting here will highlight your comment so others will take note.

<comment><USER9> It might also be that "in an ideal world nobody would be stupid enough," "an enormously stupid idea" and "most ridiculous bullshit in human history" aren't really arguments, and thus not really further the conversation.

<comment><USER8> That ignores the rest of the comment. So yes, if you ignore the comment as a whole, and choose to pick out specific parts of the comment, you can claim the entire comment worthless. But I disagree with that approach. With that approach, you've essentially become no better than someone who down votes someone for making a spelling mistake.

<comment><USER9> In my mind there's a huge difference between spelling _mistakes_, and _purposefully_ setting up a negative and insulting tone. There's no need to ignore the rest of the comment, when you think the overall language will do more harm than good.

I can accept that you find the language used to make a point not that important, but you should consider that not everyone might agree with that.

</comment></comment></comment></comment></comment><comment><USER10> What this essay (from 2008) fails to point out as an advantage is that the GPL requirements have forced many device drivers to be released as open source. And hardware support is critical for an operating system's viability.

If a project is releasing frequently and often, such as the X Windows system did in the early days, and people want the features in the new releases, the overhead in constantly forward porting private, proprietary enhancements (whether they be I18N support or driver support) tends to encourage people who might be tempted to keep code to themselves to contribute it back to the mainstream codebase. But if the project releases too slowly, or tries too hard to keep internal API backwards compatibility, it can cause people to fail to contribute their changes back, and then the open side of the project stagnates.

This is something that Charles Hannum, one of the NetBSD founders, eventually realized:

<http://onlamp.com/bsd/2006/09/14/netbsd_future.html>

In fact, he observed that a non-copyleft license tends to encourage fragmentation, and what do we see happening with Android? With a GPL license, things like Touchwiz would be have to be released as source code. (Of course, with a GPL license, there's a chance handset manufacturers would have been scared off, which is why apparently Andy Rubin very early chose Apache instead. Personally, I don't believe that to be true, given that Android did use the Linux kernel, which was GPL'ed. But, he was the startup founder, and he didn't want to take that chance with his baby, which is totally understandable.)

<comment><USER11> I have some libraries on github with MIT and GPL licenses, I will release a major software soon. I am still not certain which one is the best license for my purposes:

-I want everyone to freely use and distribute it, if they are contributing back their source code to the me or the community.

\- Except, I don't want my code to be used by patent-abusers/suers and their platforms (especially the patent war-lord Apple irritates me). I don't want them to suck my code like a black hole and avoid giving their code back to the community.

Would BSD/MIT or Apache or any variation of them help me in this case? Does GPL really help?

<comment><USER12> I don't think the BSD/MIT licenses will stop the patent-abusers from using your code because (as I understand them) they say "Here's the code, do whatever you want with it. Just keep the copyright notice on."

If you want to stop your code from being sucked into a black hole, a more "restrictive" license like the GPL would be your best bet. I would recommend the GPL because it's well-known and a lot of people have some idea of what the terms are, as opposed to something like the Apache license, which people might have to look up.

</comment></comment></comment><comment><USER13> _The GPL explicitly disallows revoking the license. It has occurred , however, that a company (Mattel) purchased a GPL copyright (cphack), revoked the entire copyright, went to court, and prevailed [1]_

This may not be entirely accurate.

Background: <http://tbtf.com/resource/cphack-history.html>

Original slashdot comment: [http://yro.slashdot.org/comments.pl?sid=4703&cid=1162803](http://yro.slashdot.org/comments.pl?sid=4703&cid=1162803)

Archive of one of the authors answering if cphack was GPL: [http://web.archive.org/web/200102042331/http://www.islandnet...](http://web.archive.org/web/200102042331/http://www.islandnet.com/~mskala/cpbfaq.html#gpl)

<comment><USER14> Sort of off topic but the authors response is a bit insane.

>"The origin of the confusion is that in one source file in cphack (note that cphack is just one of the four main items in the cp4break package), there's a comment saying "Released under the GPL". There is also a similar statement in the onscreen "About" box."

But previously: "The suggestion that it might have been GPL surprised Eddy and I just as much as it did anyone else"

Really? They think that the suggestion that a piece of software which says "Released under the GPL" in the source code and similar things in the about box is in fact released under the GPL is surprising?

Then it goes on: "I think that doesn't mean much because saying "the GPL" doesn't really identify "the GNU General Public License version 2" as specifically as a copyright notice should."

A very strange argument. Are they really claiming that the author purposely wrote that it was released under "the GPL", but was referring to a _different_ GPL (and never mentioned it)? Or is he trying to say that by keeping the language ambiguous, he can retroactively change the intention?

I'm not sure whether to interpret all this as ineptitude, stubbornness or deception.

Look, it is quite clear that they did not release it under the GPL, I'm not contesting that. But what they're claiming is quite ridiculous, and I feel like there must be more going than what they're writing.

</comment></comment><comment><USER15> According to some Apache is better: [http://stackoverflow.com/questions/40100/apache-licence- vs-b...](http://stackoverflow.com/questions/40100/apache-licence-vs-bsd-vs- mit)

I think it is too wordy though, and for 99% of projects, the MIT vs BSD vs Apache difference is not terribly important, so why weight your project down with a crazy big license?

I prefer MIT. It's a little clearer to me, and is claimed to be GNU GPL compatible.

<comment><USER16> Do _not_ use MIT (or BSD).

MIT has a killer failing: it was developed prior to the onset of software patents, and so has no patent release. This dooms it to being appropriate for only trivial projects. It doesn't matter if _you_ think there's nothing patentable in your code: others don't know that. If you want people to use your code in this day and age, a patent release is critically important.

Use Apache. Why be concerned about license length? Include the license once and then refer to it in your source copies. No big deal.

<comment><USER17> Can you explain what a "patent release" is?

<comment><USER18> BSD is basically just granting a copyright license. Apache grants you a right to use any patents the code may use.

Where I work contracts and grants prefers that we use BSD because they (as I understand it) think apache's patent grants are too broad.

Contracts and grants prefers we use Education Community License over apache <http://www.educause.edu/wiki/Educational+Community+License>

</comment></comment></comment></comment><comment><USER19> I typically choose MIT; I'd like to see a comparison of BSD vs MIT/Apache.

<comment><USER20> Please see <http://news.ycombinator.com/item?id=3402450>

</comment></comment><comment><USER21> If ( _if_ ) you want to go BSD or MIT, why don't you go with the simpler and more honest public domain, UNLICENSE [1] or CC0 instead?

Releasing software as UNLICENSE or CC0 has the same consequences of releasing it as BSD but it conveys a much stronger point.

[1] <http://unlicense.org> cache: [http://webcache.googleusercontent.com/search?q=cache:NQW6BVB...](http://webcache.googleusercontent.com/search?q=cache:NQW6BVBMQe4J:unlicense.org/+unlicense&cd=1&hl=en&ct=clnk&client=ubuntu)</comment>