Memcache top - <AUTHOR> http://engineering.tumblr.com/post/48701285213/open-source-memcache-top

<comment><USER2> Does dropping packets matter if you're looking for hot keys?

As long as you manage to be fair in what you drop, surely all you really need is a representative sample (even 1-in-100 or whatever would do).

<comment><USER3> This was my sentiment as well. Further I'm not quite sure how this works -- you run one of these instances on every single memcache instance machine, using packet capture? No mechanism to work across a cluster?

It seems like something one would make a patch for memcache itself (where injecting such metrics seems quite simple).

</comment></comment><comment><USER4> Since I wrote memkeys, maybe I can clarify a few things.

First, dropping packets matters. If you see only 30-40% of your traffic you can't guarantee that you have enough data to know what your hot keys actually are. This is especially true when you are interested in (for instance) sorting keys by bandwidth usage. You might have a key that gets half as many hits as the hottest key but is 4x the size and causing network link saturation. In this case, depending on how much data you're able to capture, you may or may not even see this data point. Also, the follow-up comment from corresation about patching memcache doesn't make sense to me.

Second, this was no 'jab' at etsy. I know the etsy guys incredibly well and we're all friends. We've collaborated on work in more than one occasion. The jab comment seems like unnecessary speculation. The comment about seeing how memkeys affects performance is of course spot on. In this case, one thread will peg a CPU core for packet capture but besides that will not be CPU intensive. Since it uses packet capture, memkeys doesn't actually interact with memcached directly so the impact should be minimal. We used it at Tumblr.

Third, fixing the packet loss issue in mctop wasn't feasible as the problem is with ruby-pcap not with mctop. Additionally, while Tumblr has plenty of ruby code in production we don't generally use it for building 'real-time' applications. There are better languages for the job.

I built memkeys because it solved a problem we had, and was fun. That's it.

</comment><comment><USER5> Larger screenshot from the Github page: [https://raw.github.com/wiki/bmatheny/memkeys/misc/screenshot...](https://raw.github.com/wiki/bmatheny/memkeys/misc/screenshot.png)

<comment><USER6> The only useful line to me is the second bottom one. It says the packet loss is more than 4% as opposed to less than 2% the article claims.

Still a nice tool, though.

<comment><USER4> This screenshot was taken on my dev box which has plenty of other activity happening. On a production memcache box, seeing 1Gb/s, I see ~2% packet loss.

</comment></comment></comment><comment><USER7> I guess when you get up to the scale of Tumblr, you need any measure of performance. I wish I knew what was going on there. Anyone care to elaborate?

<comment><USER8> At Tumblr or in the supplied image?

If the latter, it's a list of memcache key IDs, ordered by hit count.

</comment></comment><comment><USER9> Cool tool, a bit of a pointless jab at Etsy.

I don't know how it queries up Memcached but it's probably a good idea to see how it affects performance of it before running it against a production cache pool.

Just a thought.

<comment><USER10> Note: going solely off the two screenshots (mctop: <http://etsycodeascraft.files.wordpress.com/2012/12/mctop.jpg> , memkeys: [https://raw.github.com/wiki/bmatheny/memkeys/misc/screenshot...](https://raw.github.com/wiki/bmatheny/memkeys/misc/screenshot.png)), it's not clear why tumblr didn't fix the stated packet loss issue in mctop instead.</comment></comment>


Patent Holders Trying to Drag 3rd Parties into Patent Disputes - <AUTHOR> http://www.techdirt.com/articles/20110811/17233715482/patent-holders-trying-to-drag-3rd-parties-into-patent-disputes.shtml

<comment><USER2> This is how great empires come to a standstil, entitlement junkies!!</comment>


Dotty: a next generation compiler for Scala - <AUTHOR> http://dotty.epfl.ch/ <comment><USER2> Looking forward to this, its a bold step to start from "scratch", but in return the Scala community will get a compiler that have solid theoretical foundation, better performance and more utility for development tools.

Scala's Road Ahead - by Martin Odersky [https://www.youtube.com/watch?v=_2oGY8l67jk](https://www.youtube.com/watch?v=_2oGY8l67jk)

</comment><comment><USER3> We are a big scala shop at Expedia and it's concerning that Martin is more interested in Dotty.

Scala 2.12 is late, and not having easy java8 interoperability is becoming more and more of an issue.

I love the language but it is becoming harder to recommend it for new things due to the ambiguous roadmap.

<comment><USER4> I fail to see how this is concerning. Scala isn't a one-man project. Martin is a university professor, i.e. someone supposed to work on education and academic research. It's already pretty remarkable that so many students and researchers at LAMP/EPFL (funded by Swiss taxpayers) are working on real-world projects, that you can use in production at your commercial company.

<comment><USER5> One small correction, they're funded by the Swiss taxpayers and the European union.

<comment><USER6> well no, this is not the case. ( I have a Ms in CS at EPFL)

<comment><USER5> [http://www.scala-lang.org/old/node/8579](http://www.scala- lang.org/old/node/8579)

</comment></comment></comment></comment></comment><comment><USER7> Not directly related, but: do the world a favor and build a new SBT! This <<= one += is a bit -> """strange""" .

<comment><USER8> Strongly agree. SBT really is puzzling and (IMO) overcomplicated. Someone is working on an experimental alternative called CBT which is pure Scala (as in: less DSL like syntax)

<comment><USER9> I'm not even sure why the acronym stands for simple build tool.

<comment><USER8> I think they refitted the acronym into "Scala Build Tool" a few years ago

<comment><USER10> What was the original meaning then ? sluggish bloat transducer ?

<comment><USER11> Sucks big time

</comment></comment></comment></comment></comment></comment><comment><USER12> There are many evolutions for Scala. Here is a compiler to compile scala code to native: [https://github.com/scala-native/scala- native](https://github.com/scala-native/scala-native)

<comment><USER13> Wow, this looks like exactly what I've been looking for. What is the interop story as far as Java/existing Scala code?

<comment><USER14> Interop with Java seems unlikely unless they keep a JVM tucked away somewhere.

<comment><USER13> Now that I look at it, they essentially do, it's just that they implement it from a more Scala-centric point of view (e.g. implementing traits directly instead of being layered on top of a Java variant). It seems like it shouldn't be too hard to compile JVM bytecode to run on the same runtime.

</comment></comment></comment></comment><comment><USER15> When I read this, I can't think of anything else but Scala fatigue. As a CTO migrating a company from .NET to the JVM, I found there's already a mess of conforming to a subset of Scala within real (and more importantly - ordinary) teams.

What subset of Scala? what libraries? what build system? apparently if things worked well, there would be at just one true - and well respected - answer for these.

So now I ask, honestly, why not go with Kotlin ([https://kotlinlang.org/](https://kotlinlang.org/))? a language that IMHO didn't try to rule the world from day one (a Good Thing), but scores high on aesthetics, abstraction, power, IDE, compilation speed, and Java integration.

I have been following (and playing with) Scala since a bit before the Yammer thing exploded, I've been following Odersky as a student listening to the OOPSLA podcasts, and I never got to convince myself Scala is worth it. Can someone convince me to still use Scala when Kotlin is around?

<comment><USER16> Can you share the reasons for migration?

<comment><USER15> We bought a company, and that company had a technology that was based on the JVM. We were on .NET.

The domain dictated that we needed a 'heavy lifting' framework like .NET or the JVM.

We did also work with Ruby, nodejs, and Go for certain microservices.

So now, decision making time:

\- Do you reimplement in .NET ? \- Do you live with both .NET and JVM bases? \- Do you migrate existing systems from .NET to Java?

The .NET system was aging in any case, people needed a fresh breath of air, and it was nice to get rid of all of the Microsoft licensing and closed garden. It is then when I decided the new-gen stack would be Java8 and Kotlin, side-by-side. Kotlin was (and still is) amazing.

<comment><USER17> >all of the Microsoft licensing and closed garden

You mean the horrors of MIT[0] license?

[0] - [https://github.com/Microsoft/dotnet/blob/master/LICENSE](https://github.com/Microsoft/dotnet/blob/master/LICENSE)

</comment></comment></comment></comment><comment><USER18> Simplification instead of piling up, clarifying and redoing right, as understanding grows, instead of adding extensions (like crippled lambdas to Java) and reduction to closest approximation to the [unattainable] optimum (smallest possible, well balanced set of mutually complementing each other features, like in R5RS) in general - is the right way.

I hope Swift will eventually stop piling up features and will try to get back to the right fundamentals too.)

<comment><USER19> Have you all seen Kotlin?

<comment> premium-concern Yes, it's like they reinvent all the things that were considered but discarded in Scala and believe they found something nobody ever thought about before.

<comment><USER20> I am not sure that Kotlin competes with Scala in any way. They are trying to remove the pain from Java by providing a concise and safe language (see the quotes from their website below). What are "all the things" they reinvented that were discard in Scala?

> Kotlin is a pragmatic programming language for JVM and Android that combines > OO and functional features and is focused on interoperability, safety, > clarity and tooling support.

> Being a general-purpose language, Kotlin works everywhere where Java works: > server-side applications, mobile applications (Android), desktop > applications.

<comment> premium-concern > What are "all the things" they reinvented that were discard in Scala?

Extension methods, properties, special syntax for everything, final by default, short constructor syntax, trying to put band-aid around Java's broken collection types, ...

<comment><USER21> I'd love to learn more about Java's broken collection types. What's broken about them?

<comment> premium-concern The pattern of throwing exceptions for operations deemed "unsupported", an API that requires massive workarounds to keep alive in Java 10, no support for immutable collections, unmodifiable views are a complete clusterfuck, no persistent collections etc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> > Is it the future Scala? Yes, it will be - eventually.

I thought, that's a big claim -- then saw who is working on it.

<comment><USER23> It also means that the main designer of the Scala language is not working on Scala but on a language that will "eventually" become the future of Scala, which means that, right now, dotty is _not_ the future of Scala.

A lot of very smart people seem to be very excited about that, I can't help but find it ominous.

<comment><USER24> > It also means that the main designer of the Scala language is not working on > Scala

No, it means that person is not working _only_ on Scala, or rather the current implementation of Scala. People can work on multiple projects over the course of a year/years.

> on a language that will "eventually" become the future of Scala

You changed "Is it the future Scala? Yes, it will be - eventually" (I think can best be reworded "eventually be the future Scala") to "eventually become the future of Scala." To me, those have different connotations. The former means that it's not finished yet, but when it is it will be the base of Scala at that time. The latter implies, to me, that at some time in the future this will be the base of Scala at some time further in the future.

> which means that, right now, dotty is not the future of Scala

And here's where that different meaning leads you wrong. dotty is the future _of_ Scala right now, but it's not that future Scala yet.

> A lot of very smart people seem to be very excited about that, I can't help > but find it ominous.

People are generally happy to have to the creator of something they like working on its future.

Scala is being maintained. Improvements and releases are being made in the meantime. More than one person can work on Scala, and a single person can work on multiple aspects of Scala. Big changes like dotty are being carefully planned and executed at the same time other changes are made. People are excited that Scala is continuing to evolve and becoming a better language, and that a beloved innovator/creator is playing a significant role in that.

<comment><USER23> Right, yes, I read "the future of Scala" but that isn't what it said at all. My mistake entirely, you're absolutely correct.

On the other hand, I stand by my "not working on Scala" comment. This is based on commit history, which I admit might not give the whole picture but is certainly a fairly strong indication: [https://github.com/scala/scala/graphs/contributors](https://github.com/scala/scala/graphs/contributors) Odersky's activity has drastically diminished towards the end of 2012, with his last Scala commit in July, 2014.

I've no issue with him doing exactly what he wishes, he owes the community (or at least, _me_ ) absolutely nothing and if he's more excited to work on Dotty than on Scala, then there is no doubt that's what he should be doing. My concern is that the more I look at Dotty, the more it looks like a very promising language that looks a _lot_ like Scala, but that adds and removes some features to it - that is to say, not actually Scala. I've no trouble imagining a future where the differences grow enough that they stay / become entirely distinct, and seeing a large chunk of the brains behind Scala busy on Dotty doesn't feel me with confidence in the former's future.

<comment><USER25> I really do not see the problem with this. Odersky oversees a team of very capable people he trusts to work on the current Scala version, while he works on the future. He is the father of Scala, but please do not underestimate the brilliant people that are actively working on Scala now, allowing him to develop the bleeding edge.

<comment><USER23> You're misreading my comment. What bothers me is not that the "father of Scala" is working on the future of Scala, but that he's working on something that I fear might become another language altogether.

I'm not saying Scala is in bad hands or a dead language. But when a project's creator looses interest and moves to different things, well, it's usually not the best sign for that project. And again, I'm not saying that this is happening right now, or even that it necessarily will, just that Dotty definitely has the potential of leading to that situation.

<comment> premium-concern > I'm not saying Scala is in bad hands or a dead language. But when a > project's creator looses interest and moves to different things, well, it's > usually not the best sign for that project.

"looses interest" ... "moves to different things" ... WTF? How can people come up with this FUD?

Scala2 and Dotty are two dialects of the same language, just as ScalaJS and Scala Native are dialects of the language.

Keep calm and carry on.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> The linked page links to a set of slides: [http://www.slideshare.net/Odersky/compilers-are- databases](http://www.slideshare.net/Odersky/compilers-are-databases)

I have a question regarding slides 29 to 31.

The author says an untyped tree is represented as Tree[Nothing]. This leads to undesired variance behavior which is in turn overriden.

But there cannot be any instances of type Tree[Nothing] because there are no instances of type Nothing. Wouldn't an untyped tree be better represented as Tree[Unit]?

<comment><USER27> There can be instances of Tree[Nothing], just like there can be instances of List[Nothing]. It just means that in a scenario like this:

        class Tree[T] { def elem: T }

if t is a Tree[Nothing] then t.elem will not return normally (it might throw an exception instead).

<comment><USER28> Ok, so there are instances, which throw exceptions, fine, we're in Java land after all, where anything can happen. But why is Tree[Nothing] more useful than Tree[Unit]? Both contain the same amount of information (both Nothing and Unit convey zero bits of information), but one throws an exception while the other is safe at runtime.

<comment><USER29> Tree[Nothing] is a subtype of all Tree[_] types. This is similar to Nil in scala, which is really a singleton implementation of List[Nothing] or None, which is a singleton implementation of Option[Nothing]. Unit does not have this property, it is just a subtype of AnyVal/Any.

Basically, Tree[Nothing] allows you to indicate that a Tree is empty via the type system while still allowing you to use that same type to build an actual tree from. If Nil was List[Unit] instead of List[Nothing], 1 :: Nil would be a compile time error instead of a List[Int].

Oh, and Unit does have an implementation in scala called "()", so if you had a Tree[Unit] you would not be able to tell if it was actually empty or not. You can see this in scala with () :: Nil. It produces a non-empty List[Unit]. Nothing has no such implementation. As for the exceptions, there's not much you can do wrt that. What should happen if you call head on an empty List? That's a straight-out error. headOption or a match block is the safe way to deal with lists if you don't want to have exceptions ever.

</comment></comment></comment></comment><comment><USER30> What's the chance for this to become a new Python 3 story?

<comment> premium-concern Zero. People are actively aware of what happened in Python 2/3.

The good thing is that Scala is a typed language, so they can

a) provide tooling for migrating code

b) compile things and get clear information about how much differences there are

I think somebody said that necessary lines of change from Scala 2 -> Scala 3 should be below 0.1% to be acceptable.

<comment><USER31> Oh you. Our codebase uses scala xml and macros; migration will be a major PITA.

<comment><USER32> Author of Scala macros here. Here's a recent discussion on the future of macros in the brave new world of Dotty: [https://www.reddit.com/r/scala/comments/4our5m/keynote_scala...](https://www.reddit.com/r/scala/comments/4our5m/keynote_scalas_road_ahead_by_martin_odersky/d4gd439).

</comment></comment></comment></comment><comment><USER33> That's going to cause some confusion ... [http://www.graphviz.org/](http://www.graphviz.org/)

<comment><USER34> DOT is just the name of the calculus used to prove the core of the language (and Dotty the name of the new compiler). It won't appear often in the literature meant for the general public so I don't think there will be much confusion.

</comment></comment><comment><USER35> "@adriaanm our plan for Scala is to declare JIRA bankruptcy and run for the githubs. Maybe take the top half of the open issues with us."

[https://twitter.com/adriaanm/status/571073842434547712](https://twitter.com/adriaanm/status/571073842434547712)

</comment><comment><USER36> Previous discussion: [https://news.ycombinator.com/item?id=10482585](https://news.ycombinator.com/item?id=10482585)

</comment><comment><USER37> Can't help, but I don't like these click a button to scroll down to relevant content presentations. That is the new style of the doomed splash screens.

</comment><comment><USER38> Does anyone know if structural typing is not coming to dotty without the need for runtime reflection?

</comment><comment><USER39> What is the relationship between Dotty and Scala Native?

</comment><comment><USER40> looking forward to seeing (reading about) how fast it is.

<comment><USER41> According to Odersky's recent talk [1, 2] it's about twice as fast as the current Scala compiler and should still improve significantly.

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

[2] [http://www.slideshare.net/Odersky/scala-days- nyc-2016](http://www.slideshare.net/Odersky/scala-days-nyc-2016) (slide 21)

<comment><USER28> > I think we can do better than Monads to achieve this.

(slide 52)

Looking forward to their solution.

<comment><USER42> For anybody curious, I think he's hinting at modern effect systems, on which there's lots of research these days. He advised for instance Lukas Rytz PhD thesis at EPFL (and Lukas Rytz is still working on Scala, now at Lightbend).

</comment></comment></comment></comment><comment><USER43> Is this enough to run chisel?

</comment><comment><USER44> I build a tool, for the tool, which is a better tool of the tool to create bytecode. Seriously adding up stack in order to solve complexity, actually creates more complexity.

<comment><USER45> I don't really understand your point. Is that a truism? Is it related to the freaking article? Also, have you built a tool or was that sarcasm?

<comment><USER42> Assuming I get him correctly, that's bad sarcasm. I'd recommend instead this joke on JavaScript toolchain: [http://cube-drone.com/comics/c/relentless- persistence](http://cube-drone.com/comics/c/relentless-persistence)

Compilers are huge beasts, but good ones are worthwhile, and Dotty is a better Scala compiler, so this criticism seems misdirected.</comment></comment></comment>


Ask HN: "best" UI JavaScript library/framework? - <AUTHOR>

I have an idea for another application and want to do it "right" this time just to learn new stuff. This will be desktop-like web application. Right now I am trying to decide which library/framework to learn and use for browser part. I really like Cappuccino look'n'feel, but their Objective J look weird to me. Is there is something like Cappuccino with plain JavaScript or it's better to invest some time into learning this Objective J thing? Any thoughts are really appreciated!<p>Update: I am looking for open source libraries/frameworks =) <comment><USER2> I would recommend Dojo over ExtJS for building "web applications", out of the "heavy duty" frameworks Dojo leads the pack by far.

If you want to get up and running quick then I would suggest jQuery, it is drop dead simple and extremely light weight. But it can start to fall down (in terms of maintainability) when you are trying to manage a large code base.

From a pure employment perspective (what job postings are looking for) jQuery is the hottest followed by Dojo.

</comment><comment><USER3> I would _love_ to see a pure Java version of Cappuccino as well.

In the meantime I use Google Closure. Certainly not the best library but it suits my needs (web applications for the Google Marketplace). Even though it looks ugly at first sight, it is actually an effective solution.

One drawback is the relative lack of support from Google regarding docs, tutorials.

</comment><comment><USER4> While it's relatively immature in terms of widgets available, I like yui3 (NOT 2) for building application type sites. It has a strong component model and the attributes/events system and widget base are excellent and I believe it's the only one that's really serious about progressive enhancement.

</comment><comment><USER5> ExtJS would be a good bet. Its parent company, now known as Sencha, just "acquired" 2 popular Javascript frameworks, jQTouch and Raphael. They also received an investment from Sequoia capital recently. The only downside is that it requires a license for non open source projects.

</comment><comment><USER6> ExtJS is definitely a great solution for building a "desktop-like" application on the web. However, if you have solid design skills, a framework such as jQuery UI provides a great deal of freedom in creating some really interesting and remarkable interfaces for the web.

</comment><comment><USER7> SproutCore (<http://sproutcore.com/>) is essentially like Cappuccino, but not Objective-J.

<comment><AUTHOR> Thank you for this hint. Any idea about licensing? I can't find anything about it on their site. Is it GPL or something else?

<comment><USER8> It's under a permissive (MIT/BSD-style) open-source license, though you're right that it doesn't seem to be mentioned anywhere on the site, at least that I can find. There's a license.js file in the actual distribution, though: <http://github.com/sproutit/sproutcore/blob/master/license.js></comment></comment></comment>


Google Glass is getting a second life in the manufacturing industry - happy-go-lucky http://www.npr.org/sections/alltechconsidered/2017/03/18/514299682/google-glass-didnt-disappear-you-can-find-it-on-the-factory-floor <comment><USER2> It's kind of clear that their quoted expert Tsai didn't interview anyone while they were using Google Glass.

"With Google Glass, it may look like you're listening to the person in front of you, but you could actually be watching a movie or looking up sports stats."

Unfortunately the problem is the opposite and more offensive. It's very obvious if you're having a conversation with someone while they're using Glass while looking at you from their eye movements, and it makes the user look really weird ignoring any fashion issues. I found the experience quite a bit more offensive than having someone reading emails on their laptop while you talked to them. Unlike the laptop case, with glass you get a very clear direct view of their eyes as they scan whatever glass is showing them, while there is the obvious false pretense of giving you their full attention.

I think one of the big problems with glass was that they picked the wrong sort of people to be early public users that then set the tone for the product. A process that ensured only super-enthusiastic users would bother applying is also the sort that would select for the least willing to notice how other people might find certain uses of it rude and annoying.

<comment><USER3> > I think one of the big problems with glass was that they picked the wrong > sort of people to be early public users

Totally agree. As awesome a technical achievement as Glass was, it was the product of 20 years of work from some very odd people (MIT's borgs) that literally wore desktop computers on their backs prototyping it, ignoring all social convention in the process. While their insights were valuable for their particular approach to wearable computing (HUD-based, data recall oriented, etc), that approach _isn 't the right approach for the mainstream_, nor are they the right brand ambassadors.

Google's perennial issue is they're a technology factory that thinks they're a consumer company. The goto market strategy Glass should have adopted was in enterprise, where there are many valuable use cases like ones in this article, and Google could have refined it there. But Google isn't good at picking markets or any form of understanding marketing, so they decided that a bunch of geeks walking around cafes, bars, and restaurants was the right way to go. _sigh_

<comment><USER4> I'd be a lot more understanding if Neal Stephenson hadn't foreseen and lampooned the concept in 'Snow Crash'. Seriously, how many people on HN took one look at Google Glass and though, "Oh shit, gargoyles!"

<comment><USER5> I didn't do it until now, when I looked at the actual borgs :)

[https://c.o0bg.com/rf/image_960w/Boston/2011-2020/2012/07/15...](https://c.o0bg.com/rf/image_960w/Boston/2011-2020/2012/07/15/BostonGlobe.com/Business/Images/rehmi_post_2.jpg)

</comment></comment></comment></comment><comment><USER6> Using Glass in a factory environment surprises me. Factories are notoriously loud, so unless Glass is _really_ good at filtering out background noise, I'd imagine that voice commands wouldn't work very well. My experience has mostly been consumer electronics factories in Asia, but I also see the following problems that may or may not apply to domestic factories:

* Equipment with clear resale value has a tendency to "walk away". We worked hard to avoid using consumer electronics such as PCs or phones on the line. When we did need to use them, we had to establish strict policies and secure storage for when the equipment was not in use. Glass seems like it'd fall in this category.

* Even dedicated, laser-based, handheld barcode scanners could be finicky with part labels. Camera-based scanners were unusable due to poor accuracy and latency.

* Internet connectivity is poor or non-existent. WiFi coverage is usually terrible due to physical and electrical interference from factory equipment.

AR work instructions would be a dream--especially if the technology could flag errors. The environment just seems especially hostile for consumer-oriented technology such as Glass. I don't have firsthand experience with Glass, but I'm really surprised this company is reporting success with it.

<comment><USER7> Several years ago I was trying to solve the problem of voice recognition in a noisy environment. After brainstorming with some colleagues, we came up with the idea of using a throat mike. The only problem was that we couldn't find reasonably priced hardware that would work with commodity computers.

<comment><USER6> Jawbone Bluetooth headsets actually contact your jaw to use the conducted vibrations to cancel background noise, similar to your idea. Disclosure: I worked on their first generation Bluetooth headset. I'm not certain the current generations still work this way.

<comment><USER8> Noiseassassin - yup, the later gen ones do as well, but as I understand it, Jawbone is basically dead at this point.

<comment><USER9> Could get a second wind with voice recognition because the problem with comms is everyone sounds the same through that style of mic.

</comment></comment></comment></comment></comment><comment><USER10> I wonder, how does one approach Google for such business tech? Or do they only find customers themselves?

I couldn't find the landing page for prospective enterprise Glass customers, though there's Glass at Work partner list with companies which do have real contact address.

[https://developers.google.com/glass/distribute/glass-at- work](https://developers.google.com/glass/distribute/glass-at-work)

<comment><USER11> After having a quick look at the site, my understanding is that you don't approach Google directly for this, you either approach a Glass Certified Partner to do the work or you become one yourself. There are no apparent links for becoming a Glass Certified Partner though, so my guess is you simply can't right now.

<comment><USER12> A colleague recently interacted with Google in an attempt to acquire Glass. The takeaway I got was Google was only interested in selling if the project was "cool" (no definition in sight) and if the quantity was substantial (minimum 100 units I think.)

</comment></comment></comment><comment><USER13> There's something ironic and lovely about the much-maligned Google Glass becoming a blue-collar tool.

<comment><USER14> It's funny, I'm an industrial electrician and my smart phone is my handiest tool. I can take pictures from awkward spots like up a pipe behind some bus bars, even thermal, download a manual and keyword search my issues. Video chat with more/less experienced employees to problem solve. Use my phone to trouble shoot cellular issues (m2m iot). Remotely configure network systems. Use OTG cable to serial interface with rs232/485\. Scan a barcode of existing hardware,compare it to new hardware and order it online. A LOT of mobile technology is wasted on company's thinking I want this to snap a highlight reel of my weekend and other trivial shit ....When what I really want to do is take a picture with my device, save the location of picture and send it to all parties concerned and document my time.

<comment><USER15> My piano tuner uses an iPhone app called TuneLab.[1]

$500.00USD. For an app. Interface that looks like the dev Googled all the images needed and used the first result. First line of the app store description is _Do not buy this app unless you are a professional piano technician._ Yet it's a highly powerful tool and professionals use it.

[1] [https://itunes.apple.com/nz/app/tunelab-piano- tuner/id335568...](https://itunes.apple.com/nz/app/tunelab-piano- tuner/id335568329)

<comment><USER16> Wow this is amazing. It really shows how powerful the app store has become.

<comment><USER17> If anything is exactly what the app store should be. Cell phones are incredibly powerful but it's rare they're used for anything besides a dumb ui for a server or games

<comment><USER18> To be fair, there's an equal amount of trash software available from your laptop/desktop as well, the only difference being that there isn't a centralized repository that it all must go through; the trash heap that rests under the app stores was inevitable, since such junk was always going to exist and people would find a way to sell it.

<comment><USER15> What I find interesting is that everyone's trying to make the next big game or consumer app, a market that's already insanely saturated.

Meanwhile a single decent professional piano tuning app can sell for $500 (I don't know the sales numbers of course) with the most amateur-looking UI ever and a description that's a warning not to buy it.

Considering that most games get lost in the heap and sell basically nothing, maybe looking to see if there's some niche tool you could make instead isn't a bad idea.

<comment><USER19> Well to be fair, it's _priced_ at $500, and aside from the single point of reference, I wonder how many have been sold.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> This reminds me of the Manna story by Marshall Brain: [http://marshallbrain.com/manna1.htm](http://marshallbrain.com/manna1.htm)

<comment><USER21> that was my first thought too! but this does genuinely seem assistive rather than controlling

</comment></comment><comment><USER22> I'm a bit disappointed that Google didn't continue Glass as a niche product. If I had money, I'd maybe buy one :-)

Does anybody know if there are any "inconspicuous" AR glasses (meaning that they look like e.g. sunglasses and not like the Borg)? Preferably full visual field?

And are there any glasses that work on holographic / light field principles? (AFAIK Hololens doesn't, despite the name!) A few years ago at university, I looked into computer generated holograms. We generated holograms of simple objects on the CPU, printed them out, and shone a laser throught them. Viewing them at a slight angle (so you wouldn't be blinded), you could see the object floating in space - as if the hologram was a window. Back then, we thought maybe you could use a GPU to generate the holographic pattern, and a LCD matrix to display it - but the technology was not there yet. Now you have shader GPUs, and high-DPI LCDs, I feel it's almost just a matter of combining the pieces and you'd have immersive glasses, or a holographic screen.

</comment><comment><USER23> Seems like a great opportunity to use video capture from all employees' GG cameras in order to train their robot replacements.

</comment><comment><USER24> Google Glass is nothing compared to real AR like Microsoft Hololens. And for Enterprise solutions, 2k for these glasses vs 3k for a hololens Dev kit is nothing.

<comment><USER25> > Google Glass is nothing compared to real AR like Microsoft Hololens

You can't wear Microsoft Hololens outside of your office, far from your desktop.

Also I'm saying that, but it's a bit silly to entertain this discussion as they are two completely unrelated products. Mircosoft Hololens is AR as in Augmented Reality while Glass is a UI floating on your face.

<comment><USER26> > You can't wear Microsoft Hololens outside of your office, far from your > desktop.

This is not true. Hololens is untethered and there's nothing preventing you from using it anywhere. Well, nothing except the fact that it's bulkier and heavier than Glass and obscures your face too much for use in social situations.

The real reason why AR isn't better than Glass for this kind of thing is that AR tracking and recognition of objects is not good enough for real applications yet. On Glass as reported in the article you have to scan a code to identify an object you're holding. In people's imaginations, an AR device would magically recognize the object and overlay useful informational displays on it as you turn it in your hands. In reality Hololens is not even close to being able to do this, so you would be reduced to scanning codes just like on Glass.

<comment><USER27> This is the second misconception I've read in this thread so far. I was at a conference in finland this year and a huge company called ABB was there with a holo lens demo. They had a hololens you could wear to see how to repair some mechanical unit. The hololens was able to recognise the unit from its previous mapping of the object and project AR on to it. They moved the unit and it still was able to almost instantaneously detect it.

The technology is here. It's ready. And it's already in use.

<comment><USER28> It's probably best to be skeptical of a demo.

<comment><USER29> Perhaps but I've used both a Hololens and Google Glass, and the Hololens is light-years ahead. It is easily capable of the 'AR repair' application. Glass on the other hand was very 'meh'. The voice interface was horribly unreliable (think 2010-level speech recognition), and it is really just a convenient small display, not proper AR.

</comment></comment></comment></comment></comment></comment><comment><USER30> Glass didn't die because of privacy -- it died because the teams walked out after being threatened with their jobs.

<comment><USER31> We need more details. Why would they be threatened when they had momentum?

</comment></comment><comment><USER32> Was Google Glass ever actually meant to be a big success in the short term?

It looks like typical Hen-Egg-Problem where you first have to build it in order for them to come (slowly). Then you have to wait it out until the actually useful applications arise from the dust.

While the smartphone has established its place in everyday life (after years and years of trying and mostly failing with similar approaches), the glass probably will be a tool for a thousand niche applications mostly in the corporate world who need a finished solution before they start acting.

</comment><comment><USER33> I'll be expecting my RSUs from Google for telling them this exact strategy in my PM interview 2 years ago when I was asked "What would you do with Google Glass?". Then again enterprise is a fairly obvious answer even before they tried the consumer angle. But, if they offer Gmail for people that colonize the moon, (another interview question I got), then I'm definitely going to need some retribution for telling them how to do that too :-P

</comment><comment><USER34> The only problem with Google Glass was that it was ahead of its time. I fully expect Apple to release a 'revolutionary new product' in 10 years time which will essentially be Google Glass with more advanced tech and better styling.

<comment><USER35> More like premature. The display was too low-res as to be useless for anything other than reading 9 or so words at once.

</comment></comment><comment><USER36> Another area where Google Glass has shown to be very useful is in medicine. You can put a pair on and have a specialist walk you through a interview or examination. The poison review toxicology podcast had an interview with a who had significant success using glass in this manner.

[http://www.thepoisonreview.com/2016/03/19/tpr-podcast- episod...](http://www.thepoisonreview.com/2016/03/19/tpr-podcast- episode-11-google-glass-and-the-toxicologist/)

Obviously it needed to be de-googlified to make it HIPAA compliant

<comment><USER37> According to that page:

"Google Glass has the potential of giving us a new perspective on telemedicine. However, the use of this device presents several problems, especially involving data security, patient privacy and HIPAA compliance."

"Using Google Glass, the consultants were also able to send and receive high- quality pictures of EKGs, pill bottles, etc."

"Although it is possible to send and receive photos using cell phones, computers, and tablets, Dr. Chai made the point that such technology is not HIPAA compliant."

So, they used it to Skype with their attendings, and it has the same compliance issues as ... normal cell phones, computers, and tablets - <AUTHOR> absolutely _are_ HIPAA compliant, if you're using secured hardware provided by the hospital (like all the laptops and blackberries used by insurance company employees carrying around identifiable patient data). Hospitals cheap out, though, and make you BYO - which is not a problem I envision Google Glass being a solution to.

Going to the cited publications didn't show any additional benefits.

<comment><USER38> HIPAA compliance is not some unacheavable data security standard. It's so basic that probably all industries should follow it. The problem is that it's surrounded in verbose policy-speak so it just looks completely opaque. There used to be a table on the HHS website that gave a concise explanation of the rules. It's things like what PII is, that it should be encrypted at rest and in transit, how to get explicit permission to transmit it, authorization and authentication is required for viewing the data, and there must be an audit log. Having worked in the financial sector this is all basic stuff.

</comment></comment></comment><comment><USER39> I could be misremembering this, but haven't head-mounted displays of one sort or another been used in industrial settings for something like 20 years? I don't remember when it was, but I seem to recall something with monochrome (and lower-resolution) displays like this being used in things like airplane repair[1].

[1] After a little searching, I may be remembering reading about the 1996 Boeing conference: [https://www.media.mit.edu/wearables/lizzy/timeline.html](https://www.media.mit.edu/wearables/lizzy/timeline.html), or it could be any of the other late-90s systems listed here: [https://en.wikipedia.org/wiki/Optical_head- mounted_display](https://en.wikipedia.org/wiki/Optical_head-mounted_display) that got press at the time.

Edit: Looking at another page, I may actually be remembering something from computer magazines back while I was in college or shortly after - the Private Eye from Reflection Technology (1989) ([https://glassdevelopment.wordpress.com/2014/04/17/hmd- histor...](https://glassdevelopment.wordpress.com/2014/04/17/hmd-history-and- objectives-of-inventions/)) - which would fit, because that plus the Twiddler chorded keyboard became part of the MIT Wearable Computer stuff and I remember wanting one of those keyboards.....

</comment><comment><USER40> Is there an affordable Google Glass like floating screen. With the number of people walking looking at their screens, it makes sense to just gave a floating screen in a nicely design spectacle. No camera, just a ui to see your phone screen and something to track finger movements and tap.

We already have people who have Bluetooth speakers, no reason to also not have a tiny screen near the eyes.

<comment><USER41> This is the best option I've seen: [https://www.vufine.com](https://www.vufine.com)

</comment></comment><comment><USER42> This is where it always should've been. The ability to look at engineering drawings, etc. as you work on something, or being able to look through work instructions without having to down tools and clean off your hands is invaluable. This is always the dream product I had for something like Glass.

</comment><comment><USER43> Beyond me why Google just simply did not add a red LED on the consumer edition to show if the camera was recording in an attempt to address the privacy concerns many people had.

<comment><USER44> While I'm not sure how much it actually was the case with the apps that were available, a lot of the ideas around it seemed to be things that require the camera running, so the LED would be on in a lot of situations where creating a recording would be inappropriate.

(And making a trustworthy indicator that only shows if a recording is actually being created is basically impossible, so "camera running" is the only thing they could show)

<comment><USER43> Right, which is why it failed, Google tried to be sneaky, it was inappropriate, and instead of realizing they needed to figure out a way around the issue, they abandoned it.

Another option and even more trustworthy would have been a camera cover that was usable & durable and clearly & visibly expressed the status of the camera.

</comment></comment></comment><comment><USER45> No surprises there, Vuzix have been selling a less stylish version of it in the same market for years.

Frankly i see little use for the likes of AR and VR in civilian life. Hell even the smartphone of today is something of a bleak shadow of the business tool it once was, thanks to every OEM trying to cater to consumers that barely message and access social media.

<comment><USER22> I can see a lot of uses for AR.

\- A killer feature for me would be (pedestrian) navigation. Highlight the road I have to take with a subtle color. That would even work on a very low- res display. Or at the train station, highlight the part of the train were my reserved seat is.

\- If you have a higher-res screen, you could add additional information to the walls of places, like restaurant ratings etc.. Making it look just like a physical sign is key.

\- One thing that is controversial, but would be huge for me, is face recognition. I sometimes have a hard time remembering what face belongs to what name. A option to show name tags for people I've seen before would be really convenient.

\- How about an app that shows plans when fixing a bike or a car? Or one that tracks where you left your screws? If you have a very good camera, it might be able to even find screws you lost :-)

\- Of course AR/VR games could also be a huge thing. Time will tell if that really catches on or not.

</comment></comment><comment><USER46> Same thing with the Segway. Remember that device which was going to revolutionize how we travel? Now it's for park police and airport staff and whatnot. Segway is now owned and made in China iirc.

</comment><comment><USER47> a similiar idea is romanticized in the 2008 mexican sci-fi movie sleep dealer, only the concept was exploiting cheap labor in full immersion controlling remote robots.

</comment><comment><USER48> Whatever happened to their big cargo ship docked in the bay?

</comment><comment><USER49>
       I am not surprised Google Glass was a product way ahead if it's time. It can still be useful in closed environment like a factory floor. To be really successful in the consumer market it needed an AI capable of identifying every object it sees which we haven't reached yet. I am personally of the opinion that augmented reality is the future of computers rather than virtual reality. People keep pointing towards privacy as the reason it was not successful which is I feel is wrong. They don't have the tech yet of making it truly useful in the consumer market.

</comment><comment><USER50> I wonder how this compares to Lumus -- [https://lumusvision.com/](https://lumusvision.com/)?

</comment><comment><USER51> Medicine still seems like the best use case to me

</comment><comment><USER52> Do we have to worry about the wifi antenna being right next to ones head for a full shift?

<comment><USER53> No, and certainly not when you consider all the significantly higher power gigahertz spectrum light we're already filling the air with.

</comment></comment><comment><USER54> And medical offices.</comment>


Kyoto Tycoon in 2019 - <AUTHOR> http://charlesleifer.com/blog/kyoto-tycoon-in-2019/ <comment><USER3> I keep hoping that the creators of fallabs make a triumphant return. They did post a small bugfix for a build error not too long ago, so the lights aren't completely out.

We used kyotocabinet exclusively for a project that ran for 3 years with ~1 billion txns/day in a big AWS cluster. Totally bomb-proof and a great piece of software. There's no reason not to use it today, really. Tycoon, the server, is good, but the library kyotocabinet is multithreaded and highly performant.

The flexibility of B+ tree or hash type stores, on-disk or in-memory with the same interface is extremely useful for building distributed systems. Very stable under load, and no data bloat as records pile up.

edit: nobody should feel guilty for using stable software with a reliable track record. Just because a project isn't being printed on tee-shirts anymore and breathlessly fawned over during the free happy hour at conferences doesn't mean that it isn't still a perfectly useful piece of software.

<comment><USER4> TK doesn't compile with modern C++ compilers; it has been a real headache for us. It needs some TLC if it is to be used.

</comment></comment><comment><USER5> KyotoCabinet is one of the most important weapons in my holster as a data scientist.

With that kind of a specialty, there are essentially two different kinds of jobs / work environments. One is where it's all about infrastructure and implementing the database to end all databases (and "finding stuff out" is a mere afterthought to that. The other is where 100% of the focus is on "finding stuff out BY NEXT WEEK" with zero mandate for any infrastructure investment of any kind. When I find myself in the latter kind of work environment and I need to quickly get sortable and/or indexable datastructures of any kind, then a key-value store is the way to go and KyotoCabinet is a really good one that I've used LOTS and it has never let me down.

Just don't let your boss find out about it if yours is of the pointy-haired variety. If he finds out that it's an open source project that has seen its last commit some 6 years ago and has been abandoned since, he will be less than pleased. -- Personally I find that's a really bad argument. It's feature- complete w.r.t. anything I've ever wanted to do with it, and its feature set is actually way richer than most of the younger alternatives that are still being actively developed (because they are still in _need_ of very active development, and aren't nearly as well battle-tested). Plus what's the worst that could happen? That you will one day want to move to an environment where it will no longer work. Well in that case it shouldn't be so hard to substitute another key-value store for this one. After all, the simplicity of the API around a key-value store where get & set is basically all you need, should make that really easy.

<comment><USER6> > When I find myself in the latter kind of work environment and I need to > quickly get sortable and/or indexable datastructures of any kind, then a > key-value store is the way to go

Interesting, can you expand on this?

<comment><USER5> Cf my ansewr to zzleeper's comment below.

</comment></comment></comment><comment><USER7> I've used Tokyo Tyrant / Tokyo Cabinet and Kyoto Tycoon / Kyoto Cabinet in production in my previous job in 2018.

There was a need to cache a large number of computation results, hundreds of gigabytes, over network, for a scientific computing process that could run for days.

The cache would not fit in memory, so the KV store needed to be persistent.

I wrote a caching layer with switchable backend, with an API inspired by KT, so that plugging Kyoto Tycoon in would be easy.

Tested with TT, KT and Aerospike. In the end, went with either TT or KT, both being stable, easy to use, performant, and compiling on something as old as RH5 (which some of our clients were still running, apparently).

Compared to KT, Aerospike had more features (ssd optimization, sharding) when used as a KV store, but we didn't need them.

In the world of persistent KV-stores there have not been that many options as of last year. Kyoto Tycoon is feature-complete and works well.

That's why you don't hear many people talking about it: it just works, there's not much to talk about.

And the source/API/documentation it's a work of art.

<comment><USER8> How did KT's performance compare to that of Aerospike's?

<comment><USER7> Sadly, I don't recall off the bat, and I don't have access to those files anymore.

IIRC Aerospike would be faster initially because it keep a lot in RAM, but they'd be about the same once the DB fills up you can't get away with that. In the end, either network or disk would be the bottleneck for the workload I tried it with.

</comment></comment></comment><comment><USER9> We use KT's in-memory database in a scientific computing application I work on (to store a graph 30-100GB in size accessed by 100-1000 workers). The performance is very impressive, and it's been reliable for our use case. But I don't think I'd recommend anyone use it in 2019 -- having an active community (and someone to actively maintain the software!) is too important. A small performance gain over alternatives like Redis is probably not worth the tradeoff of using software that is (sadly) abandoned.

edit: That's not to say it is really in need of much development -- it's pretty feature-complete. But it's undergone a bit of software rot: the Debian package, for example, ships header files which fail to compile under many recent gcc versions. And the network effect is just not there. If you run into some database slowness, searching the Web for "Redis performance problem" might get you some ideas. Searching for "kyototycoon performance problem" will get you nowhere.

<comment><USER10> Seems like it should be put up on GitHub where people can casually fix issues as needed.

<comment><USER7> The source is available, why does it need to be on GitHub specifically?

But hey, why not, done deal:

[https://github.com/cloudflare/kyotocabinet](https://github.com/cloudflare/kyotocabinet)

</comment></comment></comment><comment><USER11> Fun fact: "tycoon" is a loanword from Japanese.

[https://en.wiktionary.org/wiki/tycoon](https://en.wiktionary.org/wiki/tycoon)

<comment><USER12> That's new to me even though I'm Japanese. lol

<comment><USER13> Jim Breen's EDICT dictionary lists 'great' and 'old boy' as core meanings for associated kanji. Aside from an in-group honorific suffix the _kimi_ kanji is also associated with _moro no kimi_ or a Shinto _wolf spirit_ which may be a good definition of a tycoon. :)

<comment><USER14> Another reading of 大君 is ookimi, which is how the Emperor was called in ancient times. In this context the kanji means lord, prince.

<comment><USER15> Yes, ookimi is the common reading for 大君 today. Taikun seems to have come from Edo period. According to several Japanese dictionaries, this was the title applied to the Shogun, especially in foreign correspondence, which I assume was primarily with China and Korea from most of that period. This title was probably more appropriate for use with Chinese or Korean speakers, who would read Shogun (將軍) as General, a purely military title. In any case, it seems that after Japan opened up to western countries following Commodore Perry's gunboat diplomacy, the term was imported to the West referring to the Shogun.

</comment></comment></comment></comment></comment><comment><USER16> Cloudflare used to use KT. That's very true, but we removed it and replaced it with our own distributed KV store and replication mechanism called Quicksilver.

<comment><USER17> What were the engineering motivations for moving from KT to Quicksilver? Did that have to do with performance/throughput, or more with tooling and functionality?

<comment><USER18> There was a number of problems, but mostly boiling down to the sheer scale of our deployment. As an engineer I would say that KT gave us surprisingly good mileage. We were able to grow the company from couple of servers to hundreds, but at some point we just outgrew KT.

The main issues that triggered serious internal discussions about KT:

(1) Tuning the data structures was hard. Each data backend has many toggles, and it's not obvious what they actually do. I ended up writing script to try out all the different toggles just to figure out what the disk and performance cost would be.

(2) If we decided to tweak the data backend toggles, it was not obvious how to upgrade the storage. There isn't a single command to take the KT store and rewrite it with different specific-optimization-setting. This meant our disks stored stuff in non-optimal format, wasting our disk and memory.

(3) We added encryption to the replication protocol, it was fine for some time, but not perfect. If I remember right the SSL handshake was blocking, which meant the master stalled for some time on each replica connect. This code was ours, sure, but the problem is: integrating non-blocking SSL accept() into KT event loop was very much non trivial.

(4) The replication protocol is great (and trivial!), if you the lifetime of the replicas is roughly in line with the lifetime of the master. This was not the case in our deployment. We might bring a new colo up, or just format disks in some region. In such case, how do you bootstrap the replica? This is an unsolved problem. Sadly, you can't just rsync the data directory while keeping KT master running: it will end up inconsistent. We had to: stop the master, rsync the disk, start the replica, start the master, make sure the replica picks up the log in right place. This is fine if you have two replicas, but not hundreds.

(5) The HA story of the "KT master" was unsatisfactory. The docs say that you should configure two masters, each replicating to each other. But I never understood how it was supposed to work in case of conflicts, clock skew, or disk failures. Think about problems in second or third layer of replicas.

Most importantly (4) and (5) lead to data inconsistencies, which is unacceptable. Furthermore as we grew we were constantly toggling our KT architecture, adding more and more replica layers. This made (4) only worse.

I personally love KT, I think it's great piece of software. Sadly, it looks abandoned, lacking community. I guess at some point for us the pains of operating it outgrew the benefits it gave.

Our replacement, Quicksilver, is brilliant. Perhaps we should blog about it more.

<comment><USER19> And to add to point (4): as Marek says KT's replication is great... to a point. When Cloudflare was small and we only had to replicate to a relatively small number of machines it coped fine.

As we scaled out each data centre we quickly hit limitations in KT's ability to replicate to many clients. We ended up having to install many more replication points in each data centre or region just to allow KT to replicate to all downstream clients, otherwise it would regularly stall while trying to service all replication requests, massively slowing down replication, or sometimes even missing updates.

There's also two more points to be made:

(6) As our KC (Kyoto Cabinet) databases grew, KT had trouble keeping consistency of the file on disk. Sometimes a restart of the service would leave you with a corrupted KC database, causing us to have to resync the node from scratch. This was a huge operational burden - especially if corruption somehow replicated downstream.

(7) KT allows you to write to replicas. This one we always found crazy. You can write (or overwrite) a key on a downstream replica and that only ever stays on the replica - it can't propagate upwards (and nor should it). Until the top-level writes to that key again it will remain with this erroneous value. This made monitoring problematic because it would cause a keycount or replication diff if it ever happened.

</comment></comment></comment></comment><comment><USER20> At a previous organizion I worked at, about 5-7 years ago, I made very heavy use of Tokyo Tyrant and T. Cabinet (the predecessors of Kyoto Tycoon and KC). We had many instances throughout our infrastructure, and many engineers had at least some knowledge of it.

It was the fastest key-value store I'd ever used. I was floored by its speed and relative stability.

And the article and comments rightly point out KT's terrible documentation and thin user community on the ground. TT was just the same. This caused a lot of surprising (and mostly undocumented) issues whenever somebody was trying to get onboarded.

I was surprised that it was so obscure and so undocumented. Especially considering its speed and simplicity (in terms of getting a basic k-v store set up).

I depended a lot on DBA's and DB engineers, our sysadmins, and other engineers with more experience of TT than I had. Usually, whenever I needed to understand a configuration option in detail, deploy a new instance with different characteristics, or optimize an existing instance, I would consult them. I think we had just as much, if not, more, knowledge of this software than any community on the Internet.

But all of this raw speed, at the cost of lack of support, lack of documentation or community bit us in the ass, hard. Either the TT/TC service itself crashed, or the host it was running on crashed (I can't remember).

Some data was lost because it was designed with no fault tolerance. Most data was recovered from backups. An executive decision was immediately made to move to a different DB, with proper resilience, etc. We quickly moved to a well known, open source, commercially supported system with all the usual value- added proprietary parts.

Then the $$$$$ started pouring in to the support contract. At least we had something trustworthy that we could understand, lots of documentation, and good upstream support engineers :-)

It's a bit sad to imagine what could have become of TT/TC. I've no idea about KT/KC. They had a LOT of potential. Maybe the potential is still there? Maybe they're project deserve resurrection, at least for educational purposes?

At least the source code still exists if anybody is interested enough. Documentation generally consists of reading struct definitions and comments; a couple of decent StackOverflow posts; and now-mostly defunct mailing lists on Google Groups.

</comment><comment> k-ian I was really hoping that this was a videogame

</comment><comment><USER21> Does anyone have comparisons (even anecdata) with (L)MDB?

<comment><USER19> Cloudflare's replacement for KT that jgrahamc mentioned - Quicksilver - <USER2> LMDB for storage.

I don't have numbers, but it performs great for our needs. It's heavier on the disk though because of fsync, however unlike KT we never get database corruption on disk.

</comment></comment><comment><USER22> When investing key value stores for trying to beat a nosql speed record Kyoto Tycoon and LevelDB came up as low latency alternatives.

[http://blog.creapptives.com/post/8330476086/leveldb-vs- kyoto...](http://blog.creapptives.com/post/8330476086/leveldb-vs-kyoto- cabinet-my-findings)

Seems like KyotoDB is beating LevelDB on performance?

<comment><USER23> Google's original LevelDB microbenchmark report shows LevelDB soundly beating Kyoto.

[http://www.lmdb.tech/bench/microbench/benchmark.html](http://www.lmdb.tech/bench/microbench/benchmark.html)

But using the exact same code and microbenchmark, LMDB obliterates them all.

[http://www.lmdb.tech/bench/microbench/](http://www.lmdb.tech/bench/microbench/)

All with full ACID transactions and crash-proof reliability.

</comment></comment><comment><USER24> I used KT back in the day, but found LMDB to be much more reliable and performant.

</comment><comment><USER25> I was a huge Tokyo Cabinet fan back in the day. Was a big step up from BerkeleyDB for some workloads we were doing a lot. Always disappointed it was so fractured with successors and less adoption than I felt it deserved.

</comment><comment><USER26> The benchmark is likely limited by Python. You can't really test Redis' speed with Python, not in one process.

<comment><AUTHOR> The purpose of the benchmark was to see the _relative_ performance of the two databases.

<comment><USER26> You won't see the performance of the database if the time is spent in the Python driver.</comment></comment></comment>


Yarn author creates MIT license excluding Microsoft, Apple, Tesla, Amazon... - <AUTHOR> https://github.com/jamiebuilds/license <comment><USER2> A few of those companies are subsidiaries of other companies on the list; further, as drafted it's virtually unenforceable.

I like the sentiment, it's just missing some execution elements.

</comment><comment><USER3> "Microsoft Corporation" (for working with ICE)"

What's ICE? Immigration and Customs Enforcement?

<comment><USER4> Yes, a while ago Microsoft said, in a blog post (here [https://blogs.msdn.microsoft.com/azuregov/2018/01/24/federal...](https://blogs.msdn.microsoft.com/azuregov/2018/01/24/federal- agencies-continue-to-advance-capabilities-with-azure-government/)), that it was offering cloud services to federal agencies (ICE was among the other ones) and was proud of the work.</comment></comment>


[What Do You Get in Return for the] App Store 30% cut - <AUTHOR> http://www.manton.org/2011/01/app_store_30_cut.html

<comment><USER2> Haha, recently used a DTS Support Incident for an issue I would have liked to overcome in the UI.... and even after stating that my plan was to make it into the MAS, the two responses I got were basically "you need to override these private methods however Apple recommends against using private APIs, blah, blah."

My app isn't ready yet, and so I haven't submitted it to see what happens, but to this day, I still don't know what he was recommending me to do or if he was trying to say they would ignore the private API usage?

For a potential 30% cut, I agree with the OP that you should be able to get a straight answer.

<comment><AUTHOR> And if not the cut then the developer license fee.</comment></comment>


The Rise of Visual Content Marketing (explainer video) - <AUTHOR> http://videoigniter.com/blog/the-rise-of-visual-content-marketing-video/ We connected with Linkedin's Senior Manager of Content Marketing, Jason Miller, to learn why visual content like video is more effective for marketers than text-based content.<p>In this video, you'll learn: - Why visual content is more effective than text-based content - How to start making visual content today for free <comment><USER2> Awesome!</comment>


The "greased sled" theory of Stonehenge - <AUTHOR> https://www.atlasobscura.com/articles/how-was-stonehenge-built-pig-fat <comment><USER2> About 2/3 down of this page suggests grease has been tried before and was not effective: [https://en.wikipedia.org/wiki/Theories_about_Stonehenge#Cons...](https://en.wikipedia.org/wiki/Theories_about_Stonehenge#Construction_techniques_and_design)

<comment><USER3> As someone who's moved a lot of machinery the hard way (i.e. not paying someone else to do it with a fork lift) I like the stone rollers and wood track the best. One dude with a pry bar can roll a >3-ton (per the manufacturer, not just a guess) mill sitting on rollers sitting on 2x4s sitting on rough ground (protip: vary the thickness of the lumber depending on how much you want it to conform to the ground). A 100+ people should have no problem rolling a 40-ton stone if said stone is sitting on a wood and roller sandwich. If you have a 10yr project deadline you could build a few miles of track a year, get the whole village together, roll the stone a few miles over the course of a week then throw a party to celebrate how far you've moved the stone then leave it to sit for 6mo and do it again.

<comment><USER2> And presumably, with a large enough team, the "track" could be lifted once the stone has gone over it, and relaid at the front JIT.

I also think that the people of the time were very adept at working with large tree trunks. Many late stone-age structures used them extensively, eg large round houses, platforms on lakes, etc. Fashioning smooth round rollers would have been relatively straight-forward for them IMO.

</comment></comment></comment><comment><USER4> Bill Bryson on Stonehenge:

"Can you imagine trying to talk six hundred people into helping you drag a fifty-ton stone eighteen miles across the countryside and muscle it into an upright position, and then saying, 'Right, lads! Another twenty like that...and then we can party!'"

(Yes, I only know that quote from Civ 6)

<comment><USER5> If you consider how much time and effort goes into making a lot of movies and music which to all intents and purposes are identical as far as I can tell (but which I'm assuming makes someone a lot of money) then it's not clear why people find it puzzling that a bunch of smart (if missing some modern implements) people moved a few stones around a bit for a laugh.

<comment><USER6> "which to all intents and purposes are identical as far as I can tell"

What naked disdain for the creative labor of others.

<comment><USER7> I didn't read that comment as disdain at all; just drawing an equivalence between prehistoric, not-necessary-for-survival activites and modern not- necessary-for-survival activities.

</comment></comment></comment></comment><comment><USER8> I did some reading around to see how chariot axles were done at the time. This predates the chariot, the wheel and possibly domestication itself.

So even my visions of a nice iron age pig farm is as likely to be a reality of hunting wild boar in the forest, on foot.

<comment><USER9> Stonehenge is around 3-2000 BC, the iron age in, say, France started at about 700 BC, pig domestication started from beyond 10000 BC according to Wikipedia, so an iron age farm is conceivable. Partly domesticated pigs could also simply stay close to human settlements, without any tech necessary.

</comment></comment><comment><USER10> Solved by W. Wallington over a decade ago. The stones "walked", just like the old tales say. _One_ man could have built Stonehenge.

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

</comment><comment><USER11> 140 miles to haul a bunch of 1-2 ton stones on perfectly flat ground with grease is one thing, if there are any minor hills or a good set of them, that would require massive amounts of energy.. any chance they used animals at all?

<comment><USER12> If you want some archaeological engineering theories that aren't obviously wrong, I highly recommend this youtube series about how the Antikythera mechanism could have been made. [https://www.youtube.com/watch?v=ML4tw_UzqZE](https://www.youtube.com/watch?v=ML4tw_UzqZE)

It's the complete antithesis of this pig fat hogwash.

</comment></comment><comment><USER13> This is probably a less effective approach than the "fed a gaul some magic potion and got him to throw it 140 miles" theory.

<comment><USER14> Who said fat? (I'm just well-built, that's all.)

</comment></comment><comment><USER15> I suspect that if we could figure out how Edward Leedskalnin did it[0], we could probably piece-together if Stonehenge was done the same way.

[0] - [https://en.wikipedia.org/wiki/Coral_Castle#History](https://en.wikipedia.org/wiki/Coral_Castle#History)</comment>


Was Tony the Tiger Driven Off Twitter by Unbelievably Horny Furries? - <AUTHOR> https://www.huffingtonpost.com/entry/tony-tiger-frosted-flakes-horny-twitter-furries_us_5bc015e8e4b01a01d689054b?6r <comment><USER2> Some of those tweets are over the top.

"Fill me up with your frosted flakes daddy"

How do we know that these people are not simply 4chan trolls and not legitimately furries?

<comment><USER3> Its obviously a 'self aware' chan joke. There is a pretty big chan culture and furry culture overlap because of the many conflicts between the userbases. Eventually the furries won and now inhabit quarantine boards on 4chan.

The whole "brony" thing, for instance, was started on 4chan and started a practical civil war that ended with the dedicated quarantine board /mlp/. Furry and mlp porn was so frequently used to nuke threads on various boards that another quarantine board, /trash/, was created to hold everything that no one else wanted to look at. The idea was that the spammers would be happier hanging out, umm, discussing their artwork of choice, and forget to mess with everyone else. It seems to have worked actually.

As for over the top, well, we are talking about people who spend thousands of dollars on animal costumes</comment></comment>


How one small American VPN company is trying to stand up for privacy - <AUTHOR> http://arstechnica.com/tech-policy/2013/10/how-one-small-american-vpn-company-is-trying-to-stand-up-for-privacy/ <comment><USER2> Any american-based VPN company should be assumed to be a honeypot—use it to dodge your ISP, not governments.

<comment><USER3> While I don't wholeheartedly agree with the honeypot allegation, I do agree that you should take most VPN providers with a grain of salt, be it that they are in fact a honeypot, occasionally leak data, or do shady things like actually inspect traffic.

An additional use, and the one I use VPNs for from time to time, is to throw off ad-network information and avoid over-disclosing information about myself.

<comment><USER2> I'm quite sorry, I didn't intend to imply that PIA is a honeypot. I use PIA every day (I'm using it now!). My point was to say that at the end of the day, we must assume the government has access to all servers and services potentially subject to National Security Letters until proven otherwise.

If the government wants to snoop on you, a VPN is one NSL away from having full access to all future use unless you hide your identity and money trail very carefully.

</comment></comment></comment><comment><USER4> I seem to recall seeing information recently about one company that has taken steps to ensure that their technical people are outside the US and that the staff (& founder?) remaining within the US no longer had any access to network management, software, etc. so there could be no question of them being forced to backdoor anything. Is that PIA?

<comment><USER4> Replying to myself now that I've had a chance to research, here's the relevant link: [http://torrentfreak.com/how-nsa-proof-are-vpn- providers-1310...](http://torrentfreak.com/how-nsa-proof-are-vpn- providers-131023/) partway down the page, in the section on National Security Letters and Private Internet Access.

Quoting Andrew Lee: "However, to remain in the US, meant, as well, the relinquishing of my access to the PIA systems/network. Administrators, developers and co-founders everywhere can relate to the difficulty of doing so, but the reality is that it was a requirement if I was to remain here. This policy is in place, and relinquished access I have."

There's significantly more information in the original article.

</comment></comment><comment><USER5> Don't assume just because X service says they're not logging data that someone else isn't. In this case PIA might not be logging user activity, but as the NSA have proven in the past, it's all too easy for them to get a secret court order and install hardware into a data centre server rack that monitors network activities for a particular service. They've done it before and if they wanted too, they could do it again.

The scary part is if it's a secret court order, the service provider is gagged and threatened with legal action if they publicly disclose the fact they're complying with a Government request. Being an American based company all the more makes it too easy for the NSA to get the information if they need it. This article does not make me feel any less insecure about my privacy.

<comment><USER6> Cory Doctorow wrote a piece for _The Guardian_ [1] theorizing a sort of "dead- man's switch" for this that might allow you to circumvent a gag order. Basically, you regularly post a signed message saying "we have not yet been compromised" \-- and then when you are, you just STOP posting that.

As Doctorow mentions in his article, the basic idea is not new -- it originated in 2004 with Jessamyn West, a librarian trying to fight back against the FBI trying to look at patron's reading habits, and the accompanying gag order. In that case, it was:

> a sign on the wall of her library reading "THE FBI HAS NOT BEEN HERE (watch > very closely for the removal of this sign)."

[1]: [http://www.theguardian.com/technology/2013/sep/09/nsa- sabota...](http://www.theguardian.com/technology/2013/sep/09/nsa-sabotage- dead-mans-switch)

<comment><USER7> I think that one of the claims in the parent was that the feds can just hand the NSL to the data centre provider or whatever and monitor all the traffic that way -- they don't necessarily need compliance from the person running the service.

<comment><USER6> True -- but then there's nothing stopping the datacenters from having a "warrant canary" either.

</comment></comment></comment></comment><comment><USER8> For a privacy protecting VPN where you can't trust governments: There is really no policy-only way to trust a provider of a security-specific service where turning on logging is just flipping a single bit. There has to be some kind of technical measure to protect users, and no one has built that (yet).

It also will take a pretty clear Chinese wall between builders and operators of a service, or even an arms length multi entity relationship (eg a meta VPN provider sells sells fairly turnkey VPN nodes to operators, who then run them; maybe a third entity which does billing for end users and rev shares everything out). Much more like Tor than the commercial VPN services of today.

The corporate VPN world is different, and the simple "torrent shit on comcast" or "watch Netflix on vacation" market is way easier.

IFF lavabit is resolved successfully, you may be able to trust a US provider for general privacy stuff, but that is months or years off.

<comment><USER9> > IFF lavabit is resolved successfully, you may be able to trust a US provider > for general privacy stuff, but that is months or years off.

I've read through lavabit's filing and I'm not sure the factual predicates are as strong as they possibly could be. So they could lose on narrow grounds and still leave the door open for other companies to argue that it is possible to create a reasonable expectation of privacy for its customers in their metadata.

However if lavabit loses and the decision is written broadly, you are right that it is probably game over for any system that requires you to trust the subject to US jurisdiction operator in any way.

</comment></comment><comment><USER10> I'm the "head guy" at the ISP I work for. I'm also the "owner" (single member manager) of two LLCs that I've formed but that are mostly inactive at this point.

Unfortunately, I've been delayed (due to a fairly major motorcycle versus Jeep accident that has me laid up) but I've been considering offering a similar service (as well as Tor relays, including an exit node or two).

For those of you who (might) use such services, what would it take for you to trust a provider? An AUP/ToS stating "we don't log", a so-called "transparency report", a warrant canary, payment via Bitcoin?

<comment><USER8> There needs to be some separation between configuring the system and auditing it. If you could only push configs through something like rancid, made it read only to auditors or users, and could ensure configs only could get pushed through that, it would be reasonably to trust it. It is hard when anyone can either bypass config management to add logging, or where the audit doesn't include all systems in scope, or is only done yearly (so bad stuff can happen in between).

</comment></comment><comment><USER11> Whether a website is ranking VPN services or just discussing them, PIA is almost always mentioned before any other provider. I wonder how much they are paying for these types of advertisements...

<comment><USER8> Don't hate them for good marketing!

I think the lifetime value of a VPN customer is >$50 (accounts tend to churn but it is be same people getting new ones, in my experience with VPNs from before; users either fall into the long term customer bucket or use then for single purposes).

I've only seen their ads or promo stuff in very targeted places, as well as bitcoin (which is more them sponsoring it due to early involvement with bitcoin), so even high cpm would make sense. People go to " top VPN provider" lists with intent.

I see anchor free and hidemyass much more in general ads and forums. AF is free and ad supported, and mega capitalized, so that is probably why they go for random high volume stuff

</comment></comment><comment><USER12> Too bad it doesn't matter. As long as the US government can do what it does with forced silence, I'm not trusting any provider within the border.

<comment><USER13> Can you really trust other countries any more? If so, why do you think so?

<comment><USER14> I think we should ask Angela Merkel ? ;-)

</comment></comment></comment><comment><USER15> Unfortunately I don't think it's the right country to run a VPN service from, these days.

</comment><comment><USER16> Did Google say the paid advertisements should have disclaimers?</comment>


What You Can Learn From ido.el (Emacs vs. TextMate) [video] - <AUTHOR> http://www.vimeo.com/1013263 <comment><USER2> I was a little disappointed he never touched on the best use of fuzzy matching: function names. Lisp would probably look like APL or Perl if we actually had to type "with-open-file" instead of just "w o f TAB RET".

<comment><USER3> Interesting. I suppose we can, in part, blame Arc's brevity on the fact that Paul Graham uses vi:

<http://paulgraham.com/pfaq.html>

</comment></comment><comment><USER4> This just makes me feel like I really need to work on becoming a more advanced user of emacs. I don't utilize the built in power of emacs nearly enough.

<comment><USER5> I tried ido a few times, but never really liked it. I felt like it was jumping ahead of me, often in directions I didn't want to go.

I like Icicles much better. It offers lots of features like ido, but I actually need to press a key before they happen.

<http://www.emacswiki.org/cgi-bin/wiki/Icicles>

<comment><AUTHOR> _ido_ has advantage that it is included in Emacs22 (no third-party packages required)

</comment></comment></comment><comment><USER6> Ah, Stuart showed us his typing abilities</comment>


Shopify launches network of fulfillment warehouses and shipping in U.S. - <AUTHOR> https://business.financialpost.com/news/retail-marketing/shopify-launches-network-of-warehouses-and-shipping-in-u-s-to-handle-orders-for-independent-merchants <comment><AUTHOR> called it: [https://news.ycombinator.com/item?id=18524131](https://news.ycombinator.com/item?id=18524131)</comment>


The Top Problems in Machine Learning for 2013 - <AUTHOR> http://www.quora.com/Machine-Learning/What-are-the-Top-10-Problems-in-Machine-Learning-for-2013

<comment><USER2> I think it's sad that people at one of the world leading machine learning institutions would name "Recommendations" and "Online Advertisement" as part of the top 10 challenges for machine learning in 2013.</comment>


Creation Myth – Xerox PARC, Apple, and the truth about innovation (2011) - <AUTHOR> http://www.newyorker.com/magazine/2011/05/16/creation-myth <comment> vezzy-fnord _Jobs's software team took the graphical interface a giant step further. It emphasized "direct manipulation."_

And this right here is a major point of contention.

The standard WIMP GUI that is taken for granted today (and that evidently DE designers have a hard time shaking off even when supposedly attempting to "break new ground" \- see GNOME 3 and Unity) might have ended up being the lesser approach.

The PARC conception of a GUI (later emulated by Niklaus Wirth/ETH Zuerich's Oberon, as well as Rob Pike's 8 1/2, rio, help and acme) really had this knack for actually enforcing composability.

In present GUIs, windows are mostly dumb, isolated and unable to talk. In addition, they are very difficult (if not outright unfit) for automation. Acceptance testing frameworks like Selenium which run as headless browsers show this isn't a problem if there's a common serializable representation (HTML, DOM...), but not so for desktop GUIs.

All text on screen is modifiable, regardless of where it is. Text is executable. A lot of common scenarios where people cook up quick scripts for task automation are effectively made obsolete, given that the desktop itself is one big programming environment without the user really being told it is. Task launchers/run dialogs are no longer needed.

More recent research, like Bluebottle OS (de facto successor to Oberon?), has experimented with zoomable interfaces. These obsolete virtual desktops entirely, because you have infinite (by the colloquial definition of infinity, of course) space to work on.

It's this drive to move beyond WIMP that has motivated a lot of people toward tiling window managers. Ironically enough, they are also the most primitive and simple to create, which really says something. Still pales in comparison to the classic GUI, though.

<comment><USER2> >The PARC conception of a GUI (later emulated by Niklaus Wirth/ETH Zuerich's Oberon, as well as Rob Pike's 8 1/2, rio, help and acme) really had this knack for actually enforcing composability.

Sounds really interesting can you point to some resources where I can read about this in greater detail?

<comment><USER3> Installing plan9 is about as close as you can get without reading but actually using those concepts. There is quite a strong link between all those projects.

</comment></comment></comment><comment><USER4> I recommend anyone interested in PARC read "Dealers of Lightening" by Michael Hiltzk.[1]

It's been argued that the profits from the laser printer paid for the money spent on PARC a 100 fold. I'd agree with that. That said, I don't think Xerox could have been the new IBM/Microsoft/Apple combined - simply because their sales force was.. addicted? to the per imprint commission model, and it would be a huge change to go to a different model for them. So while PARC could have invented it, and they could have possibly gotten it into production, I don't think their existing sales and support force understood enough on how to sell and service it.

[http://www.amazon.com/Dealers-Lightning-Michael-Hiltzik- eboo...](http://www.amazon.com/Dealers-Lightning-Michael-Hiltzik- ebook/dp/B0029PBVCA/ref=tmm_kin_swatch_0?_encoding=UTF8&sr=&qid=)

<comment><USER5> Reminds me of Kodak. They had the future, but it didn't have meaning in the mind of the company. Large thriving systems seem to lack enough schizophrenia to understand what they need to do to survive.

<comment><USER6> I was at Kodak when the terminal decision was made. Among other factors... Film sales were driven by retailers/drugstores, which were hooked on the model of customers visiting to buy a roll, another visit to drop off the roll, and a third visit to get the prints - and odds were that they'd buy _something_ on each trip. When digital photography started catching on, those stores made clear that if Kodak did anything to disrupt that pattern, they'd drop Kodak products _fast_ and destroy the company. Ergo, Kodak was reluctant to dive into digital. Yeah, there was a long-term plan to cope, but nowhere near as fast a transition as customers made.

I tried to push the idea of a cell-phone-equipped camera which would immediately upload images and mail you prints, but was a mere peon so that went nowhere.

Don't lose sight of who your REAL customers are. Bulk buyers who resell product aren't.

 _lack enough schizophrenia_

Great line.

<comment><USER7> Those are good insights. You could probably add to that the fact that exhortations to avoid "marketing myopia"[1] aside, it's not all that clear what distinctive capabilities Kodak brought to the digital photo game. It certainly wasn't their chemical supply chain (though they sold off Eastman Chemical a long time ago). Nor was it especially their distribution channels many of which, as you suggest, were actually negatives in the context of a digital shift.

Furthermore, consumables businesses--especially one as rich as the film business--are hard to replace. Printing had some of the same characteristics for a while and Kodak was somewhat in there. They did the online photo service too. But nothing like film sales and processing. Kodak could have done better but it would have been a tough navigation. Fujifilm seems to have dome OK but by a very circuitous route taken by a smaller company.

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

<comment><USER6> _it 's not all that clear what distinctive capabilities Kodak brought to the digital photo game_

At one end, they had hands-down the best & fastest imagers. 13 years ago they had a fantastic camera in a manageable size & price which could have been, in time with effort, worked into a consumer product. They had a great start into dominance as a digital capital company.

At the other end, at core Kodak was a very large scale chemical consumables company.

Alas, it's very hard for a company to transition from a core competence to its polar opposite.

<comment><USER5> _13 years ago they had a fantastic camera ..._ What model ?

A documentary said Eastman/Kodak was a strong influence on Apple, now its successors as extremely successful company, using similar philosophy, simple and focused products + distribution scheme, albeit virtual now.

</comment></comment></comment></comment></comment></comment><comment><USER8> Back in the late 70's, I worked at a company called Aph. They had developed everything in house that could be used to build a PC, and the stuff was way ahead of what else was around at the time. The company was composed of numerous brilliant people (Hal Finney was one).

But what was lacking was somebody with vision to notice what we had. And so it was all for naught.

</comment><comment><USER9> "You're ripping us off!", Steve shouted, raising his voice even higher. "I trusted you, and now you're stealing from us!"

But Bill Gates just stood there coolly, looking Steve directly in the eye, before starting to speak in his squeaky voice.

"Well, Steve, I think there's more than one way of looking at it. I think it's more like we both had this rich neighbor named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it."

[http://www.folklore.org/StoryView.py?story=A_Rich_Neighbor_N...](http://www.folklore.org/StoryView.py?story=A_Rich_Neighbor_Named_Xerox.txt)

<comment><USER10> Steve went to the neighbours and paid to use the TV, Gates came and took it. If you were a developer in the 90's, Gates is still more evil than Jobs ever was, and philanthropy years later doesn't wash away the sins. Ruthless, but with enough money, it appears you can make people forget.

<comment><USER11> > philanthropy years later doesn't wash away the sins.

You could argue that they do, in the sense that stealing software/design isn't particular "evil", while Gates' recent philanthropic efforts are most certainly "good". I'm not saying what Gates did back then was right, but it really only led to damage localized to an industry; it didn't endanger people's lives or destroy culture. As a counter example, I'd call the RIAA/MPAA evil, in that they promote copyright extension and censorship, both of which directly damage culture. Back to the argument, improving the quality of life for millions of people is something I put squarely in the "good" category. In other words, Gates' previous actions didn't harm the quality of life for anyone, but his recent actions improve quality of life. So I call that "washing away the sins."

But please don't take that argument too seriously, because I don't. Its myopic and doesn't take into consideration the other, worse, things that Microsoft has done (that actually harmed people's quality of life). And really, quantifying these things is quite difficult. I'm just presenting an alternative viewpoint.

<comment><USER12> >in the sense that stealing software/design isn't particular "evil",

Stealing ideas may not be that evil. Stealing ideas, then rabidly attacking anyone who attempts to copy you does seem more evil.

</comment></comment></comment></comment><comment><USER13> There's a big difference between invention and innovation. Both are important, but we do less and less of the former. The idea of a mouse before PARC must have seemed a little crazy, whereas the idea of the iPhone before 2008 seems a little inevitable.

Alan Kay's recent talk "The Future Doesn't Have To Be Incremental" goes over this yin and yang of the two 'i' words of our industry with authority. Worth a watch.

<comment><USER3> The mouse was already in 'the mother of all demos'.

[https://www.youtube.com/watch?v=yJDv- zdhzMY](https://www.youtube.com/watch?v=yJDv-zdhzMY)

31:54

</comment></comment><comment><USER14> This seems like a great time to post the phenomenal Everything is a Remix [1]. Part one discusses movies, part two film, and part three discusses interfaces for computers, with special emphasis on Xerox PARC, Apple, and the Mac.

1\. [http://everythingisaremix.info/watch-the- series/](http://everythingisaremix.info/watch-the-series/)

</comment><comment><USER15> Now that computing has shifted towards mobile, do WIMP UIs even matter? In the mobile space Jobs clearly had the last laugh over Microsoft.</comment>