Mythbusters RFID episode axed after 'pressure' from credit card firms - <AUTHOR> http://www.theregister.co.uk/2008/09/03/mythbusters_gagged/

<comment><USER2> Wouldn't it be cheaper to design reliable technology than to pay lawyers to strong-arm people into not talking about how unreliable it is?

<comment><USER3> I seriously doubt it. Lawyers can issue scary legal threats in their sleep. It's like yawning to them.

Threatening Mythbusters is probably a matter of 15 billable _minutes_ of legal time. Whereas building a secure RFID is hundreds or thousands of engineering hours.

Here's something that just occurred to me: One reason why actual security is more expensive than lawyers is that your security team is up against black-hat hackers who are willing to spend hundreds of hours working -- anonymously, in secret, and without pay -- to defeat you. Whereas your legal team is generally _not_ opposed by a black-hat legal team that is willing to spend hundreds of _pro bono_ legal hours to try to defeat you in court. Particularly because you can't challenge a legal threat while simultaneously remaining anonymous and working in secret.

<comment><USER2> _Whereas building a secure RFID is hundreds or thousands of engineering hours._

Building the insecure RFID is also hundreds or thousands of engineering hours. There is a lot of grunt work that was done regardless; designing the radios, designing the manufacturing process for the ID chips to be as cheap as possible, etc. Getting the crypto right isn't much on top of that.

</comment></comment></comment><comment><USER4> Interesting and unfortunate. I wish the Mythbusters didn't face this sort of pressure. Maybe they can still do the segment and then put it on their website. That is less predominate than their TV show.

With information like the defcon slides already readily available I'm surprised to see such pressure. I guess a segment on a cable TV show is more public than MIT student newspaper.

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

</comment><comment><USER5> Interesting that there's already a company making wallets to block RFID signals: <http://www.rfidblockr.com/>

<comment><USER6> There's also <http://difrwear.com>

<comment><USER7> I have one of these, and after a mystifying experience at airport security, I discovered that the RFID shielding is made of metal. No clue whether it actually works, though.

<comment><USER8> "REAL ID Act and RFID: Privacy and Legal Implications," a talk at The Last HOPE, tested one such wallet, and determined that while it's closed, it works --but the one they tried sprung open about an inch when placed on a table, and the rfid card inside was still readable that way.

<http://www.thelasthope.org/talks.html> [http://www.thelasthope.org/media/audio/16kbps/REAL_ID_Act_an...](http://www.thelasthope.org/media/audio/16kbps/REAL_ID_Act_and_RFID_Privacy_and_Legal_Implications.mp3)

</comment></comment></comment></comment><comment><USER9> Does anyone know an easy/inexpensive way to "clone" an RFID card? (My work only lets me have one card, but I want to keep one in my car and one in a my wallet since I need it both in the garage and in the building.)

I figure it shouldn't be too hard, it's just sending out a radio frequency, right?

</comment><comment><USER10> This particular "myth" has already been busted. Looks like El Reg is a running a bit behind the new of the day: <http://www.networkworld.com/community/node/32254>

<comment><USER11> So first Adam claims they were pressured into dropping the segment.

Then bad publicity ensues and what do you know: Adam now claims he had a brain fart and all the big corporations say there just giddy over the Mythbusters segment. They were bending over backwards to help!

Shucks, what a silly misunderstanding!

</comment></comment><comment><USER12> Why can't they just do the episode and keeping-in-line with past 'sensitive' topics like bomb making, skip over the part where they _actually_ tell you how to do it?

Or would it even be possible given how easy it is?

</comment><comment><USER13> Incredible! Hope they show it online soon. Would become an instant hit...

</comment><comment><USER14> Does this mean hackers will be RFID-Driving for my credit card info?

<comment><USER15> well, when its this easy it gets concerning... [http://tv.boingboing.net/2008/03/19/how-to-hack-an- rfide.htm...](http://tv.boingboing.net/2008/03/19/how-to-hack-an-rfide.html)</comment></comment>


Removal of Unsafe in Java 9 – A disaster in the making - <AUTHOR> http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/ <comment><USER2> The quote stops short, and for someone like me who doesn't follow Java very much, it feels like it's misquoting via omission:

"Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _ _/ now/__. It is still years until the end of public updates to JDK 8, so we have / _years_ /to work this out properly. But sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight....

"Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone."

The quoted engineer understands that people use it, claims that there's no immediate risk (since Java 8 will stay around), and very very strongly implies that there is _a plan_ to move from Unsafe to something better than Unsafe providing equivalent functionality in a stable way, and asks for help with that. Is this correct?

<comment><AUTHOR> The post directly links to the full quote. If the intention was to misquote that would not be the case.

> there is a plan to move from Unsafe to something better than Unsafe

It is this plan and the implications of it that the post is discussing

<comment><USER3> The _intention_ may not have been to misquote, but that is the effect that I saw. I had a similar reaction that geofft did when I read the whole email: it sounds like a reasonable effort to start the process of moving to something better than what is currently available. The submission here does not seem to take that into account.

</comment></comment></comment><comment><USER4> There's a lot of backlash here against the author with comments like:

"You used a sun.* package? You deserve to die in a fire as well!"

These comments look like they are coming from people who have never used Unsafe. First, Unsafe provides some immensely useful features to the Java ecosystem. Second, there is no alternative to Unsafe on the JVM. That includes JNI (native code integrated within the JVM).

So far, Oracle has stated their intent to remove Unsafe from Java 9. To all the users of Unsafe, Oracle is basically saying, "tell us your use cases for Unsafe, and if we decide they are valid we may try to create an alternative for you. If you're lucky, we may even ship that alternative in Java 9 or 10! Have a nice day!"

Many people, myself included, find this unacceptable. For instance, it looks like several groups are currently collaborating on a document discussing uses cases for Unsafe and whether alternative features satisfying those use cases are expected to appear in Java 9:

[https://docs.google.com/document/d/1GDm_cAxYInmoHMor- AkStzWv...](https://docs.google.com/document/d/1GDm_cAxYInmoHMor- AkStzWvwE9pw6tnz_CebJQxuUE/edit?pli=1)

As you can see, the majority of the cells in the column "Expected in Java 9" flat out say "no". There is a good reason people are up in arms about the removal of this API.

Personally, if I had to choose between Oracle keeping Unsafe and Oracle implementing Java 8 Lambdas, I would have picked Unsafe in a heartbeat. At the end of the day, Lambdas are mostly syntactic sugar, especially in their current implementation. Unsafe, on the other hand, actually empowers you to do something more.

<comment><USER5> Except that those of us on the Java community that follow Java development are fully aware of the 2014 survey, done by Oracle about how Unsafe is being used and what is our opinion on it.

Of course, many HNers that hate Java aren't aware of those discussions and post comments without knowing the full background.

<comment><USER6> What is the purpose of enforcing module boundaries? That appears to be why none of these internal classes will be accessible. Outside of a sandboxed environment, who cares what you do? Is it for some magic optimization? Or just some folks on a rampage? (The quote from the guy saying it needs to die, and I read the mailing list, well it seems to be baseless.)

<comment><USER5> One of the purposes of Jigsaw is offering a way to define a public API based on multiple jar files, similar to what OSGi does.

Similar in concept how Assembly Modules work in .NET, with friendly internals, which incidentally not many devs know about.

In Java's case a linker will be part of the SDK, so that only the Java code required for a given application will be deployed.

Since Oracle needed to clean up dependencies to implement Jigsaw, they are taking the opportunity to also remove most internal APIs, Unsafe being one of them.

They are also in the process of replacing JNI with something more programming friendly, P/Invoke style, but it will only come in Java 10.

There is also the reason that in a memory safe language every use of JNI and Unsafe is another security bug waiting to happen. If the compiler/runtime are able to offer safe APIs with similar performance, then those exploits can be avoided.

</comment></comment></comment></comment><comment><USER7> So the explanation is:

      Let me be blunt -- sun.misc.Unsafe must die in a fire.
      It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and
      start the path to righteousness

And what the author takes away is:

      This engineer hates the Unsafe class for no reason at all.

The reason the engineer hates it is that it's unsafe. Disagree with it, sure. But it's a reason, and it's a good reason (imho). I understand that it's commonly used by apps I use, but it's hard to keep reading after this kind of knee-jerk.

<comment><USER8> In addition, it's in the sun.misc package, if it's not in java.* or javax.* it is ripe for pruning, you'd think people would have learned by now to stop using internal classes since pretty much every JRE/JDK release known to mankind has changed them or removed them.

<comment><USER9> The problem with that, is unlike most of the other internal classes, there is _zero_ other way to do the things people are doing with unsafe without it.

It's not a matter of expedience, it's a matter of necessity.

<comment><USER10> Yes, removing Unsafe would make things like PowerMock and Robolectric impossible to (re)implement. So what? Those libraries never should have been possible, and we can live without them.

Languages need to be selective about what features they support, and Java was never intended to support things like mocking static methods, or creating instances without invoking any constructors.

<comment><USER9> Without the current unsafe package most performance sensitive applications (whether throughput, latency, or pause sensitive) will have no recourse to meet their current performance levels.

That will leave people to choose between staying on Java 8, worse (and often unacceptable) performance, and migrating to a different language.

At this point, there is a very good chance if your library/application is known for performance and exists on the JVM it uses unsafe and without a migration plan all of us who care about performance will likely have to move off the language.

<comment><USER10> With some effort, I'm sure the folks behind Cassandra, Hadoop etc. could achieve acceptable performance with allocateDirect(). It doesn't support explicit freeing, but you can always reuse buffers and write your code to allocate slices within them.

</comment></comment></comment></comment></comment></comment><comment><USER11> Entire companies exist around functionality provided in Unsafe. I don't see this going well if they remove it without providing access to the functionality it gives.

Java has plenty of problems, but backward compatibility over the years has been simply amazing. This would chip away at one of the few legitimate reasons to use Java in 2015.

<comment><USER2> Entire companies existed around DOS extenders and TSRs. Microsoft rearchitected and everyone is better off for it.

The argument needs to be that the use of Unsafe by these companies (or the projects listed on the blog post) both is good and has no alternatives, not that the use exists.

<comment><USER12> There should be some argument made that the use by these companies is causing trouble, as well. DOS had real identifiable reasons not to use it. The rhetoric used so far just has Unsafe upsetting some engineers for existing.

</comment></comment></comment><comment><USER13> Once again, The Platonic Engineer gazes hatefully at the gronky, ugly and awkward things that make things work in real life, rub his hands together and says...

"Burn it to the ground."

<comment><USER14> _Or_ you could actually stop for a second and find out _why_ your current model needs so many ugly and awkward workarounds and try to adjust it accordingly - which seems to be what Oracle is trying to do in the long term.

<comment><USER12> This is an odd one, though. I can not remember seeing/hearing any real issues with Unsafe. For the most part, people don't use it. There are a few that do, to ridiculous benefit. As things stand right now, without it, you _can not_ get anything close to the performance people are seeing with it.

So, what many of us are seeing here is someone is upset with basically the shape of an API. They have no evidence that I have seen of trouble caused by it. Only a desire that such things not exist. This feels almost puritanical in how it is being exercised. Which is just plain silly for a technical debate.

<comment><USER13> _puritanical_

I think the correct term is platonic: each of us has an Inner Platonic Engineer who cannot abide the ugliness of real world systems and insist on The Great Rewrite. A lot of progress relies on that engineer.

However, in large, functioning and mature software systems he becomes the enemy.

<comment><USER12> I question just how much progress relies on that engineer. Be honest here, there are no identified problems that are being solved here. Merely an undesirable in the system that is very effective at its job.

Progress, on other hand, advances something in the way of the problem space. Not merely rearranges something in the solution space.

</comment></comment></comment></comment></comment><comment><USER15> I just read an article that says in order to even use Unsafe, you have to use reflection to unwind the stack and go searching for a reference to the Unsafe instance, because the Java authors worked so hard to make it private. So it seems to me that they'd be well within their rights to remove the class.

Normally when you go to that level of epic hackery, you can't expect for official support or backwards compatibility. So the author of this article using scare tactics to keep that feature seems rather disingenuous.

<comment><USER16> Could you provide a link to the article? I'm not saying you're wrong (I'm not a Java guy) but that sounds convoluted.

<comment><USER17> This is how you get access to Unsafe:

      Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
      theUnsafe.setAccessible(true);
      Unsafe unsafe = (Unsafe) theUnsafe.get(null);

Reflection, but no stack unwinding.

</comment></comment></comment><comment><USER18> Chill.

There is no disaster in the making. Oracle is very much aware of the issue, and is actually already taking the very same steps suggested by the author. It has assembled a public working group that is coming up with a spec for a public "Unsafe" API[1] (that is safer than Unsafe).

 _In the meantime_ , use of Unsafe in Java 9 will be possible with a command- line flag in order to allow the working group more time to create the new API and for Unsafe consumers to migrate, and of course to allow existing libraries to run on Java 9.

[1]: [https://docs.google.com/document/d/1GDm_cAxYInmoHMor- AkStzWv...](https://docs.google.com/document/d/1GDm_cAxYInmoHMor- AkStzWvwE9pw6tnz_CebJQxuUE/edit)

<comment><USER19> The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

<comment><USER8> Backwards compatibility is only guaranteed for official Java SE and Java EE API's existing in the java.* and javax.* packages, anything in sun. _, com.sun._ , etc is internal to the JDK and has no such guarantees.

Every time you hear of an application that only works on a specific release of the JRE you can know for sure it's because they use undocumented internal API's — keep in mind this not only impacts compatibility with other releases of OpenJDK/Oracle JDK, but the sun.* API's are not typically part of third- party JVM's like JRockit or the IBM JVM.

Stop using internal API's and then bitching when Oracle makes changes to them, you only have yourself to blame.

<comment><USER20> This is exactly the same line Microsoft took when they broke poorly architected applications with the new (and much better!) security model in Vista. "You're the one who wrote an app that needlessly requires root privileges, you have only yourself to blame."

It... didn't go well.

<comment><USER6> And MS did a lot of work to detect such apps and make them work OK. What's the real argument against Unsafe? People are upset that it exists? Really?

</comment></comment></comment></comment></comment><comment><USER21> Many people seem to be upset with Oracle, but I think they should be upset with the vendors who ship applications/libraries that depend on the "sun.*" packages.

Oracle (then Sun) have since _1998_ strongly discouraged the use of them: [https://web.archive.org/web/19980215011039/http://java.sun.c...](https://web.archive.org/web/19980215011039/http://java.sun.com/products/jdk/faq/faq- sun-packages.html)

<comment><USER22> Fine, but why isn't the argument: "This then needs to be standardised in a Java.* package and correctly documented."

Unsafe is useful, and is evident by how popular it is. Heck even Sun/Oracle must agree because they created it for their own internal usage. So why not just go ahead and standardise it.

</comment></comment><comment><USER23> What is "Unsafe?" Is it unsafe, as its name implies? If it is unsafe, why to so many programs use it?

<comment><USER24> It's part of the OpenJDK/Oracle VM implementation, not an official part of the Java standard library. It allows for all sorts of fun stuff like native compare and swap operations (used for concurrent collections iirc), object allocation without calling the constructor, accessing blocks of memory directly without object references, and other things. The reason it's called unsafe is because it allows developers to bypass a lot of the safety guarantees that java is supposed to provide as a memory managed language. But it's useful for getting more performance out of the VM.

There's currently an effort underway to push through a variety of Java enhancement proposals that would add a lot of the unsafe functionality to the official standard library. This would enshrine the unsafe functionality as official, remove access to some of the more dangerous and less useful parts of unsafe, and would also mean that the functionality would be properly documented, which it is currently not.

<comment><USER25> Thanks for the thorough explanation - you summarised the issue well, as well as explaining the impact and flow on effects.

I have to say, I agree with the engineer.. I'm cringing just knowing this sort of practice is seen as acceptable, and it reinforces my distaste for Java. If you have to resort to insecure practices to achieve performance, there's something wrong with the framework.

<comment><USER26> Reading this thread as C programmer has me scratching my head.

 _Of course_ you have to resort to low-level functionality to achieve performance. That's how computers work. We can't all live in fuzzy wuzzy land.

Surely Unsafe is safer than writing the whole thing in C and using JNI?

<comment><USER27> Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.

<comment><USER28> Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.

<comment><USER27> Sure. Unsafe in terms of program correctness. By that measure, new Thread() is unsafe.

But that's not a reasonable definition of "unsafe". This could crash the JVM is a reasonable definition. And fences and ordered instructions cannot.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> This seems a bit hyperbolic. Especially the comparison of Python 2 to Python 3. Its not like you could run Python 2 and Python 3 under the same interpreter by passing a flag.

</comment><comment><USER30> Why on Earth is it a big deal that you need to pass a flag to the JVM at startup?

I understand that backwards compatibility is valued, but if I went to my CTO and said "we're gonna drop Java 9 in production, and we're not gonna test beforehand"...the reaction would not be pretty.

</comment><comment><USER31> Document it, make it public. It's very much needed!

</comment><comment><USER32> Compression in my library is 3x faster with unsafe. I think it is lesser evil then native code integration.

</comment><comment><USER33> At least he didn't name the article "Unsafe considered harmful."

</comment><comment><USER14> > _Oracle plans to remove sun.misc.Unsafe in Java 9. This is an absolute > disaster in the making and has the potential to completely destroy the > entire ecosystem around Java._

You know your language has a problem if the entire ecosystem threatens to fall apart as soon as you actually try to enforce the language's conceptual model and try to make use of the guarantees it provides.

<comment><USER34> With the caveat that you need to believe in the hyperbole of a chicken running around with its head cut off.

</comment></comment><comment><USER35> Ok moving past the rhetoric of don't use internal classes, there is a value to sun.misc.Unsafe. It has been well known by Oracle for some time that it has to go away right.

Realise that those of us that do use it, are fully aware that it is a hack, and that we should be doing cleaner things. However know that those cleaner things _dont exist_; and that you, Dear application developer might not quite realise some of the shadow puppetry in making your favourite library work, please lay off the bile.

As others have said, this blog post stops short, the full quote is part of a very long and ongoing process to rid ourselves of Unsafe, replacing its majors usages with new API's.

This is a process Oracle started last year after the previous sun.reflect.Reflection.getCalleeClass mess. Yes, it no one should have been using an internal class. This method did not go away; it was made only available to the JVM internals, locked out from end users. The upshot of this was that, with no sane alternative, suddenly logging became between 2x and 100x more expensive where class names become involved. The JDK team somewhat back peddled on this change, and we are stuck here in a strange limbo land.

Was it right of Oracle to do this? Absolutely, everyone who goes down the internal package route is fully aware that these are open-state secrets, sure we all know them, but we should not be talking about them. Support for these damn things requires version to version checking, hideous reflection hacks and being prepared to read a lot of JVM source code for when bugs occur.

In light of all of this, and being the general level of awesome the JDK folks are they started a very direct community outreach to remove safely Unsafe. Last year they publicly asked people on the mailing list, and privately via email to do a survey ([http://mail.openjdk.java.net/pipermail/core-libs- dev/2014-Ja...](http://mail.openjdk.java.net/pipermail/core-libs- dev/2014-January/024650.html)) on usages of Unsafe. I know this because I got an email from Paul Sandoz asking me to comment on Unsafe abusages. Out of previous thinking from the JDK folks, as well as from the aforementioned survey, we have a bunch of JEP's for improving things regarding Unsafe.

Where things have gone slightly sideways is that we have, currently no unified working group to deal with these changes. What this document is, is a proposal to make a working group, focused on getting the right changes into the JVM. In the same ways as Project Jigsaw is for modularising the JVM (and is indirectly responsible for removing Unsafe), or the MLVM project handled making the VM better support other languages.

Unsafe is dead, long live Unsafe! I fully expect that we will achieve the right changes in during Java 9 to allow those of us that need to break the rules, to do it in a supported fashion. I am _looking_ forward to the day when I can do setMemory or getAndSetInt via a supported API, and not one where I have to know the words Unsafe.theUnsafe. The above is a storm in a teacup, its open-source democracy at work.

</comment><comment><USER36> What about shipping sun.misc.Unsafe as 3rd party package? Is there anything in it that can't be done as through JNI?

<comment><USER28> It'd be unusably slow. "sun.misc.Unsafe" compiles in the instruction stream. JNI implementation would need to go through a complicated calling mechanism. I think it'd be up to 100x slower.

<comment><USER36> At least in OpenJDK it is in fact implemented as a JNI package, so it is already going through the JNI calling convention: [http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/s...](http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/misc/Unsafe.java)

<comment><USER28> I think these are a strong hint they're not truly JNI:

Line 61:

      * <p> Most methods in this class are very low-level, and correspond to a
      * small number of hardware instructions (on typical machines).  Compilers
      * are encouraged to optimize these methods accordingly.

Line 90:

      /// peek and poke operations
      /// (compilers should optimize these to memory ops)

</comment></comment></comment></comment><comment><USER37> Why libraries need Unsafe, after all? What problems does it solve for them?

<comment><USER9> It's almost entirely about performance. Unsafe allows you access to concurrent intrinsics as well as memory layout functions.

It's true that it is widely used, but the people that use it also understood the ramifications of using it. If you were trying to make jvm agnostic code you didn't use it. If you were trying to make code that could run on a variety of jvm versions, you didn't use it.

A lot of what people use it for is being rolled into documented/standard libraries and this is just the migration pains coming out.

<comment><USER37> Why those concurrent intrinsics are not available with "safe" code? They are not compatible with Java Memory Model? They are not implemented at some platforms? What's so unsafe about concurrent primitives? There is API in java.util.concurrent.atomic, for example.

I understand that Unsafe is used for direct access to memory, but why this direct access is needed? May be there are other ways to solve those problems.

<comment><USER38> AFAIK there aren't other ways to get the performance required to be competitive in the financial space. People that are using these libraries don't want to use undocumented, Unsafe code. However, their hands are forced given the races they are competing in. They could switch to C++ but that's not really a great option for firms that have java code bases going back 10+ years.

Plus, personally, and for a lot of others, the jvm plus a dash of sun.misc.Unsafe, is a lot better than going over to C++.

More concretely, Here are two sets of trading libraries that use unsafe for direct memory access: [https://github.com/real-logic/simple-binary- encoding](https://github.com/real-logic/simple-binary-encoding) [https://github.com/OpenHFT](https://github.com/OpenHFT) (various libraries in here use it, once you drink the Unsafe Kool-aid it's hard to turn back from the performance benefits you obtain).

If Oracle just rips off the Unsafe band-aid without a replacement, the business decision for these firms is still sound. They will just stay on 8 and start making migration plans (likely to the C++ bandwagon).

However, It sounds like Oracle plans to give a sane alternative which is good and what everyone using Unsafe would prefer (along with deprecating it the meantime to give them some time to adapt).

One real world example: The CME (Chicago Mercantile Exchange) reworked the entire way they distributed market data (v3 of their Market Data Protocol) to mirror the cutting edge in performance oriented serialization libraries (e.g. Cap'n Proto). They also commissioned an Open Source library for parsing that data (real-logic SBE), it uses unsafe to approach the performance of C++ code.

<comment><USER9> Exactly. Though I'd add that its not just the financial space that is doing this for performance. Lots of people that are trying to scale high throughput systems use unsafe for similar reasons:

Akka for instance uses it: [https://github.com/akka/akka/blob/0de9f0ff40fc5e43540df58718...](https://github.com/akka/akka/blob/0de9f0ff40fc5e43540df58718ecb1818df35673/akka- actor/src/main/java/akka/dispatch/AbstractBoundedNodeQueue.java)

</comment></comment></comment></comment></comment><comment><USER39> This is related and unrelated and maybe even meta to some degree:

There are a couple of companies that are guilty of using their free software update mechanism to try and trick people into installing crap they don't want (and might even mess-up their systems): Sun and Adobe.

I almost happened to me last night as I updated Flash on a test system and some bullshit anti-virus crap-ware was going to be installed because I was moving fast and neglected to un-check the check-box on the site. I was able to stop the install process and start over. No harm done.

These companies need public shaming to stop using this bullshit method to make a few more bucks. Are they so hard-up that they need to trick users to install crap to make money? I sure hope not.

Sun, Adobe, please STOP trying to trick users into installing crap-ware they were not looking for in the first place.

<comment><USER9> You understand of course that Sun has been out of business for a very long time right?

<comment><USER39> Sorry, brain fart, I meant Oracle

</comment></comment></comment><comment><USER40> I read this article yesterday and I really dislike how it is worded. The "this engineer" has a name, Donald Smith, this is what he said:

"If you're using Unsafe, this is the year to explain where the API is broken and get it straight.... Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone."

It reads like a request to have a discussion on Unsafe, to talk about it and find solutions. Unfortunately, I don't see anyone pointing out why Unsafe should be kept around on that thread ([http://mail.openjdk.java.net/pipermail/openjfx- dev/2015-Apri...](http://mail.openjdk.java.net/pipermail/openjfx- dev/2015-April/017028.html)).

And this quote from Oracle shows an effort to do things right:

[http://mail.openjdk.java.net/pipermail/discuss/2013-October/...](http://mail.openjdk.java.net/pipermail/discuss/2013-October/003162.html) "This is definitely something we plan to propose for SE 9. I expect to see a JEP from the current maintainers of sun.misc.Unsafe..."

This ([http://blog.codefx.org/java/dev/how-java-9-and-project- jigsa...](http://blog.codefx.org/java/dev/how-java-9-and-project-jigsaw-may- break-your-code/)) seems like a more balanced article on the situation.

"So far we focused on the problematic aspects of Project Jigsaw. But that should not divert from the exciting and – I think – very positive nature of the planned changes. After reading the documents, I am impressed with the scope and potential of this upcoming Java release. While it is likely not as groundbreaking for individual developers as Java 8, it is even more so for everyone involved in building and deploying – especially of large monolithic projects." near future. (This is far too small to require a whole JSR.)"

</comment><comment><USER41> Literraly meme language

</comment><comment><USER42> Still using Java in 2015 – A disaster in the making

<comment><USER34> What would a MS fanboy suggest as an alternative?</comment></comment>


Ask HN: Incorporating in Ontario - Advice? Recommendations? Experience? - <AUTHOR>

I'm working on a hosted billing app (in a nutshell) that looks like it might see the light of day.  Since the application deals with actual cashdollars, I'm thinking a limited corporation makes sense (looks more professional, can't be personally sued, etc.).  I've trolled around the internet looking for advice on how to do this, if I should do this, that kind of thing, but it is precious scarce.
Actually, most of the "advice" out there comes from companies offering the service, which doesn't fill me with tremendous confidence.
HN, have any of you incorporated a small business in Ontario or Canada?  Why?  What issues and pitfalls did you experience?  Can I trust these companies whose services cost half as much as the others?  Can I trust these companies whose services cost twice as much as the others?
Bonus question: I plan on dealing with Americans as well as Canadians.  What challenges does this pose to a Canadian business? <comment><USER2> I've incorporated a number of companies in BC and the process has been simple enough to do on a self-serve basis. After a quick search, I found the following site for incorporation in Ontario, <http://is.gd/eDJP> \- it looks the same as what I went through in BC. The big thing you'll have to deal with in Canada is the GST as you'll likely have to remit on a quarterly basis, so you'll need to watch your cashflow carefully.

Dealing with American customers is largely a matter of choosing whether to accept payments in US dollars directly or do a currency conversion with each payment before it hits your bank. I'd recommend caution with this one as some banks will hit you with a currency conversion fee and give you a crappy rate, so a good payment provider may help in this area.

PM me if you have any other questions.</comment>


Skaz - <AUTHOR> https://en.wikipedia.org/wiki/Skaz <comment><USER2> At first I thought that the link is about rabies (the horrible viral disease), because this is what the word "skaz" means in Ukrainian ([https://uk.wikipedia.org/wiki/%D0%A1%D0%BA%D0%B0%D0%B7](https://uk.wikipedia.org/wiki/%D0%A1%D0%BA%D0%B0%D0%B7)).

<comment><AUTHOR> Heh, good to know. I discovered this _skaz_ concept while reading about Gogol's _A Terrible Vengeance_.

[https://en.wikipedia.org/wiki/A_Terrible_Vengeance](https://en.wikipedia.org/wiki/A_Terrible_Vengeance)</comment></comment>


Ask HN: What do you look for in a DNS provider? - <AUTHOR>

I've been becoming increasingly interested in DNS hosting, and DNS-providers.
Specifically I think that it would be interesting to provide an API to interface with DNS.  I've been thinking of accepting POSTed JSON which would ultimately end up inside a git history.
Your client would make requests, these would be applied, and if you wanted you could clone the git repository to see your history.
Alternatively I could imagine git pushes triggering DNS updates.
But beyond these rough ideas I'd wonder what features others might enjoy, desire, or need? <comment><USER2> Greetings from Bytemark, we are contemplating much the same thing right now.

We have our old content DNS system ([http://www.bytemark.co.uk/support/technical_documents/dnsc](http://www.bytemark.co.uk/support/technical_documents/dnsc)) which just lets you upload tinydns data via rsync (since 2003). Based on tinydns, so it's been completely rock-solid stable but missing more and more features as time went on (IPv6 is in, but DNSSSEC is a long way off).

Our challenge is to add / augment this to allow sane control panel access for people that want t ouse it and not proliferate databases or logins. We have a rough idea of what to do, as maybe you do too, though we will likely have to make people choose between "old" and new type logins

But the idea will remain the same -upload a nice simple text file of records, becomes live straight away. tinydns syntax can certainly be transformed from other formats pretty easily...

What're you working on then?

<comment><AUTHOR> I suspect you could solve your problem ("provide web-interface to DNS") reasonably easily without moving away from tinydns. If you used a sneaky second access mechanism (HTTP, say) to get the hosted/live records from your upload-host you could wrap that into a form with fields and select-boxes for record-types (since tinydns is so trivial to parse).

(If you were to just expose the actual tinydns file then the whole thing is trivial of course, but user-error is more likely.)

Once you have some user-interface then applying changes goes in the same direction, process the form submission, then put back the modified records to the central location, and trigger a rebuild of the binary records.

\--

My current prototype allows a complete zone-file to be POSTed to a HTTP service, and then written out to a tinydns file _or_ uploaded to Amazon's route53 service.

Similarly you can query a zone and retrieve back an array of records. Each record has an ID, a type ("A", "NS", "AAAA", "MX") along with the associated data.

The point where I've started to take a step back and think things over is the case of adding/editing a single record. Because each record has an ID you can trivially say /zone/example.com/delete/$id or POST to apply an update.

But allowing operations to be applied to a single record complicates things somewhat, and that was the point where I started considering using git as the storage back-end. That would allow historical tracking, and interesting things to be done - especially if you exposed the actual store too.</comment></comment>


Ask HN: Best option to host an MVP within budget? - <AUTHOR> I have built an MVP, it's a social network, with specific features that target a niche group of user (atm, I just want to see if this works and then make it more general in case it is actually useful the way I think it is).<p>Problem is I have no experience in hosting and I am not sure what are the things I should be aware of when choosing any particular option. <comment><USER2> If you just want An Answer, then use Heroku. Throw it up there and see if there's traction before you worry about hosting. Once you find traction, there's a lot more to consider, but for now you're talking about minimal traffic and you can deal with this later.

At that point, you start getting into breakdowns of the various providers out there, and--most importantly--what they offer you in terms of failure resilience. If you know nothing else about software deployment, know that _everything can fail_ (whether in a data center or in AWS or whatever) and that correctly and quickly responding to those failure cases is the core of a modern operations/platform effort.

At the point where a product works and has traction, I'll usually evaluate AWS or GCE (and tend to go with AWS because the tooling, publicly available knowledge, and my personal experience lean that way), because I like having easy answers for "but what if it breaks?" and "how do I protect myself?" in a way that neither less featureful/lower-quality services like either DigitalOcean or a bare-metal provider like OVH can offer. But people with different budgets and risk tolerances can reasonably disagree.

<comment><AUTHOR> Well, besides an answer I am also looking to learn. The opinion I hear about Heroku, and also my primary concern, is it can become quite expensive to run, especially since I have to use two dynos - one for backend API and one for serving the frontend app. Compared to that will starting with AWS or GCE free tier be a better option? I am ready to deal with a complexity if that means I can squeeze a bit more value out of stuff since budget is a bit too tight atm.

<comment><USER2> If it gets expensive, you have a Good Problem on your hands.

I don't think trying to learn AWS's stuff should gate you on seeing if your product gets traction. What's stopping you from launching on something simple and easy like Heroku _while_ you learn AWS or GCE?

<comment><AUTHOR> Ah yeah I didn't think it that way. Thanks.

<comment><USER2> No problem. Feel free to email me directly if you'd like; this is a large part of my business.

<comment><AUTHOR> Thanks, I will keep that in mind. :)

</comment></comment></comment></comment></comment></comment><comment><USER3> for me - either firebase or AWS. depends on what I am trying to build. Good luck!</comment>


Israeli Moon Lander Poised for Lunar Touchdown Thursday - <AUTHOR> https://www.space.com/israel-moon-lander-lunar-touchdown-final-approach.html <comment><USER2> So... Does a Beresheet on the moon, or in the woods?

<comment><USER3> Oy vey</comment></comment>


How Apple's Developer Conference Grew Too Big for Its Own Developers - <AUTHOR> http://www.wired.com/gadgetlab/2013/04/why-wwdc-is-too-big/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wired%2Findex+%28Wired%3A+Top+Stories%29 <comment><USER2> TBH, the same thing happened with Google I/O. It became a rush for tickets for free devices instead of a true developer-focused event.

<comment><USER3> The WWDC purchase process was _much_ less painful than the Google I/O process. I didn't get tickets for either, but at least the Apple process was done within minutes. Google took me nearly an hour of watching a progress spinner and retrying before it finally denied me. Kudos to Apple for how well their servers responded and not wasting my time.

<comment><USER4> I agree. I furiously kept trying for 45 minutes for IO and finally failed to acquire one. It was frustrating. Apple on the other hand closed it in 2 mins but reaching out after the failed attempt was nice serendipity.

</comment></comment></comment><comment><USER5> This is an interesting problem - I have a YouTube focused event called Playlist Live and we have a similar problem.

We have three primary tiers of attendees:

      - Popular creators who perform, speak and collaborate
      - Fans of the top tier who want to take it in and get autographs
      - Up-and-coming creators who want to grow

The event isn't selling out in a day and our sell-out this year was only 4200 tickets, but it's increasingly difficult to offer a meaningful experience to all three groups, especially with fans outnumbering the other groups.

This year we expanded our "Insight" track which gives up-and-comers a chance to work with the most popular creators one-on-one and it was great! The problem is that fans are willing to pay more than up-and-comers just to get _access_ to creators, so charging more for Insight doesn't seem to separate things.

<comment><USER6> Break the fan/performance thing out into a separate event entirely? Playlist Live/Playlist Creator?

Some fans would undoubtedly still buy tickets for the 'creator' event, but I've got to imagine their willingness to pay is mostly a function of "no other good way" to ever get access to the creators they enjoy. If there _was_ another way, a way that was geared to their interests (performances vs powerpoint) I'd imagine the numbers of fans willing to sit through a talk on SEO for an autograph would dwindle.

I mean, how many _fans_ are trying to scam press passes to E3 anymore, now that there are things like PAX?

</comment></comment><comment><USER7> At this point, I wish they would break-up the conference into iOS and OS X or have some paid engineering support where we can facetime / screen share with an engineer.

<comment><USER8> It seems kind of weird that they (I mean Apple specifically) have not started doing online conferences yet. We are talking bleeding-edge development, are we not?

<comment><USER9> Apple makes videos of the sessions available through iTunes to registered developers after the conference.

The main reasons to go to the conference are to network and be a part of the spectacle.

<comment><USER7> > The main reasons to go to the conference are to network and be a part of the > spectacle.

No, the main reason is the Apple engineers in the labs

<comment><USER9> Yeah that's true, too.

</comment></comment></comment></comment></comment><comment><USER10> Honestly, if you have a limited number of something, and people know that it sold out last time in an hour or two, and then you announce the selling time in advance, all it takes is _slightly_ more demand than capacity, and you will have a huge rush at the selling time.

</comment><comment><USER11> Apple developers, Apple developers, Apple developers, Apple developers!

Steve Ballmer must be jumping for joy right now /s

</comment><comment><USER12> I absolutely despise the term "developer". It insinuates that we, hackers, write code because we want to "develop," not because it's a fun hobby or because we want to find practical solutions to everyday problems.

As pg put it, "'Engineer' is a kind of bureaucratic term that companies use to refer to a programmer. 'Developer' is a slightly less bureaucratic term that companies use to refer to a programmer."

<comment><USER8> If pg has a problem with the term 'Engineer' then he's got a problem with its meaning (which stems from 'problem solving' essentially). I'd rather be called an engineer (an ingenious person) than a 'hacker' (whatever this means).

<comment><USER13> Could part of the problem be that adding an "engineer" to a title is also used as a pseudo-euphemism for low ranked workers? e.g. maintenance engineer = janitor

<comment><USER8> Well, yes, if "maintenance enginner" means janitor then obviously there is a bureaucratic problem.</comment></comment></comment></comment>


Escaping The Walled Garden of Enterprise Analytics Using R and Python - <AUTHOR> http://www.marginhound.com/escaping-the-walled-garden-of-enterprise-analytics-using-r-and-python-for-data-analysis/

<comment><USER2> While we are on the topic, the much anticipated Python for Data Analysis (<http://shop.oreilly.com/product/0636920023784.do>) is supposed to come out this month. I'm wondering if anyone here has tried the early release and what are your thoughts?</comment>


Generator (yield keyword) support in CoffeeScript for Node.js - <AUTHOR> http://almostobsolete.net/coffeescript-generators.html

<comment><USER2> Lovely work, and it looks like it wasn't too difficult to add:

[https://github.com/jashkenas/coffee- script/pull/3078/files](https://github.com/jashkenas/coffee- script/pull/3078/files)

If anyone wants to chime in on the pull request itself, input is welcome -- particularly about how to address the conflict with the usual "compiles to JavaScript that runs anywhere" ethos of CoffeeScript. If we're going to start moving past that, "yield" is a fine place to start.

<comment><USER3> There are going to be some bigger issues if you start targeting ES6, like the inconsistency between for/of in ES6 vs. CoffeeScript, differences in destructuring, semantic inconsistencies in classes, etc.

I'd be very interested to see a proposal for how to deal with that moving forward for CoffeeScript. Will CoffeeScript:

1) ignore new ES6 features that have syntactic overlap with existing CoffeeScript features

2) leave the existing syntax alone and create new syntax that targets the ES6 syntax (for/of means CoffeeScript for/of, while for/inside means ES6 for/of)

3) break backwards compatibility and release a CoffeeScript 2 that targets ES6 and doesn't use syntax that could conflict in the future

There may be another option, but I can't think of it. Knowing exactly which of these options CoffeeScript will take will give me a better understanding of the long-term viability of CoffeeScript.

<comment><USER2>
        > Knowing exactly which of these options CoffeeScript will take
        > will give me a better understanding of the long-term viability
        > of CoffeeScript.

Mmm, nothing like the whiff of uncertainty on a summer evening ;) For starters, you needn't worry -- CoffeeScript already being a heavily forked open-source project, I'm sure there will be versions (whether Coco, Live, Iced, Gorilla, or perhaps a cutely named CoffeES6cript) that track each of the options you've listed.

But you asked about my proposal. I'm most interested in targeting the useful subset of JavaScript that runs across the popular JS platforms at any given moment -- not what may or may not exist in the future, but lives currently as a spec; and also not features that actually exist, but aren't essential (read, harmful, error-prone, nasty), like getters and setters, or E4X (in my opinion, natch).

So in general, what I'd like to see mainline CoffeeScript do, is adopt useful ES6, ES7, and ES8 features, as soon as they land in enough platforms/browsers to be widely useful (yield may be at this point already, or very soon), and to continue to try and find a pleasing minimalist syntax for writing and reading them. If this means taking the ES* syntax wholesale, that's fine. If it means minting a new (and hopefully, but arguably, nicer) syntax, that's fine too. And if it means breaking backwards compatibility, that's also alright, as the compiled lowest-common-denominator JS output will still be perfectly compatible with the new stuff.

<comment><USER4> Thankfully E4X doesn't actually exist anymore (as of FF 21) :)

</comment></comment></comment></comment><comment><USER5> Alternatively you could use fibers. We've been using them together with Common Node ([https://github.com/olegp/common-node](https://github.com/olegp/common- node)) at [https://starthq.com](https://starthq.com) with great success - running smoothly on an EC2 micro instance with 300+ concurrent users on site.

<comment><USER6> I have been quite interested in using fibres. I have concerns about compatibility with existing libraries, stability etc.

Could you point to some documentation/discussion/blogs/anything that addresses these concerns and provides decent examples of use?

<comment><USER5> Here's a talk I gave on the topic: [http://vimeo.com/32507674](http://vimeo.com/32507674) and here are the slides: [http://www.slideshare.net/olegp/js- everywhere-2011](http://www.slideshare.net/olegp/js-everywhere-2011)

Feel free to message me on Twitter (@olegpodsechin) and I'd be happy to answer any questions you have.

</comment></comment></comment><comment><USER7> Great idea. Generators are one of the features that still seperate coffeescript from python, in terms of productivity/elegance.

Still missing is a syntax to consume these generators, like in "for a in b" or "yield from"

<comment><AUTHOR> Definitely agree with need for iteration syntax and yieldfrom keyword. The iteration syntax will probably have be something different than "for a in b" because that's already used for array-like iteration and adding another case would slow existing code down (all of which wouldn't be using it of course). For yieldfrom the code it needs to generate is something like this:

        var generator = g1(), result = {}, send;
        while(!result.done) {
            result = generator.send(send);
            send = yield result.value;
        }

<comment><USER7> I would suggest "for a from b". If that only uses .next and .send, it might work with class instances too, like the iterator protocol in Python.

<comment><AUTHOR> I've found one problem with that syntax: people use variables named "from" quite a lot in code already (including all over the coffeescript source)

</comment></comment></comment></comment><comment><USER8> Does this work when compiling code to run on the browser?

If not, how could you modify the Coffeescript compiler to make that happen? (Preferably without requiring browser makers to make any changes.)

<comment><AUTHOR> It's possible using two techniques called continuation passing transform and trampolines[1]. The downside is that the produced code would be a bit ugly and one of coffeescript's selling points has always been that it produces sensible code.

[1]: [http://en.m.wikipedia.org/wiki/Trampoline_(computing)](http://en.m.wikipedia.org/wiki/Trampoline_\(computing\))

</comment></comment><comment><USER3> Does this mean that the mere presence of the word `yield` turns a function into a generator? Is there any way to build a yield-less generator (say, a noop generator for an API that requires a generator)?

<comment><AUTHOR> Yes it does.

If you did want a generator that didn't yield anything I guess you could write:

        myEmptyGen = ->
          yield if false

Which is pretty ugly, but it's not something I've needed to do often with generators (in Python at least)

</comment></comment><comment><AUTHOR> I just added yieldfrom (like yield* in ES6, includes the output of one generator in that of another) support in a separate branch:

[https://github.com/almost/coffee- script/commit/67f2347685b45...](https://github.com/almost/coffee- script/commit/67f2347685b450eb5ae0a1d0ead73c5e6dce0273)</comment>


Ask HN: Tools for (re)learning Java - <AUTHOR>

Hello HN-
I have a pretty solid programming background, but I have been working as a network engineer for the past 7 years. In some ways building and maintaining the network requires a totally different mindset, and I feel like I have forgotten quite a bit of what I once knew.
I'm particularly interested in Java because I'm particularly interested in Android development.
Are there any favorite tools / books out there that would make a good refresher course? The problem I have of course isn't a lack of information, but an overload of information - a quick Google search will give me far more than I need and it's difficult to figure out what not to read and where to start.
Thanks all <comment><USER3> Learn about Design Patterns, they will force you to really use Java's features such as Interfaces and Abstract Classes, accessibility modifiers (public, private, protected) and others. That is the method I use when tutoring individuals in similar situations as yours that want to get back into Java specifically.

I recommend the Head First Design Patterns book if you're not turned off by the less-than serious nature of it. I really did not like the book at first glance, but after actually working through some of it as instructed I enjoyed it and really developed a solid understanding. Simple examples like Vending Machines and Washers really helped me, I still use them in my head when thinking about problems. Design Patterns are not always the best solution and forcing them on problems can make things worse, but as far as teaching Java I really recommend it. [http://www.amazon.com/First-Design-Patterns-Elisabeth- Freema...](http://www.amazon.com/First-Design-Patterns-Elisabeth- Freeman/dp/0596007124)

I also recommend learning about Test Driven Development as previously suggested, we use JUnit4 to teach our undergrads at my university. There are also other methods of testing besides TDD, but I feel it was the easiest to help students.

<comment><USER4> TDD is a very valuable practice. We've used it for years. Please see this resource that I have found useful: [http://alm.parasoft.com/bid/52034/How-Can- Test-Driven-Develo...](http://alm.parasoft.com/bid/52034/How-Can-Test-Driven- Development-TDD-Be-Automated)

</comment></comment><comment><USER5> One of the biggest changes in the past 7 years is the rise in popularity of Unit Testing.

It light of that, I recommend picking up Robert C. Martin's clean code - <USER2> it isn't specifically about the Java language (though lots of the examples are in Java) it will refresh you on how to write good Object Oriented systems that are easily testable.

After years of reading procedural Java code, its clear that syntax is not enough...

</comment><comment><USER6> If you are interested in Android development, probably you should do some hand-ons. It is just not possible for anyone to put everything you come across in their development into print/words.

The Android Developers website's Dev Guide is fairly comprehensive, you can almost get started in your app right away.

</comment><comment><USER7> Assuming you know the basics of the language, Effective Java by Joshua Bloch is very good: <http://www.amazon.com/gp/product/0321356683/>

</comment><comment><AUTHOR> Totally agree with shortlived and iworkforthem, in fact that's what I've been doing for several months now. Increasingly though, I find myself thinking "you know I'll bet there is an easier way to do this if I had a deeper understanding of the language," and that's what I'm looking for.

Thanks everyone for your comments, they've been immensely helpful and insightful.

</comment><comment><USER8> _I'm particularly interested in Java because I'm particularly interested in Android development._

Skip the books and jump straight into some tutorials for Android dev and build a few simple apps for your phone. You can go back to reference material as needed.

</comment><comment><AUTHOR> Thank you both, looking at both of those now.</comment>


Ask HN: What is something you always wanted to program? - <AUTHOR>

<comment><USER2> A roguelike. I get started and then one of the following seems to happen:

\- I become disillusioned with the whole project and walk away

\- I get distracted by another technology

\- Laziness sets in and I spend my time playing roguelikes instead of programming one.

<comment><USER3> Are you tempted by 7 day roguelikes, or do they fall to the same problems?

<comment><USER2> I actually followed the last 7DRL fairly closely and I'm definitely tempted by them. I've considered trying to give the next one a shot.

I think having a deadline and the goal of creating a smaller, playable roguelike really appeals to me.

</comment></comment></comment><comment><USER4> Stuff that's close to the hardware:

\- Embedded software to control any kind of interesting device in real time (industrial machinery, vehicles, robots, disk drives, etc.).

\- Operating system kernel code.

I had a little bit of experience doing this in school (took some hardware classes; hacked a Unix device driver), but that was a long time ago and I haven't done anything like that since then.

<comment><USER5> Grab a raspberry pi 2 starter kit. I just ordered one for $84.99 shipped from Amazon.

The damn thing runs on Linux now. I'm about to have a lot of fun with some raspberry pi projects!

</comment></comment><comment><USER6> A global illumination raytracer. A subdivision surface modeller. A surround audio mixer.

</comment><comment><USER7> AI software that finds a pattern in popular songs and produces hits. i will probably never write it but it may give someone an idea.

</comment><comment><USER8> Particle physics. Simulate air movement, the weather, chemical reactions etc.</comment>


Using Capabilities for access control with Spire.io and other cap-based systems - <AUTHOR> http://www.spire.io/posts/clever-with-capabilities.html

<comment><AUTHOR> This is a follow-up to <http://www.spire.io/posts/web-capabilities.html> \- My only regret is not calling the server that holds the capabilities the "mothership", in hopes that this can be someday called the Mothership Pattern.</comment>


Peloton S-1 - <AUTHOR> https://www.sec.gov/Archives/edgar/data/1639825/000119312519230923/d738839ds1.htm <comment><USER3> Under the risks section:

"We derive a significant majority of our revenue from sales of our Bike and a decline in sales of our Bike would negatively affect our future revenue and operating results;"

What many people don't know is that you can access all their classes using your own exercise bike and their apps, paying a little over 1/4 of the normal monthly subscription fee. The limitations of this approach is that you don't get to participate in the leader-board gamification of your workout, and your bike won't have the integrated sensors to tie your output back into their app, but for a fraction of the price of both the bike and the service, it's a good way to either test out their service to determine whether it's something you're into, or to permanantly utilize most of their product at a fraction of the cost.

<comment><USER4> I have it and I like how the whole package works together -- in particular, how certain teachers are very careful to show how to keep good form for your back etc.

When I see a guy on the same exact machine as me, showing bad form like a slightly curved back or whatever with the heels, and then correcting to the proper form, referencing the same bike, on a giant Android tablet in front of me, that is very helpful.

And this whole thing is sitting right there in my room as a ready to go thing whenever -- taking mini-obstacles out of the way like going to the gym, studying proper form without someone having to ape it for me, etc. are admittedly pretty trivial things -- for a lazy sack like me, having all these done and together has made a difference.

"It just works."

(Edited for grammar.)

<comment><USER5> "You can do everything an iPod can do with a _____ for a fraction of the price."

I can't even remember what the competitors were, because none of that matters if it's not effortless to use.

<comment><USER4> I was a naysayer about smartphones/iPhones -- why would I want all these things globbed into one thing instead of my beautiful modular setup now?

Here, too, I thought -- it's an Android tablet bolted to an exercise bike.

Not saying that either the Peloton or the iPhone were epoch-shattering brilliances. Just noting that, as you suggest, sometimes putting together things that used to be separate is, well, a good and useful thing.

<comment><USER6> It's all about the experience. Same as all early Apple "i" products... the same tech was already out there, Apple just polished it way better than everybody else.

</comment></comment></comment></comment></comment><comment><USER7> This thread on the pretentiousness of the peleton ads (which clearly work for them) is a bit of fun:

[https://mobile.twitter.com/clueheywood/status/10896997623312...](https://mobile.twitter.com/clueheywood/status/1089699762331217920?lang=en)

</comment><comment><USER8> Nice unit economics: Our Connected Fitness Subscriber Lifetime Value for fiscal 2017, fiscal 2018, and fiscal 2019, was $267.1 million, $604.4 million, and $1,053.8 million, respectively, or $3,433, $4,015, and $3,593 per Connected Fitness Subscriber, respectively.

As we expand our content offering, develop new interactive software features, and grow our community of Members, we believe we can maintain a low Average Net Monthly Connected Fitness Churn, resulting in a high Connected Fitness Subscriber Lifetime Value. In addition, with the growth of our Connected Fitness Subscriber base over time, we expect to improve our Subscription Contribution Margin as we scale our fixed content production costs.

Net Customer Acquisition Cost (profit) can be calculated as Adjusted Sales and Marketing Expense (which excludes depreciation and amortization expense and stock-based compensation expense) less Adjusted Connected Fitness Product Gross Profit (which excludes depreciation and amortization expense and stock- based compensation expense). Our Net Customer Acquisition Costs (profit) for fiscal 2017, fiscal 2018, and fiscal 2019, was $14.2 million, $(4.9) million, and $1.6 million, respectively, or $183, $(33), and $5 per Connected Fitness Subscriber added, respectively. We believe we will continue to drive rapid payback and efficiencies in Net Customer Acquisition Costs (profit) by further leveraging sales and marketing investments as a result of heightened brand awareness and growing word-of-mouth referrals. Changes in Connected Fitness Product margins or sales and marketing expenses may result in an inability to fully offset our customer acquisition costs.

<comment><USER9> What's amazing is that they get people to pay _more_ than they would - <USER2> would even think of paying - for a streaming service like Netflix or Hulu, but their content creation costs are obviously a fraction of what it take to produce even one show on those platforms.

<comment><USER10> What's really crazy is that the cost of 1 month of a Peloton subscription is less than the cost of 2 spinning classes in a real-world spin studio.

If you spin enough, you actually do save money with a Peloton. $40/month + $2000/bike vs $30/class (in LA/NY/SF) results in a breakeven point of roughly 4 months if you spin every weekday, which many spin aficionados do.

<comment><USER11> What's really crazy to me is how expensive those spin classes are, how many people go to them, how little they pay the stay, and how all those companies still lose a ton of money!

<comment><USER12> How much do instructors get per class? $25?

<comment><USER13> Yep.

</comment></comment></comment></comment></comment></comment><comment><USER14> It really makes we wonder how we could be on the verge of a recession when companies like this become successful? Maybe I'm just too cheap to ever buy something like this but it feels like a mass marketed luxury good that requires a decent level of consumer confidence to have succeeded.

<comment><USER15> On the surface this is basically the Juicero of fitness equipment. If you want a good piece of workout equipment, buy a Concept2 erg. If you want a bike, you can get a carbon-frame bike for the same amount of money and then just get a trainer for it. Ostensibly there is zero reason for this to exist.

The one argument in its favor is that youth sports are usually very heavily subsidized by masters sports. So if you weren't on a varsity sports team in high school or college and didn't learn how to work out properly, then it's easily 5x more expensive to do so as an adult. So maybe there is some value in having someone to teach you how to do basic cardio.

<comment><USER10> This is nothing like Juicero.

Peloton addresses two real needs in the exercise marketplace: home-based classes, and high-quality exercise machines. It simply combined both into one product.

There is huge demand for the former, especially from white-collar workers with high demands on their free time, and a a fair amount of demand for the latter.

At $2000, a Peloton bike is $1000 to $2000 cheaper than the cheapest carbon- frame bike I could find on Google, and more than $3000 cheaper than a racing or tri-bike. For indoor use, you'd also need a trainer, adding another $600-$2000 to the cost (depending on the trainer you get).

Generally, the people I know that have carbon fiber frames also have several other bikes, each for a different niche, and the Peloton would slot right into the indoor spin use case.

<comment><USER15> Bikes are usually 20 - 35% off when the next years models come out, which e.g. is this week for Cannondale. You can easily get a carbon Synapse for less than 2K from almost any bike shop that sells them, or even REI. It's an endurance bike, but for doing low cardio you wouldn't necessarily want a race bike anyway.

<comment><USER10> _You can easily get a carbon Synapse for less than 2K from almost any bike shop that sells them, or even REI._

True, REI has the Synapse on sale for $1700 right now not including delivery. Once you add a trainer of the equivalent functionality as the Peloton trainer, you're looking at $2500 spent. Add in a screen, and you're looking at $2700 for a small screen or $3500 for a similar-size screen as on the Peloton.

<comment><USER16> But when you decide to join your local cycling club or even get outside for a spin, you are good to go with the Cannondale ;) ... not so much with your stationary Peloton. Also, the highest priced CycleOps trainer on REI's site right now is $420. So $2120 with trainer...as for the screen, most people buying carbon road bikes and trainers probably already have a working flat- screen to spare.

</comment></comment></comment></comment></comment></comment><comment><USER17> They seem to have been careful to take some lessons from the soul cycle S-1 and roadshow, [https://www.sec.gov/Archives/edgar/data/1644874/000119312515...](https://www.sec.gov/Archives/edgar/data/1644874/000119312515270469/d844646ds1.htm). That one was eventually pulled.

The subscription part is interesting, they did 4x the sales in bikes -connected fitness products- as 2 years ago (719/183), and cogs is ~4x (410/113). But subscription revs are up 5x (181/35) and cogs on that are only up 3x (100/3).

</comment><comment><USER3> The Peloton "How I Built This" episode is well worth a listen for anyone interested in the company.

[https://www.npr.org/2019/04/05/710439824/live-episode- peloto...](https://www.npr.org/2019/04/05/710439824/live-episode-peloton-john- foley)

<comment><USER18> Good call.

At 33:30, John Foley and Guy Raz start talking about the Kickstarter and how it didn't achieve its goals.

At 35:00, they talk about the the initial pricing for the bike being breakeven ($1,200) and how that didn't work. The feedback was "at $1,200 [the bike] 'seems cheap', 'it sounds cheap.' And so, we said, well, let's increase the price...."

You can listen to more of the podcast, unpack this, and analyze what the reveals about that the demographics of the customers with whom they've connected so far. Without any intent to be critical, the HN readers who think the bike is too expensive have the opposite reaction to the people who became customers.

I suspect the average Peloton customer has more money than time.

</comment></comment><comment><USER19> Wow I was heavily skeptical of Peloton until these numbers. I would have thought who would pay a few thousand dollars for a machine and then an additional $39 a month. But 92% of all customers who have purchased the equipment are still subscribers at the end of June 2019, that is extremely impressive.

<comment><USER20> Do you spin, and have you ridden a Peloton? Nearly every person I know who likes spin enough to go to spin studios buys a Peloton after test riding one. They did that good of job nailing and improving the spin studio experience.

Their risk is that spin studios are a luxury item over and above gym memberships and will be the first things cut in a recession.

</comment></comment><comment><USER21> There are some funny things in the Risk Factors section:

"We have identified material weaknesses in our internal control over financial reporting and if our remediation of such material weaknesses is not effective, or if we fail to develop and maintain an effective system of disclosure controls and internal control over financial reporting, our ability to produce timely and accurate financial statements or comply with applicable laws and regulations could be impaired."

There are also three long subsections about music licensing (edit: and music- related legal proceedings mentioned in multiple places).

<comment><USER3> "There are also three long subsections about music licensing."

I'm a customer. I've noticed that some of their old classes are no longer available, presumably due to music licensing issues.

<comment><USER22> Yup: [https://www.cbsnews.com/news/peloton-lawsuit-fitness- company...](https://www.cbsnews.com/news/peloton-lawsuit-fitness-company-sued- for-stealing-music/)

</comment></comment></comment><comment><USER23> I'm a mega bear on this. It's Juicero 2.0

The bike's only have a lifetime of a couple years and the experience isn't that great. The promise of software upgrades only take it so far until planned obsolescence kicks in.

This is just creating a fleet of useless metal that will have software vulnerabilities up the wazoo in a decades time.

<comment><USER24> I'm genuinely curious:

> The bike's only have a lifetime of a couple years

What's your source for this figure?

> and the experience isn't that great.

According to whom? You? Or the legions of apparently very satisfied subscribers?

</comment></comment><comment><USER25> I use a Keiser M3i with the Peloton app on an iPad. It's great. The Peloton app records heart rate and cadence via Bluetooth. I run the Keiser app on my phone to record additional metrics, such as power. Much better solution than being tied to a proprietary Peloton bike while still enjoying the benefits of the always-fresh Peloton classes.

Mike biggest complaint is the music change. Way too many knock-off versions of songs by "studio musicians" instead of the original artists... [https://www.engadget.com/2019/04/25/peloton-users-music- comp...](https://www.engadget.com/2019/04/25/peloton-users-music-complaints- licensing-lawsuit/)

<comment><USER26> Have you ridden the Peloton bike? Wondering it compares to the Keiser, which I like quite a bit.

</comment></comment><comment><USER27> I have been waiting for essentially this, but with racing games onscreen. Does anyone know if they allow, or plan on allowing third party apps and games?

I can see a game like Mario Kart being very popular.

<comment><USER28> That would be amazing... I've never tried a spin class but if I knew that I could play Mario Kart or Burnout or something like that on the bike... what an idea!

</comment></comment><comment><USER29> I will invest in this company because I love the product and so does everyone I know who uses it.

But the general and administrative costs in 2019 seem ridiculously high. The tender offer last year only makes up 1/3 of that increase. What's up with that?

</comment><comment><USER30> Am I doing correct math that they spent about $1200 per new subscription? $324m sales & marketing / (511k - 246k) new members in 2019 = ~$1222.

$915000000 revenue / 1800 full-time employees = ~$500k revenue per employee, though.

</comment><comment><USER31> I was surprised to see how low the gross margin is on their subscription business, it has only recently broken above 50%. The cost of revenue for their subscription business includes licensing the music in their workouts, and the costs to operate their NYC and London studio.

I was also surprised to see the margins on the bike itself are about the same as on the subscription business. They have room to lower the price of the bikes to get more customers hooked on that sweet, sweet recurring subscription revenue.

</comment><comment><USER32> These guys are following the Uber business model. Burn as much cash as possible up front to generate buzz and big numbers for the IPO, worry about profitability later. The problem is that, as Uber has shown, profitability never comes. Peloton will limp around for a few years after the executives have all taken their sweet IPO money home and become a shell of what it once was. Too bad.

</comment><comment><USER33> 85million cumulative workouts as of June 2019... really low actual usage relative to revenue.

<comment><USER12> Do they follow the same model as a big chain gym? Hope people get the subscription, but never use it?

<comment><USER34> I don't think their marginal costs increase the same way as a gym. People using their bikes more just means somewhat higher load on their servers for users using the workouts (and I suppose more demand for new content). There is a cost, but I'm guessing it's much lower than the cost of the added wear on gym equipment and the need for extra staff and other costs associated with a gym.

</comment></comment></comment><comment><USER35> Is it normal for the "20-votes-per-share" class B stock to "convert automatically upon ... (ii) ten years from the closing of this offering"?

<comment><USER17> Earlier of three events with a hard cap at 10 years, not really. Thats a bit of peace offering to investors re: dual(+) share classes and control.

</comment></comment><comment><USER36> A figure in the "Opportunity" section has two large inverted cones showing total addressable market.

The lie factor[0] of the "Peloton's Current Markets" chart is 4.2. The lie factor of the "U.S. Only" chart is 5.8.

[0]: [https://infovis-wiki.net/wiki/Lie_Factor](https://infovis- wiki.net/wiki/Lie_Factor)

</comment><comment><USER37> I just wrote this post to summarize my views on the S-1. Focused more on the skeptical side, since I know there will be plenty of euphoria to counter- balance it:

[https://medium.com/@mattthurmond/a-skeptical-look-at- peloton...](https://medium.com/@mattthurmond/a-skeptical-look-at- pelotons-s-1-3f0a5d67ddb3)

</comment><comment><USER33> Churn rate is better than I would have guessed.

Losses going up 4x year over year to $200m on $1b in revenue is pretty insane though.

<comment><USER38> When you spend that much on the bike you'd better get your money's worth.

<comment><USER33> I bought nearly new equipment for my home gym for 1/5th of the retail value on Craigslist... tons of sellers out there.

<comment><USER39> Is it true that the best deals are in February, after people realize they won't use the equipment they bought in January for New Year's resolutions?

</comment></comment></comment></comment><comment><USER40> I wish you didn't have to wait a week to buy options for newly listed stocks, I want to write calls and buy puts on this ticker

Once consumer credit dries up, this company goes _poof_

</comment><comment><USER41> Given how expensive a bike is, I imagine their market being even smaller than the apple iPhone market and a subscription-based health system can arguably be as important to someone as an iPhone, but it doesn't really have that "i want that" shine that iPhone does. I imagine they'll see a lot of growth short term and taper off really soon maybe after 6 years.

<comment><USER42> Have you seen how expensive a gym membership is?

<comment><USER43> Under $30 a month for a 24 hour fitness membership via Costco with zero initial cost ;)

"Nice" gyms like Equinox are of course significantly more. It's important to segment the gym market into different tiers and niches, and figure out what the market size is for each. Same as for direct equipment sales like this.

To your point, though, I suspect the people who would pony up for a Peloton are the same people who would splurge for a $100/month gym membership instead of a 24 hour, Planet Fitness, or local hole in the wall gym.

<comment><USER10> Spin classes cost $30/month at spin studios. The people going to those classes are Peloton's target market, not the people content to spin at the local 24 hour fitness.

<comment><USER43> What city are you in? Here in Portland, spin classes are more than double that. I think Peloton's market overlap is a combination of people who would sign up for Spin classes at a dedicated studio, people who would sign up for Spin classes at a nice gym that gives them as part of a membership, and people who think cycling is a good workout and have high disposable income, but no desire to join a real class or gym of any kind.

It's obviously not for people like me who would happily buy a set of used free weights for a few hundred bucks if I had a garage or basement.

</comment></comment></comment></comment></comment><comment><USER44> if you need all the S-1 tables in one excel file (free but collects an email; FD: I work there) [https://get.sentieo.com/peloton- ipo/](https://get.sentieo.com/peloton-ipo/)

</comment><comment><USER45> Does anyone know if fitness benefit reimbursement would apply to these?

</comment><comment><USER46> TLDR; "We have incurred operating losses each year since our inception in 2012, including net losses of $(71.1) million, $(47.9) million, and $(195.6) million for fiscal 2017, 2018, and 2019, respectively, and expect to continue to incur net losses for the foreseeable future..."

<comment><USER47> Aha, this is what the cool kids call growth hacking! Exponential growth in net loss YoY. I've been a complete idiot trying to grow the curve in the other direction.

<comment><USER48> This is typical of most "growth" companies. Yeah, the revenue doubles.... but so do the losses.

</comment></comment></comment><comment><USER49> Can't help but start to think that everyone is cashing out before the impending recession.

<comment><USER50> IPO takes months and months of effort and planning. It is not as short term as you seem to imply.

<comment><USER51> Also looks like they are already profitable, and growing like crazy.

EDIT: my bad interpreting the loss format, they are not profitable.

<comment><USER52> > We have incurred operating losses in the past, expect to incur operating > losses in the future, and may not achieve or maintain profitability in the > future

> We have incurred operating losses each year since our inception in 2012, > including net losses of $(71.1) million, $(47.9) million, and $(195.6) > million for fiscal 2017, 2018, and 2019, respectively, and expect to > continue to incur net losses for the foreseeable future.

They've never been profitable.

<comment><USER51> My mistake, I interpreted the $(...) values as being negative losses.

</comment></comment></comment></comment></comment><comment><USER53> another company i could have gotten in on on the ground floor for some stock options but was too pragmatic to think they'd be successful

<comment><USER54> Pragmatic in what way?</comment></comment>


Commodore KERNAL History - <AUTHOR> http://www.pagetable.com/?p=926 <comment><USER2> It was common practice for most advanced C64 software to avoid most kernal routines, replacing disk i/o with custom fast loaders, screen output with custom rendering, and system interrupts with their own. This was almost always true for games, and sometimes true for applications, for example, the C64 didn't have a UART, and high modem baudrates sometimes lead to bit errors, so some fast terminal programs wrote their own.

This article is amazing though, because it revealed stuff I never knew, even after years of C64 coding. For example, I didn't know about the VECTOR calls to save/restore the vector table. I almost always started out my code doing this myself, e.g. SEI/LDA $0314/STA SAVED_IRQ/.../CLI.

I remember writing a BBS in assembly language for the C64 and using $FFD2, but I had to hook the kernel to implement multiple window support, so that when the SYSOP was doing stuff, he had an overlay window and output could be directed at different screens. The design of the kernal gave you just enough flexibility to do what was needed.

20 years later, and I still feel like I had more joy developing on the C64 than any modern system. The tools were primitive, the kernal was primitive, the constraints were great, but everything was much more predictable. You knew exactly how long something took, you knew what resources you had to work with, and it was possible for a single person to completely understand the whole system down to even the hardware layer.

And man oh man, the Action Replay cartridge. Immediate feedback from changes, and global freezing of a system and inspection of all system state _including WRITE ONLY_ registers.

<comment><USER3> Back in those days I wrote my own assembler for the C64 (and later the C128). Probably my single greatest moment of joy as a programmer was when it successfully assembled its own source code.

</comment></comment><comment><USER4> I think the software designers of the Commodore 8-bit personal computers deserve more recognition than they have. The hardware independent jump table is something not often seen in the 70's with severely constrained memory machines.

Of course, IBM had the 360 and CP/M had a similar idea at its core but, still, this is pretty sophisticated for those early years.

<comment><USER5> Isn't the whole point of the post that it wasn't a hardware independent jump table?

<comment><USER6> Well, most of the post, but some of the later models were designed to be forward compatible.

</comment></comment></comment><comment><USER7> Neat, as a VIC-20 owner back in the day I wasn't really aware of this.

I remember my parents getting me into a week long computer camp when I was 8 or 9 (below the minimum age and required a special interview) and all the computers they had in the lab were PETs -- and how excited I was to be able to record the BASIC programs I worked on and bring them home to run on my brand new VIC-20.

That said, Commodore was not nearly as good at Apple and Atari at keeping backward compatibility on their 65xx 8-bits, and they did something weird with the Plus/4 type machines, which bizarrely had almost no compatibility at all. You could easily run software from the late 70s on a mid/late 80s Apple IIgs, or on an Atari XE.

<comment><USER8> Yeah, Commodore's business model seemed to be designing incompatible 6502 computers and throwing them against the wall to see which ones stuck. There was like a dozen of them, and only 2 or 3 really mattered. When they were riding high on the Commodore 64, they released the incompatible Plus/4 to great hype, and the market reaction was WTF, these guys are totally clueless.

Commodore mainly sold on price, which was great for people who wanted an accessible computer. But growing up, I knew a lot of people with zero interest in computers who had a Commodore stuffed in their closet. There was a thing "Computers are the future, so you're a bad parent if you don't buy one for your child." And the Commodore was the cheapest thing at K-Mart....

So in these discussions, people always say Commodore had bad management, but that was also the public perception at the time. They seemed shady. Meanwhile, Apple was expensive, but they were seen as really solid company. And not to mention IBM.

<comment><USER9> Commodore frequently made (bad) decisions based on cutting parts cost. Plus/4 was just plain cheaper to build than the C64, and they thought they could charge the same price for it...so, it looked great on paper to the bean counters. They just fundamentally misunderstood the market and the success of the C64 within that market and repeated that misunderstanding over and over again.

C64 was successful not just because it was cheap, but because it provided a lot of value. It was a powerful computer for the price. The Plus/4 couldn't provide C64 compatibility without including the C64 chipset, and those were the features that made C64 expensive (comparatively) to build. The Commodore 16 was an even bigger joke; at that point, _nobody_ was shipping such an underpowered machine.

Similarly, they put a lot of resources into things like the CDTV, which was a five-year-old computer in a home stereo style chassis. At that point, cheap VGA and high-quality sound cards were already available. It was anemic, but because it was old tech, it was cheap to make. Just more cashing in on their previous successes by making lower value versions of good products.

The C64 wasn't seen as the "cheap" product, IMHO, it was seen as a good value. Where Commodore screwed up later was failing to deliver good value, while keeping the cheap price. The 64 was a revolution. And, the Amiga was, too, but on a different set of metrics (cheap and good value were not really Amiga characteristics, in a world with cheap PC compatibles with VGA and 16-bit sound flooding the market...the Amiga 500 was probably the last great value product Commodore ever shipped, and that's reflected in the relative success of the product).

<comment><USER10> >the Amiga 500 was probably the last great value product Commodore ever shipped

Agreed, the Amiga 1200 was too little too late, I remember when I first tried programming on the PC coming from Amiga, segmented memory and 16 colors, I thought no way am I ever gonna use this!

Next time I gave it a try there were dos extenders giving you a flat memory model as well as vga 256 color mode-x where each byte corresponded to a pixel on screen, which performed so much faster than the Amiga's blitter with bitplanes that it was suddenly very clear that it was all over for Commodore.

<comment><USER11> You probably mean mode 13h - 320x200x256 colour. Mode X is actually similar in some ways to the Amiga's bitplanes because it uses a planar memory arrangement. This is actually quite useful for fast drawing of pixels because in Mode X for example you can draw four pixels at once with one write.

<comment><USER12> > Mode X is actually similar in some ways to the Amiga's bitplanes because it > uses a planar memory arrangement.

Mode X does not separate bitplanes. With Mode X, you don't need to write to 8 memory addresses to completely change a single pixel. (In the worst case, you needed one slow "out" and one fast "mov" instruction, if you wanted _completely random_ access. However, no one ever did this, because you could simply draw every 4th pixel once for each bank, requiring just 3 (or 4) bank switches per frame.)

Mode X is _nothing_ like Amiga bitplanes.

Also in Mode X each byte does correspond to a pixel on screen, it's just banked in 4 banks.

Mode X it interleaves framebuffer pixels into four banks. Top-left pixel at coordinates 0, 0 is in bank 0, next right is in bank 1, etc. until pixel at coordinates 4, 0 is again in bank 0.

You could also write same pixel to all banks at once (or in any combination).

On Amiga, bitplanes worked very differently. They were basically layered "2-color" bitmaps, one bit corresponds always to one pixel. 1 to 6 bitplanes (or 1-8 for AGA) could be combined to form 2^1 to 2^8 colors. So for example for 256-color display, you actually had to set _eight_ bitplane pointers.

This type of bitplane arrangement made setting a single pixel very slow. You had to rotate desired color value bits and mask & set corresponding pixel in _8_ different memory addresses...

<comment><USER11> Ah right, I think I was confusing it with EGA, where you have one bitplane for each colour component.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Calling the commodore's firmware a kernel is a bit of a stretch in my opinion because it did not schedule anything. The 6502 had no MMU and therefore no virtual memory or running of more than one app.

One clever idea I learned when I was a kid tinkering with C64 was how the ROM resided at the same memory address as RAM. By toggling a bit, you can switch between the two. Applications back in the day would toggle this bit really fast to give the capability of having an assembly language program running in the background while your basic program interacted with it.

I learned this and it stuck with me over the years. C-Net BBS by a company called Perspective Software, if I recall correctly, did just this.

Cool article!

<comment><USER14> He is not referring to the firmware as "kernel" ... See [https://en.wikipedia.org/wiki/KERNAL](https://en.wikipedia.org/wiki/KERNAL) :

        "KERNAL is Commodore's name for the ROM-resident
        operating system core in its 8-bit home computers;
        from the original PET of 1977, followed by the
        extended but strongly related versions used in its
        successors: the VIC-20, Commodore 64, Plus/4, C16,
        and C128."

<comment><USER13> Too bad that's not stated in the article. The way the article reads seems to imply a kernel OS.

<comment><USER14> > "The way the article reads seems to imply a kernel OS."

I don't think so. Here are some instances of the word KERNAL in the article:

        * ... jump table at the end of the KERNAL ROM ...

        * ... The system ROM ("KERNAL") was now 4 KB

        * ... making the KERNAL and the editor merely
        a device driver package.

        *  ... jump table in the KERNAL ROM for interfacing
        with it

        * ... these are the KERNAL calls used by BASIC ...

        * The following eight KERNAL routines ...

        * ... it calls out to these KERNAL functions ...

        * ... these KERNAL calls have to parse the BASIC
        arguments ...

        * These 6 KERNAL calls are actually BASIC command
        extensions, ...</comment></comment></comment></comment>


A videogame that powers quantum entanglement experiments - <AUTHOR> https://www.wired.com/story/this-random-video-game-powers-quantum-entanglement-experiments/ <comment><USER2> Obtaining randomness through this process sounds very strange to me. Is there not a better way to get randomness? Random.org claims to use athmospheric noise to generate "true" randomness. Without knowing much of the game it is normally considered impossible for people to generate true random sequences, as they would underrepresent extreme outliers (like the sequence 0000) and overrepresent patterns that "look" random (like 1010).

<comment><USER3> Under non-competitive circumstances this is true. However people are actually very adept at generating nearly perfectly random choices in competitive games. There is evolutionary pressure to produce randomness, because if you are predictable in a game, you will lose.

Citation: [https://www.sciencedirect.com/science/article/pii/S089360800...](https://www.sciencedirect.com/science/article/pii/S0893608006001638)

</comment></comment><comment><USER4> The _Wired_ article doesn't make clear the reason for using humans rather than a mechanical generator of randomness, hence several commenters here are, understandably, questioning this. Why not use a chaotic physical system instead? Because that would involve assumptions about the behavior of the chaotic system. A way to eliminate these assumptions is to add "free will".

Original paper:

[https://www.nature.com/articles/s41586-018-0085-3](https://www.nature.com/articles/s41586-018-0085-3)

</comment><comment><USER5> Aren't humans a pretty terrible source of randomness? And _especially_ if they're being asked to solve some kind of problem and their inputs are being used as "random"? I would expect the results to be nigh useless especially if you're trying to find some kind of correlation between different users' inputs.

I don't claim to fully grok quantum physics but what little I do know of it says this is not related to it.</comment>


When Apple f's up - 12 Apple products that failed - <AUTHOR> http://www.networkworld.com/slideshows/2009/081709-heisler-apple-disasters.html#slide1

<comment><AUTHOR> Apple's not impervious to failure, believe it or not</comment>