Bond – An extensible framework for working with schematized data - <AUTHOR> https://microsoft.github.io/bond/manual/bond_cs.html <comment><USER2> The Bond compiler is written in Haskell: [http://blog.nullspace.io/bond- oss.html](http://blog.nullspace.io/bond-oss.html)

It is about time considering that Microsoft research has been one of the main funders of work on the Haskell compiler.

<comment><USER3> I've saw this yesterday, pretty happy about it, but then.. see that the compiler was coded in haskell..

This make it pretty "unportable" because its the same dependency with the Java VM, so how can i distribute code with this library, with a dependency like that, asking people to download the whole GHC ?!

Unfortunately for libraries that should be embedded in third-party code, the reality beyond C/C++ is pretty harsh.. for full applications the reality is different.. but for embedded libraries.. despite the fact that i've liked the solution for something im doing, i had to pass because of this small detail.. and im too busy to write a parser in C++ to make this more portable in source code form.. so i had to get back to protobuf :/

<comment><USER4> You need Haskell only to build the Bond compiler. Once you do that, you get a native, stand-alone executable for your system (you don't need Haskell to run the Bond compiler). You use the Bond compiler as part of build process for programs using Bond. Programs using Bond don't have any Haskell dependency.

<comment><USER3> Im sure there's no problem to distribute it in binary form, the problem would be in the source code distribution, giving you add the dependency on the GHC compiler for everybody/dev that need to build the program.

Im working on something that can have a lot of dependencies in thirdparty libs, so i need to minimize the dependency side-effects.. so despite the fact i like this more than protobuf, i'll have to stick with it (cap'n proto had to rewrite from haskell to c++ because of this).

PS: Oh no, The haskell inquisition downvotes (as expected)

<comment><USER5> You're being downvoted because your point is nonsensical. First, GHC is not the same as requiring Java, since you don't need it to _run_ the code. If you replaced Java with C++ your first comment would be more accurate. Second, complaining you need a compiler for Haskell to compile the source code version...you might as well complain you need a C++ compiler to compile your code. I know _I_ don't have a C++ compiler installed, so how is installing GHC any more onerous than installing G++?

<comment><USER3> >First, GHC is not the same as requiring Java, since you don't need it to run the code

I think you dont read what i've wrote, or more likely, im explaining it poorly(not a native, sorry) . This __can __be a binary to compile and create source code, but also and often can be embedded to be used as a library.. im guessing you are using Windows because you 've said you dont have a c compiler at hand.. but Windows are most a end-user thing, and end-users probably wont care about compiling code.. otherwise a c/c++ compiler is ubiquotous

Im not complaining about the tool, but about the use as a library, which is something this also aim to be, and C is a better aim at that because can be embedded in any language.. given the compiler is in haskel i cant access the AST for instance, i cant embed in my binary, but have to call another external binary instead.. but at least have a runtime to embed.. this may be ok for some.. but i was just saying that, despite the protocol language being very good, i couldnt use it instead of protobuf because i would have a more limited api and my end program/ goal would lose power and flexibility.

This is a pretty technical explanation, it could be coded in Brainf*ck.. nothing against the lang in itself.. is just that it limits the use case of this tool(as compared with protobuf)

<comment><USER6> > end-users probably wont care about compiling code.. otherwise a c/c++ > compiler is ubiquotous

ghc is pretty ubiquitous these days. Any serious linux distro will have a package so it's one line (apt-get install ghc or similar). Even on e.g. a mac it's no harder than installing ruby or python.

> given the compiler is in haskel i cant access the AST for instance, i cant > embed in my binary, but have to call another external binary instead

You could write Haskell. It's a pretty nice language.

More to the point, Haskell does have a C FFI and allows you to build a library that exposes a C interface that C programs can link against. I don't know whether the authors have done that here, but the functionality is available.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Slightly OT- I'm working with data sets that might change, but not often if at all, which are provided by Elasticsearch. I'm processing the raw data in Flask (API), munging, joining, and dropping what I don't want going out to the world.

I've been toying with the idea of using something like PB, Cap'n Proto, or now Bond to define and track schema changes and centralize marshaling / serializing logic. I'm not concerned about having RPC. Does this sound like crazy talk? Anyone else happen to track schemas agains schemaless data stores?

(I also like the idea of not having to ship JSON everywhere if I don't want to.)

<comment><USER8> TL;DR by using more of the available features in ElasticSearch, you can probably replace all of your external app with ElasticSearch.

A few things:

\- ElasticSearch is definitely not schema-less, but it can try to generate a schema (aka "mapping") for you if you don't give it one: [http://www.elasticsearch.org/guide/en/elasticsearch/hadoop/c...](http://www.elasticsearch.org/guide/en/elasticsearch/hadoop/current/mapping.html)

\- ElasticSearch has tons of ways to customize the data you get back, so, unless you really don't want the ES cluster crunching things for you, you can do a lot of the transformation server-side. You can go so far as to have your own type + mapping for e.g. a report, which sources data from another type and transforms it: [http://www.elasticsearch.org/guide/en/elasticsearch/referenc...](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping- transform.html)

\- This covers both why the schema can't, by nature, be dynamic (so the argument of "schema-less / dynamic schema" is BS in practice IMO), as well as how to get data out from one index an into another (e.g. your "report" index which does scripted transformation).

\- Another idea would be to use the scripting module to write a custom "view": [http://www.elasticsearch.org/guide/en/elasticsearch/referenc...](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules- scripting.html)

\- You can use Groovy, mvel, JS, or Python for scripts. If you combine this with how ES lets you do "site plugins", you could make a JS + CSS + HTML site which is actually served by the ES cluster, which interacts with it and generates reports or whatever all without additional infrastructure. Example: [https://github.com/karmi/elasticsearch- paramedic](https://github.com/karmi/elasticsearch-paramedic)

</comment></comment><comment><USER9> It's cool that the .NET version actually JITs specialized serialization and deserialization code at runtime. This is one place where managed languages really shine, because emitting bytecode is easier and more portable than emitting, say, raw x86. It's also safer -- the runtime can verify the memory safety and type safety of the code.

<comment><USER10> Is it? To start that JIT process, you need to have a class in your code that the compiler for the .NET version generated. Disk space is cheap nowadays, even on mobile, so I do not see a big disadvantage of generating the deserialization code at the same time the source code for the class gets generated (and if you things that way, you lose get one-time delay, and you don't need the code that generates those serializers in your application)

What a I overlooking? What information is know at runtime that isn't already available at build time? (And no, "the exact CPU/memory/etc. the code runs on is not a valid answer. This is C# code, so there always is a runtime that handles that stuff)

<comment><USER4> There are two advantages to generating code at runtime:

1) In some scenarios you have information at runtime that allows you do generate much faster code. The canonical example is untagged protocols, where serialized payload doesn't contain any schema information and you get schema at runtime. Bond supports untagged protocols (like Avro) in addition to tagged ones (like protobuf and Thrift) and the C# version generates insanely fast deserializer for untagged.

2) It allows programmatic customizations. If the work is done via codegen'ed source code then the only way for user to do something custom is to change the code generator to emit modified code. Even if codegen provides ability to do that, it is very hard to maintain such customizations. In Bond the serialization and deserialization are composed from more generic abstractions: parsers and transforms. These lower level APIs are exposed to the user. As an example imagine that you need to scrub PII information from incoming messages. This is a bit like deserialization, because you need to parse the payload, and a bit like serialization, because you need to write the scrubbed data. In Bond you can implement such an operation from those underlying abstractions and because you can emit the code at runtime you don't sacrifice performance.

BTW, Bond allows to do something similar in C++. The underlying meta- programming mechanism is different (compile-time template meta-programming instead of runtime JIT) but the principle that serialization and deserialization are not special but are composed from more generic abstractions is the same.

<comment><USER10> Ad 1): if you don't know at compile time what kind of objects you will deserialize, you need to do more than generate the serialization code; you also need to generate the class. So, basically, you need the entire schema compiler. I still don't see why separating those two generation steps is a gain.

Ad 2): does this mean that one can also do efficient schema migration at deserialization time (rename fields, add fields with default values), or that one can deserialize to something else than the class that got generated when the schema was compiled?

<comment><USER4> 1) I didn't do a good job explaining this. You are right that if you want to materialize an object during deserialization you need to know a schema at build time to generate your class. But the crucial things is, and this is true of all similar frameworks, you don't know the schema of the payload at that point. One big reason you use something Protobuf, Thrift or Bond is to get forward/backward compatibility. What this means in essence is that deserialization is always mapping between schema you built your code with and schema of the payload. There are two common ways to do that mapping: (a) payload has interleaved schema information within data and you perform branches at runtime based on what you find in the payload (this is what Protobuf, Thrift and Bond tagged protocols do) (b) you get schema of payload at runtime and use that information perform the mapping (this is what Avro and Bond untagged protocol do). The latter case is particularly suitable for storage scenarios: you read schema from file/stream header and then process many records that have that schema. This is the case where having ability to emit code at runtime results in a huge performance win: you JIT schema- specific deserializer once and amortize this over many records.

2) You can do both. You can also do type safe transformations/aggregations/etc on serialized data w/o materializing any object.

</comment></comment></comment></comment></comment><comment><USER4> There's been a lot of questions on how Bond compares to Protobuf, Thrift and Avro. I tried to put some information at this page: [http://microsoft.github.io/bond/why_bond.html](http://microsoft.github.io/bond/why_bond.html)

</comment><comment><USER11> No RPC? Disappointing. There are so few choices C and C++ programmers with regard to battle-tested, easy (read: code generation for decode and dispatch), language-agnostic RPC.

<comment><USER12> Have you tried any of the MessagePack RPC implementations? I haven't but I'm curious.

<comment><USER13> i recently evaluated msgpack-rpc and thrift for a small side project. surprisingly it turned out that msgpack was not only much faster but also way easier to use (for lots of small messages).

i got around 300k msgs/s throughtput with msgpack-d-rpc

</comment></comment></comment><comment><USER14> How would this compared with apache thrift?

<comment><USER4> See [https://news.ycombinator.com/item?id=8868045](https://news.ycombinator.com/item?id=8868045)

</comment></comment><comment><USER15> how does it compare to protobuf,thrift ?

<comment><USER16> Quoting apc @ [https://lobste.rs/s/7w6p95/msft_open_sources_production_seri...](https://lobste.rs/s/7w6p95/msft_open_sources_production_serialization_system_written_partially_in_haskell/comments/kh9zpl#c_kh9zpl)

The current offerings (Thrift, ProtoBuffs, Avro, etc.) tend to have similar opinions about things like schema versioning, and very different opinions about things like wire format, protocol, performance tradeoffs, etc. Bond is essentially a serialization framework that keeps the schema logic stuff the same, but making the tasks like wire format, protocol, etc., highly customizable and pluggable. The idea being that instead of deciding ProtoBuffs isn't right for you, and tearing it down and starting Thrift from scratch, you just change the parts that you don't like, but keep the underlying schema logic the same.

In theory, this means one team can hand another team a Bond schema, and if they don't like how it's serialized, fine, just change the protocol, but the schema doesn't need to.

The way this works, roughly, is as follows. For most serialization systems, the workflow is: (1) you declare a schema, and (2) they generate a bunch of files with source code to de/serialize data, which you can add to a project and compile into programs that need to call functions that serialize and deserialize data.

In Bond, you (1) declare a schema, and then (2) instead of generating source files, Bond will generate a de/serializer using the metaprogramming facilities of your chosen language. So customizing your serializer is a matter of using the Bond metaprogramming APIs change the de/serializer you're generating.

<comment><USER11> Thrift _has_ pluggable protocols. It comes with 'compact' (protobuf-like), 'dense', 'binary' and json out of the box. It also has pluggable transports and multiple server implementations (threaded, async, etc). I'm personally not seeing any innovation here... I think they just wanted their own version of Thrift such that they could ignore the languages they don't care about.

<comment><USER17> > I think they just wanted their own version of Thrift such that they could > ignore the languages they don't care about.

I'll put it bluntly: you have no idea what you're talking about.

Bond v1 was started when Thrift was not production ready. This is Bond v3. There is no conspiracy to make Bond hard to use for technology we "don't care about." In general I'm fine with tempered speculation, but your conclusion here is just lazy, and we both know it. It contributes nothing to the conversation, and spreads FUD for no good reason. We can do better, agree?

Now, to address your comments about customization directly: pluggable protocols are an _example_. The metaprogramming facilities of Bond are dramatically more rich than those of Thrift. A good example of these facilities: using the standard metaprogramming API and a bit of magic we have been able to trick Bond into serializing _a different serialization system 's_ schema types. So, picture Bond inspecting some C# Thrift type (or something), and then populating the core Bond data structures with data it finds there, and then serializing it to the wire.

 _This_ is the kind of power you get when you construct the serializer in memory using metaprogramming, and then expose that to the user. The flexibility is frankly unmatched.

<comment><USER11> Microsoft could have pulled a Facebook (They improved the C++ server in FBThrift) and forked or rewritten Thrift, reusing the IDL and existing wire formats _if nothing else_ , and dropped a kickass C# implementation. The result would have been D, Rust, Go, PHP, and Python developers, etc etc, wouldn't have had to go off and reinvent the wheel for the Nth time, for negligible gain in terms of tooling, and an almost certain regression in terms of ecosystem and acceptance. I don't think it's FUD to express a bit of cynicism here or cry NIH Syndrome.

> I'll put it bluntly: you have no idea what you're talking about. Bond v1 was > started when Thrift was not production ready. This is Bond v3.

Let me put something bluntly. I don't care who started writing code first. Microsoft are well over half a decade late to the party. Thrift and Protobufs have been public domain since, what... 2007/8?

And frankly, at least on the C++ front, there's not much to get excited about with regard to metaprogramming here. The Avro C++ code generator already produces a small set of template specialisations for each record type, and they're trivial enough to write manually for any existing classes you wish to marshal against your schema. std namespace containers are already recognised through partial template specialisations. MsgPacks implementation also does this. Other more general metaprogramming solutions, like Boost Fusion, are also being used by many, in production, for completely bespoke marshalling.

Don't get me wrong, Bond looks really nice, particularly for C# programmers, and I have respect for the work being done, but I can't get excited about it. It's kind of like someone announcing yet another JSON library or some new web framework when what the industry needs is _consensus_ on formats and APIs. Right now there are so many serialization frameworks that the de-facto standard will just continue to be schema-less JSON and robust tools will remain largely non-existent.

<comment><USER4> I think your points are valid, especially about wire format compatibility. Bond and Thrift are in fact close enough that providing Thrift compatibility is a real possibility. It wasn't high enough on our priority list to make the cut but we do in fact use some Thrift-based system internally. The impedance mismatch in the type systems are higher between Bond and Avro/Protobuf so we will have to see about those.

I hear you on the fragmentation. I know that this doesn't help the community as an explanation, but big companies like Facebook, Google and Microsoft really have a good reasons to control such fundamental pieces of their infrastructure as serialization. Case in point: Facebook has forked their own Thrift project because, I presume, having it as Apache project was too restraining.

FWIW, we plan to develop Bond in public and accept contributions from the community.

</comment></comment></comment></comment></comment></comment><comment><USER18> And yet they still can't build a web page that isn't a shitshow.

Main content has horizontal scroll on portrait monitors, which underlaps the transparent fixed div they used for navigation.</comment>


I bought a domain at NameCheap today, because GoDaddy supported SOPA - <AUTHOR> http://martinkou.blogspot.com/2011/12/i-bought-domain-at-namecheap-today.html

<comment><USER2> me too, i moved 5 domains to namecheap today. i don't support sopa.</comment>


Digital upstarts taking on Britain's dominant few banks - <AUTHOR> https://www.economist.com/news/finance-and-economics/21737028-battle-between-one-side-novelty-technology-and-gusto-and-other <comment><USER2> Monzo is really good but I think it's unfair to characterise the high street banks as dinosaurs that never innovate. They almost all have phone apps that let you instantly send money to other people, often straight from your Contacts.

<comment><USER3> Disagree. Most of the UK banks are dinosaurs, inhibited by technical debt they were too scared and/or lazy to pay off.

I've used four established UK banks. Monzo is light years ahead.

Simple example: buy round in pub.

Monzo: "£10.50 spent at Red Lion in Shoreditch" immediately pops up. Balance is reduced.

All other banks I've used: <nothing happens for days, as long as a week>. Showing on app after that: "6-Feb CHG A LO SWIN 3868X £10.50" or similar garbage. And if that subsequently takes you overdrawn, well, your fault buddy! Should have tracked every penny you'd spent and run a spreadsheet to make sure you weren't going overdrawn. Not our fault you're too busy to itemise your spending, even though there's absolutely no good reason for you to have been required to do that for decades.

The first time I used Monzo, I topped up from my bank's debit card and bought something from the shop. My phone buzzed as I tapped the card reader and it gave me that magic moment feeling startups are always looking for. Five days later, the top up from my old bank appeared on my internet banking. After a minute, I realised what it was, laughed, and closed the old bank account.

<comment><USER4> personally I'd much rather have the bank-account-that-receives-my-salary have its transactions processed by prehistoric software running on an ultra- reliable mainframe instead of the latest version of mongodb or cassandra on AWS

I will however happily sign up, deposit the bare minimum and thank their VCs for paying the foreign exchange fees for my holiday :)

</comment></comment></comment><comment><USER5> I use Monzo, I can see what I spent where, and eacd 'where' is part of a broader category so I can see what is being spent by category. It is the ui that banking has needed for a long time.

It must be relatively easy to only operate the liabilities side of banking, its the assets (loans) side I would expect to be the most difficult path to navigate for new banks.

Nothing on the Monzo roadmap re loans: [https://trello.com/b/9tcaMB4w/monzo- transparent-product-road...](https://trello.com/b/9tcaMB4w/monzo-transparent- product-roadmap)

<comment><USER6> I used to work with the head of engineering at Monzo, smart guy.

I know he pushes a lot of their tertiary code open source.

</comment></comment><comment><USER7> Curious for those that use "upstart" banks, what convinced you to try out and move funds into that bank account? In the US at least, customer stickiness to their financial institution is extremely high and personally, the last time I opened a new bank account and moved out all of my funds was due to how I was treated as a customer at my old bank.

The other appealing draw for me was also high interest rate, but curious to hear what are the killer features for a digital bank.

<comment><USER8> Digital servicing and apps, no need to head into a branch, ever.

<comment><USER9> MM and you trust an easily losable, stealable, and hackable phone also prone to catastrophic failure with access to you bank account.

The UK broadsheet weekend financial sections regularly future people who have lost life changing amounts to fraud and the banks response is to shrug and say "data protection"

And you think an "app" based bank is going to be better.

<comment><USER10> I sometimes wonder how much of the UK economy is actually built on this fraud. The vast majority of these accounts are with UK institutions, it should be rather trivial to track down. Just the sort code alone tells you the bank and very often the branch.

I've heard it claimed that often the money gets transferred internationally from the shell account. Even so, the KYC for anti-money-laundering purposes should cover who owns the account it first lands in.

The most benign sounding explanation I've heard that sounds plausible is that privacy is a key selling point for UK financial services (I hear Switzerland isn't so private any more) and that main parties that investigate organized fraud (typically City of London police -- distinct from the Metropolitan police) know where their money's coming from.

Viewed from this perspective, every article on a couple being blatantly defrauded of their life savings is more like an advert for those international customers that might want a bank within a country that allows the whole banking system to take "data protection" to ridiculous levels.

<comment><USER4> very little I would imagine compared to the absolute vast amounts that travel around the financial system every day

</comment></comment></comment></comment></comment><comment><USER11> If you have a business and spending a lot of money on banking take a closer to the new Fintechs around the globe. If you are e.g. in the EU you are not forced to have a bank in the same country as your company... you can use any bank in the EU (and also beyond). It's also advisable to have bank accounts in different countries. I've seen more than once bank account blocks by state regulation although no crime was conducted, simply an computer error on tax authorities side (this can happen any time). Many banks live in the past and think they can charge a lot because there are no visible alternatives... but they are wrong in the digital age...

</comment><comment><USER12> If you think high street banks are slow and cumbersome and can't catch up you are (probably) wrong; I know enough from being a contractor in London to know they very much are catching up. They are changing every aspect from internal APIs and tech stack to customer-facing apps and sites. I definitely wouldn't bet against them. Monzo has a clear lead but I can't see that being sustained long enough to counteract the strength of existing brands once they start to release their new products.

<comment><USER13> > ...counteract the strength of existing brands

Hmm, apart from being widely known (thanks to marketing), I'd argue existing banks don't have a very strong brand. Mention the word Natwest, HSBC or Santander and most people's first response will be "I hate them, they took forever to open my account/incorrectly charged me/have closed all their branches".

<comment><USER12> Fair. And especially HSBC who are pretty much universally hated. But I know that at least a couple of others are making huge improvements. Plus by "brand" you need to include "trust" (wither or not that's misguided!)</comment></comment></comment>


What Happened to Innovation Ireland? | New Tech Post - <AUTHOR> http://newtechpost.com/2011/05/10/what-happened-to-innovation-ireland <comment><USER2> Sorry, this is off topic but what is the Facebook "care" button about?</comment>


Taiwan's HTC sues Apple over patents - <AUTHOR> http://www.reuters.com/article/2011/08/16/us-apple-htc-idUSTRE77F38E20110816 <comment><USER2> You have to wonder how much cheaper mobiles would be if companies hadn't a) patented all the obvious ways to do things and b) spent millions suing each other.

I blame the patent office. There was a segment on NPR yesterday where they pointed out in some cases there are thousands of patents that cover the same invention. Isn't that why you _have_ a patent office... to prevent this from happening? Instead all the real decision making is kicked (expensively) into the courts.

</comment><comment><USER3> I don't think it's ever been as clear as now that the patent system is broken. Everyone is suing everyone else, and if anything innovation just goes on in the background regardless of patents.

</comment><comment><USER4> Think we're going need a new "who's suing whom" graph, getting hard to keep up... ([http://cdn.mashable.com/wp- content/uploads/2010/10/whos_suin...](http://cdn.mashable.com/wp- content/uploads/2010/10/whos_suing_whom.png))

<comment><USER5> When it comes to patent litigation, it's safe to assume that they all are, or will be, bi-directional.

Unless one side has no products.

If one side merely has no (relevant) patents, it usually just means they're going to go buy some patents and then make their counter-suit.

<comment><USER6> Maybe true but that obscures the fact that the recent escalation of patent madness is caused by Apple suing every Android manufacturer. What I'm saying is, Steve Jobs is an asshole.

</comment></comment></comment><comment><USER7> The Android strikes back! Start of the patent apocalypse.

Here is a way to abolish patents -- overload the court system with it.

<comment><USER8> The cynic in me says that will just lead to a bigger court system as they hire more lawyers and judges to handle the increased load.

<comment><USER9> That's a way to battle unemployment that is caused by technological progress... just enlarge the not-productive sectors until everyone has a job shuffling papers around.

<comment><USER10> My next startup is going to be Heroku meets Angie's List for Telephone Sanitizers.

<comment><USER7> Help the world and make your next startup's business model "pay us to find prior art to invalidate patent X, and open source our results"

</comment></comment></comment></comment></comment><comment><USER11> I'm assuming this new suit is based on patents HTC acquired from S3?

</comment><comment> john-n Are the patents in question known?

<comment><USER12> There are links to them in this article: <http://thisismynext.com/2011/08/16/htc-sues-apple-patents/>

</comment></comment><comment><USER13> Wouldn't it help if Google sued on behalf of all device makers now that it has much larger trove?

<comment><USER14> Motorola is already suing Apple(and Apple is suing Motorola) over Motorola's patents. That shouldn't change with Google's acquisition, and any resolution of the suit would probably make Apple a licensee of the patents, making them immune to any suits over them.

<comment><USER15> A patent holder is not required to license their patent. If found valid by the court, they are free to enjoin others from using their technology for the duration of the patent period.

<comment><USER14> Motorola is counter-suing Apple, though. Without knowing exactly what patents each party is saying the other is infringing on, I would wager that the endgame for both companies is now a cross-license agreement more than an injunction against the other's products.</comment></comment></comment></comment>


Thoughts on, and pictures of, the original Macintosh User Manual - <AUTHOR> https://www.peterme.com/2007/08/27/thoughts-on-and-pics-of-the-original-macintosh-user-manual/ <comment><USER3> What a great article!

I liked the commentary about preppy white guys. I think this was deliberate (perhaps subconsciously so), but not for reasons why it might happen today.

First, back in the 80s there was still a big issue as to whether execs would use computers. Most could not type; that was at that time considered a female activity. Sounds absurd, but this was literally a topic not just in newspapers talking about computers but also in computer journals wondering if PCs could break into business. And most execs were (and still are :-( ) male.

Second, the Mac was quite a bit more expensive, really at the edge of what an individual could afford (Apple offered a finance plan, if not at launch then soon after). So they were making an affinity pitch to people who could afford it.

> Also, why is the keyboard in Chapter 3 positioned like that? Why on earth > was it posed that way?

I suspect it was to show you could use the mouse and not be intimidated by that scary keyboard thing.

I was also struck by the Chapter 3 photo as it seemed to be the only one that could have been shot today (except for the Mac itself of course). All the others had hairstyles, color palette, and/or artifacts (desk phone, tape dispenser) that you'd never see today. Even the final shot of the Stanford Campus has bikes that look old fashioned.

<comment><USER4> _not be intimidated by that scary keyboard thing._

I think it's more about showing you can use the computer with just the mouse. They went to great lengths to avoid having the series-of-menu- selections/commands-by-keystroke-and-arrow-keys type text mode UIs (which were the norm on other personal computers) replicated on Macs. The original Mac keyboard didn't even have arrow keys.

<comment><USER5> AFAIK there was no on-screen keyboard, so you would not have been able to do things like enter filenames and such with only a mouse.

(On the other hand, try using that Mac with only the keyboard, and you'll be disappointed at how much more difficult it is.)

<comment><USER4> _things like enter filenames_

Entering filenames is exactly what the interface is trying to avoid, doubly so for entering paths. And it worked - you could be a sophisticated classic Mac OS power user and not know what the HFS path separator was.

<comment><USER5> Unless you want everything named Untitled, Untitled(1), Copy of Untitled, Untitled(3), etc. you are going to have to enter a filename at _some_ point.

<comment><USER4> Sure, at some point you will have to type. But the idea here is not that you _never_ have to type, it's that most of the time, you can point. If anything, it's striking it's remained true for as long as it has.

</comment></comment></comment></comment></comment></comment><comment><USER6> The original Macintosh also came with a cassette tape in the box, with audio lessons on how to use the "mouse" to move the "cursor" around on the screen, and how to "click" and "double-click" it to make a "selection" \-- new terms and new concepts for the vast majority of early users. And, of course, everybody had a cassette player.

<comment> open-source-ux In a similar vein, when Microsoft released Windows 3.1 in 1992 (much later than the 1984 Macintosh) they also included lessons on moving a mouse cursor on screen and double-clicking. However, they turned their lessons into a simple but effective interactive tutorial. Here's a screen recording of the entire tutorial - it still holds up as quite informative and well put- together:

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

<comment><USER7> Once upon a time I needed to look something up on my home computer, so I phoned my mum from work and tried to talk her through clicking on a few icons. This was with Windows 3.11 and the task was far from rocket science. After getting nowhere for twenty minutes I discovered what was wrong. My mother - bless her - had the mouse held the wrong way up. She knew that mice - as in the sort that scurry around and work very hard in laboratories - had the tails at the back. Consequently she held the mouse upside down, with the cable coming out the back.

Before arriving at this simple mistake I had got her to close the blinds in the room where my computer was setup. In those days mice were opto-mechanical with the ball, and, under extreme bright light the sensors in the mouse were vulnerable to light coming through the plastic housing of the mouse. Connections had been checked too, plus I had managed to get her to reboot the machine with the reset button on the front. Yet all along it was operator error, I imagined everything that could be wrong up to 'it must be a stray neutrino' levels of implausible yet I overlooked the idea that my mum intuitively thought that a computer mouse was like a real mouse with the 'tail at the back'.

We got there in the end after I had the eureka moment and worked out my mum was holding the mouse wrong. I could talk her through the rest when that was resolved and got the snippet of information I needed - a telephone number - which I needed for work.

It was only when ecommerce and the Amazon Kindle came along that my mother was finally able to use a computer. All difficulties and fears mysteriously vanished when it came to buying stuff online, she became perfectly adept at using a computer then, much to my father's amusement.

If only I had known of this tutorial back then.

<comment><USER8> > _She knew that mice - as in the sort that scurry around and work very hard > in laboratories - had the tails at the back. Consequently she held the mouse > upside down, with the cable coming out the back._

The original mouse _did_ have the cable at the back. That's why it was called a mouse.¹

1\. [https://stason.org/TULARC/languages/english- usage/51-mouses-...](https://stason.org/TULARC/languages/english- usage/51-mouses-vs-mice-Usage-disputes-alt-usage-english.html)

</comment></comment></comment></comment><comment><USER9> I recently found my copy of the 1991 Macintosh User's Guide. It has the superb line:

"Until you save your work, it exists only in the computer's memory - <USER2> thoughts that are lost unless you write them down."

This is almost as good as:

"All those moments will be lost in time, like tears in rain"

<comment><USER10> "Everything not saved will be lost."

-Nintendo "Quit Screen" message.

</comment></comment><comment><USER11> I was a beta tester for the original Mac, as well as in the first Mac Professional Developer Program, introduced at Harvard University as a summer session in '83\. I still have my mimeographed partially typeset, partially typed version of Inside Macintosh. It is filled with hand written notes by the original developers, and was copied directly from their copies as they worked to complete the beta version that summer. I had it appraised around the time of Job's death, and the response was it's priceless and needs to be in a museum. It's still in a air sealed box at the moment.

<comment><USER12> Wow! I hope you can find a way to digitize it. I picked up the giant one- volume version of _Inside Macintosh_ from an MIT Library sale, and even without the rich added character of yours it's an extraordinary piece of technology history.

</comment></comment><comment><USER5> Compare the IBM PC/AT "Guide to Operations" of the same time:

[http://www.minuszerodegrees.net/manuals/IBM_5170_Guide_to_Op...](http://www.minuszerodegrees.net/manuals/IBM_5170_Guide_to_Operations_1502241_MAR84.pdf)

No colour, and of course a CLI doesn't need a lesson in how the UI works, but plenty of technical information.

<comment><USER13> "The scroll lock light comes on when you press the Scroll Lock key or when your program is in the scroll lock mode. The scroll lock light goes off when you press the Scroll lock again, or your program is no longer in the scroll lock mode."

"The System (Sys) key has its functions defined in your operating system or application program manual."

Heh, it's like it's written by my co-workers that simply can't do anything user friendly but like to make totally redundant "documentation." E.g.:

"The option --result-dir specifies the result directory"

"The function int getSize( int frob ) returns the size of the frob. The parameter is frob." (God forbid they inform you what the allowable range of input or output is, in which units they measure the size or what the frob in their program means or what is actually measured or counted, and they _never_ include an example of using anything)."

<comment><USER14> That is the worst and most useless type of documentation.

Also the most common.

<comment><USER15> I suspect the problem is often that engineers try their best to write objective documentation and it unconsciously goes to an absurd extreme — "I shouldn't presume to tell them how they might want to use this function, let's just stick to the facts."

(Btw this is an illustrative example of why you can't have "news that just states the facts." That principle doesn't even work for technical documentation! You need some degree of interpretation and empathy for writing to make sense.)

<comment><USER14> My suspicion is that it's documentation written by people who don't use, don't know how to use, and do not understand the product.

Fundamentally, technology is _means_ and _method_ , and both point to _ends_ or _goal_.

 _Technology is the study of means._ (John Stuart Mill's definition. He also gives science as "the study of causes".)

Which means that _documentation_ should point you at _what you might want to do_ and _how the tool(s) available to you serve that end_. Referencing _only the internal state of the system itself_ (and worse, at the most trivial level, as in the example give, which is _by no means_ unusual in the field) is ... perfectly useless.

It's actually worse than useless, because you've got to wade through so much goddamned mud soup _trying to find information that 's actually useful._ I've long had this problem with various "documentation by the pound" publishers -- Que and "Learn Foo in 24 hours" type series -- where the books are so padded with cute comments and junk statements that you cannot find the real meat.

O'Reilly's "Nutshell" series often go too far in the other direction, but at least the information is (usually) there.

The O'Reilly _UNIX Power Tools_ book, a _cookbook_ of recipes and methods _with specific ends and goals explicitly stated_ is, pound for pound, probably the most valuable reference book I've ever bought. It doesn't cover everything (though it touches on a lot of material), but it covers _a vast range of useful information_ and best of all _gives you the tools to find out more._

</comment></comment></comment></comment></comment><comment><USER16> this is wonderful. it's especially interesting how dramatically different Apple's idea of what a computer user is and wants to do vs. how IBM viewed it. They are coming at it from two fundamentally different mindsets.

a full PDF can be found here: [http://www.maccaps.com/MacCaps/DIY_Information_files/Macinto...](http://www.maccaps.com/MacCaps/DIY_Information_files/Macintosh_Manual_1984.pdf)

<comment><USER5> Ironic that one of the sentences in the introduction is "With Macintosh, you're in charge." and there's plenty of references to " _your_ Macintosh". Ditto for the IBM PC/AT manual I linked to in another comment here, although the latter explicitly mentions near the very beginning that it has built-in BASIC (and the manual for that is also supplied) while the Mac manual never mentions programming until the very end where it briefly references the Programmer's Switch and warns users not to use it.

Apple makes it difficult from the beginning to do anything other than use the computer as an appliance, while IBM seemed to be the exact opposite.

<comment><USER17> It's hard to over state how much easier to learn and use Macs were back then, compared to any other computer.

I used to teach computers in the early 1990s before Windows 3.1 was popular, and the main PC apps like Lotus 123 and WordPerfect were impossible to learn without the keyboard templates that had the key-presses printed in them you needed to do anything including edit, print and save. Each app had its own key presses and the publishers fiercely protected them to ensure competitors were NOT copying them. Then came the Mac and you learned to print in one app, you knew it for EVERY OTHER MAC APP.

At the time developers couldn't understand why such functions (and appearance) were standardised and many considered it negatively, as in "Apple restricting my creativity and telling me what to do."

</comment></comment></comment><comment><USER18> Doesn't hold a candle to the VIC-20 user manual:

[http://www.classiccmp.org/cini/pdf/Commodore/VIC-20%20User's...](http://www.classiccmp.org/cini/pdf/Commodore/VIC-20%20User's%20Manual.pdf)

<comment><USER19> This is neat! Doesn't just teach you how to use the computer, but it's a complete introduction to programming. (At the time, I suppose, there was not much difference :)

</comment></comment><comment><USER20> The basic nature of the instructions reminded me of talking to a guy I met in Charlotte who was mad about how young people today don't really know why editing text or photos is called "cut and paste." He was a professional photographer who took many iconic photos of stock car races from the 50s through the 80s or 90s, and was good friends with (for example) Bill France of NASCAR.

Anyway, he published a magazine (or maybe more than one, I can't remember) with photos and stories about racing. They had to be literally cut and pasted onto boards before printing. It was genuinely irritating to him that people could simply point and click at a scissors icon to edit their layout and still call themselves "editors."

Of course, I listened with great interest, since I'm still irritated that CLI isn't the standard any more.

<comment><USER17> > They had to be literally cut and pasted onto boards before printing.

Well resourced offices had a machine that you'd feed the photos into to put a thin layer of wax on the back. The wax remained tacky (like post-it note glue) to hold the photos and text elements in place but let them be easy to reposition.

</comment></comment><comment><USER21> I'm pretty sure this manual was written by [https://en.wikipedia.org/wiki/Chris_Espinosa](https://en.wikipedia.org/wiki/Chris_Espinosa)

Source: He was a highschool and college friend.

</comment><comment><USER22> I prefer the rougher edges of the Apple II Red Book.

At times, the prose is a bit flowery: "Computers can perform marvelous feats of mathematical computation at well beyond the speed capable of most human minds. They are fast, cold and accurate; man on the other hand is slower, has emotion, and makes errors."

[http://www.classiccmp.org/cini/pdf/Apple/Apple%20II%20(Redbo...](http://www.classiccmp.org/cini/pdf/Apple/Apple%20II%20\(Redbook\)%20Reference%20Manual%2030th%20Anniversary.pdf)

<comment><USER23> That quote echoes Steve Jobs's comments about tools augmenting human capabilities.

[https://www.brainpickings.org/2011/12/21/steve-jobs- bicycle-...](https://www.brainpickings.org/2011/12/21/steve-jobs-bicycle-for- the-mind-1990/)

</comment></comment><comment><USER24> Ah, I understand the "scroll bar" now. Never put that name together until now.

</comment><comment><USER25> It's interesting how that computer "fits" on a desk very nicely space wise.

I have a huge Ikea desk and some monitors. I never feel like it all "fits". I won't give up my big monitors... at the same time it irks me that it never feels it all fits on my desk.

<comment><USER26> I just hang my monitors on the wall behind the desk. I'm up to 5 now and there's still plenty of room.

</comment></comment><comment><USER27> > My favorite is scrolling. I can imagine the discussion: "Well, it's called a > scroll bar… I know, let's use a drawing of a scroll!" Yes. Because people in > the mid-80s were all about scrolls…

Uh... that's literally _why_ it's called a scroll bar in the first place...

</comment><comment><USER28> What was really striking was the difference between manuals for the Apple II and Macs. The II manual was probably one of the finest user-friendly manuals for a computer ever created.

Of course it addressed a different audience ... the users, not the purchasers.

The same thing happened to the technical manuals; the II manual was transparent about the machine; while the Mac manual left out a lot of useful technical info and replaced it with the first incarnation of the software- prison. No PEEKs or POKEs or hardware insights, no friendly appeals to having fun and learning.

Eventually the rainbow logo became a blase grey ... same shape, but drained of color. Revealing a different personality.

</comment><comment><USER29> This a great piece to come across. Written in 2007... nice to have a chance to see it. I was laughing at the part where he packed in a bag and started biking away with it. Like... wow that bike must have been front-heavy.

</comment><comment><USER30> It is amazing how much the manual has to explain to a 1980s user, for a device that, for me at least, exuded a sense of magic, especially compared to the competition. The office at my first technical job had both an Apple Lisa and a Macintosh, as well as IBM PCs, XTs and ATs. The Macintosh really felt like a different sort of beast... and though I've had several Apple machines over the years, all of them far outperforming the original Mac, none of them ever felt quite as special for some reason. I suspect a lot of it might simply be the original industrial design, which still looks cool to me.

</comment><comment><USER31> PDF: [http://www.maccaps.com/MacCaps/DIY_Information_files/Macinto...](http://www.maccaps.com/MacCaps/DIY_Information_files/Macintosh_Manual_1984.pdf)

</comment><comment><USER32> Am I the only one for whom every smaller photo (of the first 7, it turns out) goes to an enlarged version of the same photo #1, and clicking 'next' from there goes to a totally unrelated photostream item?

</comment><comment><USER33> I love that people were (at least in Steve Jobs's vision) biking around the Stanford campus with macs in the 80's. Nothing ever really changes about that place...

</comment><comment><USER34> I recall that my Apple II came with a booklet of handwritten notes about assembly code.

</comment><comment><USER35> Also interesting that at least one picture is at Stanford University. They had right from the start the prestigious university student as a target demographic. :)

</comment><comment><USER36> Is it just me, or do the pictures on chapter 3 and 4 look like prototypes with a 5.25" drive?

<comment><USER37> Those particular pictures don't look like that to me, but some prototype Macintosh machines had a Twiggy drive. There's a great story about how the mac designers had to hide their negotiations with Sony from Steve Jobs so he wouldn't get mad on folklore.org.

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

[https://www.folklore.org/StoryView.py?project=Macintosh&stor...](https://www.folklore.org/StoryView.py?project=Macintosh&story=Hide_Under_This_Desk.txt)

</comment></comment><comment><USER38> "The Finder is like a central hallway in the Macintosh house" - that works for me.

</comment><comment><USER39> I like the appendix photo... The bicycle for your mind in a bicycle... at Stanford

</comment><comment><USER40> I still have mine.

</comment><comment><USER41> Remember Flickr? >..<

</comment><comment><USER42> _Pretty cool how they got the computers to work w /o plugging them in._

That was a Jobs thing. For years, Mac ads didn't show cables. Then came the iDweeb earbuds.

<comment><USER43> it likely predated jobs by a long shot. i don't know how far back it goes, but all add for electrical appliances (even lamps) don't show cords. cords are ugly.

even ads for other things, say a desk, don't show cords of the computer or lamp on the desk.</comment></comment>


Want to Build Native Apps and Progressive  Web App with Lonic FremeWork - <AUTHOR> http://www.blog.brsoftech.com/build-native-apps-and-progressive-web-apps-with-ionic-framework <comment><USER2> Haha "Lonic". I don't want to make fun of anyone but this is too fun not to point out.</comment>


Show HN: A short game to know if you're good running 1:1s - <AUTHOR> https://www.oneonemeeting.com/choose-your-own-adventure.html <comment><USER2> Asking them an esoteric question will make them uncomfortable but a personal question that addresses specific members of their family by name is going to put them at ease?

This reminded me of the episode of The Office where Dwight steals Micheal's Rolodex to get information on his clients and it leads to him asking, "How's your gay son? ... Tony? The homosexual sophomore?" If you don't know someone intimately don't try to fake an intimate connection. The very next part of this quiz encouraged me to be upfront and honest instead of hiding behind excuses and managerial tricks. What if he were upfront and honest in response to the personal question and told you that his wife calls him a poor father and insults his manhood, are you ready to pivot to that subject? Can you reasonably expect him to answer that question dishonestly and if he needs to do so in order to avoid an awkward conversation then hasn't the question failed its purpose of opening an honest dialogue? What if this is a performance review and the result is somewhat negative? Is he to understand that his poor relationship with his wife had some bearing on his negative performance review? If not then why would you bring it up in that context? A relationship can thrive on one of two things: complete honesty or respectful boundaries.

Maybe I am too sensitive about personal questions but that question doesn't seem appropriate. Also, esoteric conversation starters are great. I would much rather talk about why I would want to be a sunchoke than give a generic response without actually thinking about my answer.

<comment><AUTHOR> I understand, but in this fictional situation, I added an explanation why that question was ok (because Sancho mentioned his family often, implying that is regular subject in their conversation). Maybe I should also make it clear that it is not always ok, depend on the relationship</comment></comment>


School Stunts Development - barry-cotter https://www.adamsmith.org/blog/school-stunts-development <comment><AUTHOR> Hold up. There seems to be a non-sarcastic statement that schooling too early stunts development and the author references a The Onion article.

To those not familiar TO is a parody newspaper printing fake news that is comedic in nature. They are known to make comedic fake news for decades.

I think this shows that the author had terrible research.

<comment><USER2> Satire.

And while the linked article was probably fictional, it contained more Truthiness than any other news source.

> "I don't want to go to school," Bolduc told his parents, the crushing > reality of his situation having yet to fully dawn on his naïve > consciousness. "I want to play outside with my friends."

<comment><USER3> >> it contained more Truthiness than any other news source

You got an Oatmeal comic to back this statement up?

<comment><USER4> Ironically many Oatmeal comics seem very well researched.

<comment><USER3> True but I need my research with a giant dose of WIN and exploding diarrhea cats, else I'm bored.

</comment></comment></comment></comment></comment><comment><USER5> The article, and the parts of the study I skimmed, are appealing if you already agree with the conclusion, and they're full of holes if you don't.

The value or(/and?) harm of school is such an emotional topic for almost everyone, so it would be useful to be much more rigorous when writing an article like this. The authors might have gained by hiring a statistician to poke holes in the research, and then scale back conclusions or plug the holes.

<comment><USER5> Replying to my naive self: Seems the point of this article was to point out some absurd abuses of statistics. Faith in humanity restored!

</comment></comment><comment><USER2> I think the corollary to this is manifested in the extended adolescence we see with millennials. Well meaning parents have delayed maturation by limiting those activities which cause emotional and metacognitive growth, free play.

By over focusing on academics and structured activities, the amount of time dedicated to just being is reduced. I would like to see a world where we focus on making self-actualized present individuals.

<comment><USER6> That's an interesting hypothesis you have there. It would be a shame if someone validated it.

Seriously, though, if anyone is aware of a paper that deals with this or a closely related idea, I'd love to read it.

</comment></comment><comment><USER7> This isn't that strange - the concept he's touching on is part of why Montessori schools exist and are effective.

<comment><USER3> I like the concept too--until a certain age anyways. There is something to be said for academic rigor, but perhaps places like America force it a bit too early in the education process. My girlfriend works in enrollment at our public school district and when a local Montessori shutdown, the reaction was pretty... visceral. "How ever will my 16 year old learn to study for an exam!?"

Edit: looked it up and secondary education in Montessori schools is more uncommon, ostensibly for this reason?

<comment><USER7> Yeah, if I remember correctly it's great up until about 3rd grade.</comment></comment></comment>


DOM Manipulation and Event Handling in ClojureScript - <AUTHOR> http://davedellacosta.com/cljs-dom-survey <comment><USER2> One thing that sold me on Dommy over Domina was being able to bind multiple event handlers in one statement.

[https://github.com/Prismatic/dommy/blob/master/src/dommy/cor...](https://github.com/Prismatic/dommy/blob/master/src/dommy/core.cljs#L276)

Not a big thing, but when you work with a library regularly, small annoyances like that gnaw away at you.

</comment><comment><USER3> I use hiccup + laser on server-side and enfocus on client-side. Then every static html/js resource that I can make use of looks like nail to my hammer.

</comment><comment><USER4> related: check out CLJS in Qt (via QmL) on YouTube</comment>


Charm shutting down because of unfixable kernel panics with Rails on Ubuntu - <AUTHOR> https://raw.github.com/gist/020171fce9ffca2b77d4/0b194a4bc566e2395833f57f8c11453ddbeb43a5/gistfile1.txt <comment><USER2> What??? How is this even remotely possible?

I call BS. It's either a smoke screen for some other issue, or their app was built back asswards. Either way, this post and the circumstances are indicative that Amy and/or the Charm leadership has no idea what they are doing.

And they were not even launched? Beta or something? The comment about opening to the general public implies that they weren't getting that much usage. These days it's hard to build something with a modern framework and decent hardware that does not at least work for a closed-beta period. Add 100k to the mix and honestly what the hell.

Amy/Tom run Freckle and do some other cool shit so why are they dropping the ball on this? It's like getting a paper cut on your finger and going home for the day because it's just too much to bear. Cry me a fucking river.

Why does this keep happening?! People are throwing cash into the dumbest shit these days.

<comment><USER3> Who gave these guys & gals $100k?

Reading this must make founders striving to get investments furious..

<comment><USER4> Yes, the other gentlemen are correct. This was all our own money. Which we earned from scratch from our other products (all doing very well, thank you). And, perhaps more galling, VCs approach us every month to try to invest (but we're against it).

I'm sure shutting down a perfectly good and potentially very profitable product will make lots of wannabes and aspiring entrepreneurs jealous. Luckily I don't make my life decisions based on what other people would do in my situation.

When you run a real business, with real customers, you quickly discover that what sounds good, isn't, and what looks bad, is often the absolutely right thing to do. Luckily, our early access customers for Charm heard & understood & appreciated my email.

<comment><USER3> I'm sorry I jumped to the wrong conclusion. Not very sorry, but a little bit.

FWIW, it deserve respect to shut down something you built with your own money.

In hindsight, I think you would have gotten an entirely different response had you said _"We can't run Charm with the team we currently have, there are technical challenges we can't solve"_. Understandable and believable. But for all the people dealing with problems like the one you blamed on a regular basis, saying what you did just sounds like:

 _"We spent or life-savings building this great house! But it keeps running out of toilet-paper, so we burned that s"#¤ down!!"_

<comment><USER4> When running out of toilet paper causes your house to fall down and people to lose money, your metaphor will actually make sense.

</comment></comment></comment></comment></comment><comment><USER5> They seem to be over their limit with Github, pasted below as a mirror:

You probably noticed Charm had some nasty downtime a couple weeks ago.

Service quality is very important to us. If we didn't think we could do better, we wouldn't do it at all.

We've spent very generously on sysadmin services and infrastructure (nearly $100k of investment on sysadmin services/infrastructure alone). We hired the best possible, and we splurged on a redundant, powerful, and expensive server configuration from the beginning.

Now we've discovered that there's some kind of base incompatibility with Ubuntu, which is giving us kernel panics which nobody can track down. Charm has been plagued by mystery technical problems from the beginning, when we had to backport from Rails 3.x to 2.x because of massive performance slowdowns which even Rails Core members couldn't identify.

What this has really shown us is that, if we open Charm to the general public, we won't be able to provide you with the kind of service you deserve. We are a tiny team, and so far, we've had zero luck in our attempts to grow by hiring developers. Problems which are small now will only get bigger.

There are a lot of things I'm willing to take risks with, but not with _your_ ability to provide support to customers for _your_ business.

And so it is with a very heavy heart that we will cease operating Charm from Dec 15, for the foreseeable future.

You won't be billed again, and we'll refund your last payments.

We will gladly help you migrate your data out of Charm. Please contact us directly (firstname.lastname@example.com) for help.

Thank you so much for taking a chance on us, and sharing our dream for a superior email interface.

I'm truly sorry to disappoint you.

Best wishes,

Amy

<comment><USER6> Paste the link in another tab.

</comment></comment><comment><USER7> For a 100k, they could have

1) Bought a ton of Heroku dynos with every single addon enabled. That would have given them any version of Rails they wanted with Ruby 1.8, 1.9 or even 2.0; Postgres, MySQL, Redis, MongoDB, two different kinds of Memcache and three different kinds of asynchronous processing.

2) Gotten fully managed servers at Rackspace with pro support for pretty much any setup they wanted.

How is this even possible? The same application happens to hit bugs in the Ubuntu kernel and Rails core that haven't been fixed all the way to 3.2.9? And they have 100k to spend but couldn't be bothered to try different kernels and distros? Really? Have they seen the AMI launch screen on EC2?

<comment><USER8> 3) hired two $5000/mo sysadmins for a year.

<comment><USER4> I shared your comment with people who actually hire for technical positions, and we all had a good laugh.

</comment></comment></comment><comment><USER9> Wow, this is unprofessional.

Lots and lots of people run Rails apps on Ubuntu. Many more run them on non- Ubuntu distros. There is not an epidemic of "welp, Rails magically crashes the kernel, time to pack up and go home", and citing that as the reason to close down after spending over $100k on infrastructure smells really, really funny.

"A poor workman blames his tools."

<comment><USER10> _"A poor workman blames his tools."_

. . . but even a master carpenter can't build a house out of rotten wood. Of course, to me, rotten wood is OSX and Windows (why anyone would build servers on those instead of one of the BSDs or Linux, I'll never know; to me, development is also incredibly painful on Windows and OSX), but Ubuntu is not without issues. The rallying cry of "usability first!" is all well and good, until things like taking shortcuts by way of binary drivers causes crashes. Still, one has to wonder why they didn't just try another distro. If you think your tools (or your "lumber") are the problem, try different ones.

<comment><USER9> Lots of people successfully run Rails on Ubuntu in production. I don't think it's fair to cry "rotten wood" here, unless the Rails ecosystem is flush with amazing systems wizards who can work around crippling flaws in the OS to run their software.

<comment><USER10> _I don't think it's fair to cry "rotten wood" here, unless the Rails ecosystem is flush with amazing systems wizards who can work around crippling flaws in the OS to run their software._

Agreed; however, if they were having problems with Ubuntu (or indeed Linux in general), why didn't they try something else? That's the quick and easy way to see if it's really the platform or your application that's the problem (quick tip from my own userland developer experience: it's almost always not the platform; the times I've had Linux crash on me I could always trace to one of three things: 1) flaky hardware, 2) binary drivers, or 3) I was mucking about in kernel space ;)

<comment><USER9> What really blows my mind is that they did a regressive rewrite to Rails 2 rather than learn to use profiling tools.

The whole situation just makes my brain stare blankly and wonder what on earth was happening over there.

<comment><USER4> Yes, because it's not like Thomas (my partner/husband) is a performance expert or anything. And it's not like 3-4 Rails Core team members who tried very hard to help us have ever heard of profiling tools.

My mind just exploded, too, due to your willful inability to read the details.

</comment></comment></comment></comment></comment></comment><comment><USER11> If rails causes a kernel panic then this is really a bug in the kernel. No user land app should ever do this. Why not try to scale on *BSD or Windows all of whom have different kernel and scale just fine?

$100,000 and no one said "hey what about running it on <insert other os>"?

<comment><USER12> This is normal for Ubuntu kernels from experience. They are shitty. Various server releases have given us hell. They're fudging them somehow.

We moved to debian after numerous problems and have had no issues since.

<comment><USER13> Yeah, when I see people running Ubuntu for their production servers I always assume it's developers with minimal system admin experience who just want to use the same distro for their server as their desktop. I've got nothing against Ubuntu, and have even used it to convert a few windows users over, but if you're going to run a production server then install Debian on it.

<comment><USER14> I have been using Debian since 1996, and became a package maintainer in 1997, a position I held for nearly a decade until I began to not have enough time for it. While continuing to think that Debian is a first-rate effort, I got tired of certain aspects of it, and moved to Ubuntu, lock stock and barrel. I actually like to have my desktop system marching in sync with my server, so that the packages are pretty much exactly the same. And you know what? Ubuntu works pretty well on the server, and comes out with nice regular releases, allowing me to decide, and gauge, time-wise, when to upgrade. Certainly, like everything else, it has its defects, but by and large, I've had good luck with it, as both a desktop and server distribution.

</comment></comment></comment></comment><comment><USER14> My business runs on Ubuntu/Rails just fine.

Maybe if they were a bit more familiar with Linux they would have done better, or at least have saved some money figuring out what went wrong:

<https://twitter.com/amyhoy/statuses/189072763590418432>

<comment><USER15> That link was really insightful. The fact is that there are tens of thousands of servers running Rails on Ubuntu without any issues.

Sounds to me they would rather blame Ubuntu than their inability to fix the issue.

Later edit: to elaborate that last point. I'm not saying Ubuntu is not at fault, but rather that problem solving goes with the territory. Given the wide array of alternatives, this was not the sort of thing you could openly complain about.

<comment><USER14> <https://twitter.com/amyhoy/status/94166175247908864>

Ouch.

<comment><USER10> Wow. Hmm, how can I put this politely? As a desktop Linux user, I don't feel particularly left out in being ineligible for the hiring pool for a company that wouldn't let me use Linux. Maybe they scared away all the competent Linux admins with their negativity towards Linux?

<comment><USER4> Baseless speculation is one thing, when the original post actually contains information which contradicts you, it's just a sign of laziness.

<comment><USER16> What do you mean baseless? There were two provided links showing your distaste for Linux. One could be a fluke (had a bad day), but two shows a pattern. This, added with the mention of using Ubuntu (and not trying another distro) shows that Linux is not your forte.

I, for one, would not like to work for you. I'm not trying to be offensive; in fact, I respect the decision to cut bait when you realized you were over your head. I just don't think I, as a Linux user, would fit in your organization. Many of the good sysadmins also have this same viewpoint, so the above certainly is well founded.

</comment></comment></comment></comment></comment></comment><comment><USER17> Does this make sense? They don't mention trying to get support from Engine Yard on hosting their app on Rails without kernel panics, or trying a managed solution such as Heroku, or trying other OSs other than Ubuntu such as CentOS or something from Joyent. Just trying with the best possible syadmin they could hire and "Rails Core members".

Anyway, kudos for not submitting their users to a service they're not confident they would be able to provide with adequate quality and better luck next time!

<comment><USER10> _or trying other OSs other than Ubuntu such as CentOS or something from Joyent._

Or even just Debian. I ran into issues (years ago) with Ubuntu stability due to closed source drivers on a laptop; sure, I have the skills to debug that sort of thing, but why waste my time? I had been running Debian just fine on desktops and servers for years, and after switching the laptop to it, the lockups stopped.

I'm more than willing to admit there may be real technical issues they ran into, but it sounds to me like they gave up too easy, and we may never know what the problems are. Would've been nice to at least have seen a bug report (honestly don't know if they submitted any, but I'm willing to bet they didn't).

<comment><USER16> Or Arch Linux. Arch packages are pretty vanilla, so it would be a pretty good way to reduce the attack surface.

Also, with Arch, you get less by default, so you'll end up with a cleaner system. I didn't realize how much stuff I didn't need on a default install of Fedora until I set up an Arch system.

</comment></comment></comment><comment><USER18> What on earth?

Blaming this on Linux or Rails is ridiculous. And as for 'mystery technical problems'...

I think the reality is more like they got in over their head, decided it was all a bit too difficult, and gave up.

</comment><comment><USER19> We run a lot of webservers, our own hardware, on Ubuntu and we do not have this issue at all. Rails doesn't cause Kernel panics. It sounds like they have a bad install or honestly, just don't know what their are doing.

Probably a bad idea to advertise you can't keep a simple webserver up. Probably won't get funded ever.

<comment><USER20>
      >Probably won't get funded ever.

Amy Hoy is in the same bootstrapper camp that DHH and Jason Fried are in. Regardless of the situation, I imagine "won't get funded ever" is ranks pretty close to the top of her "don't give a shit list".

<comment><USER19> Sure. But it also means a lot of people who are looking at her future projects will pause and think twice.

<comment><USER4> Think twice, like what? "Gee, there's a woman with integrity who shuts down a service while it still works 99% of the time, and refunds my money, instead of growing it like a nutjob until it has weekly downtime like oh I don't know Desk.com"?

I do so hope you're right.

<comment><USER21> A service with a weekly downtime is still more useful than no service at all.

</comment></comment></comment></comment></comment><comment><USER22> Let me see

1\. Open Source OS

2\. Open Source web server

3\. Open Source programming language

4\. Open Source web framework

5\. Some (relatively) simple customer support ticketing app [not likely to be a system pounding Gorilla]

And they claim that they've not been able to root-cause a Kernel panic and a framework slowdown?

And they've spent $100K on that with no results to show for it?

That sounds really strange to me.

[I've debugged Linux kernel panics on custom stacks, with no disk/logs, only console, 32MB of RAM, PPC cross-compiled - and never run into a dead-end like this]

<comment><USER17> "When Qurve got involved with the Charm project the site was being alpha tested by a handful of early adopters, but a months away from being ready for public consumption. Qurve was brought on in a Ruby on Rails development role to help fix bugs, complete the necessary functionality and ensure the necessary code quality for a public launch.

Over the next few months our role expanded to include a complete rewrite of the user interface, a reimplementation of the credit card billing processor and a few more major changes."

<http://www.qurve.com/clients/charm/>

<comment><USER4> Yes, Daniel helped us backport to Rails 2.x and make a lot of improvements while we were at it, after everybody had given up on finding our Rails 3.x performance problems.

</comment></comment></comment><comment><USER23> This seems like a bit of a cop out? Why not try a new kernel or separate stack like Fedora for example?

<comment><USER24> They spent over $100k on sysadm/devops and couldn't try to deploy a different kernel? What?

</comment></comment><comment><USER25> This is a bogus excuse. There must be some other reason they are shutting down as this appears to be a rectifiable problem.

</comment><comment><USER26> What was Charm? What did it do?

100k for "infrastructure alone" seems like a massive investment for a startup. How far along were they?

<comment><USER27> It was a customer support / issue tracking service.

<comment><USER28> This type of service has been written many times before without kernel panics.

I didn't get to see Charm before they shut down, so I have no idea what they were doing.

Could anyone speak towards how their experience was unique enough to cause kernel panics?

<comment><USER9> Anyone outside of the company would just be guessing. If anyone inside of the company could answer that question, they wouldn't be shutting down.

<comment><USER28> Pointless response.

</comment></comment></comment></comment></comment><comment><USER29> Canonical provide commercial support for Ubuntu, don't they? For "$100k of investment on sysadmin services/infrastructure alone", did they ask Canonical for support?

<comment><USER17> Actually they spent like $20k in what I assume was the salary of their sysadmin:

<https://twitter.com/amyhoy/status/271128780058267649>

The rest was infrastructure costs ($40k) and porting from Rails 3 to 2.

</comment></comment><comment><USER30> Any links to bug reports or mailing list discussions where Charm reported their problems?

Googling for "rails charmhq" doesn't reveal much, just that one of the Rails contractors was a company called Queve: <http://www.qurve.com/clients/charm/>

</comment><comment><USER31> Yes, kernel bugs exists

You can open a bug with distros and try to work around it. It is usually doable

"unfixable kernel panics" don't seem something a person familiar with Linux would say. Also, there are several distros, kernel versions, and Ubuntu isn't my first choice for a server.

And the gist is over the rate already.

</comment><comment><USER32> If you trust a random gist link as little as I do, here's a more reputable confirmation:

<https://twitter.com/amyhoy/status/271012712253911041>

</comment><comment><USER33> It sounds like they were on the bleeding edge, and got cut too deep. Premature optimization, yadda yadda...

It's better to go conservative on your infrastructure, get it stable, then experiment if required.

<comment><USER4> Not sure why you got downvoted, because we agree with you.

</comment></comment><comment><USER34> Sounds a bit strange.

I'd love to see an Ask HN with _proper_ technical details. Who knows, maybe they'll get better ways to solve this rather than close shop.

</comment><comment><USER35> Does anyone have any links to information on charm, or demos? All I can find is their website, which has no information: <http://charmhq.com/>

Found this so far: <http://charmhq.com/Charm_Bootcamp.pdf>

</comment><comment><USER36> Does rails not run on Centos, Debian, or SuSE?

<comment><USER37> I can _personally_ attest that it runs on SuSE (SLES), Debian, Arch, Fedora, [and Ubuntu].

I have no idea what this team was trying to do, but I imagine there _had_ to be more than what they wrote in this gist. That, or they simply ran out of money to troubleshoot the issue further.

There are also many different ways you can run Rails apps. They could've tried to run them on varoius Rack compatible application servers (Passenger on Apache or Nginx, Thin or Unicorn, et al.) -- If they migrated backwards to Rails 2, they could've used an [obsolete] version of Passenger with Ruby 1.8.7-Enterprise, which had many speed and stability improvements. (Assuming their app wasn't 1.9.x compatible.)

tl;dr: There has to be more to the story than this, they had so many options. For a $100,000 investment in administration, I'd have trouble believing they _didn't_ explore other options.

</comment></comment><comment><USER20> I wonder how many users Charm had and I wonder how many would have been needed to make porting the code from Rails to something like Java worth it.

</comment><comment><USER38> The reason that everyone is so incredulous at the shut down is because so few details were given about what they tried. I'd be really interested to know what they tried e.g. different kernels, different OS's.

</comment><comment><USER39> The message makes it sound like it's all over, but this alludes to a reboot in 2013:

<https://twitter.com/amyhoy/status/271279292741201920>

</comment><comment><USER40> charmhq.com's current landing page does not render correctly in Firefix. The Charm logo is positioned off screen in Firefox, but centered on the screen in Chrome.

<comment><USER40> The Firefox layout issue is because Firefox's HTML "quirks mode" is less quirky than WebKit's. With a proper DOCTYPE to disable quirks mode, Chrome will render the page like Firefox.

</comment></comment><comment><USER41> Anyone have a link to their website or anything? Talk about a horrible name for a startup, simply cannot even find it.

<comment><USER20> You can find (previous) references to it on Amy Hoy's blog unicornfree.com.

</comment></comment><comment><USER42> Did they test other linux distros?

<comment><USER7> I don't think they tested other browsers. Distros might be pushing it a bit.

</comment></comment><comment><USER4> What I find interesting about the reaction to this email, from you bench spectators, is that you completely missed the point of the email.

The email isn't "Wah we hit a server problem, bye bye."

The point is:

"What this has really shown us is that, if we open Charm to the general public, we won't be able to provide you with the kind of service you deserve. We are a tiny team, and so far, we've had zero luck in our attempts to grow by hiring developers. Problems which are small now will only get bigger."

If you've never run a serious product, or a real business, or tried to hire for technical positions, I can understand why you'd zero in on the "facts" about the technical situation and ignore all the "foofy personal window dressing," and write things like "I call BS! It's a smoke screen!" or "Why didn't they just try BSD?"

And yet I addressed the actual problem in very clear terms in a paragraph you can't possibly miss.

Next time somebody makes a hard business decision and you hear about it on HN and come out, irony guns blazing, may I humbly suggest you read more than the subject line written by the unrelated HN submitter?

As for any poor silent, lurkers who wonder if this is how they will be treated if they -- gasp! -- ever find themselves in over their heads, or in a business they realize they _don't actually want to be in_ … our customer reactions have been uniformly:

"Aw, I'm so sorry... Charm is such a nice piece of software... your email was so touching."

Why? Because we've always shown our customers respect by creating great software, and we're showing them even more respect by ensuring we do not make promises we can't keep.

Our friends and technical acquaintances have been full of nothing but sympathy, understanding, and for those closest to the situation, praise for making the right, hard decision.

Yep, it sucked. Yep, we poured something like $200k into development, redevelopment, and infrastructure all told. Yep, it is a fucking amazing piece of software and the best thing I've ever designed.

But is it worth the constant heartache of the impossible task of finding people equipped to work on it? Of having it stuck in some kind of product half-life because of that? Of feeling responsible for, but incapable of, being "on call" in the middle of the night?

Of feeling guilty because, unless we can somehow suddenly be great at those things, we're taking money for a service which might let our customers down?

Nope. It's not worth it.

And boy do I feel lucky and privileged that because we spent nothing but our own money on it, we are free to decide to do whatever we think is right.

See also my principles 10 and 11: [http://unicornfree.com/2011/lessons- learned-from-16-years-of...](http://unicornfree.com/2011/lessons-learned- from-16-years-of-hustling/)</comment>


Show HN: Loopon is a multi-user beat maker in the browser - <AUTHOR> http://sponoders.nko2.nodeknockout.com

<comment><USER2> I like it a lot but can you support private rooms? People jump in my room and mess up my sweet track. :-0

<comment><USER3> Yeah, this is pretty much unusable without private rooms. Too bad, because it looks like fun.

</comment></comment><comment><USER4> I understand its a little buggy like everyone else is saying, but overall I had a ball using it for about ten straight minutes. It was annoying at first when random people started dropping beats in left and right, but it usually just made it even better. Thanks

<comment><AUTHOR> Thank you for the positive feedback. If it were any other situation, we would fix the bugs, but we don't get to. :(

I am glad you enjoyed it, we are for sure going to improve on it and make it something great.

</comment></comment><comment><AUTHOR> If you are so inclined to vote, it would be appreciated. Sometimes the vote link/widget on the site doesn't work, but feel free to use the direct link: <http://nodeknockout.com/teams/sponoders>

There is also more information about the project and the other guys that helped build it.

I had fun, I kind of wish competitions like this came up more often.

</comment><comment><USER5> When you drop instruments in it often doesn't take.

When you attempt to delete instruments it often does not.

I think it works better as a whack-a-mole variant (trying to 'x' out instruments) since there are no private rooms and strangers just wander in and drop instruments all over your board.

Cool idea though. Keep at it.

Edit: I should add that it looks very slick. Well done there.

<comment><AUTHOR> Thanks for the feedback. Yeah there are a few issues with the sounds, if we had maybe an hour more we would have been able to patch that before the competition ended.

</comment></comment><comment><USER6> Looks interesting, but doesn't actually play any sound here. I'd guess perhaps you use Flash to play sound; a quick scan of the page source doesn't turn up any embed or object tags, but perhaps they get added from a script.

Any plans to support the HTML5 Audio Data API or something similar?

<comment><AUTHOR> We had performance issues with the HTML5 audio api, and didn't have time to troubleshoot. Ultimately I would like to support it fully, but we did what worked at the time.

<comment><USER6> Understandable, and glad to hear that you've both tried it and that you plan to support it in the future! I look forward to trying Loopon as soon as it works without Flash, and if you need a beta-tester for the HTML5 version, let me know. :)

<comment><USER7> Thanks Josh, we'll keep ya posted!

</comment></comment></comment></comment><comment><USER8> Doesn't really work for me :( Nothing in FF, sort of works in Chrome, but not really. Sounds don't always play, and most importantly, the timing is way off.

I've been waiting for somebody to do this properly for yeaaarsss.. so much fun potential here.

<comment><AUTHOR> What browser?

What is happening? As I have said before, we are going to continue working on it. Once we hit another major release, we will be posting it again here.

</comment></comment><comment><USER9> It looks like GitHub for Mac, except with not-as-pretty button icons.

<http://mac.github.com/>

</comment><comment><USER10> This app breaks the browser back button.

<comment><AUTHOR> Sorry about that. If we had even a few more hours, we could have tested it better. Thanks for the feedback.

</comment></comment><comment><USER11> An exciting concept for musicians, as working together asynchronously isn't possible sitting together.

<comment><AUTHOR> Funny that we choose to make it asynchronously for technological reasons, but it makes sense on a lot of levels. I really am excited to push this to the next level so you could potentially make some real music with it.

</comment></comment><comment><USER12> Cool but doesn't work very well. On Chrome and W7.

<comment><AUTHOR> Are you referring to the sounds not appearing after you drop them? If so, that is a known issue, and sadly something we caught too late to fix completely. Luckily when you drop them, even though they don't appear on your end, they are being sent to the server and a refresh will most times have it where you dropped it.

<comment><USER12> Yeah, I have to refresh it constantly and then it works.

</comment></comment></comment><comment><USER13> The name sounds too much like Groupon.</comment>


From ROS prototype to production on Ubuntu Core - <AUTHOR> https://kyrofa.com/posts/from-ros-prototype-to-production-on-ubuntu-core-1-5 <comment><USER2> The video includes a lot more detail about what the commands actually look like: [https://www.youtube.com/watch?v=x6BkzfwOZbc&feature=youtu.be](https://www.youtube.com/watch?v=x6BkzfwOZbc&feature=youtu.be)

Another example of how the general trend towards containerization vs. automated installation is excellent for reliable deployment. For server software, I was in the Ansible camp for a long, long time until I tried my first Docker-based deploy and realized that a whole swath of uncertainty about "documentation notwithstanding, can I trust this to deploy given the current state of the deploy target" just disappeared. For robotics this is even more important, because unless you're building a drone swarm, robots aren't generally in a redundant self-adapting cluster :)

Regarding why Ubuntu Core is a better fit than Docker for this, [http://askubuntu.com/questions/808524/whats-the-main- differe...](http://askubuntu.com/questions/808524/whats-the-main-difference- between-docker-and-snap) seems to shed some light. You want your "container" to have full access to the (robotic) system but still benefit from immutable dependencies.

</comment><comment><USER3> A bunch of us in the robot club are using Neato Botvac's and RasPi's. Significantly cheaper.

<comment><AUTHOR> Is it? Which one are you using? Walmart has the D80 for $499, which is about $50 more than the Kobuki.

<comment><USER3> I'm using a D80, but they can be found for less. The D-series is much preferred, because the XV-11 has a lame USB driver and the LIDAR data chokes it. I didn't realize Kobuki's were that cheap.

<comment><AUTHOR> Yeah, the Turtlebot 2 is significantly more expensive than just the Kobuki, as mentioned in the post. But you get more stuff, too.

</comment></comment></comment></comment><comment><USER4> I use ROS heavily and also a core contributor but I personally I do not like using Ubuntu or Raspberry Pi's for it. However this is the first time I'm hearing of Ubuntu Core so maybe I'll give it a go. My preferred method is Gentoo Linux with an external build bot that updates the images etc.</comment>