MVPs and $100k AWS Bills: Reflections on our launch - <AUTHOR> https://octopus.com/blog/octopus-cloud-1.0-reflections <comment><USER2> > Octopus Cloud customers could start a free 30-day trial, which meant that > those hundreds of trial signups per month, each of which cost us $100 to > host, quickly added up.

> We also didn't have our pricing quite right. We initially launched Octopus > Cloud at $10/month, with a different pricing model from the one we currently > use. Unfortunately, this was one of the most painful lessons we learned > because the deficit between what we were charging and spending was magnified > by the sheer number of people using Octopus Cloud; continued growth would > further amplify the problem.

"Every person who fills in a web form gets to burn a $100 bill of ours" is the real disaster here.

I know it's trendy to think that software isn't like regular business, and you can lose money but make it up on volume, but going to a cloud vendor gives you a real cost of goods sold, and that needs to be accounted for.

(also, the irony of a company whose product appears to be about cloud deployment having a disaster by deploying to the cloud should not be lost on us)

<comment><USER3> Even without the free trial, how on earth can you burn $100 in cloud resources in a month if you plan to resell it for $10?

<comment><USER4> I think the basic idea is 'you need money to make money.' The hope is that with scale and engineering they can burn less. It is dubious that anyone can reduce from 100 to 10 -- 90% reduction would be an incredible feat, and this is why:

AWS has something like profit 25% margin. Therefore assuming that AWS is within 15% of doing a half-decent job at controlling costs, that's still max 40% profit margin if you were running bare-metal and beating AWS at their own game to the tune of 15%. So if you're selling stuff for 10/month, your AWS bill should be 17/month just to break even after all the awesome engineering you've done with the VC money -- at least that's how I see it.

Now, if they are doing incredibly stupid stuff, to the tune of 90% wasted ec2 cpu cycles/db requests, then maybe they've priced it right -- who knows.

Would love to hear some insights on where I might be wrong/misjudging here.

<comment><USER5> You're not including the scale factor in your reasoning.

AWS has (taking your number as correct) 25% margin _at immense scale_. Hardware is cheap at this scale. unit pricing for power and space is cheap at this scale. But labor cost is enormous at this scale. Even factoring in leverage of automation, at this scale there is just enormous bureaucracy. One guy or just one team just can't "do something". Anything worth doing will have enormous repercussions across many areas and needs to go up and down the chain. Stuff still gets done, because impact is large at this scale.

> 90% wasted ec2 cpu cycles/db requests,

So then, my point is, if you are just using EC2 and egress, AWS is very expensive. You don't need all the big scale engineering they have, to launch an MVP. Of course, you need to be able to hire the type of people that can manage in-house compute, and that may be hard to find these days, at any price. But taking labor shortage out of the calculation, it's vastly better to DIY.

If you are using PaaS features, that's the sweet spot where you get tremendous value out of AWS.

> profit 25% margin. Therefore assuming that AWS is within 15% of doing a > half-decent job at controlling costs, that's still max 40% profit margin.

Getting back to this, even if you dispute all of what I've said, your basic math is wrong. 15% short on 25% is 29.4%. (25/.85, not 25+15).

</comment></comment></comment></comment><comment><USER6> "To bring Octopus Cloud to market quickly, we did the simplest thing possible; we took our self-hosted Octopus Server product and bundled it into an EC2 instance for each customer that signed up. We had to make changes to the product, but mostly around permissions."

I have used octopus and I could have told them that they can't lift-and-shift. The amount of requests the app makes is ridiculous, the way they wrote their database is appalling (actually crazily dumb [https://octopus.com/blog/sql-as- document-store](https://octopus.com/blog/sql-as-document-store)). Everything about it would mean they can't scale in the cloud without wasting a ton of money.

"Cloud stuff can be really expensive" \- yes if you write dog shit, putting that in the cloud will be expensive.

<comment><USER6> From the "sql-as-document-store" post, I re-read it every now and then to realise how actually terrible it is:

"For a many-to-many, we do something a bit naughty: we store the values with | characters between each value:"

Not naughty, stupid.

<comment><USER7> Why would you bother with a relational database at that point? That sounds like it's not normalized.

I haven't read the post... maybe I'm missing something.

<comment><USER6> because they didn't know what they were doing - I can say this as this is what the blog shows, they don't understand databases and customers (including me) have suffered this

<comment><USER8> I've learned much too late in my career that competent software engineering is completely orthogonal to creating a successful(from a market perspective) software product.

<comment><USER7> Well yeah most of it's just CRUD and that's pretty straightforward even at a large scale (ex stack overflow.)

</comment></comment></comment></comment></comment></comment><comment><USER9> I have a streaming multimedia app that I want to launch. It ingests from the client, does some transformations, then sends it back to them (or to other parties) in realtime. It's pretty novel though - Snapchat adjacent.

I can't do it clientside. Nature of the problem.

I'm writing it in Rust, so it's relatively fast. But throwing thousands of people at it will still require extreme scale. I'm going to use K8S horizontal autoscaling. This will be _obscenely expensive_.

I'm not sure I can afford this. But I think a month of successful demonstration will get me funded (or bought out). So _in theory_ my costs could wind up getting paid. Maybe.

Do I risk launching this and potentially having $100k multiples of AWS bills? I can't afford that. I don't want to deplete my life savings or potentially go bankrupt.

Could I put it on a corporate card as an LLC and do my best to make it work? Then fold without harm or fowl if it doesn't? Is that unethical? Could I get sued?

All that said, I'm almost certain that a successful demo at scale with the Internet thrown at it will get me money. It's a really cool and novel product. People will be talking about it.

What should I do? Advice will be very appreciated.

<comment><USER6> onboard customers slowly and charge them - as you scale, make sure your charging as well and get paid.

you don't need to go from 0 - 100k a month in a single month, octopus could because they have backing.

<comment><USER9> This is a social media app, so I can't charge money for it. My hope would be for funding or a buyout. Otherwise it will be shut down.

<comment><USER6> Just stop what you are doing, you need to have a way to generate revenue if you want to sell it.

</comment></comment></comment></comment><comment><USER10> The architectural decision to deploy each customer on their own segmented components to make sure that "no one user's data to mingle with another" seems to me like a solution in search of a problem.

First, the deployment was on AWS (EC2 and RDS among other services) which was probably already co-mingled with other AWS customers.

Second, when you are selling a SAAS offering, the assumption is _already there_ that you'll build security and multi-tenancy into the app and the underlying infrastructure shouldn't matter.

And 100K/month for a MVP SAAS offering. I'm speechless. I just, I can't even understand how this burn rate passed muster with the leadership.

But Kudos to the team for owning up to it and sharing. Lots of lessons learned here.

<comment><USER11> It could make alot of sense for alot of government, healthcare and financial use cases.

<comment><USER10> I agree. In those cases, sell those customer separate products and expectations and price it accordingly.

</comment></comment></comment><comment><USER12> The lesson to be learned here, and the one they admittedly already knew in advance, is if you do a lift and shift to AWS without changing your processes to be cloud native, you will always spend more.

Unfortunately, I've met way too many old school netops guys who got one AWS certification and all they knew was how to log into the web console and duplicate their colo infrastructure, charge their client a lot of money, and call it a day.

That being said, I've used a lot of CI/CD tools and OctopusDeploy is by far my favorite.

Even though my company is very much a "pay someone to do the undifferentiated heavy lifting" type of company, OctopusDeploy is so easy to use and maintain, I am not sure we would migrate.

<comment><USER6> Going to the cloud won't save you money.

Going to the cloud lets you scale beyond your own data centre

Going to the cloud can be cheaper if you use the elasticity and make good use of PaaS services (servless,paas, etc)

<comment><USER12> I agree, but it also lets you automate and probably lets you get rid of or not hire as many infrastructure people between automation and outsourcing the simple stuff to a managed service provider.

</comment></comment></comment><comment><USER13> I'm sorry but this was a bit of a painful read. Hindsight is 20/20 but this was pretty poor engineering and business modelling from the start.

"To ensure there was no way for one user's data to mingle with another, each cloud instance had its own dedicated VM, database, and a large number of security configurations to prevent any funny business.". AWS has a myriad of security and isolation tools to do that in significantly better and cost efficient ways.

"Octopus Cloud customers could start a free 30-day trial, which meant that those hundreds of trial signups per month, each of which cost us $100 to host, quickly added up." So you're essentially allowing anyone to press a "Submit" button to spend $100 for you. This sort of below-cost methods to gain marketshare works for Amazon, Google, Microsoft and son because they have the deep pockets but it's a questionable strategy for smaller companies.

</comment><comment><USER14> This is insane. It's the engineering equivalent of smashing one of your hands with a hammer and then being surprised it hurts. Well no shit.

At that level, at the very least, it would make sense to run some amount of physical infrastructure.

</comment><comment><USER15> Pardon me for asking a really dumb question: but do you have a positive item charge - CGS? Because I'm sure one can get a great demand by selling a $1.00 for $0.90 but that's not a business model.

<comment><AUTHOR> The post didn't make this very clear. $10 was the starting price - at the time it was for 5 users. Similar to Confluence or Jira with a very cheap (in this case loss-making) starting tier. Once a customer got to ~10 users it became profitable.

What we didn't know if whether there'd be enough customers for us to care about the loss on those $10 tiers. E.g., if only 100 customers signed up a month, the costs would have been around $10K/month - enough to write off as a marketing expense. Once it got to $100K it became something we needed to fix.

<comment><USER15> > The post didn't make this very clear. $10 was the starting price - at the > time it was for 5 users. Similar to Confluence or Jira with a very cheap (in > this case loss-making) starting tier. Once a customer got to ~10 users it > became profitable.

Err.. That's not a correct way of looking at a long tail. CGS on a long tail must still be lower than the unit charge, otherwise you are paying $1.00 for $0.90 which gives you an incorrect signal about the demand.

Say you make apple juice. And each juice uses 4 apples and only apples. 4 apples cost you $3. Setting a price of juice to $1.00 does not actually tell you if there's a demand for the juice because it is below the CGS, which you cannot make up in volume.

The long tail test is to set the juice price at (CGS + x) where x is some number and see if you get the demand even if x is less than the other costs attributed to juice ( rent/electric/juicer/salaries). If you do, then you can make up your loses in volume because the higher the volume you are going to have the smaller process cost attributed to every unit will be so there's going to be a number at which CGS + y < CGS + x where y is the process cost attributed to a unit.

</comment></comment></comment><comment><USER16> Can't wait for this Cloud meme to die out and we can go back to On Prem but instead of VMs managed by VMWare, Cloudstack, Vagrant, LXC etc, we will have nodes managed by Kubernetes.

<comment><USER17> Why would cloud go away? If you're a team of 3-4 people and have a startup idea what's easier? Create an AWS account and smartly spin up required servers?

Or find a location (rent$), get fiber($$) to that location($$), find hardware($$), install said hardware. Now you're back to where you were with AWS.

For larger already established businesses on prem is probably a setup you should explore but on day 0 of a new business, cloud will probably have a large cost and flexibility advantage as long as you smartly set it up.

<comment><USER18> I can purchase and then colocate 2x Dell R640s (8c/16t, 64gb of ram, as much NVMe storage as I can stomach) with tier 1 bandwidth billed at the 95th percentile and 24/7 remote hands support for about $150/month. The purchase price on the Dells is about $3500/ea.

Total first year cost on this setup: $8,800

Total three year cost on this setup: $12,400

2x m5d.4xlarge EC2 instances (this isn't counting ingress/egress rates, or really anything else) First year cost: $15,621 .

Total three year cost for the EC2 instance: $46,863.36

For the cost of using EC2 you could hire an extra person to help grow your company.

Yes, you can get discounts in AWS for agreeing to a three year term. Yes AWS offers you flexibility to walk away at any time.

If you have a base line load (which most companies do) you should really look at colocating your owned equipment. You also get the bonus of being out of the watchful eye of Amazon's profitability team looking to see if they can copy what you're doing.

<comment><USER19> > For the cost of using EC2 you could hire an extra person to help grow your > company.

You _will_ be hiring an extra person to manage these machines. That's the beauty of The Cloud (tm). Need more compute? You got it. Provisioned too much? Get rid of it. If you're a startup, you don't have time nor money to be managing your own infra.

Not to mention the ability to deploy to _any_ region within minutes. Now you're talking $8,800 / region + someone to maintain other regions.

> ingress/egress rates

unless you're also using S3 or CloudFront, this doesn't really mean anything. Put a free CDN in-front of S3 or your instances if you're worried about load or cost of IO.

> You also get the bonus of being out of the watchful eye of Amazon's > profitability team looking to see if they can copy what you're doing

Ok now you're reaching.

<comment><USER18> How much management does a bare metal box need? Nothing more than what an ec2 instance would need.

There are colocation providers all over the world. Psychz.net is a great example. My assumption is a single box per region. There is no redundancy in your ec2 systems.

You should google the Amazon profitability team if you don't believe me.

<comment><USER20> I can't find anything related to AWS and "profitability team" on Google. Can you share some info/links?

<comment><USER18> [https://news.ycombinator.com/item?id=19734261](https://news.ycombinator.com/item?id=19734261)

Tangentially related: [https://www.datacenterdynamics.com/news/ovh-ceo-unlike- amazo...](https://www.datacenterdynamics.com/news/ovh-ceo-unlike-amazon- google-we-will-never-be-in-competition-with-you/)

[https://sellercentral.amazon.com/forums/t/amazon- literally-s...](https://sellercentral.amazon.com/forums/t/amazon-literally- stole-my-product-idea-and-took-over-my-listing/323388)

[https://fortune.com/2016/04/20/amazon-copies- merchants/](https://fortune.com/2016/04/20/amazon-copies-merchants/)

[https://www.theverge.com/tldr/2019/9/19/20874818/amazon- allb...](https://www.theverge.com/tldr/2019/9/19/20874818/amazon-allbirds- shoe-clone-copy-sneaker-206-collective-private-label)

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> > We quickly learned that everything in AWS has some kind of service limit

Except S3. Unlimited objects, and unlimited Put and Get requests.

<comment><USER22> Your comment is not true in all cases. S3 is limited to 5,000 get/put requests per prefix. So while it's possible to achieve what you've said, it's also possible to stumble upon this limit in a fashion similar to the original comment.

<comment><USER20> It looks like the number is slightly higher now - [https://aws.amazon.com/about-aws/whats- new/2018/07/amazon-s3...](https://aws.amazon.com/about-aws/whats- new/2018/07/amazon-s3-announces-increased-request-rate-performance/)

Do you know what exactly a 'prefix' means in this context? The first N characters? What is N?

</comment></comment></comment><comment><USER23> _To ensure there was no way for one user's data to mingle with another, each cloud instance had its own dedicated VM, database_

No this will not protect you. Understanding the proper way to configure IAM roles with principle of least privilege will.

The author mentions that _The issue here is Octopus is like a CI server - customers can run arbitrary code in the instance (not a problem most SaaS apps have). So a VM per customer was almost the bare minimum._

If you're using the same IAM role for your EC2 instances, and you're allowing your customers to run arbitrary code, well now at the very least they have access to everyone's databases.

</comment><comment><USER24> Rent dedicated server from OVH, install ESXi, hire a sysadmin. You will save huge amount of money. Cloud can be great, but sometime it looks like people forget there are other solutions.

<comment><USER25> Dedicated servers are often so much cheaper these days, but it is not the new cloud, so a lot of startups look the other way.

</comment></comment><comment><USER26> Well glad they had the capacity to recover.

Even accounting for hindsight being 20/20...every customer gets their own VM is a rather ambitious approach to scaling.

Would love to know what made them shift to Azure. Especially while embracing linux at same time.

<comment><AUTHOR> Compute is one part of it but not much different across clouds. Databases are the other big part (each customer needs their own DB). The SQL Server databases in Azure for our usage scenario turns out a lot cheaper. We'll explain more in a future post.

</comment></comment><comment><USER27> Octopus is a fantastic deployment product for .NET (happy user here).

<comment><USER6> what's it like working for paul? :)

<comment><USER27> I'm a long term (5+ years) customer of Octopus, I know Paul is the CEO, I don't work for him, I'm a startup founder with my own company.

</comment></comment></comment><comment><USER28> Ha, I'm re-reading The Lean Startup and this paragraph seems like a contradiction in terms of what an MVP is:

 _We decided to build an MVP based on our best estimates and test the market that way. The goal was to launch something in 6 months and test if the demand was there; and if it wasn't, we'd only wasted 6 months. We chose to optimize for getting to market quickly rather than worrying about how much it would cost._

Contrast it to what the Lean Startup principles say:

 _The Lean Startup methodology has as a premise that every startup is a grand experiment that attempts to answer a question. The question is not "Can this product be built?" Instead, the questions are "Should this product be built?" and "Can we build a sustainable business around this set of products and services?"_

So instead of doing what a lean startup would do, they did the _opposite_. Let's see what they could have done instead...

"How many customers will actually use it?"

\- Lean startup: create a signup page with a mock up or landing page and a few buttons that work and every potential behind a "coming soon" screen \- Their approach: actually build the whole product and then launch it and see who's interested

"What is it all going to cost?" \- Lean startup: As little as possible to discover the insights we need to iterate and evolve the product \- Their approach: well we already paid the salary for our engineers and we've given them six months, so what's half the salary+benefits of X number of engineers?

"What should we charge for it? Is it going to cover the infrastructure costs?" \- Lean startup: experiment on costing and pricing as you go along \- Their approach: give away the product for a 30-day trial at a high cost to ourselves! Unbelievably expensive customer acquisition costs.

Reference: [http://theleanstartup.com/principles](http://theleanstartup.com/principles)

And now I guess I've truly learned why product managers exist. Someone let this crazy experiment run for _six months_. You're saying in six months you couldn't spend one month finding the simplest/cheapest ways to test these various hypothesis?

$100k customer acquisition spend is insane.

The whole post is just a lesson in contradicting what an MVP _minimal viable_ product is.

 _Even when we were building v1, the team knew it wasn't the ideal architecture. Before v1 even launched, there were plenty of conversations in our Slack about whether we should port Octopus to Linux and run it on Kubernetes, or see if we could run it on Windows within Kubernetes or use Nomad by Hashicorp?_

Lol, engineers always want something fun to work on and sometimes it turns out to be a great idea. But they porting software for an MVP? Why not evolve the new product so that it generates more revenue or reduce the costs in some other way instead of talking about porting and rewriting?

If you're at an established company that has money to burn, go ahead, read the whole blog series. If you're trying to create a new startup, whether it's a product or service, avoid this article or read it as a warning. When you've spent as much as a decent engineer costs in _one month_...something's gone off the rails.</comment>


Business Lessons From a Former Gang Member - <AUTHOR> http://www.businessweek.com/articles/2012-11-30/business-lessons-from-a-former-gang-member <comment><USER2> Interesting guy, and that BW article is an okay read but doesn't do that great of a job telling his story.

But then I looked him up and came across this HuffPo article on him and absolutely loved reading it, it's a must-read for founders: [http://www.huffingtonpost.com/2012/04/02/ryan-blair- visalus-...](http://www.huffingtonpost.com/2012/04/02/ryan-blair-visalus-my- first-million_n_1383430.html)

I love collecting stories like this. They're real-world case studies of PG's "Anatomy of Determination" - <http://paulgraham.com/determination.html>

</comment><comment><USER3> A cool two-paragraph back story, but otherwise generally worthless. Also, it appears the protagonist of this story is the founder of a successful MLM company - good for him but he'll never knowingly get a dime from me.

</comment><comment><USER4> Not related to the article, but if people are interested in the "economics" and "sociological" aspect of gangs and other illegal activites, the book "Gang Leader for a day" is a very compelling read. Check your library. (EDIT: I ended up liking it enough to buy a copy.)

<http://www.sudhirvenkatesh.org/books/gang-leader-for-a-day>

</comment><comment> daniel-cussen "Get My Name Right"

This is so important. If you just stop and focus on 1) pronouncing a person's name correctly and 2) remembering it, people are going to give you a much easier time.</comment>


The Madrid Statement on Perfluoroalkyl Substances (PFASs, Found in Cookware) - <AUTHOR> http://ehp.niehs.nih.gov/1509934/ <comment><USER2> i don'tt use teflon, never trusted it.</comment>


Run as the Root Account - <AUTHOR> http://www.garyshood.com/root/

<comment><USER2> first thing I do when I after I login to linux:

su

Why don't I just login as root from the get go? I am not an animal, I disabled root login via SSH and only allow connections via an SSH key to a non-root account.</comment>


The Ultimate Daily Deal Site - Why doesn't this exist? - <AUTHOR> http://www.rickmaher.info/2013/the-ultimate-deal-site-and-bync-will-fail/

<comment><USER2> im afraid its not this easy. continuing your stock exchange analogy, trading volume at the individual stock level will be too sparse and unevenly distributed to make an unassisted exchange workable except at massive unprecedented scale (which i admit we'll achieve eventually). that's why in daily deals "stock brokers" exist, they are groupon/LS/etc. and they're still bleeding cash trying to reach these merchants profitably despite their "high" gross margins.

also i dont think you've adequately fleshed out the chicken and egg problem; ie i dont think folks will sit there and load up their deal preferences without you having demonstrated some kind of value first. demonstrating that value will be difficult without reverting to industry standard stuff. back to square one.

most importantly, in daily deals merchants pay for marketing+distribution = new customers. what you're describing will mean the customers voting on a merchant will already be aware of that merchant, and this makes your pitch to them a different (and much more difficult) conversation. from the merchant's perspective, discounts lower their product's value in their customers' minds. imho the right way to deal with loyalty is through having a loyalty program (assisted by the many great startups in this business), not generalized discounting.

hope this helped.

</comment><comment><AUTHOR> I've outlined in some detail a concept I've thought up for a daily deal site truly unique and better than Groupon, Living Social, and all the copycats including the most recent - Bync.

I'd love any feedback.</comment>


Spain regulates the price of Internet to implement "The Right to Broadband" - <AUTHOR> http://www.pcmag.com/article2/0,2817,2356014,00.asp

<comment><USER2> We need to develop a word other than 'right' that means "not a fundamental human right, but something we collectively agree people should be able to get, if it can be made available at a reasonable cost, a reasonable price, and without forced labor". We could use it in the health care debate, too. Maybe the Spanish need it as well, although I can't tell if the PC Mag article is translating such a word into 'right'.

<comment><USER3> It seems to me that the qualifiers "negative right" and "postive right" do a decent job at this. Of course, there are some 18th century thinkers who don't believe that positive rights are legitimate, but that hasn't stopped the rest of the industrialized world from recognizing the intrinsic value of universal education, health care, public infrastructure and so on.

Whether broadband qualifies, and whether Spain's chosen method of implementing it makes sense, are of course open to discussion.

<comment><USER2> I would agree with you, but have personally found it unexpectedly difficult to get people to understand the difference between "negative" rights and "positive" rights. Maybe those words have too many other connotations?

</comment></comment></comment><comment><USER4> I'm spanish and the price for 1mb of ADSL is similar to the price of 20mb in france or any other european country. This is a very expensive right...</comment>


As rents rise, struggling tenants face uncertain future   - <AUTHOR> http://mv-voice.com/news/show_story.php?id=7235

<comment><USER2> It just doesn't make sense to be earning minimum wage and spending $1400/month to live in a 1-bed apartment. There are cheaper places to live elsewhere that are safe to live where you can earn similar wages.

<comment><USER3> True, sure they could move to Idaho or Montana, but many people have roots and strong family ties, which bind them to a small geographic area, so to them leaving simply isn't an option to them anymore than going and living on the moon would be (and I mean that almost literally). I have an uncle that's never left the state and considers a "city" an hour away an exotic location.

For example 46% of midwesterners live in the same community their entire life ([http://pewsocialtrends.org/files/2010/10/Movers-and- Stayers....](http://pewsocialtrends.org/files/2010/10/Movers-and- Stayers.pdf)), even though many of them could probably move elsewhere when the finish school (HS, Tech, College, Uni, etc.) and get much better jobs than they could locally.

</comment></comment><comment><USER4> Don't live in Mountain View. Moving sucks, but there's no other options. Living in MV isn't a right.

<comment><USER3> What a harsh point of view. When does that cycle end?

Now they can't live in MV, next they won't be able to get on the list in East Palo Alto because it's too long already, soon they'll be living in South San Jose or Morgan Hill, but their job is still in MV, so now they're spending three hours a day commuting each way and can't spend time with their family/children at all.

And every time they move they're forced into lower and lower quality neighborhoods, exposing their children to more violence and illegal activity because at that level of living the risk/reward level for legitimate work starts tipping to make crime more attractive even if they dislike the idea.

There's a lot of major social issues that become very difficult/intractable when entire regions undergo gentrification.

<comment><USER5> >Now they can't live in MV, next they won't be able to get on the list in East Palo Alto because it's too long already, soon they'll be living in South San Jose or Morgan Hill, but their job is still in MV, so now they're spending three hours a day commuting each way and can't spend time with their family/children at all.

If you're working a minimum wage job you can move literally anywhere and get another just like it. There's no reason to commute.</comment></comment></comment>


Ask HN: IP, employment contracts and side projects - <AUTHOR>

I'm employed at xxx big IT consulting company. I was hired out of college as an "associate project manager" last year, but have never been given any projects. I work less than 5 hours a week for a full-time salary. I would like to start a niche website on the side, which will produce revenue from google ads. This site will not be in any way related to my employer's buisiness, or any project I've been associated with through my day job.
What should I be considering given that I signed a  fairly restrictive contract when I started this job? How standard for the industry is the contract I signed? Does my employer really own all the IP I produce while on salary? Will I have to quit my job to start this website? Is this a cut and dry legal issue or does it also have to do w/ my company's history of litigation on past similar issues?
And is there a differentiation between my for-profit idea, and any other side projects I do which are free and open source?
Thats a lot of questions.... thanks in advance. <comment><USER2> By and large it doesn't matter what the contract says, if they don't like what you're doing they may just sue you anyway. What the contract says will affect the outcome of the court case, but that doesn't matter, in the large scheme of things once you're into the realm of your employer suing you you've lost already.

<comment><AUTHOR> Yeah, I realize that if litigation starts, it means, I lose, no matter what the outcome. I would need to make sure to avoid this at all costs... either by avioding the issue of the contract altogether or by hoping that they wouldn't find the site and put 2 + 2 together. (I think that no matter what this seems likely -it won't be a google killer or anything, if the company found out about it at all it would probably be random)

</comment></comment><comment><AUTHOR> It says.... any and all work created by me... while employed... will be owned by XXX company....

Is that the clause I should be looking at? It doesn't seem like there are any explicit exceptions to this written into the contract.

<comment><USER3> I'd recommend you talk to a lawyer that is familiar with employment contract law in your area. My experience has been that companies will put unenforcable restrictions in contracts because they know 99% of people will never check if the restriction can be enforced. It doesn't cost the company anything to add the clause but they benifit from it anyway.

<comment><AUTHOR> yeah, that was the main gist of my question: What makes such a clause enforceable or unenforceable? Is that speaking in terms of legality, or that it's simply impractical to do so?

I would really like to hear from some other HNers on this: Are you already well aware of the ramifications of the contract you signed before you begin work on side projects, (and maybe even demanded changes to a contract before you signed) or do you forge ahead w/ the knowledge that the "any and all" clause (or whatever) is unenforceable? - this assumes you are not violating any non-competes -it's just a question of IP.....

It seems unlikely to me that every engineer w/ side projects hires a lawyer to go through his/her employment contract before they sign it.... What's best practice when dealing w/ a contract both before you sign it?

</comment></comment></comment><comment><USER4> Just make it anonymous or use a fake person. May be you can register everything(domain name,trademark) on your wife or you cat. Also you can join an open source project.It's your life, by the way. It cann't belong to your company

</comment><comment><USER5> A lot of it depends on the actual contract you signed. I would take a look at that to start off. Maybe post your findings back here if you feel open.</comment>


Useful SASS Mixins - <AUTHOR> http://sachagreif.com/useful-sass-mixins/

<comment><USER2> Making all the text on a page semi transparent is ridiculously bad advice.

> using transparent instead of opaque colors make your elements blend in > together better, and your design more coherent.

wow…… just wow</comment>


Understanding the corporate impact (of upgrading Firefox) - <AUTHOR> http://mike.kaply.com/2011/06/23/understanding-the-corporate-impact/ <comment><USER3> Merits of the argument aside, I was surprised to see the tone that Asa Dotzler took on that thread. To me, it sounded like "you enterprises are dumb and we don't care about you."

If I were "Community Coordinator for Firefox marketing projects," I think I would have tried to be more tactful.

I'm not trying to throw darts at him, but it may be instructional for those of us who are geeks to consider how our words can come across online.

<comment><USER4> I didn't say anything that could be remotely construed as calling enterprises dumb. I said that they have not, and in my opinion, should not, be Firefox's target.

<comment><USER5> Well, you believe what you believe, and nobody can fault you for your beliefs, in and of themselves. I happen to disagree with you, but that's not my issue with your comment... my issue is that - regardless of what you intended - <USER2> tone came off as very arrogant, dismissive and mean-spirited. And, like it or not, there is a PR aspect to consider anytime someone - who is as visible and well known as you are - says something that sparks controversy.

I think this whole thing has done some damage to the Firefox brand, and that makes me sad, as I've been a Firefox (and before that, Mozilla... going back as far as Mozilla M2, IIRC) supporter for a long time.

</comment></comment></comment><comment><USER6> Staying at FF3.6 wouldn't make them the most out-of-date by a longshot. A _majority_ of our site's corporate users are on IE6!

But it seems to me that part of this problem is that they're trying to accomplish two things with the browser, that for their needs might be better separated into two.

For internal corporate apps, there's probably little reason to upgrade. In particular, the security risk posed by accessing _internal_ systems on a backlevel browser is pretty minimal. They could retain FF3.6 for use in this context.

For general web browsing (research, etc.), you really want to be as up-to-date as possible, but there shouldn't be any repercussions to doing so. If you're accessing the internal apps on your old FF3.6, then you can have a separate "external browser" that's kept current.

So my suggestion is to stick where you are for the internal apps, and separately install Chrome or IE or something for external access. Set up configurations that restrict each browser to only be able to access its intended sphere.

<comment><USER7> I can't imagine trying to get everyone in a large corporation to use the right browser for the right thing. Most normal people barely understand that IE is not the internet, let alone understanding the difference between websites, web apps and internal and external servers.

In a very small company, maybe, but not in corpo-land.

<comment><USER8> Wait... what IS the difference between a webapp and a website?

<comment><USER9> Buzzwords, Ajax, HTML 5

</comment></comment></comment></comment><comment><USER10> So here's my take on the matter. This is a Damned if you do, damned if you don't problem.

a) Firefox must release frequently to keep up with competition. A firefox by any other version is just the same set of changes, just labeled 4.1 vs 5. I don't know why they changed their numbering system (to keep up with chrome i guess) but it makes absolutely zero difference.

b) Any corporation cares about stability vs progress. They want to test now, guarantee that it will work for say 10 years, and just stick with it.

And now of course

c) The web needs to progress. (ie6). IE6 is still being used. This has been beaten long and hard for years. The problem is not IE6, the problem is corporations. IE6 will die, it'll die soon (I hope) as I still have to support that heap of crap. HOWEVER tomorrow firefox 3.6 will be it. FF 3.6 will have some crap and work like shit 10 yrs from now and some corporation will want to use it and nothing else just like IE7 and IE8 and actually anything.

\--

Anyone who embraces chrome is embracing a mindset, it will always be up-to- date and our it must support the latest version, we'll force a restart of chrome at some point to update that version. Our sites MUST WORK WITH LATEST CHROME.

Here we have examples of companies complaining, and I guarantee if Mozilla would state that 3.6 will be forever supported (7 yrs?) like IE6 was they would get the same shit MS got for IE6, sure not today, but in a few yrs "omg fucking ff 3.6 can't do shit like rounded corners right, it needs to die" followed by the FF3.6 eulogy website etc. The only way to win this is for companies to realize that the following will be true on the web:

a) security vulnerabilities in browsers will be discovered/patched, and quickly. You must upgrade frequently to keep up.

b) The web is moving forward, even if you dislike that. Due to this rendering engines must be updated constantly. Sorry. Adopt best practices and release frequently. Its an unfortunate cold hard truth and its costly but its the nature of dealing with the web.

c) Mozilla can't support an old browser forever. Pay them and they will. However they are not Microsoft, and even MS can't do this effectively, so if you want something for "free" (IE included here) be prepared for paying for having to move in the direction they take. Otherwise contribute cash to them to support what you want. I'm sure Mozilla will happily create a special FF3.5 branch back-porting fixes for years as long as you pay them to.

<comment><USER11> Let me put my flame-suit on ...

To further distill your points, there is fundamentally two problems:

1\. Maintaining backwards compatibility while providing support for new features;

2\. Providing security updates without breaking compatibility.

I need my flame-suit because, if Mozilla can't solve those two problems, then they seem to be ignorant of some very basic strategies in software development.

In web-based application development lately, you see a lot of "MVC" talk. MVC is far from a new concept, but more people are starting to see the wisdom of keeping your business logic separate from your UI logic.

There's no reason why a web browser shouldn't be constructed the same way. Internally, it should be separated into distinct parts -- the network interface, the rendering engine, the user interface, etc. -- with those parts communicating only through a largely static API. Each of those parts should then endeavor to separate the security-related logic from the rest of the application logic.

In other words, there is absolutely no reason why it should be impossible to apply and maintain security fixes to multiple versions of the code base, simultaneously.

Once upon a time, programmers saw the wisdom of maintaining separate versions of their applications, and they helped their system administration brethren by signaling the impact of changes in the version numbering:

major.minor.revision

Sysadmins running a specific major.minor of an application could always feel comfortable blindly updating .revisions, which typically consisted of things like security updates. If a .revision ever broke anything at all, the developers were generally considered to have screwed up.

Sysadmins could more leisurely apply major.minor updates, after double- checking that the .minor change didn't break any of the stuff that their network relied on.

And, meanwhile, sysadmins could even more leisurely take their time in developing comprehensive testing periods and update roadmaps for major releases, so that nobody in the company would get caught with their pants down.

So, not only is Mozilla committing an egregious error in not being able to apply _just_ security updates without changing any other application functionality, but they're committing a whole other sin of long-standing software best practices by abandoning the most sensible version numbering system that was ever developed, and developed for damn good reason.

I think it's clear that Mozilla simply doesn't give a shit about their users at this point. They are either accidentally or intentionally ignorant of why these practices were developed and what problems they were intended to solved, not only in corporate markets but in home users as well. Mozilla is also digging the graves of system administrators everywhere who pushed for deployment of Mozilla applications in corporate environments and are now going to be faced with nothing less than a huge fucking maintenance nightmare -- and I promise you that nearly every corporate IT department has an administrative overlord who is much less interested in why a particular software product is _technically_ better than they are in what the _cost_ will be or how many people are going to complain.

I'm beyond furious, personally. Way, way beyond furious. I've been making similar comments in every single Mozilla-related thread since this was announced. My company was _still_ switching our clients -- clients who work with us because they _trust our judgement_ \-- to Firefox as of last week. This new release strategy has just fucked us in the ass. As of now, we've completely halted Firefox conversions, and I have to figure out what to do next.

As far as website compatibility goes, would it really be so hard to support a simple comment tag at the top of the page that listed the browser major versions that the site had been built for, and then -- because the application was designed well so as to be capable of such magic as this -- use the appropriate rendering engine, dynamically loaded?

<comment><USER12> There is no way to separate out security from the other software layers. In a web applications and user agents _everything_ is involved with security. I agree it would be great if they provided security fixes for obsolete releases but let's not pretend it would be cheap or easy. Someone would have to pay for that, the open source community is unlikely to deal with that level of configuration management drudgery for free.

<comment><USER13> > There is no way to separate out security from the other software layers.

Are you sure that's not the underlying cause of the problem?

Security is a lot like scalability and fault tolerance: you have to plan your software architecture to support it systematically. You can't just bolt it on later.

</comment></comment></comment></comment><comment><USER14> The corporate mindset is the problem. They've got to get away from the hubris of thinking their software testing process is so special or better than the community's.

Although it's a pretty cushy assignment. I'm sure plenty of bigcorp PMs would rather do that than to manage something with more complicated deliverables.

<comment><USER15> I agree. The assumption here is that the corporate IT mindset is the constant factor, and Mozilla, Chrome, or whatever, have to adapt to it.

I don't agree with that assumption. Corporate IT has to get better and faster, or they will get marginalized by cloud hosted solutions that can move faster and deliver superior experiences at better cost.

If your internal software is so crappy you can't upgrade your browser, maybe you should try and fix your internal software.

<comment><USER13> > Corporate IT has to get better and faster, or they will get marginalized by > cloud hosted solutions that can move faster and deliver superior experiences > at better cost.

That's easy to say when you're not responsible for a system where an hour of downtime comes with a seven-figure number in brackets on this quarter's review.

Corporate IT guys get a lot of grief about imposing picky rules and making life difficult, but the bottom line is that they are the guys who are going to take the flak if stuff breaks. Most of these policies are not there because someone at the head office wants to throw their weight around, they are there because a lot of people on the corporate network really could cause serious damage without even knowing how or why if left to do whatever they wanted.

If you want to blame someone for this cultural problem, blame the big software and infrastructure providers, who haven't yet collectively invented a robust global IT architecture where risk can reliably be localised to the user at fault. Or step up and do something about it and get very rich, because it's a real problem facing literally billions of staff every day.

Alternatively, you could take the view that cloud computing is the way forward, releasing a new browser every three months will make these sorts of problems go away, and everyone who develops in-house tools and operates a conservative IT policy is a moron with no idea how to run a successful business. Good luck with that. :-)

<comment><USER15> > That's easy to say when you're not responsible for a system where an hour of > downtime comes with a seven-figure number in brackets on this quarter's > review.

In particular if you have such a critical system, you should have a plan on how to upgrade, test, and deploy it.

Releasing a browser every three months (or constantly, such as Chrome) does make a lot of problems go away. And having reasonably-well written web apps does help as well - just because you're developing in-house tools doesn't mean they have to suck and only work on IE6.00.14.13 patch level 3 with the right fonts and ActiveX version installed.

Corporate IT can learn a lot from how application development works on the web, the web is the more robust IT architecture you're asking for.

<comment><USER13> > In particular if you have such a critical system, you should have a plan on > how to upgrade, test, and deploy it.

Indeed, but wouldn't such a plan start with building on a firm foundation that isn't going to get EOL'd and no longer support security updates after three months?

The reality is that building on FF or Chrome now means trusting potentially critical business functionality to an outside group you can't control with a history of pushing breaking changes.

(If anyone is about to pipe up with how they only release useful changes and the community testing is sufficient to prevent regressions, please keep in mind that both Firefox and Chrome have each outright broken both cosmetic rendering details and basic functionality recently, in minor/point releases that you wouldn't normally expect to change user-observable behaviour at all, plus of course there are many widely and less widely reported compatibility issues.)

> And having reasonably-well written web apps does help as well

Don't tell that to anyone who uses Java applets and has spent significant time over the past few months working around the repeated screw-ups made by major browsers as they implemented new internal details.

(If anyone is about to pipe up with how Java applets are yesterday's technology and browser vendors don't need to care about them any more, congratulations, you are a walking example of my point.)

> Corporate IT can learn a lot from how application development works on the > web,

Or web application developers could learn a lot from corporate IT, depending on your point of view. Personally, I can't remember the last time I saw a business critical corporate IT system completely fail or a major deployment of old-fashioned desktop software block a whole company, while I see the trendy style of rapid-development cause major errors with alarming frequency. That applies to everything from Reddit falling over every ten minutes to Google Docs' seeming inability to display even basic documents and spreadsheets properly on all major browsers at any given time.

<comment><USER16> > Indeed, but wouldn't such a plan start with building on a firm foundation > that isn't going to get EOL'd and no longer support security updates after > three months?

Why? Why does it matter if 4 is EOL when 5 is available? Instead of obsessing about having _security_ updates, why not just expect updates. If you're willing and able to test and deploy a new browser every 3 months, what does it matter if they call it 4.2 or 5.0? Test and deploy the new browser and stop worrying so much about the version number.

> If anyone is about to pipe up with how they only release useful changes and > the community testing is sufficient to prevent regressions, please keep in > mind that both Firefox and Chrome have each outright broken both cosmetic > rendering details and basic functionality recently, in minor/point releases > that you wouldn't normally expect to change user-observable behaviour at > all, plus of course there are many widely and less widely reported > compatibility issues.

So don't deploy on day 0. Breaking changes can be, and sometimes are, introduced in minor version increments. If you need to test, you need to do so whether you're going from 5 to 6 or 5.1 to 5.2.

<comment><USER13> > If you're willing and able to test and deploy a new browser every 3 months

I'm not, and I don't think a lot of other people are either. The version number is irrelevant. The frequency of releases is the problem here.

> So don't deploy on day 0. Breaking changes can be, and sometimes are, > introduced in minor version increments.

OK, fine, but now _everything_ is effectively a minor version increment in Firefox and Chrome, and anyone who doesn't update within 90 days is apparently going to lose all security updates. That is not a viable combination for any users who value a stable platform they can build on more than cutting edge toys.

<comment><USER16> > I'm not, and I don't think a lot of other people are either. The version > number is irrelevant. The frequency of releases is the problem here.

A lot of people very clearly _are_ willing to update every three months. A lot of users update Firefox regularly. And for people using Chrome, they get updates even more frequently. When the upgrading is painless, no one minds doing it.

As for corporations, if they aren't willing to roll out a new browser every three months, how often are they willing to do it? And how are they dealing with browser exploits in between these long cycles?

> OK, fine, but now everything is effectively a minor version increment in > Firefox and Chrome, and anyone who doesn't update within 90 days is > apparently going to lose all security updates.

So how is this different? If you are not willing to update, you're not getting security updates anyway.

> That is not a viable combination for any users who value a stable platform > they can build on more than cutting edge toys.

This is either hyperbolic or delusional. You tell me which. I'm using the latest version of Chrome. I also have Firefox 5 installed. They both work on every site I've visited lately. The only exceptions are some internal corp sites that only work with IE, and those clearly didn't work with FF 3.6 either (also I think those were all recently upgraded or retired so they're no longer an issue, but I'm not certain).

If you want to build stable apps, then use the stable pieces of HTML/CSS/JS/whatever. No one says you have to use the latest feature that Chrome/Firefox/IE/Safari added. You can choose to build on a stable platform without running a 2-year-old browser.

<comment><USER11> > _A lot of people very clearly are willing to update every three months._

...and a lot of people very clearly are _not_. So now what? We say, "this doesn't work for lots of people", you counter-point that it does work for a lot of people ... both statements are true and nothing has been accomplished.

> _And for people using Chrome, they get updates even more frequently._

And for people using Internet Explorer, they get updates much less frequently. Guess which browser still has the lion's share of the market? (Hint: <http://getclicky.com/marketshare/global/web-browsers/>)

> _When the upgrading is painless, no one minds doing it._

Right, and that's the rub! Upgrading is _not_ painless! I think you, and I, and Silhouette are in agreement here: if upgrading were painless, no one would mind doing it. The problems seems to be that for you, "painless" means, "I have to download and install it", and for us, "painless" means, "we have to answer support calls about what happened to the bookmarks menu and why X page is no longer working even though it was two weeks ago and by the way the back button looks different and I don't think I like this new version..."

> _If you are not willing to update, you're not getting security updates > anyway._

 _Nobody's objecting to security updates!_

This very statement is _so_ indicative of what the problem is here: that security updates are being conflated with _application updates_. Security updates are fine! Corporate IT will almost always roll out a revision change, no problem!

Microsoft's Update Tuesdays? Usually OK!

Service Packs? Let's wait!

Now Mozilla's got a huge troll face on and is saying, effectively, "Hehehe, here, have an update ... it might be a security update, it might be a service pack! Enjoy!"

> _This is either hyperbolic or delusional. You tell me which._

See, now here's where I want to make this personal now.

Don't pull that shit. Just because you don't _understand_ someone else's problem, doesn't mean their problem is insignificant. OK?

<comment><USER16> > ...and a lot of people very clearly are not. So now what? We say, "this > doesn't work for lots of people", you counter-point that it does work for a > lot of people ... both statements are true and nothing has been > accomplished.

Now nothing. I never said there weren't a lot of people on the other side. I was responding to Silhouette's comment: "I'm not, and I don't think a lot of other people are either." He's not willing, and doesn't think many others are. That's incorrect, because indeed many others are. "I don't think a lot are" is not the same as "I think a lot are not". (Compare: "I don't think a lot of people are fans of Justin Bieber." vs "I think a lot of people are not fans of Justin Bieber." These are very different statements.)

> And for people using Internet Explorer, they get updates much less > frequently. Guess which browser still has the lion's share of the market?

And? Are you advocating that Firefox should follow IEs lead? It looks like IE's lead is dropping almost as quickly as Chrome's share is rising.

> Right, and that's the rub! Upgrading is not painless!

It would be a hell of a lot less painful if it didn't involve a massive rollout of new software every 18 months. Chrome's always-updating model has proven to be painless for a lot of people.

> for us, "painless" means, "we have to answer support calls about what > happened to the bookmarks menu and why X page is no longer working even > though it was two weeks ago and by the way the back button looks different > and I don't think I like this new version..."

So use IE and be done with it, or maintain FF 3.6 indefinitely yourself. If you want your browser to remain unchanged for very long periods of time, and Mozilla won't help you with the goal, I don't see what your other options are. I really don't see how Mozilla has an obligation here.

Also, if you upgraded frequently, the changes that arrived wouldn't be quite so large. When you follow the "big bang" software rollout technique, it's a lot of changes dumped on the user at once. If you roll out smaller changes, users have less to adapt to any any given time. Maybe just send an email telling them where the bookmarks moved to.

> Nobody's objecting to security updates!

My point was that you have to go through testing for security updates as well. I concede that you're less likely to have users calling to ask about why the bookmarks moved after a security update, though.

> Now Mozilla's got a huge troll face on and is saying, effectively, "Hehehe, > here, have an update ... it might be a security update, it might be a > service pack! Enjoy!"

That's hardly fair. What Mozilla is saying is more along the lines of "Here's the latest and greatest." And "It's too much effort to maintain a bunch of old branches indefinitely, so we're not doing that anymore."

> See, now here's where I want to make this personal now.

You want to make it personal because you took offense to something I said to someone else? How thin-skinned are you?

> Don't pull that shit. Just because you don't understand someone else's > problem, doesn't mean their problem is insignificant. OK?

I did not say his problems were insignificant, and you need to stop getting your knickers in such a twist. I was responding to a specific statement: "OK, fine, but now everything is effectively a minor version increment in Firefox and Chrome, and anyone who doesn't update within 90 days is apparently going to lose all security updates. That is not a viable combination for any users who value a stable platform they can build on more than cutting edge toys." This is indeed hyperbolic (or possibly delusional). Minor versions with new functionality very clearly is a viable combination, because it's been working for Chrome for some time now.

The idea that you need everyone on FF4 for a year so that you can have a "stable platform" for development is ridiculous. If the move to FF5 is going to break everything, then you're already screwed, and your best bet isn't to dump a year into development for FF4, but to find a way to write apps that won't break every time the browser is upgraded. You cannot stay on FF4 forever (I hope), so at best you can postpone the problem and probably make it much harder to resolve in a year.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> To counter a point that has been made several times here: it's not just corporations which operate a "conservative" IT policy: many SMEs do so as well. Innovations are great at home but at work, they confuse users, break things which have worked _forever_ , and represent an unknown quantity in support terms. I've already decided not to put FF4 in front of my users because of the interface changes (I know I can restore the address bar, etc, but I don't want to spend my time doing that for each user).

The Firefox team are solving problems most users don't know they have, i.e. I rarely hear complaints that "the address bar is confusing", or "the status-bar is in the way", but frequently "I went to Google Image search and it's trying to install something on my computer". Time spent solving the second problem is far more valuable to me than time spent on the first (non-) problem.

</comment><comment><USER18> So? Let's all get stuck with FF 3.6 like IE6?

Please no. Mozilla shouldn't slow down the release cycle just because big corporations can't keep up with it.

Alternatively, what would help those big customers to keep up would be the opposite of what they require. Instead of having infrequent "big" releases every few months, having continuous updates ala Chrome where each increment in almost compatible with the next one could help to mitigate the problem. There will be no big breakages and everyone that wants will be able to keep up when time comes.

<comment><USER13> > Mozilla shouldn't slow down the release cycle just because big corporations > can't keep up with it.

 _No-one_ can keep up with it. Not big corporations. Not people who make web sites and web apps. Not even people who make extensions for the browser itself.

The only people who can keep up are users who ticked the "update me whenever you feel like it" box. They only benefit in practice if the people providing the content can take advantage of any new functionality. Otherwise, it's just a no-win/lose proposition, a significant risk of breaking stuff that used to work for no real benefit.

<comment><USER19> Its a vast improvement for web developers who have to develop for 1 version of chrome versus 4 versions of ie, Its a vast improvement for web developers who get to use new functionality to deliver better experiences to their users, Its a vast improvement for users who get a faster, smoother, more featureful web experience.

The only people it sucks for is large corporations who for some reason have applications that are tied to 10 year old technology and for extension developers, its a shame but certainly not worth holding back the web for

<comment><USER13> > Its a vast improvement for web developers who have to develop for 1 version > of chrome versus 4 versions of ie, Its a vast improvement for web developers > who get to use new functionality to deliver better experiences to their > users, Its a vast improvement for users who get a faster, smoother, more > featureful web experience.

It would be a vast improvement if any of those things were actually true, but unfortunately none of them is.

Web developers aren't developing for one version of Chrome or Firefox now, they're developing for one version every three months. That is far worse than supporting, say, IE8 and IE9. (Please can we drop the IE6 nonsense now? The remaining market share is negligible and the arguments are academic outside of niche markets.)

Web developers can't use the new features if they can't keep up with them, and in any case they are typically not portable, robust or future-proof enough for production work when first released.

That means users don't get a more featureful experience. If anything, they get less, because trendy web sites use trendy CSS3 features and the like to save time, and those features don't work for a very substantial proportion of the web-surfing public where the older but tried-and-tested techniques did.

<comment><USER19> The list of fatal regressions both chrome and firefox have introduced is pretty close to 0, developing a new version of a web app every 3 months for both browsers is beyond obtuse to the point of outright lying.

Web developers arent as utterly hopefully as you seem to think, my gmail supports drag and drop attachments, my irc client supports websockets when available, my task tracker works offline (and on a mobile), my maps support geolocation.

And I personally dont support have to support ie6, but a lot of people still have to. I havent heard of anyone that has to support Chrome v1.

<comment><USER13> > The list of fatal regressions both chrome and firefox have introduced is > pretty close to 0

Well, if they've only introduced a few here and there, I suppose that's OK then. </sarcasm>

> developing a new version of a web app every 3 months for both browsers is > beyond obtuse to the point of outright lying.

It's a good thing that's not what I said then, I suppose.

> And I personally dont support have to support ie6, but a lot of people still > have to.

A few people still have to, I'm sure, but the market share has dropped like a stone over the past year or two. For most projects that aren't in-house jobs in the organisations that haven't managed to leave it behind yet, it is no longer relevant.

</comment></comment></comment></comment></comment></comment><comment><USER20> The problem I see with this complaint is what "End of Life" means in corporate IT. What it boils down to in practical terms is that the vendor no longer is available for support calls.

We continue to run many EOL apps because of these kinds of issues -- we know the apps are stable for our usage of them, and it is a low risk that we would have needed vendor support anyway. We make an explicit decision to accept that risk

So this is technical impact, but really it is a risk management issue.

<comment><USER21> The FF4 EOL announcement has a bit more impact than that. It has been announced that FF4 will not received security updates. This means that if you deploy FF4 in your enterprise, you'll not only be committing to software without support, you'll have internet-facing software that contains published vulnerabilities (as they appear). That's just unacceptable.

Browser vendors would do well to adopt a release strategy that is similar to Ubuntu's model. You have a churn of releases with a periodic LTS release that will receive security patches for a longer term.

The key here is understanding that there is some middle ground. The "release often, period" method of software development is attractive to a lot of us individually, but it's nearly impossible to plan for when you manage hundreds of PCs per tech support staff member. Providing a consistent LTS release schedule would at least give corporations the ability to plan.

<comment><USER16> Corporations don't want LTS. They want RidiculouslyLTS. Ubuntu's LTS releases are supported for 3 years. IE 6 is now almost _10 years old_. This is what corporations want. They want to install software and forget about it for a decade. This is not a realistic model for a browser. Even 3 years is not very realistic. 3 years means running Firefox 3.0 now, in June 2011. Sure, some people do it, but it's not a great idea for many reasons.

When you're looking at Microsoft Word, expecting long-term support makes sense. It's shrink-wrapped software and upgrading is a big ordeal. You have to upgrade everyone at once, or someone's going to (repeatedly and consistently) send out docx files to coworkers who cannot open them. It can take a lot of time and money to upgrade everyone. Browsers are (or should be) different. The web is continually evolving. New exploits pop up fairly often. Regular upgrades are necessity for security and functionality, so upgrading a browser should be a minor, easy thing, and it should happen frequently. The problem is not the lack of support from Mozilla, but the expectation from corporations that browsers should be treated like Word processors.

<comment><USER21> "Corporations don't want LTS. They want RidiculouslyLTS."

Sure they do, but they also want 100% tax exemption, employees that will work 80 hours for 40 hours pay, and $0 fire and theft insurance. Companies want lots of stuff they don't get :)

My point is that it's not black and white unless Mozilla chooses to make it that way. Right now, it's white. For Mozilla to say: "Infinite incremental release is the way forward" is to say, "We don't care about your ability to plan releases in any way shape or form." That's pretty black & white. Any commitment to a release schedule would, at least, give them the ability to plan.

I agree that web browsers are not synonymous with word processing software, but the expectation that large corporations will simultaneously adopt web based technologies while throwing out decades of change-management process is just naivety at it's finest.

Large organizations benefit from economies of scale. This means reduced costs. This means one IT manager per five hundred PCs. This means you can't roll out software willy-nilly and expect your organization to stand. Any in-roads Mozilla gained with corporations will be quickly squandered if they stick to this strategy.

Again, I agree that the old pattern is not what we need, but this is upheaval, and that's not what works at corporations.

<comment><USER16> Exactly, companies want a lot of stuff, but that doesn't mean they should get it.

> My point is that it's not black and white unless Mozilla chooses to make it > that way. Right now, it's white. For Mozilla to say: "Infinite incremental > release is the way forward" is to say, "We don't care about your ability to > plan releases in any way shape or form." That's pretty black & white. Any > commitment to a release schedule would, at least, give them the ability to > plan.

Asking for a release timeline and asking for 3 years of support on a dead branch are entirely separate things. It's not unreasonable to ask the Mozilla keep users informed of the release schedule (don't they already do this?), but asking them to support an old version for 3 years seems silly. It takes a lot of manpower and there's no value in it for probably 95% of their customers.

> I agree that web browsers are not synonymous with word processing software, > but the expectation that large corporations will simultaneously adopt web > based technologies while throwing out decades of change-management process > is just naivety at it's finest.

I would say it's practical, not naive. If you want a browser that allows you to stagnate while enjoying long-term support, then either start paying someone for support, or start using IE. You agree that web browsers and word processors are different, so why should Mozilla bend over backwards to allow corporations to try to treat them the same?

> Large organizations benefit from economies of scale. This means reduced > costs. This means one IT manager per five hundred PCs. This means you can't > roll out software willy-nilly and expect your organization to stand. Any in- > roads Mozilla gained with corporations will be quickly squandered if they > stick to this strategy.

Sure, so don't roll out willy-nilly. Test and then roll out, just as they do now. But instead of rolling out 4.1, roll out 5.0. I don't understand what the big issue is. I'm sure it's a bit more work if there's a breaking change, but frankly you're going to have to deal with those breaking changes eventually unless you're going to stick with the same browser for years (let's call this the IE6 model). You just deal with them incrementally rather than in one massive painful push. Frankly the incremental approach sounds less painful for everyone involved.

We're talking about corporations demanding that a free product meet their antiquated needs. There's no grounds for the demand. It reflects their broken rollout policies, not a deficiency on the part of Mozilla. Maybe if it takes you several months to approve a browser rollout, that's your real problem. And let's be honest, a lot of this is just baseless fear. We're talking about a change in the way version numbers are incremented. People are worrying because it's called 5.0 instead of 4.1. The number attached doesn't really matter.

> Again, I agree that the old pattern is not what we need, but this is > upheaval, and that's not what works at corporations.

What else would work? For Mozilla to dedicate a lot of extra resources to maintaining dead branches for years? Not only does this not help move corporations forward, it doesn't help Mozilla, and it doesn't help the web.

If the current change management models are not working, then they need to be fixed. Test and rollout faster and more frequently. Roll out in stages, rather than with the "big bang" model. Have a roll-back plan and system in place. Really, the way people talk, it's as if every week the browser is going to break half the web. I hardly think that's the case, and I frankly think Mozilla's testing is probably more thorough than most any corporate IT department.

<comment><USER21> I don't entirely disagree with most of what you said, but I think you underestimate the challenges. I own a small start-up, so I know how nice it is to operate at a small scale. I let my employees chose their own browser, but I require that they keep it up to date. I can do that because I don't have to worry about supporting 500 people.

I've also consulted for very large corporations. The same disruptive ideology that applies to start-ups falls flat with large corporations. The biggest mistake is to take a unilateral position with them. They _will_ fall back to IE. They _will_ stagnate on old versions if we don't work with them. Is that what you want?

Maybe your product can avoid the corporate space altogether, but there are a lot of us who rely on them. I don't want to re-live IE6. I want browser makers to acknowledge that changing the corporate world isn't the same as creating Google or Facebook. It's far less glamorous and usually means doing shit in a way that you don't like for longer than you like. Change is coming, but it's coming slowly.

I hate line-item rebuttals, because they just turn in to pissing matches, but I did want to offer some clarification on these two points.

> Asking for a release timeline and asking for 3 years of support on a dead > branch are entirely separate things. It's not unreasonable to ask the > Mozilla keep users informed of the release schedule (don't they already do > this?), but asking them to support an old version for 3 years seems silly. > It takes a lot of manpower and there's no value in it for probably 95% of > their customers.

Let me clarify: I don't think 3 years is a viable LTS schedule for browsers. I don't know what the time frame is, but I'm sure it's not 3 years, and I'm sure it's not "We release continuously." I should have been more clear about what "similar" means when referencing Ubuntu. By similar, I mean that they should continue their march forward, but that there should be an occasional LTS release that is maintained for a longer, more planned interval.

> I would say it's practical, not naive. If you want a browser that allows you > to stagnate while enjoying long-term support, then either start paying > someone for support, or start using IE. You agree that web browsers and word > processors are different, so why should Mozilla bend over backwards to allow > corporations to try to treat them the same?

I'm saying it's naive (showing a lack of experience, wisdom, or judgment) to expect that this new development cycle won't have ramifications. Mozilla is free to do what they wish with their product. What I'm claiming is that it will come at the cost of market share in the corporate world. If they don't care about the market share, then go ahead and walk on it.

<comment><USER16> > I've also consulted for very large corporations. The same disruptive > ideology that applies to start-ups falls flat with large corporations. The > biggest mistake is to take a unilateral position with them. They will fall > back to IE. They will stagnate on old versions if we don't work with them. > Is that what you want?

What I want is for corp IT departments to not pretend as if this is somehow an insurmountable change. Yeah, corporations are slow and risk-averse. How risky is it to upgrade the browser once per quarter? Are they not testing and upgrading now for the sake of security fixes?

> Let me clarify: I don't think 3 years is a viable LTS schedule for browsers. > I don't know what the time frame is, but I'm sure it's not 3 years, and I'm > sure it's not "We release continuously." I should have been more clear about > what "similar" means when referencing Ubuntu. By similar, I mean that they > should continue their march forward, but that there should be an occasional > LTS release that is maintained for a longer, more planned interval.

Okay, I can understand that. I can see the value in dropping a version every 9 months with a guarantee of 1 year of security fixes. Or maybe drops every 6 months that get 9 months of support.

I think if Mozilla is committed to backwards-compatibility moving forward, though, this shouldn't be necessary. If they can't avoid breaking changes for some reason, then it is an issue. (One exception would be breaking changes in beta/bleeding-edge features. If you build your product on unstable CSS or whatever, that's your burden. And if you built your product on features that were only around for 3 months, then you should be able to fix your product quickly.)

> I'm saying it's naive (showing a lack of experience, wisdom, or judgment) to > expect that this new development cycle won't have ramifications. Mozilla is > free to do what they wish with their product. What I'm claiming is that it > will come at the cost of market share in the corporate world. If they don't > care about the market share, then go ahead and walk on it.

Thanks for the definition of naive. :) I never said it wouldn't have ramifications. I actually said the opposite. Corporate IT shops need to find a way to move more quickly. They need to _change_. Running everything on a multi-year upgrade cycle is ridiculous, and borderline incompetent (though the incompetence might be coming from higher up than the IT guys).

<comment><USER11> > _Corporate IT shops need to find a way to move more quickly. They need to > change._

That is easy to say, and difficult to do.

The simplest way I can think of to explain why is that every single move, or change, comes with a nonzero cost-per-employee. While it may be possible to reduce that cost, nobody has yet invented a way to eliminate it.

When you have 5 employees, a small change that costs X-per-employee is not a big deal.

When you have a few thousand...

<comment><USER16> > That is easy to say, and difficult to do.

No doubt. That doesn't mean it shouldn't happen.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> If you don't learn from history, what are you planning on learning from?

Debian solved this sort of problem by forking Firefox to produce Iceweasel, which is a stable FF version plus security patches.

There's nothing to prevent someone from doing the same for a Windows build of Firefox. There might even be a plausible business plan in providing support and updates. The releases would be free, but you can charge a fee for integrating and writing new patches, plus .msi installer scripts, plus answering questions. Cygnus was doing this for a bunch of GNU projects up until their merger with Red Hat.

</comment><comment><USER23> "Education programs, documentation updates, communications all are planned."

Couldn't you just fire all employees who need education programs and documentation updates for a browser update?

I know it sounds harsh and will get me downvotes, but think about it?

Maybe there are legit employees who are unable to grasp a new browser. But maybe for them a full blown browser is the wrong solution anyway. Perhaps somebody should step in and create dummy browsers that only have a couple of buttons for the limited set of activities those users are capable of performing. Seriously: the point of apps with nice UI is to make documentation superfluous. So instead of creating documentation nobody wants to read, create apps that make the docs superfluous.

It could be some kind of "browser generator".

<comment><USER24> One indeed might wonder at the people who need education programs for a browser.

seriously, the only major ui innovation since netscape 2.x? 3.x? was the merging of url bar and search bar.

</comment></comment><comment><USER25> What makes the web great is its constant change and innovation. How is it that a 2 person startup can deal with it's users changing browsers whenever they want, but a giant corporation can't? When your browser is beholden to a corporate dev cycle what you get is Internet Explorer.

What exactly would be wrong with a test system that included support for a variety of browsers? Perhaps they could _automate_ this test suite. Any process that made your dev system more agile would be a step forward in this turbulent economy. The current rate of change in the world is going to be increasing exponentially for the foreseeable future. Those well adapted to this environment will prosper those who aren't will perish.

Furthermore, "faced with deciding which is more important: security updates or the critical production web application needed to manufacture your product is not a happy place to be." if you're running the same browser to browse the web and do process control you're asking for XSS/CSRF attacks against your process control system, setup some special link on the desktop that launches a custom browser, then you can keep that browser _stable_ and have an up to date browser for the rest of the internet. Personally, if I was charged with securing a process control system I would have it entirely disconnected from the rest of the corporate network. Only systems that _need_ to access the process control should be connected to that network. We live in the world of stuxnet.

<comment><USER26> > What makes the web great is its constant change and innovation. How is it > that a 2 person startup can deal with it's users changing browsers whenever > they want, but a giant corporation can't?

That two-person startup consists of two hackers who eat, sleep, and fucking _breathe_ Web technologies. They have bookmarklets for six different sets of Web documentation, and they can quote chapter and verse from any of them. They work 18-hour days because they love their job.

The giant corporation's line-of-business app team consists of an IT guy, an accountant who owns a couple of dogeared books on JavaScript, and maybe a couple of contractors. They work 8-hour days, only half of which is actually devoted to the application they're working on, and they don't _care_ about standards as long as they can finish writing that Web app and get back to their actual job.

I'm certainly exaggerating a bit, but the reason is because that giant corporation's business is almost certainly _not_ writing Web apps for a living.

</comment></comment><comment><USER27> It appears to me that corporate wants to repeat mistakes of past. Is it really Microsofts fault that IE6 won't die?

Why is IE8 still around? Microsoft, of all companies, has tried to support legacy software for as long as possible, and often longer than possible, by reversing EOL'd announcements. The fact you can still run most 10+ year old software on a modern OS from Microsoft illustrates this.

Look where Microsoft is today, I certainly don't wonder why that is.

Corporations define policies and procedures for software releases internally. They find what is stable, slap a stamp of infinity approval on it, and forget about it. If this is to continue, there will be an IE6 problem again in a few years, only this time it will be FireFox that is being blamed.

Browsers need to be updated often, this is only going to become more important as the web advances. If this breaks your stuff, if your intranet falls apart as a result, more than likely, this is the fault of your intranet, not that of the vendor software. If it is the vendor software, in a few days, a patch will auto update.

As a corporation, you can chose to fix your intranet, put in the time and money to repair your mistakes, or not. Doing so will benefit you moving forward, and eventually, your intranet will be modern enough that these issues will be no more than a small inconvenience. It is not the problem of a browser vendor to stagnate their software because you want to allow your own software to stagnate.

The source is available, you have options. You can fork your own, keep the software where you want it, and patch it internally. If you don't like that option, contribute back to the current version, and help move things along. If you don't like that, write a check to someone to do this for you. I would bet that Firefox will be more than happy to backport for the right price.

You don't get to have your cake and eat it too, especially at the expense of the rest of the internet using world.

All the suggestions in the comments of the linked article lean on FireFox developing different versions and augmented policies to somehow continue to support an old version to aid in keeping crappy intranet's working. Why should FireFox spend a moments thought on making a Corporate Legacy Infinity Support Humping Along version just to appease the corporations inability to progress.

Sure, it is a lot of work to roll out 500,000 updates to FireFox. Move to Chrome and that won't be an issue, you are always up to date. Or, maybe there is an auto-update mechanism to FireFox for that scale. But doing that, removes the need for a large staff to take months to years to plan a browser update. That sentence is so insane, having a team to plan and document the upgrade of a browser!

People will find small portions of their jobs are irrelevant. Progress is like that. One day, many of our jobs will be replaced by robots. There must have been resistance to the copy machine, and all those secretaries no longer had to hand type a letter from the boss. Carbon copy paper may have had equal resistance. Progress happens, sometimes at the expense of jobs. Stay on top of your industry, and change with it, and your job should be secure. Don't get comfortable with the fact that your job is hanging on by a thin thread of aged policy in a corporate environment that changes slowly. That will be forced to change, as we are seeing now.

Corporate IT workers are demanding to turn FireFox into the IE6 problem. This has come at the expense of the entire internet using public in the past. FireFox is not willing to allow that to happen.

Version numbers are going to stop mattering. When you check the version number in the future, it will say "current" or "needs updating". Embrace this, and your intranet will be modern and more bulletproof. Don't, and I hope you are confident there are other aspects of your business that do not rely on technology so you will still be relevant in some other field. Someone will always need to put more paper in the copy machine, maybe you can create a procedure for making sure that all the copy machines waste a page per print. Your job is safe for at least your lifetime.

<comment><USER28> > _"The fact you can still run most 10+ year old software on a modern OS from > Microsoft illustrates this. Look where Microsoft is today."_

38th largest company in the US in terms of revenue.

$18 billion in profits puts them 4th behind Exon-Mobile, Chevron, and ATT.

[[http://money.cnn.com/magazines/fortune/fortune500/2011/full_...](http://money.cnn.com/magazines/fortune/fortune500/2011/full_list/)]

<comment><USER29> And vast majority of corporate desktops.

</comment></comment></comment><comment><USER30> I used to do IT in the Navy and participated in upgrade processes like this, and this is exactly why I didn't go work at a government software contractor like most of my shipmates did after we got out.

</comment><comment><USER31> I think this is a challenge especially for open source projects. I'd rather _write documentation_ then have to maintain an old, deprecated codebase.

</comment><comment><USER32> Stuff changes. Corporates need to get used to that.

Add to that the motivation for buying software is usually either a bonus for completing a project or cash backhand from the vendor rather than on the merits of a tool.

Also, I know a certain large company that used paper envelopes for asset tracking. They bought in a fantastic electronic system to handle it and all the staff sabotaged it because: A) it made them accountable ... B) it made people visible of what they were doing.

TBH I think most corps are deranged as are any groups of humans with N > 5.</comment>


Ask HN: Passed the FB screen but no offer (yet) - <AUTHOR> I'm in a slightly weird situation that I'd appreciate a more experienced HNer's input on.
I had a phone screen for a FB internship last week. Yesterday the recruiter got back to me and said that I'd done well but that they didn't have room in the track that I'd originally been slotted for (PhD ML engineer) and to give them 1-2 weeks to figure it out.
But the recruiter also said that there were spots open in the Systems and Infrastructure track and that if I were interested in that she could connect me with those teams. In fact I am interested in systems and infra (I said as much during the warm-up with the first interviewer during the screen) so I immediately responded in the affirmative.
Today I spoke with a friend that works at FB and he said the issue is that it's quite late in the semester and so the recruiter is being honest about having trouble finding me a spot.
The reality is I would be absolutely ecstatic to work on anything at FB (systems, ML, mobile, frontend, etc) but I'm not sure if they're considering me for all those slots or only PhD slots. I'm also not sure how to effectivity communicate this to my recruiter (that I'm excited about anything).
Any advice while anxiously waiting out the next 2 weeks would be appreciated. <comment><USER2> why in 2020 would you want to join a shady operation like FB in the first place?</comment>


Is chatroulette over? - <AUTHOR>

I have an idea that's been stewing in my head for awhile but first I need additional input.
I've read that both Fanning and Parker believe that chatroulette has the potential to become big.
I think that once they've fixed the obvious problems, what's left will be a big group of people nexting and nexting 'til they encounter the very limited pool of attractive or interesting people using it. Doesn't sound very fun.
Is chatroulette a fad that's over? <comment><USER2> I say this as a former developer who created some of the first video chat rooms ever (CUworld in 2000). Talking to random people online eventually devolves into porn. You can't help it. Chatroulette got around that stigma by eliminating all approach anxiety to a conversation (Parker's words)--sort of like the exact opposite effect of perusing profiles of people on a dating site and messaging someone very attractive (who probably gets inundated with requests).

I think the notion of turning chatroulette into a performance platform is very interesting. Some of the Ben Folds chatroulette performances were pretty fascinating and managed to get at the one-to-many-ness necessary to drive large amounts of traffic on a consumer site (you don't need that to make an interesting product--but Skype seems to have nailed 1 to 1 video pretty well). Being able to have different bands 'battle' on chatroulette or have comics or musicians present new material could be great.

<comment><AUTHOR> Perfect. Thanks.</comment></comment>


Mark Cuban on startup investing (and Gmail management) - <AUTHOR> http://mediamemo.allthingsd.com/20090115/mark-cubans-startup-investing-tips-buy-now-bonus-advice-how-to-manage-5000-emails-a-day/

<comment><USER2> What other big name entrepreneurs are that accessible?</comment>


Show HN: NCurses Terminal Webcam - <AUTHOR> https://github.com/mustafaakin/terminal-webcam

<comment><USER2> MPlayer can also do this. Something like this should work as an example:

      $ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 15 -vo caca

<comment><USER3> For the record, that's not pure terminal (it opens up another window). This project works even in a bare vterm. I'd love to see this work over ssh.

<comment><USER2> It will draw an X11 window if there is an X display. Unset DISPLAY and it will render in the terminal: $ DISPLAY= mplayer ...

Updated command for clarity (might want to fullscreen your terminal with this):

        $ DISPLAY= mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 15 -vo caca

<comment><USER3> Sweet, I didn't realize that. Sadly, the result flashes on and off and is essentially unusable for me (either in xterm or a TTY on Slackware64 14.0). I can tell it's working, though.

This also seems to work over ssh, though, which is cool.

<comment><USER4> Add the -quiet option to mplayer.

<comment><USER3> That fixed it. Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER5> Interesting - I just made something exactly like this (screenshot looks exactly the same): [https://github.com/billyeh/termchat](https://github.com/billyeh/termchat)! I even had to publish a Node package to do it (pixelr).

Except it's got a chat function with other users as well :)

</comment><comment><USER6> It's still using the old OpenCV calls, so I did a quick port to OpenCV 2. [https://github.com/techwizrd/terminal- webcam](https://github.com/techwizrd/terminal-webcam)

</comment><comment><USER7> Cool. You can do it also with `vlc` and the `-V aa` (ascii) or `-V caca` (colored ascii) video output in the console.

Can play any videos or stream the webcam:

        vlc -V aa file.avi
        vlc -V aa v4l2:///dev/video0

</comment><comment><USER8> Please add encryption (on by default), sound, and hook this up to PGP so that it can be skype for hackers (and I don't mean just crackers, I mean in the most general sense)

Just in case it wasn't clear - I think this is awesome.

<comment><AUTHOR> Well, I was going to do it (2 years ago as you can see in repo), but somehow I forgot. Now, I made NodeJS fork of it: [https://github.com/mustafaakin/terminal-webcam- chat](https://github.com/mustafaakin/terminal-webcam-chat) to turn it into a chat

</comment></comment><comment><AUTHOR> If you want to get full performance, use xterm, gnome-terminal and others are very slow. Colorful one uses only 6^3 colors but it looks nice: [https://raw.githubusercontent.com/mustafaakin/terminal- webca...](https://raw.githubusercontent.com/mustafaakin/terminal- webcam/master/colorful.png) (It is currently night here mywebcam sucks on night)

</comment><comment><USER9> This is pretty awesome. I'm surprised that you can get such a detailed and responsive image with just different characters. Very cool.

<comment><USER10> YouTube did something like this a few years ago for April Fools. I think on a modern Retina-level display it would look even more impressive due to the higher resolution and smaller character-pixels.

Also reminds me of this: [http://www.oldskool.org/pc/8088_Corruption](http://www.oldskool.org/pc/8088_Corruption)

<comment><USER11> Forget about retina displays, imagine on a VT340* in glorious sixels!

[https://github.com/saitoha/PySixel](https://github.com/saitoha/PySixel)

*Or even xterm compiled with sixels support ;)

</comment></comment></comment><comment><USER12> See also: [https://github.com/dhotson/txtcam](https://github.com/dhotson/txtcam)

</comment><comment><USER13> The submitted program, and the mplayer incantations in the threads, are the most delightful things I've seen all day.

</comment><comment><USER14> Neat! I made something similar for OSX: [https://github.com/dhotson/txtcam](https://github.com/dhotson/txtcam) / Screencast: [https://asciinema.org/a/7301](https://asciinema.org/a/7301)

I used halftone characters to do "dithering".

Someone forked and updated it to work with iTerm2's 24 bit colour support: [https://s3.amazonaws.com/f.cl.ly/items/063S2A0b2b3w3T2Z3J0q/...](https://s3.amazonaws.com/f.cl.ly/items/063S2A0b2b3w3T2Z3J0q/Image%202013.11.25%2022%3A22%3A23.png) .. not bad!

</comment><comment><USER15> OK, now how can I make this loopback such that this is what the people I'm talking to on google hangouts sees?

EDIT: duh, hangouts has a "share window" feature .. this is awesome!

</comment><comment><USER16> Forget looking at my ugly face, how do I watch movies in my terminal?

<comment><USER2> You're in luck:

      $ mplayer -vo caca my-movie.mp4

</comment></comment><comment><USER17> This isn't mine, but it does a similar sort of thing in browser. It's actually a port of libcaca to JavaScript using emscripten:

[http://experiments.coscolla.net/libcaca/](http://experiments.coscolla.net/libcaca/)

The author is this guy: [https://github.com/kozko2001/libcaca.js](https://github.com/kozko2001/libcaca.js)

</comment><comment><USER18> See also hasciicam by Jaromil. [https://github.com/jaromil/HasciiCam](https://github.com/jaromil/HasciiCam)

</comment><comment><USER19> See also [https://github.com/zfogg/ascii-chat](https://github.com/zfogg/ascii- chat)

</comment><comment><USER20> great work!

i did one the runs on osx a couple years ago. might be broken now, haven't run it in a while.

[https://github.com/helloandre/cam2ascii](https://github.com/helloandre/cam2ascii)

</comment><comment><USER21> Reminds me of AAlib and bb, the portable demo.

<comment><USER22> To go up the stack a bit, it reminds me of TTYQuake. (original website gone :( )

[http://ingles.homeunix.net/presos/quake/4/ttyscreen.html](http://ingles.homeunix.net/presos/quake/4/ttyscreen.html)</comment></comment>