QuickTeX – Quickly Render a LaTeX Equation - <AUTHOR> http://ezb.io/quicktex <comment><AUTHOR> OP here, this is just a tool I wanted because I often find myself wanting to send a small equation or two to friends, and couldn't find anything online that could do that. Everything is wrapped in a \begin{align} ... \end{align} (even though I haven't really made that clear...)</comment>


House temperatures as a metaphor for interest rates - <AUTHOR> http://econlog.econlib.org/archives/2015/10/a_theory_of_hou.html <comment><USER2> As a non economist I was a bit lost by the end. What is the Wicksellian equilibrium rate and how exactly does it fit the analogy?</comment>


A Simple Guide to Five Normal Forms in Relational Database Theory - b-man http://www.bkent.net/Doc/simple5.htm <comment><AUTHOR> I do a lot of interviews for software developers, and I ask a very simple database normalization question that close to half of the candidates miss completely.

Something like: "You're tracking doctors, hospitals, and patients. Doctors can see multiple patients, and doctors can staff multiple hospitals". All I'm looking for you to say is that you'd put junction tables between the main entities.

It's so, so crucial that developers understand the basics of database design, and normalization is a huge part of that.

<comment><USER2> junction! really! i looked up this word online and only found this <http://en.wikipedia.org/wiki/Perl_6#Junctions>

the relational term would be relation, please stop interviewing ppl for jobs you are not qualified

<comment><USER3> Why downmod him so? His implication that the term "junction table" is nonstandard terminology is correct.

Despite 45 years in IT and a good 25 years of relational databases, I don't recall having heard (or read) the term "junction table" in a technical discussion. A cursory Google search indicates it may be recent terminology from the Microsoft corner of the universe.

<comment><USER4>
      Why downmod him so?

Probably because many here don't like someone badmouthing another over something so small.

</comment></comment></comment></comment><comment><USER5> You understand everything most developers should ever need to know about normalization if you get the following two sentences.

 _The key, the whole key, and nothing but the key. So help me Codd._

(For those who don't get it, the first sentence describes first, second and third normal forms, and the second sentence names the guy who is responsible for most of the theory behind them.)

</comment><comment><USER6> Thanks, nice to get a refresher on the fifth normal form. Though in practice I have yet to see anything behind the third normal form used; "The Key, the whole Key, and nothing but the Key, so help me Codd"

<comment><USER7> Almost everyone honours the 4th normal form without thinking about it. I think the "the 3rd normal form is the practical level" just became a bit of a meme.

</comment></comment><comment><USER8> Don't take it for granted.

With modern software design and especially OOP the risk of data inconsistency is less of a problem (I do web apps for entreprise and it simply never happened to me).

On the other hand duplication of information is a great way to scale an application. And incidentally offers data security since you can cross check your data in case of corruption.

<comment><USER7> >With modern software design and especially OOP the risk of data inconsistency is less of a problem

This sounds mighty hand-wavy. How does "modern software design" reduce the risk of data inconsistency?

>On the other hand duplication of information is a great way to scale an application

Most relational systems have facilities for duplicating information to scale. Materialized views, for instance, generate vile offenses to all normal forms but perhaps the first, hyper optimized for consumers, but it is guaranteed coherent and consistent, and happens with barely any work.

Seriously, we've been solving these performance issues for years. Every time some, failing a better word, noob writes up their big internet paper on why the relational model fails (with "modern" software, which is chuckleworthy), the world gets just a little bit dumber.

The bit about checking data for corruption is just disturbing.

<comment><USER8> > How does "modern software design" reduce the risk of data inconsistency?

By grouping code by business logic, code manipulating the same set of tables tend to land in the same place. Sometimes it even gets refactored.

> Seriously, we've been solving these performance issues for years.

Who are you?

</comment></comment></comment><comment><USER2> If you want to learn the relational model using a fairly slim book, i cant recommend "Practical Issues in Database Management" by Fabian Pascal enough for you!

And always remember, relational theory is one thing, and popular RDBMS is another.

</comment><comment><USER9> Software developers and SQL developers can both usually figure out how to get what they want out of the database...

The problem is the software developer may rely on loops ( and variables, and cursors and temporary tables and dynamically generated sql, the horror) to do his thing while the SQL developer will use set theory to avoid as much of that as possible.

They both rely on what they know, it's just that one persons knowledge is better suited for programming and the other is specific to relational databases.

<comment><USER10> You are entirely right, but permit me to respectfully add a few points I think are critical.

First, the two domains of knowledge are not mutually exclusive. Almost all SQL experts/DBAs are also able to do many forms of more conventional programming, and do them properly. Similarly, many software developers know SQL reasonably well and can write good set based code when they choose too.

Second, if working in the other domain, you pay a hefty price for not approaching that domain on its own terms. Using loops and cursors in MS SQL Server is enormously less efficient than the same solution done in sets (Oracle has a slightly narrower gap, but still a gap. I suspect the same is true of all RDBMS but I can only speak to those from experience). On the flip side, if a normal database developer is shoe horning data into an RDBMS that is not relational, that will cause complications as well.

</comment></comment><comment><USER11> I've always thought that 5NF is a bit overkill. Didn't find one decent example that would make me say "oh, so that's why they do it".

I must say though, after the Database Systems course at DTU, when I come up with a DB design it's almost always in 4NF to start with :). Man, I hated this course.

</comment><comment> alan-crowe I know so little about relational databases that I'm worried about being misled by an unreliable guide found on the internet. Reading suspiciously, this guide seems garbled.

Section 3, second and third normal forms, says "Under second and third normal forms, a non-key field must provide a fact about the key, us the whole key, and nothing but the key. In addition, the record must satisfy first normal form."

There seems to be a stray word "us". Ignoring that, this is cute word play that doesn't quite make sense. If your table has non-key fields you are inevitably providing facts about the non-key fields.

Continuing,

"We deal now only with "single-valued" facts. The fact could be a one-to-many relationship, such as the department of an employee, or a one-to-one relationship, such as the spouse of an employee."

This is the wrong way round. Usually there are lots of employees and a few deparments. Each employee works for just one department, but each department has many employees. Thus the "department of an employee" is a many-to-one relation, or function, which takes an employee and yields a department. The one-to-many relationship here is the employee list of a department.

The example for 3.2 seems to be opening the wrong can of worms. Suppose that Mr Strauss, who works for the department of waltz in Vienna, is seconded to the department of piety in Rome, in order to teach them some dance steps. Then we want his row in the database to read

(Straus, Waltz, Rome)

So one can of worms is sticking generic labels on your fields. If you label your fields (Employee, Department, Employee-location) there is no problem. If you label your fields (Employee, Department, Department-location) you have a problem, but it is obvious. If you label your fields (Employee, Department, Location) you are heading for trouble as some users of the database fill in the location of department and other users of the database fill in the location of the employee.

Hmm, second and third normal form are suspiciously similar, differing only because we regard some fields as belonging to the key. Is the article trustworthy?

</comment><comment><USER12> I studied this summary before my most recent interview. It's a little abstract (in terms of lacking motivation/examples) for those who don't have experience in the field, but if you read it enough times, you get a decent handle on the idea.

<comment><USER13> I don't have any experience in the field, but I did not find it too abstract. Rather not abstract enough. (But on the other hand, I am a mathematician, and know about relations in theory.)

</comment></comment><comment><USER14> Did anyone notice how many grammatical mistakes that article has?</comment>


Ask HN: Company is changing direction, need career advice - <AUTHOR>

I have joined the place 2 years ago. The position was advertised as one for an expert in PHP with ability to understand a lot of the nuances of best practice approaches in web application development. The project that I joined on and for was in trouble. Last fall we shipped it. Yay!
The subsequent work aside from shipping the main project was to maintain other similar stack applications as well as prepare and implement a new project using the same stack.
At some point last year, developers and engineers were notified that the applications used internally and externally will undergo modernization. For all intents and purposes, the new 'stack' projects were the modernization steps, but managements seemed dissatisfied.
Word started to spread that upper and some middle management were less than impressed, and called development efforts as unsustainable.
By the decree from the very top, modernization plan was kaibashed and Oracle/Peoplesoft RFP is now well underway. Hardware is being sourced, software stack will most likely change.
Messaging about the whole thing is tightly controlled. News about eventual implementation is only spread on need to know basis. Questions are simply answered with "When we know something, we'll tell you" approach.
I have close to 10 years experience developing applications. I'm on my third contract extension. About half of the engineers are contract and half are FT. I'm also an optimist, but I'm starting to get wary about my situation.
I would like to ask for your suggestions. If you have any words of wisdom, please share on how one should approach these next couple of months. <comment><USER2> According to the Chinese, a crisis is also an opportunity.

You will come to this crossroads many times in life: things are changing in the workplace - do I have a future here?

The best way to handle this situation is to be ready for both eventualities. If your contract is terminated, you should be in a position to start a new one fairly soon. Since you appear to have some lead time, polish your resume and start interviewing. If your contract is renewed, you may wish to continue, as it is an easy thing to default to.

The former White House Chief of Staff, Rahm Emanuel, used to say "You never let a serious crisis go to waste. And what I mean by that it's an opportunity to do things you think you could not do before."</comment>


Ask HN: What are the best books/articles for startups? - <AUTHOR> EDIT: I know one, Hello, Startup <comment><USER2> if u are just looking for startups then I can recommend u => [https://www.cofoundme.org](https://www.cofoundme.org)</comment>


Ask HN: Describe your first enterprise sale - <AUTHOR> What was it like to make the first enterprise sale at your startup?<p>How'd the enterprise hear about you? What was the first meeting like? What obstacles and challenges did you run into? Were there other companies in the mix? What did you do wrong? What did you do right? <comment><USER2> About six years ago I set up a Dropbox-like service for real estate brokers to handle the paperwork side of the sale and purchase of condominium blocks.

I built the product, which was basically a service for storing and authenticating access to PDFs.

I'd previously built a news portal for the industry and had a mailing list of around 8,000 professionals. I emailed them all and got nothing back. At the same time I researched a few flagship developments and contacted the parties involved. Eventually one agreed to use the service as a trial at zero cost. I was excited - this was a big business. But they weren't interested in continuing and I saw nothing back.

About a month later I received a phone call from the technology manager at a top 5 national firm who'd seen our product being used by this company and thought it was exactly what they needed. I flew for a meeting with them, I copy and pasted my way through a template SaaS contract. They made me fill in a disaster recovery questionnaire and quite a bit of other paperwork - no-one ever checked anything. They wanted the source code for this website in Escrow but in the end they never made any arrangements.

They signed the contract and six years on they still use the service, are the only client, and absolutely love it.

My only helpful advice would be that enterprise sales are actually way more personal than consumer stuff. Me and this technology manager get on well, and have worked well together for years. As the client, they expect to be bought lunch and dinners - that's just the way it is. After all, they sign the checks. Over time my contact has gradually realized that this is a one-man operation. At the same time he's risen high in this company because his initiative has delivered a service that really works for them. Meanwhile all their competitors spurned my 'simple' service to do it in-house, and most of them still haven't built anything. My client merged with another company who had sunk $220,000 into developing the same system and it didn't work. They scrapped it and now just use mine.

I don't want to talk about the service (or grow it) - I keep it going because the monthly check is good, and because they rely on the service.

<comment><USER3> > They made me fill in a disaster recovery questionnaire ... They wanted the > source code for this website in Escrow ...

Can you elaborate on the details or circumstances these parts outlined? Particularly in regard to provisions or protocols to be followed in the event you become unable to render product service (due to disaster against the product or its infrastructure, personal circumstances, or otherwise).

I'm in a similar position that you've described. I'm mostly a one-man shop with a SAAS product that has a Fortune 100 customer. As it becomes increasingly integrated within their company they've voiced concern over what happens if I become unable to render service. We likely have contract amendments coming for code escrow, but I've no experience in this particular area, so thought I'd ask what you learned from these parts of your contract.

If it matters, the product is tightly customized to the customer's work flow, and provides a solution they've been unable to readily find elsewhere. So in the event that service can no longer be rendered, having them subscribe to another product wouldn't be immediately viable.

<comment><USER4> Where I've worked has been an <10 man shop with 2 critical personnel who wrote software that was responsible for the healthcare of hundreds of thousands of individuals, actually probably in the low millions.

We were required to have code escrow contingencies, and one company required those two key personnel not to travel on the same flights.

<comment><USER5> > not to travel on the same flight.

Did they also asked them not to travel in the same car? Chances of dying in a car accident are considerably higher than a plane, unless I am missing the reasoning behind it

<comment><USER6> Part of this is about making sure people are available at last minute notification. If you're in transit from Sydney, Australia to London, UK, you're out of action for 30+ hours plus the time to get over jet lag.

<comment><USER5> I am not buying that, People sleep and do morning routine for 10+ hours and on top of that they have personal life and weekends, you won't ask them to stop doing that so they will be available for you at last minute notification.

<comment><USER7> Whoever is oncall rotation for that week does.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I created a order taking ios app for companies in Italy with Sales reps.

Here's all my first sale story.

-Inbound marketing

I setup a web site...and eventually got some leads (name email phone).

-Qualifying call

I call them up and asked them about the problem they were trying to solve. Many of them were just Software tourists (people that sign up just for fun) but some looked promising.

-Skype meeting Setup.

Some of them asked me to visit them... I said yes, but I told them that I would to set up a short Skype meeting first to understand their problem better... In reality I just wanted to know I there where really App-Worthy before doing the human brochure.

-Skype meeting.

At the beginning of the skype meeting I would try to know more about them, their role in the company etc.. After a little warm up I would dive into the problems list and asked them what my app should do for them rather then just presenting my app.

I asked them if they already have a budget, and when they would like to solve the problem

I show them part of my app (only the parts they asked for) and clearly asked them from 1 to 10 if they think my app would solves their problem.

If I got a vote 8 or below I asked what it would take to reach a 10.

If I got a vote above 8 I asked what we should next..

Most of them usually reply "send me a proposal"

-End of story

After few days... I received my first signed proposal... without meetng them.

<comment><USER9> this all sounds about right. refinements i would add:

* don't ask the customer what the next step is, tell them, show them, push them in the right direction. they have a job to do, and don't want to think about yours.

* also setup a final proposal review meeting for last minute q&a. ask what any last hurdles might be. then push hard for the signature, buyers respect a seller who is confidently trying to drive the schedule forward. be polite but drive forward.

* include a deposit, if not the entire licensing fee as a requirement to start work/deployment. a customer that does not pay you is not a real customer, they are trying to manipulate you for some other purpose i.e. reducing their incumbent vendor's price.

* if you have a working product, do not, under any circumstances, offer any kind of "30 day out" clause, or refund, or whatever. this just means you are going to waste 30 days of your time and money. this is fine for SaaS with freemium, but not enterprisey sales/services driven deals.

in larger businesses you can be flexible on the last point (i.e. accepting a purchase order instead of cash), but as a small shop you can't afford to waste your time or be jerked around by assholes.

but honestly i wouldn't even worry about it, if you're a newbie at sales, it's 100% guaranteed you're going to learn that the hard way. c'est la vie.

<comment><USER10> the 'what happens next' question should be answered or asked depending on the client's personality. sometimes the client wants to be a little important in the negotiations or the company clearly has their own way of doing things, so I ask them 'now what', but it is never asked so bluntly. More along the lines of "To move forward, I typically would send you a proposal/invoice, but I would defer to you on how you company handles this. What works for you?"

</comment></comment></comment><comment><USER11> I don't have a story about enterprise sales, but if you'll allow me I will just slip in the story of the first copy of software that I sold. I hope no one minds.

I wrote a silly computer game about cats ([http://store.steampowered.com/app/386900](http://store.steampowered.com/app/386900)), essentially making a puzzle game out of finite-state automata questions you get during the computation course of a Computer Science degree. Of course, the abstraction on the mechanics involve cats, because it's a good way to trick people into doing computer science.

Now, three weeks before I released the product, I stuck up a webpage where people could purchase the game for a higher price, but the twist was that they could send me a picture of their cat, and I'd put the cat in the game, in a level somewhere. I didn't really know if anyone would be interested, I didn't do any marketing, but since it didn't take long to hook Stripe up and the idea amused me, I went for it. The next day I received my first customer, someone from Peru, who in broken English described their cat 'Missy', and attached a dozen or so photos of her. So, I draw an in-game representation of the Peruvian cat, place her in the game, and add a feature where when the user mouses-over Missy, an overlay pops up with a photo inside. I still have no idea how this customer found me, but I do know who their cat is, what food it likes, what toys are its favourite. Over the course of the three weeks, a little more than a dozen people preordered and sent me (usually loads) of pictures of their cat(s), which was quite a personal subject for some. More than one had recently lost their pet, and wished me to memorialise the cat inside the game, either for them, or their wife/husband, as a gift or as a surprise when they played it through. I did not expect to be in some way apart of people's grieving. Some of them wrote me much later to express their thanks. What stuck with me most though was the feeling of making a personal connection with someone on the otherside of the globe, Peru, Singapore, Algeria, etc, and effectively being introduced to a member of their family. It was a surprisingly meaningful experience.

So no, not at all about big enterprise sales, instead a $10 game involving cats, but, there you go.

<comment><USER12> That's a great story, and it looks like a good game.

Could you elaborate on Steam sales? Non-steam? Thanks!

<comment><USER11> I released on Steam, and Steam's been great. Since I just developed the game by myself, I only needed to sell a couple thousand copies to break even, and that happened fairly quickly. Releasing on my site ([http://cranktrain.com](http://cranktrain.com)) and on other stores like the Humble Store, the Mac Store, that's all rather worthwhile too, it all adds up. My site is a small Django site with Stripe, so that gives me the biggest margins, though I then have to sort out things like European VAT payments, which is a pain, but hopefully I'll grow that for my next game and it'll become worthwhile.

The Cat Machine has done modestly well, but it's let me work on games full- time. And it all started with that one cat-owner in Peru.

<comment><USER13> Have a look at [https://quaderno.io/](https://quaderno.io/) for handling the EU VAT stuff. I actually don't use it, but I remember that they provided a checkout experience similar to Stripe.

</comment></comment></comment></comment><comment><USER14> We recently had our first huge sale to a single customer. It started out as an inbound inquiry to the general email address. I wasn't involved at this time (there are 6 of us, but only one other person handles anything sales/customer related). I believe there were a total of 4 emails outlining the general service, our products, current pricing, and what we could offer in the future. I later learned it was a very junior member of their team who was collecting this information.

The final email, which included a presentation, led to the scheduling of a call with about six people from their side on the call (and two of us). This call lasted about 90 minutes with me talking almost non-stop. After the call they asked for an NDA so that we could share more details. It took about two weeks to get the NDA in place.

The NDA was followed by a request for me to visit them in person for a couple of days. We're based in Chicago and it was a three hour flight. The meeting lasted about 10 hours, with about a half-dozen of their staffers involved, including their consultants. Consultants were involved to offer advice on build-versus-buy.

After I went home, I was asked if their management team could come to Chicago. This ended up being an 8-hour meeting. At the close of that meeting, I had a verbal approval. The paperwork took another week or so to get in order. The initial funds were wired immediately after the contract was signed.

<comment><USER15> _The initial funds were wired immediately after the contract was signed._

For those who are new to enterprise sales and reading this - this is highly unusual for enterprise sales.

Be prepared to waste many man-days chasing after payments to be payed and expect months of delays in receiving them.

The larger the contract the more the delays.

That's the nature of the game

<comment><USER16> It is amazing what not giving the customer the product until they have paid does for speeding up the payment process. I have yet to have a customer who can't manage to get the bill paid when they really want the product.

<comment><USER15> In large enterprise sales, you would typically structure the payments into various milestones.

You may be able to invoice the first one before you actually give them anything but there is a vanishingly small chance of collecting the full payment until well after the product is deployed, probably in-use and occasionally after demands for features that were not agreed upon have been delivered.

</comment></comment></comment></comment><comment><USER17> A Fortune 100 company reached out to one of our advisors looking for technology that was right in our wheel house. We didn't yet have a product but we had the technical underpinnings of a product. I think when they first agreed to talk to us they thought it would just be a way to educate some of their engineers on state of the art techniques in our field. Sort of continuing education for their staff. But we threw together a demo in a week and it impressed them enough that we kept talking and the tone shifted to the potential for a commercial relationship. We put together a few more custom demos and got them to the point where they believed we could deliver technologically. From there we went to a 3-month trial where we gave them the "real product" but only on about 1/10th of their full data. I think we charged about $15k/month for that. The trial was a success and it came time to iron out the full-blown contract. This was a huge ordeal. Because they had so much leverage in the relationship, they threw every awful thing you can imagine in the contract. The negotiation process was stressful and got pretty nasty at points. We caved on many things but held firm on a couple and actually had to walk at one point. They played dead for a couple weeks and then came back to the table. It took about 4 or 5 _months_ to get it over the finish line and we were able to get them to pay the trial fee for all of the months the contract was in limbo (that felt like a big win). The contract was worth just north of $1M and in retrospect I think we got a good deal. What did we do right? We came in very high on price initially and that helped us settled on the higher end. What did we do wrong? We probably fought more than we should have on some of the terms since now we know they were mostly just CYA. It would have been nice to have wrapped it up much more quickly.

In short: takes forever, prepare for pain due to power inequality, and aim high on price.

<comment><AUTHOR> If you don't mind me asking, how much higher was your initial price?

<comment><USER17> About 3x that.

</comment></comment></comment><comment> zupa-hu We ran a web scraper startup selling leads to London property agencies.

I built the product in 3 months in Hungary after which my partner was about to sell it but couldn't due to a vis major.

I extracted the addresses of all London agencies (~2000) from a website collecting them. Then I built a simple CRM system in about a week that was essentially a Google Maps frontend with all of them on it + ability to add notes & color mark them according to their status (if I have visited, interest, etc.).

Than I flew to London, printed some brochures and walked in ~500 of them in a week. (London is/was packed with them, there were sometimes 3 in a row.) I ran around with a brand new iPad 2 which brought me lots of interest - in the iPad..

We got 1 big sale, where I bumped into the CEO of a small chain. He was very entrepreneurial and simply wanted to give it a try. It took a couple of days of negotiation over the phone to iron out the terms. There was no second in- person meeting.

FYI, we got some 10 smaller sales but the marked proved way smaller than anticipated so we shut down.

<comment><USER18> Nice story! With the large volume of Hungarians moving to London, was there not a way you could use your data to help them find a place to live? Having a web scraper that finds appropriate listings before you could physically comb through the websites sounds like it would gain some traction.

</comment></comment><comment><USER19> Simple, contacted VPs of sales for of a large consultancies and offered to give them a percentage of any sale I got from leads they provided. Found one, and required their CEO sign-off on it. After that, all the leads I got were hot and for me, larger than I would have gotten on my own; for the company feeding me the leads, the project sizes were too small.

<comment><USER20> Did that really worked ?

<comment><USER19> Yes, got enough clients to grow on just cashflow; one leads turned client I got from it was a very well known globally recognized brand, publicly traded and a market-cap of half-billion+.

</comment></comment></comment><comment><USER21> I was 17, skipped the last days of school and sold a forum-/chat-/etc. software to the largest german TV channel. The software didn't actually exist at that time, I had to make do with a prototype built in powerpoint.

We got about 20k€ iirc, and later learnt that we should have probably added a zero to that. Took us quite a while to build it and became a bit much for me to manage that project, but we got it done mostly intact.

The whole thing was quite a mess of php spaghetti-code, though. Still had a lot to learn.

</comment><comment><USER22> We had a good idea where we wanted to be - HR software. We built our enterprise product by looking online at what others were doing in the space, then building something that had a single key screen in it that was better than anything else we could find. It seems one good page is often all you need to entice prospects (we certainly didn't have a fully formed product).

Then we got lucky, which is something you probably need at some stage. We came across (chance networking) a giant Telco who needed our product. They'd just 6 months earlier been through a typically elaborate and baroque RFP process to pick their incumbent, a big US player with an exceptionally ugly legacy product. Despite doing their due diligence up the wazoo, they got shafted when the vendor decided to stop selling that product and asked them to pony up again for a multi-100K re-implementation fee onto their new platform.

Telco was enormously pissed off, and we lucked across them just at that moment. They were open to procuring their replacement product in a more lightweight way, so we side-stepped the RFP process and snuck in (also found out afterwards we were about an order of magnitude cheaper - though cost is often not that big a factor in enterprise sales).

From there on we were on a roll, because Telco was so ginourmous, we got plenty of other people signing up just off the back of the halo effect of that one deal.

Then we did all the hard yards - converting those steadily growing revenues into product improvements, and all the stuff that's less luck and more execution. We did awesome, great work, but its questionable whether we'd have got the chance to even run onto the field if not for an initial lucky break.

Things you need for enterprise sales:

\- luck

\- a likeable, trustworthy front person with a cultural affinity with target customers

\- the illusion of a solid, well managed company, i.e. not a one man band

\- the patience to do a swag of accompany paperwork - RFPs, disaster recovery plans, external audits, etc. All a PITA, but worth gold

\- the balls to ask for large amounts of money for your product, because its worth it, and you're worth it

\- perseverance

<comment><USER23> Great story!

How did you manage this: >>\- the illusion of a solid, well managed company, i.e. not a one man band<<?

<comment><USER22> Really a matter of faking it until you've made it..

\- have a physical address

\- have photos of your employees (even if some were drafted in from the office next door)

\- be highly responsive to strange (to you) requests for documentation etc. from their IT, procurement, exec and management teams

\- this is hard but don't over stress when they are late paying you. It takes a hideously long time for corporates to actually cut you a check. They always pay - eventually. But its not impossible to wait for 9 months longer than you thought to get paid, just because of their process. You have to somehow survive this

\- have a lawyer

We bootstrapped off of consulting revenue to cover the costs in the start

</comment></comment></comment><comment><USER24> Our first customer was a lead from one of my co-founders. He'd been in another company a few years prior in the same space, and that company went bust, and the customer needed a new solution. An easy first sale. Later sales proved to be extremely difficult.

IIRC our original price list ranged form $15k to $100k. The typical sale included hardware, a 1U rank-mount server that we pre-instated our software on.

Why were sales so difficult?

\- Enterprise sales can take a long time to close. I think our average close time was a year. That's not surprising when you think about the process most companies have to go through -- getting buy-in across divisions, waiting for an annual budget period to arrive, etc. Educational institutions took the longest -- over a year. You need a lot of runway.

\- Enterprise sales are very high-touch. Lots of phone calls, lots of demos, lots of on-site visits. Prepare to buy lots of meals for decision-makers! It's reasonable for a large company to want to spend time to get comfortable with a start-up... you're competing with HP, Microsoft, EMC, etc. for these customers, and none of them are going away anytime soon, but your startup needs to prove it's real and has staying power.

\- During one of your first get-to-know-you calls, I highly recommend learning about the internal process of the company. What's the signature authority of your contact? Who has to sign off to approve a payment of the size you're thinking of? It's not uncommon to believe you have all the approvals you need, and actually be wrong. We had situations where we installed gear on-site and later learned that a VP needed to sign a check of that size. Don't be rude, but make sure you ask the right questions. You may need to get the name of someone in Payables to get the real deal.

\- To avoid the lengthy approvals process... a trick I liked was to make a custom product just below the expense limit cutoff. For one company I talked to, they could authorize and expense anything under $1k, so we made a product that was $1k/month that they could pay with a credit card and expense.

\- Contracts are part of the long lead time. Expect lots of modifications. If you don't have an attorney handy, this can be a real expense.

\- Source code escrow came up a lot. You may want to investigate options ahead of time and bake the cost into your pricing structure.

By the end of my time there, I was convinced that enterprise sales weren't worth the trouble.

</comment><comment><USER25> I won't give too many details as negotiations have only just closed, but we are product development engineers building a physical hardware/software system and selling to operators to whom product development is a completely foreign concept.

We knew who our target customers were, and made contact with one who came to us at a trade-show. This went through a few rounds of talks, but although the initial contact and his manager were dead keen, the decision maker stalled and we gave up.

Simultaneously, we found a contact in our network who got us to near the top of the hierarchy of a second much bigger customer. They sent a single manager to have a demo, and we must have blown him away because they brought the CEO, CFO, some VPs and even a board member around for the same demo a few days later. They proposed a partnership that day and left us to iron out the details. Direct access to the decision makers was a HUGE part of making this happen.

It took about four weeks of meetings and emails to get alignment, but we're now preparing for a paid trial with an MOU for a much longer partnership assuming all goes well. The biggest challenge was withholding their desired exclusivity in different ways until we reached alignment on the upside to us, at which point we gave them the lockouts and distribution rights they wanted.

Fortunately this deal went well for us, but had it not we'd be talking about how much time we wasted preparing models and spreadsheets and refining terms of agreement. We had other paths we could have gone down, and the interest from this customer was validation that the product was valuable so we weren't short of options. I think that gave us good negotiating leverage, and we were ready to walk away at one point. The biggest irritation was probably the translation from verbal discussions to written form, as it seemed like terms we'd talked through and removed were being re-added in different flavours each round. Careless (or perhaps deliberate...) wording could have cost us half our upside, but we spotted that and resolved it.

I don't believe any other companies were in the mix. I suspect they saw that our product was a distinct improvement over their existing capability on so many counts that they just jumped at the prospect of getting it exclusively before their competitors did.

</comment><comment><USER26> We were building a price comparison company. I was trying to figure out ways to make money after we were turned down by YC and unsatisfied with 4 months of fundraising. Thought we'd try and sell our price lists to businesses who wanted to be competitive.

I tracked down the biggest in the region, found someone there who had upvoted a couple answers of mine on Quora, pinged him there, and he replied. Said it was interesting, but he had no idea what price comparison was, so forwarded me on to the COO.

I met the COO at Starbucks, we talked for a couple hours. Initially, he said it was a very interesting concept, but he didn't understand how to integrate our information into his product. I said it would be easy to integrate it in his data warehouse. He asked me what that was. I explained, he asked me how much we'd want to build it for them part time. The contract was signed the next day after a 30 second meeting with the CEO, and so we were in the data business.

I didn't get on well with the CEO, in great part because I was still inexperienced at the political side of sales and would say what I thought in emails, particularly about their existing BI efforts. So we parted ways after 6 months, but they had a data warehouse and automated reports by that point, which afaik are still running there under a new team.

To this day it is my only cold pitch conversion. Every other client I ever had came through connections (making me wonder the value of spending time on pitching). Sometimes as random as - I met a guy in a conference I talked at, he invites me to his next government event, he introduces me to his friend who left the civil service for a VC, the VC likes what I'm saying and introduces me to her portfolio companies, one of them signs.

</comment><comment><USER27> I used to run a company called Active Interview. I say "used to" because the product is on auto-pilot now, and just cruising along without any support with MRR of around $1200.

The very first sale was done before our recurring pricing was even built. We had a contact who sold video interviewing to One Laptop Per Child _without a product_. He was a sales guy trying to build a product, but was having trouble executing on the implementation (as programmers, this is probably an old story). He saw our product and said it was exactly what he was trying to build. He agree to split the revenue with us 50/50, if we allowed him to use our product for his clients. That was our first and last enterprise check, and this was before our product was even fully finished. The One Laptop Per Child interviewing went very well, and we were able to get some minor publicity out of it. At that point, we thought we had something big, and wanted to pursue our vision of a SaaS product, instead of doing pure enterprise with the sales person who found us. We were one of the first video interviewing products, along with Hirevue, and was sure there was a market out there. At first, this was true.

Our first enterprise sale on our own was Airbnb, and was relatively easy. A lead from one of their departments sent in an email, and after a demo, they signed up for our $500/month plan. We created that plan only to provide a contrast to our $99/mo plan, which we thought would be the primary seller. Turns out $500/mo is nothing for enterprises, and soon that's the only plan anyone ever cared about. The Silicon Valley startups in general were much easier to sell to. Wildfire Interactive (later bought by Google) was also an early customer, as was odesk, and a couple of other startup companies. They were all very easy to deal with. They were abnormal though, as we found out later.

The real enterprise sales experience came from more traditional industries. For our product, that meant mostly recruiting firms. No one used the free trial, and everyone wanted a demo. They wanted to speak to someone over the phone, and do several rounds of demos. The first was usually with a smaller manager or analyst in HR. Then subsequent demos would be head of recruiting or HR, or other senior executives. Almost every demo ended with the clients being impressed by the product, but no commitment. We did demos with some of the largest recruiting companies in the US, and with some of the largest retail firms in the US (head of Marshalls/TJMaxx, for example). In the end they went with a bigger company because they couldn't trust a couple of scrappy guys with their business, even though the product was good. Our pricing was also off-putting, because it was way too low. Low prices send a signal of poor support and poor quality to senior executives. $500/mo is a rounding error to them, and we probably would've made a better impression by asking for $10k upfront and $2k/mo and assigned an account manager to each client so they have a point of contact.

That taught us a lesson - if you want to go after enterprise, it's not really about the product. It's all about sales and hiring account managers and showing that you too are a big company. In that sort of field, you almost have to take VC funding to "act big".

The alternative is to do what Basecamp did which is become thought leaders in your field, but we really didn't love the recruiting industry enough to even attempt to do that.

I'm not sure if this is the type of answer you're looking for, as this is more of a failed enterprise company. I've talked to a lot of small companies who do enterprise sales, and the success stories I've heard always revolve around building an in-house sales team and ensuring a successful on-boarding experience for customers by way of account managers.

That costs a lot. For bootstrapped companies, that's just not possible.

<comment><USER28> Thanks for sharing your story. It's super interesting.

I've seen the long, drawn out and high touch enterprise sales process shock a lot of product and engineering driven startups.

It's too bad. I think this heavy sales process that enterprises usually demand slows down the pace of innovation. I mean, I get why they want account executives, and even why they feel more comfortable dealing with a seemingly "bigger" company. But there are a lot of people with game-changing ideas who can't get them off the ground because they can't build an effective sales org on a shoestring.

I wonder if there's a way around this situation. I mean, maybe some kind of AEs-as-a-service thing could be helpful (if that doesn't already exist).

<comment><USER27> There are sales-as-a-service type of companies out there, but most I've seen are a bit sleezy. Premium ones, I imagine, would cost similarly to a good salesperson.

The most successful model I've seen is hiring recent college grads who are sharp and willing to learn. They are cheap and will dive into the industry they're selling. A lot of funded startups operate this way, usually led by an experienced salesperson.

</comment></comment></comment><comment><USER29> These are great. Could the OP please include a request for people to optionally include their technology stack?

Thanks either way!

<comment><USER30> A wonderful thread indeed!

</comment></comment><comment><USER31> Selling software to law firms. Father of a friend's wife had heard I was building the particular type of software his firm needed for a case. They purchased the software almost sight unseen. Sometimes you need a little luck with those first sales!

</comment><comment><USER32> Started a company that sells SAAS to US investment banks. I was a former banker and spent a lot of time priming my colleagues for the service prior to starting it assuming they would be willing customers when it was ready (we addressed a niche that was quite a problem for the banks). I thought that if we built a better mouse trap that significantly improved the user experience (for investors, the under writers and the issuers - the companies that actually raise the money) and saved everyone thousands of dollars it would be a no brainier for the banks to use us. Didn't happen. When the time came, bankers who, contrary to public perception are highly risk averse and focus on risk mitigation, didn't want to migrate to something untested despite our domain knowledge and demonstrable improvements. They didn't say this of course - it was always another reason such as "it's not my choice" or whatever.

The way we established a foot hold was to go straight to the issuers. What made our service unique is that while a bank was our user the service was often chosen on behalf of someone else (their client, the issuer). 99% of the time the issuer is silent on which service the banks use, after all they pay the banks to advise them. So we instead sold the service to them (well in the beginning let them use it for free). They in turn told the banks that they needed to use our service and the banks, who ultimately serve the issuers, simply complied. Once we had 2-3 of the banks onboard, network effects kicked in. With each sale we would go to another bank and say "let me show you what we did for XYZ"

Moral of the story (for us at least): 1) someone may indicate they are a champion but when the time comes, most are unlikely to be there. For every team of 40-50 you can at best expect 1-2 people willing to be champions 2) if possible (and I can appreciate that not all services can do this) sell to the person that ultimately benefits from this. In our case, banks use our software in relation to capital markets deals for other companies like John Deere so go to John Deere directly. 3) random point not mentioned above but worth highlighting ... I find that enterprise customers care more about making a dollar than saving a dollar. Our sales improved dramatically by tweaking the message to focus on this. If possible, focus on how you help these organizations grow P&L 4) I am a HUGE believer in Trojan Horses (and I don't mean hacking software). If possible, figure out a way to get your prospects using or benefiting from your software immediately by giving some service away (maybe not even your core service) weekly or if possible daily. The more they interact with you, the easier it is to bridge the divide and get through the process. 5) last point, don't get hung up on engagement letters. I know the lawyers will advise against this but a lot of deals die in the engagement letter phase. I appreciate not every business can do this but I made it crystal clear to my accounts that if they don't like my service they don't need to pay for it - that gave gem the comfort to use it regularly and at the end, they all paid for every use.

I can go on further on some of the tactical nuances of the above and other strategies. Feel free to ping me.

<comment><USER33> Yeah I'd like to hear more. What are the specific ways you tweaked your message to focus on making a dollar?

<comment><USER32> In a typical enterprise sale, the people making the decision (to buy your solution) are usually too senior to be the ones actually using it. There is a subtle corollary to this that I did not appreciate at first... often, these people are responsible for the profit of their group but less responsible for the costs associated with the technology. Thus, teams are less sensitive to cost than they are top-line revenue. There is a lot of theory about how silly focusing on top line is instead of profit but we all know the difference between theory and practice.

So how did I change my pitch: I ripped out all the slides that walked through my site and all the neat ways we saved time, automated workflows, etc. I focused on the data we generated (in one page) and threw in two case studies that highlighted how decisions made with our data generated more revenue.

It is important to highlight that the pitch-deck is not what is selling your solution, you are. The key is to tell a story worth listening to and I use my pitch decks to guide that story. My pitch today has X pages:

\- Cover Page \- Page with client logos (demonstrating social acceptance) \- Page with big picture showing our platform works on all browser enabled devices (a major innovation on wall street) \- Page demonstrating the insights our data creates \- 2x case studies

Hard to put an exact number on how well this new method of focusing on the outcome rather than the solution has helped but I do not believe I am exaggerating by saying it improved close rate by 1-2 order of magnitudes.

If you want to read some great books that I believe will dramatically improve your close rate, I recommend the following in order:

1) Dale Carnegie's How to Win Friends and Influence People - if put in practice, this will pay a life-time of dividends. I wish this was taught in schools.

2) Getting to Yes (on negotiation theory) - a powerful negotiation framework allows you to create and preserve value in very measurable ways.

3) the Psychology of Influence - great case studies on how people make decisions, often in ways that are irrational. I incorporated a lot of the learning points into my pitch and in our slides and absolutely saw a shift.

I love thinking through this stuff so to the extent you want to chat more, happy to hop on a call or grab a coffee if you're in NYC. Shoot me an email (in my profile).

<comment><USER33> Thanks, it's so useful to get this kind of detailed advice from someone who has worked through these challenges. I may take you up on that offer!

</comment></comment></comment></comment><comment><USER34> How we got our first enterprise customer (a company in Sri Lanka)

[http://vpj.github.io/b2b_customer.html](http://vpj.github.io/b2b_customer.html)

tl;dr; We got the contact from one of our investors. First meeting was a product demo and a short presentation. There were long time gaps between meetings (it took several months to get to the trial). We didn't have a simpler way of doing the trial.

</comment><comment><USER35> went to a marketing tech conference and pitched our idea about AdWords Automation : AdNabu to a bunch of people. Exchanged cards with a few of them. We couldn't get meetings with any of them.

We got a call from from an enterprise with whom we couldn't interact personally. Met them in their office twice, started a free trial, showed positive results and they became a paying customer in a month

We had to sign a lot of documents but the contract is longer and more profitable to us :)

</comment><comment><USER36> JGEWQ</comment>


Paul Buchheit Affiliated imo.im Seeks Hacker ($25k starting bonus) - <AUTHOR> http://www.crunchboard.com/item/18800419-imoim-software-engineer <comment><USER2> unifying messaging. blog here ~ <http://imoim.blogspot.com/> pb is an advisor

<comment><USER3> Paul shares an office with this guy. I assume they're similar ages, and seem to be similarly experienced (both early Googlers, now retired). Is advisor really the right word, here?

</comment></comment><comment><USER4> Is $25k starting bonus a usual thing? I now use this over meebo, so fast and clean

<comment><USER5> that bonus is your pay. the salary is just sweat equity. i've been tricked by this before.

<comment><USER6> It does sound like an old dot.com 1.0 scam: $25K starting bonus!!! And your salary is... stock options!

If it is $25K bonus plus $100K salary plus 2-4% of the company, it is worth considering.

The person they are looking for is hard to find and would be worth $95-$140K STARTING at another startup.

</comment></comment></comment><comment><USER5> meebo?

<comment><USER7> it loads faster than meebo

<comment><USER8> Does it load faster than RadiusIM?

Ebuddy?

The Google Talk Widget?

KoolIM?

Aren't these things a dime a dozen?

<comment><USER9> It'll definitely be interesting to see if/how they try to distinguish themselves from the others.

<comment><USER10> According to the blog, the group chat can span multiple networks (AIM, Yahoo!, MSN etc)</comment></comment></comment></comment></comment>


Mark Zuckerberg can't believe India isn't grateful for Facebook's free internet - <AUTHOR> http://qz.com/582587/mark-zuckerberg-cant-believe-india-isnt-grateful-for-facebooks-free-internet/ <comment><USER2> Mark may think that he is doing right, but in reality, he is not. Even now FB is running an Ad campaign on TV channels in which Mark is addressing gathering at Town Hall of IIT-D and professing free basic internet. Though how hard he argues, it is against net neutrality and yes they websites that are going to be there under free basics, are going to become way more popular than the other. So one way or another, this isn't a charity as Mark is pinpointing, it is money making under the covers.

</comment><comment><USER3> If MarkZ is really serious of providing free Internet in India. He has 2 options:

1\. Provide free access to non-profit sites like Wikipedia & Indian Govt sites that will help the people. This is in a gray area as Wikipedia in non profit org and Govt sites do not profit from the access of people.

2\. Provide very Indian user free 200mb internet connection. The user can access any site they want. With some browser like Opera Mini that takes less bandwidth.

The point MZ refuses to understand or acts like he does not understand is that if his version of service starts, the "next-Facebook" will not have any chance in India. Hope he does not forget that Facebook itself was the "next-Orkut" & "next-myspace".</comment>


Node.js is genuinely exciting - <AUTHOR> http://simonwillison.net/2009/Nov/23/node/

<comment><USER2> I just jumped on node a few days ago.

People who are already comfortable with programming with events and closures in Javascript are going to try Node and say things like "where has this been all my life?". In those few short days Node has highlighted to me just how dramatic of an impact a tool that is close to your language/model of choice can have on your ability to rapidly turn ideas into working code. For a cross section of coders that work with jQuery all day, Node will be a big deal.

Node has some really friendly and highly productive people working behind it, chief among them Ryan Dahl ( <http://github.com/ry> ). To learn Node's ins and outs and have some fun, I spent this weekend building out a simple node-based MapReduce-like work unit processor and needed a lot of random help along the way. When I needed gzip ( <http://github.com/waveto/node-compress> ), or to communicate with Unix command processes, or a redis client ( <http://github.com/fictorial/redis-node-client/> ), the Node community was there to help me very quickly.

Simply said, Node.js is a very productive and fun environment for weekend hacks, and I expect it to become a primary fixture in my toolbox in the coming months.

[edit: added links]

</comment><comment><USER3> It's really awkward to write evened code without a good implementation of futures ( or go's channels ). The problem is that you end up nesting a lot. Look at the example for the posix rename here: <http://nodejs.org/api.html#_posix_module>

Now imagine implementing a normal http controller. You have to do say 5 MySQL call (or redis, whatever) to get all the data you want. This means that you have to nest together 5 closures. Now if any of the methods fails and there is no global error handler that disconnects the client then that means that the connection will hang forever until the browser user hits the stop button. Spotting these situations becomes really hard with complex code.

Futures ( Go channels ) solve this because they block the thread when someone accesses the data. If you want to do 3 db calls you can just write familiar code:

var a = db.select(...); var b = db.select(...); var c = db.select(...);

print c #=> blocks until c has returned

<comment><USER4> This is precisely my concern, and I have talked to a lot of people regarding this exact point. I think node.js is really cool but I would love if this was just built into the language, such that code would perform asynchronously but not move to the next line.

var a = something_async(), b = something_else_async();

Upon calling something_async, the code starts waiting and blocks further execution until it is ready, going to the next statement. This is not a foreign concept at all, and is used in javascript as well with alert, prompt, confirm:

fries = window.confirm("Do you want fries with that?")

confirm is an async method (has to wait for the user), but the next line is not executed until it returns. I personally see _no_ advantage to creating a system of callbacks:

do_x(function () { do_y(function() { do_z() }) })

when this would be much more readable:

do_x(); do_y(); do_z();

and would have the exact same perf characteristics. In fact, you could probably simpy code transform the latter into the former (I know this is what stratified JS does), although this is probably the worst way to do it. What you really want is to just auto-call "wait" on every promise (I believe wait still gives you the asynchronous benefits).

Of course, the main "drawback" to this is that you need language support to pull it off, so you need to implement a preprocessor of some sort.

<comment><USER5> I don't understand your concern. When you say 'Upon calling something_async, the code starts waiting and blocks further execution until it is ready', you're describing a _synchronous_ call. Indeed window.confirm is a synchronous function--nothing is executed until it returns.

And yes, both asynchronous and synchronous operations have their place, _umm_ , except perhaps in Haskell where things get funky. Chaining async operations together in javascript can be tedious, but its easy enough to write a helper function to handle it for you. Every javascript app I've written that uses AJAX always has some form of createCallback(context, function, arguments) function.

<comment><USER3> Re-read my example. All 3 db queries are run in parallel however the code does not continue if you access one of the values until the value is available. In a typical web application you usually get 3-5 things from the db, then you start rendering the templates. Each DB query waits for completion, then it starts the next which is a huge waste of time. In fact the system can easily start the parser and template renderer while the DB queries run and all the data will likely be available once it's accessed. This means you have _all_ the benefits of synchronous processing with the majority of the advantages of async. The vast majority of web applications would likely very rarely block a thread in such an architecture.

I'm very surprised that not more languages implement this pattern. Maybe i'm missing something but this is the major feature of GO, except that almost everyone missed it and focused on the fact that it compiles fast and looks like c

<comment><USER6> Seems like you the dataflow paradigm is exactly what you'd need. With dataflow, trying to read a variable that doesn't know its value yet blocks until the value becomes known.

</comment></comment></comment></comment></comment><comment><USER7> I'm excited about it. I've been attempting to blog, and using node.js as my subject matter. (Don't want to link-pimp as I need to enhance/edit, but you can check my profile if you're interested).

It's my opinion that JS is the new lingua franca of programming, and it's about time we replaced C/Java. It has consistent syntax, some great functional aspects, dynamic typing, and it's now become a top target for optimization by some of the world's smartest engineers.

Breaking into systems coding is the next step, IMO, in JS becoming a legitimate option for "anything" programming. I think node.js is going to be the library for it. It's really idiomatic and concise, and it's got just the right amount of opinionatedness I think to become the systems and JS version of Rails.

<comment><USER8> What exactly is the driving force behind the desire to do everything in Javascript? Is it just because we have a surplus of Javascript programmers? It doesn't seem to me that this task is particularly well suited to Javascript. (I think) Something like Erlang would be more applicable.

And to me it seems that learning a new programming language (even one using a relatively obscure syntax), is a much simpler task than designing an entire project (or piece of a project), around a language that doesn't really fit the needs of a project.

To that extent, I think that the idea of a 'lingua franca' language is an inherently broken metaphor. Programming languages are closer to human-computer interaction tools than they are natural languages. 'Lingua franca' implies that every language can communicate approximately the same thing (it is just a matter of who has influence). I think this is a mistake, as different languages allow you to think in hugely different ways about programming. Different languages have different intrinsic concepts.

It may be that this argument boils down to 'if all you have is a hammer, everything looks like a nail,' but even that is an oversimplification, as I don't even use the same hammer for all types of nails (tack hammer, framing hammer, etc).

I am not saying that node.js is necessarily a bad thing to have. It may turn out that Javascript is indeed particularly well suited to this type of application. Superficially, however, nothing convinces me that this is some sort of exciting home-run-win situation (or that it is any better than any other functional-style programming language).

Could you explain the excitement and appeal to me?

<comment><AUTHOR> "Could you explain the excitement and appeal to me?"

There's not much I can say that I didn't already say in my blog entry. JavaScript is designed for event-driven programming in the browser, and my brief experience with node.js makes me believe that it also works well for event-driven programming on the server. And V8 is really fast.

As for Erlang... when you're programming for the web, it's useful to have a programming language that treats strings as more than just an array of integers.

<comment><USER8> With regard to Erlang, are you sure? Joe Armstrong seems to think its fine for string manipulation...

[http://www.erlang.org/cgi-bin/ezmlm- cgi?4:mss:47293:200911:d...](http://www.erlang.org/cgi-bin/ezmlm- cgi?4:mss:47293:200911:dmkmepbchkebogigcnaf)

(You can either think that he is biased or that he would be an expert on it).

I mean, it seems to me that javascripts main advantage in programming for the web would be DOM manipulation. And that is good, but a lot of languages can do it. (Honestly I've never really done (much) direct string manipulation for web programming).

It doesn't seem to me that javascript really has a monopoly on event driven programming either. It is relatively easy to do that sort of thing in almost any other functional style language...

</comment></comment></comment></comment><comment><USER9> > Twisted and EventMachine are hampered by the existence of a large number of > blocking libraries for their respective languages. Part of the difficulty in > learning those technologies is understanding which Python or Ruby libraries > you can use and which ones you have to avoid.

This is what's interesting, I think. The reason Erlang does so well at this is that stuff written in Erlang basically just doesn't block because a scheduler sits under the whole thing.

> Node creator Ryan Dahl has a stated aim for Node to never provide a blocking > API—even filesystem access and DNS lookups are catered for with non-blocking > callback based APIs.

So that's the tricky bit, I suppose, especially as your language/environment grow, and people start doing random stuff with it.

BTW, it's also worth mentioning that Tcl has had a nice event system since well before Twisted came out, built into the language. However, like Python, you can't count on random commands not to block, so you have to be careful.

<comment><USER10> I don't find that particularly true with Twisted because for every common blocking library there is a Twisted equivalent. Whether you need http, ssh, db, or a multitude of other protocols and interfaces, Twisted has them. Sure, you have to be a _little_ careful, but chances are if you're using an event- based networking engine you have a good reason for doing so and a pretty specific purpose.

</comment></comment><comment><USER11> I've compiled it and had a brief look at this. I have got only this to say, it is a very important evolutionary step in server-side coding and coding in general. Really impressed! Though I have one more question, how do you handle concurrency? I mean, mutex, locks, etc. Don't get me wrong, I'm not being picky, just wondering what could be the best solution for this.

Edit: Or Events in EventEmitter are being executed one at a time, so there is no need for locks?

<comment><AUTHOR> Node is single threaded, so you shouldn't need to implement any locks yourself.

</comment></comment><comment><USER12> (Comment repeated from proggit, where this was also posted.)

Don't get me wrong here, I love coding in Javascript and have often entertained the idea that server-side Javascript would be fun. I also totally buy the need to get away from thread-per-request for many web serving scenarios, Comet being a perfect example.

However when I see someone going so far with this as to say "all APIs must be non-blocking" I have to wonder if they would be better served by using a language where threads were less expensive. I know closures make this kind of thing a lot less of a pain than back in the day when we were programming against OSs with no threads and async APIs were often a necessity, but to mandate this style is basically asking developers to manually rewrite all of their logic into continuation passing style. It's a bit, well... naive is the kindest word that comes to mind.

BTW, I don't think it's a coincidence that all of these event-driven web frameworks are for interpreted languages with crappy thread support.

</comment><comment><USER13> The 'Hello World' example (at the top of the front page of the Node.js website) is a server that listens to http requests, waits 2 seconds, then responds 'Hello World'.

The server is supposed to continue responding to incoming requests even while it is waiting 2 seconds for previous requests. So I figured that if I quickly queued up a bunch of requests (say, over the course of one second), they would all respond just as quickly after the two seconds was up.

However, each response came a full 2 seconds after the previous response. I increased the wait argument to 10 seconds just to be sure.

This seems functionally equivalent to blocking. Is this the way the example is supposed to work?

<comment><AUTHOR> Was your client sending the requests concurrently? If I do that and run "ab -n 100 -c 100" (for 100 requests run with concurrency 100) the benchmark takes almost exactly 2 seconds to execute all 100 requests.

<comment><USER13> I guess not - it worked when I followed your suggestion. Thanks!

I was naively cranking out a bunch of tabs in Firefox really quickly. :) I guess Firefox doesn't make concurrent requests when it's the same URL...?

<comment><USER14> Firefox only makes two (by now maybe four) concurrent requests to the same server as mandated by the HTTP protocol.

<comment><USER15> It's technically not mandated, but recommended. Servers need to be able to deal with more anyway, as proxy servers are recommended to open up to 2 * [no of clients] connections to upstream servers.

</comment></comment></comment></comment></comment><comment><USER16> It is unfortunate that none of the JS VMs have support for concurrency. Event driven programming can get messy (lots of state machines).

<comment><USER17> It's usually pretty trivial to create an event bus where you can publish and subscribe to events.

<comment><USER16> How is that equivalent to new threads (stacks) of execution?

<comment><USER17> It's nothing to do with concurrency - the event bus pattern will alleviate much of the pain around event-driven programming (the FSM's you were referring to) and decouple the event handling machines. In my experience, moving to an event bus model makes event driven programming very manageable.

If the event bus has executors (which it could in v8), it will be parallel to boot.

</comment></comment></comment></comment><comment><USER18> "Exciting" is an understatement. Cloned and compiled it yesterday and since then I can't bring myself to stop playing with it.

<comment><USER19> I also recently cloned and compiled it myself, but I haven't had much time to play with it yet.

I have been doing a lot of Javascript/jQuery UI stuff at work lately and have become VERY comfortable with the anonymous callbacks and such. Now I'm ready to jump on Node and see what I can do. This looks awesome!

</comment></comment><comment><USER11> Sorry, can somebody explain me how this works? Obviously, I'm missing something. Is the code being interpreted on the server-side? Then my question is, how fast it is and if it's capable to serve large number of connections? Actually, it's very exciting if it runs no slower than Java.

<comment><AUTHOR> Yes, it's being executed on the server. It's very fast - 3,500 requests a second for returning a "hello world" string with 100 simultaneous connections, and because its all event based it should be able of handling thousands of concurrent connections without much trouble (I haven't tried yet because my laptop runs out of file descriptors).

<comment><USER20> You know you can just bump allowed file descriptors up with ulimit, right?

</comment></comment></comment><comment><USER21> Glad I read this. I'd assumed Node.js had something to do with the Nodebox visualization environment on Javascript (I think a project like that has been featured here before). While that would be interesting and pretty, it wouldn't be my cup of tea right now.

This, however, looks really cool. I've been waiting for a compelling JS server side framework for awhile—definitely going to have to check it out. I hope other people aren't making the same mistake.

</comment><comment><USER22> For those of you who have taken a look at this, is there any library or construct in python that would be equivalent to the Events in Node.js? <http://nodejs.org/api.html#_events>

That's the deal maker for me... To have custom defined events. Correct me if I'm wrong but even Twisted doesn't have this facility?

<comment><AUTHOR> I'm pretty sure Twisted's deferreds serve the same purpose.

</comment></comment><comment><USER23> It's great to see node.js starting to support CommonJS (<http://commonjs.org/>) modules.

</comment><comment><USER24> Very exciting! What sort of persistent storage options are there for something like this?

<comment><USER25> There are several options already available, including file i/o and Postgres db connections. cf. <http://wiki.github.com/ry/node>

</comment></comment><comment><USER26> What's the main one advantage of Node.js over php (or ruby)?

<comment><AUTHOR> As I said in the article, it's event based which means it can handle massive concurrency and serve pages that don't necessarily reply straight away - perfect for implementing things like comet. It gives you similar capabilities to Ruby's EventMachine. I don't think PHP has an equivalent at the moment.

</comment></comment><comment><USER27> Does v8 know supports cross-platform aio, epoll, kqueue or at least sendfile()?

<comment><USER28> Node uses libev: <http://software.schmorp.de/pkg/libev.html></comment></comment>


Red meat and processed food 'not back on the menu' according to new review - open-source-ux https://www.nhs.uk/news/food-and-diet/red-meat-and-processed-food-not-back-on-the-menu-according-to-new-review/ <comment><USER2> I swear if it weren't for the many institutional problems plaguing academia including publish or perish in particular, shoddy bullshit studies like this would never see the light of day.

Even bending over backwards they were barely able to show a tiny _correlation_ from _surveys_. Meat consumption was the evolutionary step that enabled primates to develop and maintain biologically expensive brains that made them human. There unquestionably had to have been a strong evolutionary pressure to adapt completely to meat eating.

This is just data dredging in pursuit of justification for some kind of weird anti-meat sentiment which has been growing for decades, when the real culprit is already known - it's the sugars that have most likely been killing all of us, although to be honest if the same "gold standard" methods were applied to sugar related studies I'd question those as well. The way the media continues to sensationalize these correlative, broken studies is shameful.

<comment><USER3> Perhaps there could be a strong evolutionary pressure to adapt to meat eating AND it could cause a slight increase in certain illnesses if consumed regularly by certain populations? If we look at blue zones where people live the longest, one commonality is 95% of their diets are vegetables, grains, and legumes, with limited meat consumption. At the end of the day it comes down to goals and priorities. If performance is a priority, I think meat consumption can be a good thing. If longevity is a priority, limiting meat consumption is probably a good thing. We have to take a nuanced approach. Nutrition science is difficult, and different populations naturally respond in different ways to a variety of diets. Some will naturally thrive on meat heavy diets while others will not.

<comment><USER2> >If longevity is a priority, limiting meat consumption is probably a good thing

But 90% of people don't seem to understand that literally _all_ studies on meat are of this quality and there's zero reliable evidence that red meat is actually harmful.

However there is reason for bias considering meat gets a bad rap for being environmentally unfriendly and cruel, although both of those things can be solved with modern technology. But neither are valid reasons to dig for dirt with an agenda. That's bad science and studies like these are potentially the results. Not to accuse the authors specifically, but the bias is very likely influencing the direction of research in the field.

</comment></comment></comment><comment><USER4> This is great. A calm, accessible analysis of a complex, emotive and apparently volatile topic. Well done NHS.

Of interest here's a Freedom of Information request about the consultants Bazian who produced this for the NHS: [https://www.whatdotheyknow.com/request/bazian_services_to_th...](https://www.whatdotheyknow.com/request/bazian_services_to_the_nhs_and_r)

<comment><USER5> I used to read this blog, until I realised every article was:

"This study is limited and warrants further research. This alone does not warrant a change to dietary advice. We encourage people eat per the Eat Well plate, as we've done for 15+ years."

At which point I stopped reading newspaper articles on diet, nor their critiques, and spent that time on following their advice.

<comment><USER4> No sensible health authority would change dietary advice based on a single study. Consider research like this as discrete steps in one direction or another, with a much longer continuous waveform representing national and population-led understanding.

</comment></comment></comment><comment><USER6> >red meat: 0.17% over 10 years, 0.41% over 20 years and 0.62% over 30 years

Isn't this essentially nothing? Am I misinterpreting these results?

<comment><USER7> > Isn't this essentially nothing?

Essentially nothing: for an individual? Yes. For a population? No.

You or I may not care about a 0.62% increased CVD rate for ourselves over 30 years, but that does translate to 6,200 extra possibly-preventable cases of CVD per million people. That's about 76,000 diagnoses annually in the US alone.

<comment><USER8> This way of interpreting the data is misleading. For population, it still could mean nothing. People are not living in an isolated environment just eating red meat or processed food and do nothing else. At the population level there are way more factors need to be considered. You can't even imagine how many things in the society will be impacted if people stop eating red meat or the processed food. CVD will be the least of concern at the population level.

So, yes, this tiny effect size means nothing.

Moreover, this tiny effect size could be much smaller than noises in the data.

<comment><USER7> It _could_ mean nothing, or it could not. But a small effect size alone doesn't tell you this, and you are correct that there are many factors — that is exactly the point of this study, to tease apart which other factors are causative.

Of course, this study says nothing about what happens if you try to change behavior, that seems like an entirely unrelated point.

Taken together, I'm not sure how you can be so confident that a small effect size therefore means nothing.

</comment></comment></comment></comment><comment><USER9> Just as bad to lump both red meat and processed food into the same category. The additives in the latter have been shown definitively to do harm, whereas there is less evidence about the former.

<comment><USER5> Did you read the article?

The analysis and results treats then separately:

"processed meat: you would increase your risk by 0.4% over 10 years, 1.02% over 20 years and 1.74% over 30 years red meat: 0.17% over 10 years, 0.41% over 20 years and 0.62% over 30 years"

> The additives in the latter have been shown definitively to do harm, whereas > there is less evidence about the former.

The article _is_ evidence of their relative risk, and it does sound consistent with your prior.

<comment><USER10> I haven't read the article yet, but going from the headline, I certainly assumed they were claiming the same/similar risk for both red and processed meat.

From the summary you gave, it certainly does seem like a click-baity headline. Personally I would have hoped for better from the NHS (even if I wouldn't have expected it).

<comment><USER11> I'm sorry, but that's simply an unwarranted assumption.

<comment><USER10> Eh? The figures given are clear (and yes, I've read the article by now) - <AUTHOR> risk associated with processed meat is _much_ greater than that with red meat.

<comment><USER11> The assumption I'm referring to is just the thing you said, in your post, that you assumed.

<comment><USER10> Ah, sorry, I see what you mean now. It was the part where you said "unwarranted" that confused me, as the thing I said was warranted by the headline, the very thing I said was the basis for the assumption.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Interesting how the numbers are pumped up for the headline.

The risk is increased by 7% for eating _processed_ meat, not red meat. And the actual numbers are:

        processed meat: you would increase your risk by 0.4% over 10 years, 1.02% over 20 years and 1.74% over 30 years
        red meat: 0.17% over 10 years, 0.41% over 20 years and 0.62% over 30 years
        poultry: 0.20% over 10 years, 0.54% over 20 years and 1.03% over 30 years

<comment><USER13> I'm mostly surprised poultry is worse than red meat. I realize the supermarket chickens most people eat are a far cry from their ancestors (ridiculously overfed, grain diets, selectively bred to grow faster and fatter), but cattle have many similar issues.

<comment><USER12> It is mentioned that the results are barely statistically significant for unprocessed meat; it also states that _" poultry could mean plain meat or deep-fried"_ which makes a huge difference.

</comment></comment></comment><comment><USER14> Could someone explain to me how could researchers come to these conclusions if there are different factors at play that surely impact the results? The article states that:

> Participants consumed a weekly average of 1.5 servings of processed meat, 3 > for unprocessed, 2 for poultry and 1.6 servings of fish. People with higher > intake were generally more likely to be smokers, drink more alcohol, have a > higher body mass index (BMI) and a lower overall diet quality.

If that's the case then how is it possible for a cohort study to properly control for all of these? Isn't 7% increase in risk basically telling nothing then? The other thing is the methodology. The article says that they used "standard food frequency questionnaire" which I think means Food Frequency Questionnaire. This alone seems like it would have great effects on the efficacy of the research making the results even more questionable.

<comment><USER15> They use statistical methods to eliminate the confounding variables. But given that they do not understand the fallibility of doing that on extremely noisy data, the conclusions are telling us nothing.

They cannot control anything and it's all just questionnaires.

It's fine too look at these things but they seem to get blown out of proportion every single time, even when industry funded studies come out saying eggs or bacon is fine.

And yes, 7% increased risk is practically nothing. That's baseline risk multiplied by 1.07. It's noise all the way.

<comment><USER16> > They use statistical methods to eliminate the confounding variables.

Some of those anyway. You can only account for confounders that you know about a priori.

And given they used Food Frequency Questionnaires, it's mostly wasted efforts imho.

</comment></comment></comment><comment><USER17> I would love to see the BMI as another dimension in the study. Given that a portion of meat would have _10-20x_ more calories than an equal amount of vegetables, you need to try hard to get overweight on a mostly vegetarian diet.

Of course, stating that _red meat causes CVD_ is much more sensationalist than merely confirming that extra weight does it, since it implies that ~90% of the population [0] are making an unhealthy choice.

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

<comment><USER18> However if the vegetarian diet consists of mostly starches and grains it is pretty easy to put on weight.

<comment><USER17> That's exactly I would love to see BMI as another dimension in the study, as it would fully eliminate this speculation.

</comment></comment></comment><comment><USER19> The thing about processed food is that it came about in the 50s, at a time when many Americans still remembered the dust bowl. Processed food could be shipped long distances and stored for long times without spoiling and was available at any time of year. It was, among other things, a hedge against starvation.

It's not high quality food, and you should, by all means, prefer fresh food when it is available and you can afford it. But the jihad against processed food may have unpleasant consequences the next time famine conditions arise.

<comment><USER20> Define "processed food" - I understand it often includes decidedly un-modern steps, such as salting and curing; even doing your own pickling.

<comment><USER21> [https://www.nhs.uk/live-well/eat-well/what-are-processed- foo...](https://www.nhs.uk/live-well/eat-well/what-are-processed-foods/)

According to the NHS who also did this study, this is the definition of 'processed food'...

I think it's dangerous to use the term processed when it's clearly just the fat, sugars, or other added chemicals and usually not the process that is unhealthy. 'Freezing and baking' is not unhealthy and yet they are what the NHS considers 'processed'.

</comment></comment></comment><comment><USER22> I'm looking forward to the keto rebuttal.

<comment><USER23> What rebuttal?

> red meat: 0.17% over 10 years, 0.41% over 20 years and 0.62% over 30 years

0.62% increase over 30 years is next to nothing, especially when you consider that many people have shit diet habits anyway.

<comment><USER24> Those numbers are assuming 2 servings per week. How many meat eater limits themselves to that few of servings?

<comment><USER12> The numbers in the study are something like 2 servings meat, 3 chicken, 1.6 fish weekly.

<comment><USER24> Haven't looked at the original study, but from the article

>>>In terms of the actual difference eating 2 servings a week would make to an individual's baseline risk of CVD, the researchers calculated:

processed meat: you would increase your risk by 0.4% over 10 years, 1.02% over 20 years and 1.74% over 30 years

red meat: 0.17% over 10 years, 0.41% over 20 years and 0.62% over 30 years

poultry: 0.20% over 10 years, 0.54% over 20 years and 1.03% over 30 years

</comment></comment></comment></comment></comment><comment><USER25> Note that this wasn't actually a study, they just looked at 6 other studies and based a consensus on that.

<comment><USER3> That is what we call a meta analysis. It is probably the best thing to look at if you are going to derive conclusions from science.

</comment></comment><comment><USER26> Definitive conclusions shouldn't be derived from observational studies only. Also, the methodology used is very questionable.

We should be more critical about matters concerning our diet, as studies like the former will be used by the media and professionals to back potentially life-changing advices.</comment>


Drive: The surprising truth of what motivates us [video] - <AUTHOR> http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_embedded

<comment><USER2> In case you want to see comments from earlier submissions of this, here are a few links.

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

<http://news.ycombinator.com/item?id=1357390> <<<\-- This one has the comments.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<comment><AUTHOR> Oh my! I'll be more careful next time.

Thank you for taking the time to point this out.</comment></comment>


Using Gambit-C Scheme to Create Small, Efficient Native Applications (2009) - <AUTHOR> http://www.devx.com/opensource/Article/42778/0/page/1

<comment><USER2> Single page link for those who would prefer to read the article whole, instead of broken into five parts:

<http://www.devx.com/print/opensource/Article/42778></comment>


Expired SSL certificate - <AUTHOR> https://manjaro.github.io/expired_SSL_certificate/

<comment><USER2> WTF, changing your PC date is not a solution! This will cause more issues.

<comment><USER3> A much better workaround would have been to install SuperFish as that completely disables all certificate checking on SSL.

</comment></comment><comment><USER4> What is shocking is that they still haven't found the way to properly fix it after 3 days.

I updated some SSL certificates last week (which even required contortions such as moving to a new issuer since some legacy software requires old-style SHA-1 signed ones which our current one doesn't provide), and it didn't take more than one (long) day of work.

<comment><USER5> It's just embarrassing.

I can only assume the sysop is on holiday.

<comment><USER6> Checking their about page, they have 3 web developers, one of which wrote that post. That's worrying.

<comment><USER7> The available web developers may not have access to either the SSL vendor or where the certificate is stored. None of the front-end devs I work with have access to either of those things.

<comment><USER8> The first problem is solved by getting a new vendor. The second, well someone has to have access to that.

</comment></comment></comment></comment></comment><comment><USER9> I wonder if browsers should for (say) a week after a cert has expired, show an error so alarms are raised, but allow the dialog to be dismissed with an OK instead of all the "Confirm Security Exception" that would go on for a more serious cert rejection.

<comment><USER10> I don't agree. If this happens, same rule should apply for domain name expiration.

<comment><USER11> You just made me wonder what happens if you have a cert but let the name expire. Can you MITM your old domain until the cert expires?

<comment><USER12> Sure, if you can get the client to connect through your machine.

<comment><USER11> If that's the case, shouldn't all certs only be valid until the domain expires, and all domain name sales should require revocation of all certs?

<comment><USER12> Sure, but how do you enforce the latter?

<comment><USER11> The latter can't be enforced, but individual buyers can demand that for all known certs.

And I think you can currently get certs expiring later than the domain, which seems wrong to me. Is there a good justification for that?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Our website monitoring service [https://t1mr.com](https://t1mr.com) will warn you before your certificate expires (in addition to warning you when your site is down, and giving you reports of inbound and outbound dead links).

<comment><USER14> As does nagios' http check with the -c option. Basic monitoring helps solve so many problems.

</comment></comment><comment><USER15> Should we set it to 1st of April?

</comment><comment> agarcia-deniz I can't help but notice the motto:

Enjoy the simplicity

</comment><comment><USER16> Rant mode:

If I understand right, getting a replacement cert doesn't result in a change of the private key anyways.

It's just magically, on the expiration date, your cert is somehow insecure and we must treat it as if YOU ARE IN DANGER!! - even though it's still better than then plain HTTP that everyone uses every single goddamned day. Hell, a self signed cert is better than plain HTTP, yet for some backwards-ass reason we treat it as worse, despite the fact it makes you immune from passive eavesdropping and any injection attacks, which the average person is a lot more likely to run into than a self-signed cert being used by an attacker to MITM you.

CA's are a scam and a racket. I can't wait for Mozilla's Let's Encrypt[1] to come along and put them all out of business, hopefully before the last decade or so of training users to ignore the wolf-crying cert warnings comes to fruition.

Yeah, this is irresponsible on Manjaro's part, they know the rules of the game, but the game is broken!

[1] [http://letsencrypt.org](http://letsencrypt.org)

<comment><USER9> A "passive eavesdropper" has all the information they need to become an active man-in-the-middle. Observe the DNS query on its way out and send your own response with your IP before the real response comes back. The client will then make its TCP connection to that injected IP.

<comment><USER17> _send your own response with your IP before the real response comes back_

Being able to inject traffic is not "passive".

<comment><USER9> The DNS response doesn't have to come from the same channel as the original request. If you've got an ISP that doesn't check the source IP of what you're sending, your target's endpoint will see your fake response and treat it as the real one.

Where we stand now, the only thing stopping an eavesdropper from becoming a man-in-the-middle is the will and resources of that eavesdropper.

<comment><USER16> Yup - but there's still a difference. Someone might just want to snoop on your traffic rather than mess with it.

</comment></comment></comment></comment></comment><comment><USER18> 30 minutes, comodo reseller, seriously; You won't get SHA256, but you won't be asking your users to hurt themselves.

</comment><comment><USER19> Don't pretty much all browsers let you accept using an expired certificate?

<comment><USER5> The issue is with HSTS. If you've visited the site before you've likely cached that SSL is required and your browser will refuse to connect. Using e.g. a 'private window' will allow it to be bypassed.

<comment><USER20> > Using e.g. a 'private window' will allow it to be bypassed

In Firefox, yes. But not in Chrome (in my experience).

</comment></comment></comment><comment><USER21> Why is this on the frontpage?

<comment><USER19> Because it's kind of completely ridiculous; both the problem and the proposed solution.

<comment><USER22> ...and the fact that it kind of suggests that you might not want to trust a Linux distro to get security right on your boxes if they are unable to fix their SSL certs after 3 days.

<comment><USER23> Manjaro had a rather… iffy relationship with developing a security mindset in the past: [http://allanmcrae.com/2013/10/comparison-of-security- issue-h...](http://allanmcrae.com/2013/10/comparison-of-security-issue- handling/)

It appears they're not learning.

<comment><USER5> The two are not really related.

With regards package updates, when Arch started publishing security update announcements Manjaro could start pushing those out faster. Delayed updates of other upstream packages is not really an issue (e.g. Ubuntu and CentOS have many packages that are not in sync with upstream).

</comment></comment></comment></comment></comment><comment><USER24> This is really awesome. Why do certificates expire in the first place?

<comment><USER9> By having an expiry, revoked certs can be forgotten about once the expiry has passed. We'd need to keep a forever growing list of revocations otherwise.

<comment><USER25> Also certs get switched to ones with stronger algorithms and longer keylengths after expiry. You also would have to revoke old certs all the time when their crypto isn't safe anymore.

</comment></comment></comment><comment><USER26> Awesome</comment>


Educational Mithridatism - <AUTHOR> http://zedshaw.com/2015/09/14/educational-mithridatism/ <comment><USER3> TL;DR Apply the method of progressive overload to mental exercises - <USER2> which you don't find immediately rewarding.

</comment><comment><USER4> I read this as Mithrandirism and was expecting a balrog or something.</comment>