Why you can't hire - <AUTHOR> http://startupboy.com/2011/12/13/why-you-cant-hire/ <comment><USER6> > Throw out the old cap tables. A founder doesn't get 30% and an early > engineer shouldn't get 0.25%. Those are old numbers from when you had to > raise VC capital before you could build a product. Before everyone could and > did start a company.

Choice quote. I'm kind of amazed this isn't brought up more.

<comment><USER7> completely agree. as someone that's just about to graduate, i have to say i was a little shocked when i figured out this is the way things are. the difference between the first engineer and one of the founders never seemed so categorical to me, and this was one of the few things that made me feel it's not really worth joining a startup as early as I'd like (to work on interesting+useful things, have impact, etc.) unless I'm actually involved at the founding stage.

<comment><USER8> > the difference between the first engineer and one of the founders never > seemed so categorical to me

The categorial difference is that if the company flops in a few months the founders are out a lot of money, whereas as first engineer you are merely in a similar position to before you took the job, but with some nice experience on your resume and a few months worth of pay in your bank account.

<comment><USER9> Wait, what?

Most founders I know would pay themselves a salary after the first funding round. A small one perhaps, but I don't think the difference is as big as you make it out to be. Especially when you consider that the first engineer in a startup gets at least the same workload as the founders.

<comment><USER8> That assumes there is a round of funding. Not all startups are in the kind of sexy areas that cause VCs to throw money at them. Some are funded by the savings of the founder (and sometimes a second or third mortgage on his house). At that kind of startup, the founder often only gets paid his salary if the company has profits.

</comment></comment></comment></comment></comment><comment><USER10> > There isn't a shortage of developers and designers. There's a surplus of > founders.

This is especially true of non-tech companies looking to hire quality people for positions in their IT departments.

I currently work in such an IT department and we have a position for a J2EE developer to write portlets for our up-and-coming Liferay portal. Needless to say, we can't find anyone good (outside of recruiters, which we'd rather not use) to fill this position. My boss has asked each of us if we know anyone we can recommend for this position. As far as I know, no such luck.

Personally, I'm not the least surprised. None of the developers that I know would even touch a job like this. Most don't/won't do J2EE. Portals never really took off like corporate America hoped it would (and Gartner said it would). I have some things that I'm working on on the side, and if/when that becomes something, I'll be headed out the door too.

What my employer fails to understand is that they are hiring as if it was still 1998. Developers now have options and no longer have to settle for jobs like this. Their competition is no longer other IT departments, it's freedom of choice itself.

<comment><USER11> So what's the answer when jobs like this need to get done?

It may not have to be J2EE, but there are plenty of corporate jobs that have to get done to help build big company infrastructure, and if much of the talent that was available now has more attractive options, is the only answer to escalate salaries? Or to hire in shorter-term contract developers?

<comment><USER12> Well, if good engineers don't want anything to do with your opening at the compensation you're offering... increase the compensation.

And, honestly, change the position so that the person hired isn't considered just a cog in management's plans, who's expected to be on call 24/7 and to put in 50 hours a week in a windowless room. I wouldn't go back to that shit even at double my current salary.

<comment><USER13> Agreed. The reason people put up with soul crushing jobs like investment banking is because the compensation makes up for it. Granted, most people in those kind of jobs burn out after a few years, but you anticipate that when taking the job. I have several friends doing the "make tons of cash while young, move to easier job in 5 years" career choice.

Corporate America IT jobs have all the soul crushing without the reward.

<comment><USER14> It's not really burn out, it's the management cabal that likes to keep the body count high. There's a lot of mildly desperate people who really forced their way up into unstable career positions, and natural genocidal tendencies peek out every now and then. It's innate human behavior. History's purges were not by accident.

</comment></comment></comment></comment></comment><comment><USER15> I feel the urge to point out that, if the cap table gets squeezed, there is no a priori reason that any particular part of it should get squeezed. It is entirely possible that, as he frequently argues, the productivity of money is going down (because "startups are cheaper than ever to start") and the productivity of product teams is up (because of huge amounts of leverage in the system via OSS, platform companies, improved development technologies, The Cloud, etc).

If one buys that set of facts, there is exactly one participant in the startup ecosystem who should be getting told "Sorry, your contributions are not worth what you think they are." It isn't founders or engineers.

P.S. That said, psst psst, being last cofounder beats first engineer 100% of the time.

<comment><USER16> One assumption being made here is that hiring is a critical task. It's entirely possible that a company can achieve its objectives without hiring; if that's the case then the argument doesn't apply.

</comment></comment><comment><USER17> I actually don't understand the author's point or numbers. A fully loaded engineer costs 100-200k depending on where you're located in US/Canada. And let's say you need 25-50k for 2 founders to live for a year. Giving yourself a 12 month runway you're at needing 150-300k in the bank to even be in the position to hire.

If you have 150k in the bank it's because you have some seed money, or have bootstrapped your way to that position. If you've bootstrapped then you've achieved pretty good product/market fit and have good revenues. Conversely if you've raised 150k and haven't achieved product/market fit, then you probably shouldn't be hiring.

Now, if you look at companies that have raised 150-300K I don't think you'll find many of them hiring, at least not very aggressively. I feel that level of money is used to give the founders time to iterate until product/market fit and not be cash constrained when it comes to things like contracting a good designer or buying a domain. And once a seed funded company achieves some semblance of product/market fit they go and raise 1-2 million.

So is this article intended for the few companies that have raised in the 100-300K range that are starting to hire? If that's the case then ya, I agree such a company is going to have difficulty hiring. They have significant risk of not achieving product/market risk, and they don't have sufficient capital to give a fair market wage. So a potential employee is taking a huge chance on such a company, and should obviously be compensated for that (relative to the very attractive compensation packages are companies like Yammer, Square, etc). But I don't really think there are very many companies like that, but maybe I'm out of the loop.

<comment><USER18> The authors point is that the system has changed:

Before: Founders put together a biz plan and raised a decent seed round and then started hiring the first few employees.

Now: Some person gets an idea, pitches it to another person, and they start building it, then they pitch it to a third person. They don't pay themselves salaries, live off their savings and their credit cards. An 'incubator' may give them some cash to pay for things like AWS instances and filing incorporation papers. They may be up to 5 or 6 people before they have a 'minimum viable product' (MVP) and are willing to pitch it to VCs for a real series A.

The author points out that all of the first 3, 4, 5, or 6 people who were working to get the company to the MVP point, _they are founders._ Not just the 'idea guy' or the 'wizard' that they snagged to help implement the idea. Everyone who came on board before series A has made it possible to get to that point is a founder.

And yet there are companies that treat person 2 - n as 'employees' and give them way less equity. Because of that people don't want to be employee 2-n, and thus hiring them is 'hard'.

I've noticed this as well, and have been puzzling around with the following thoughts.

Lets say you create a company and decide that prior to series A, 80% of the company will be owned by the founders and 20% to outside investors. You start with 10 shares, 2 for an angel, 8 for the founder.

Now you add a founder, you double the share pool and now you give 8 to the new founder and 2 to the angel (distribution is 4 + 8 + 8). Now you add another engineer/founder and you now add 80 shares to the pot and distribute them 27 + 27 + 26 for the founders and 20 for the angel. Add a new angel and you double the shares to 200 where each angel get (20 + 20) and founders get (54 + 53 + 53) shares.

The idea being to keep the ownership percentage of the company 20% angels, 80% workers.

Now you go for series A - my thought is you pick three ratios, investors/founders/employees. That may end up being 49/31/30. Allow your angel to either contribute their shares to the series A (cash out) or to participate. But at the end of the day the representation is 49,31,30. Same deal when you add more investors, add to the size of their pool so that works, add to the other pools to keep it balanced.

I am undecided if it would make managing the equity table easier or harder.

<comment><USER19> Just to nitpick a bit -- your final three numbers add to 110, not 100. Perhaps you meant 49/31/20? I point it out only because 49/31/30 seemed too good to be true.

<comment><USER18> Good catch, 49/31/20 would probably be the end result.

</comment></comment></comment></comment><comment><USER20> This rings very true. I've interviewed with and turned down 8 YCombinator start-ups in the past three years. Of the 8, I would have been within the first 5 employees of 6, within the first 10 of the remaining two. They all offered below market salary in exchange for "huge equity". Thoe "huge equity" offers ranged from 0.35% to 2% (the 2% one offered me 40% of market-rate). I didn't mind, I was only interviewing to network and try to sell my $150/hour consulting services to them. (3 of them are still customers). Being an employee for a start-up is a sure-fire path to an early grave in potter's field.

</comment><comment><USER21> Amen, brother!

This is why I don't consider jobs with even exciting startups with early traction at this point in time. Why would I bother getting 50x less return for a similar investment and risk as a founder? We should at least be in the same order of magnitude. Especially if the startup is practicing "lean" and is going to completely change by the time it exits. Might as well just start my own company.

And, if you can't get into an incubator, you can just as easily bootstrap your way through the early stages.

</comment><comment><USER22> I see a lot of positive comments for this post but I'd like to chime in and suggest that upping the equity is not going to solve the problem.

In once sense the engineer is making the same kind of bet as the VC. They don't know the founders too well, not sure if the idea is any good, its a big gamble. Buy unlike a VC, the company will be the engineers whole life until the idea proves itself or fails.

A few extra percentage points of a deal that will probably never happen is not really all that attractive.

The only solution is to raise more money and pay them more.

</comment><comment><USER23> "Raising the first $25K for product development is easy – join an incubator."

I think that trivializes the process. There are now multiple incubators, but about two orders of magnitude more looking for spots. Y Combinator gets thousands of applications for a few dozen spots. Tech Stars Boulder got 600 apps IIRC, and only 10 get in the program. Early stage money gets trivially easy if you're in one (especially YC or TS), but getting further funding is still a time drain, and now you're competing with the 100+ incubator-based startups for VC/Angel money.

I do agree about cap tables. With less money needed to start a company, the equity normally given to investors can (and should) go to employees. It's an opportunity for many who have talent to get a bigger reward for their hard work.

<comment><USER24> I suspect those numbers may be skewed by the same "we only hire the top 1%" phenomenon. There could very well be a recurring group of people with not so great ideas that repeatedly apply to incubators, and repeatedly get turned down, whether with the same idea or a new one.

I'd be interested to see the skew as well. Maybe a large part of those declined were unserious college students or similar.

<comment><USER23> Sure, at least half of the applications hit the trash bin. I recall a comment from pg at startup school in 2010 correctly, he said a surprising number of the applications to YC (I want to say 20%) were in ALL CAPS. That's an easy way to self-select one's way into the bit bucket. But even at half the size, there's still at least 1000 applications that are likely well-formed in one way or another. PG has said that the hard part is finding something exceptional in an application that would put it over the top.

</comment></comment></comment><comment><USER25> This. A thousand times this.

Oh, and offer me as much salary as you can with the option for me to dial that back into equity. I can't pay a mortgage or buy pizza with options, and my market rate does not fluctuate based on how much buzz you have on twitter.

<comment><USER26> The Goodfellas school of startups.

The founders' got Pauli as an engineer, any problems, he goes to Pauli, problems with EC2, he can go to pauli, troubles with rails, hard drives, Linux, he can go to Pauli, but now he's gotta come up with Pauli's money every week, no matter what.

Your tweet didn't go viral? Sorry to hear about that, fuck you pay me.

Your funding didn't come through? Fuck you, pay me.

People don't need more coupons? Fuck you, pay me.

Servers crashed in the middle of the night? Fuck you, pay me.

And then finally when there's nothing left and he can't raise another dime from the VC, or clear anymore paper on second market, you bust the joint out, take the code and release it as open source.

If founders actually believed their option bullshit it would be a no brainer to keep those valuable options and pay engineers 200K. There is no shortage of engineers, only a shortage of suckers.

<comment><USER27> Your goodfellas analogy is pretty close to perfect (and I know quite a few paulis myself, hell, I'm a Pauli). That being said, the author's suggestion of a vastly larger amount of equity with the right founders in place might convince me. But .25? Even 3? Fuck that, pay me.

</comment></comment></comment><comment><USER28> This should be common sense.

When there is a scarcity of a product (engineers to hire), the cost naturally goes up. If you are having trouble hiring, raise your compensation. If you don't have cash to offer you need to raise the amount of equity you give (or perhaps other perks).

</comment><comment><USER29> Sometimes I feel like the last person left who raised traditional angel money and then VC money.

We paid our first engineer market rate and had actual benefits. Our cap tables are pretty traditional and we haven't had much trouble hiring all things considered (though we are extremely picky).

I have to say, if you have to give 20% of the company to your first engineer in order to get him/her on board, then I don't really see the benefit in going the incubator route over traditional funding.

</comment><comment><USER30> I agree it's a supply and demand issue. But for comparison: We couldn't find people to hire in Y2K either after having raised $20M.

Throwing equity around does not solve the fundamental issue, it just is a competitive tactic.

</comment><comment><USER31> The issue with this method is that it assumes that the investor model has to change too. VC's will attempt to have the right ownership over the lifetime of an investment eventually getting to around 20%. Some want 20% right away. The problem with granting so much equity to employees makes the rounds of funding required later difficult to match this ownership target.

Investors want founders with meaningful ownership of the business, a syndicate that owns enough to care, and employees happy too. That is where the model is driven from, and would require a change at the investor level for this to work.

Assuming 2 investors (40%) 2 founders (40%) that leaves only 20% remaining which does not fit the proposed changes.

</comment><comment><USER32> Succinct and to the point. +1.

I really appreciate the comment about the surplus of founders (as opposed to a shortage of developers.) There's a context that's very important in that statement: that not all founders are really necessary, nor do they really come before other key team members (namely, engineering) in terms of foundership.

Great post.

</comment><comment><USER33> Yes! This article just raised my market value by giving me new insight into the market.

</comment><comment><USER34> This article helped me clarify an interesting contradiction in my own motives. As a founder I'd much rather pay market rates and hold on to equity - 0.5% incentive doesn't hurt me but my hackles raise at 10% or more. (The state of my hackles is not correlated to how fair the compensation is, BTW - it's just greed.)

On the other hand, even more than getting the top 2% unicorn squad, I want _engineers who believe in the business_. Taking equity in lieu of salary is a sort of screen for this, and I think that's why I've structured things that way in the past.

I agree with the article that it's not fair to the first N employees, though.

</comment><comment><USER35> My question is, if not the traditional equity model, what would you offer to get and retain key early engineers? How about sales people? Community manager?

To clarify, perhaps people can post their thoughts on what equity percentages you'd offer to the following? (or something similar) :

1 - 5 Employees - <USER4>

1 - 5 Employees - <USER5>

1 - 5 Employees - Community Manager/Support

6 - 20 Employees - <USER4>

6 - 20 Employees - <USER5>

6 - 20 Employees - Community Manager/Support

Thanks in advance!

</comment><comment><USER36> I don't want your fucking equity. Pay me, and when you inevitably can't pay me anymore, I'll move on.

</comment><comment><USER37> I think that this is true in Silicon Valley and possibly NYC, but not in other areas.

I firmly believe we just haven't churned out enough CS graduates nationwide over the past decade to meet the demand of both the startups and the established businesses that are all hiring right now.

<comment><USER26> Good thing you don't need to be a CS grad to churn out a mobile social coupon CRUD app and website.

<comment><USER38> But the mobile social coupon CRUD owners only want to hire the top 2% and then cry they can't find anyone. The job market is like taking a racing horse and having it plow a field. The incubators have a similar problem, the candidates are so good they don't even really need the incubator, I imagine the incubators doing worse as time goes on because people are not so hungry for success and will just combine with others when the going gets tough.

</comment></comment></comment><comment><USER39> I agree that something in the cap table has to give, but I don't think it's founders. It's investors.

Psychologically, I would also make sure those "early employee founders" really risk something; even if it's just securing $20K of their savings in a bank account to be used in a pre-approved way if the company needs to make payroll. $20K is, after all, just 2 months of gross salary for your self-determined great engineer applicant.

Doing something like this has 2 benefits: 1\. Applicants self-select for risk tolerance. 2\. You avoid the spoiled kid syndrom of "co-founders" making all types of employee requests ("I need $6K for a top notch working station", etcetera.)

</comment><comment><USER40> Thank you for showing and communicating a sense of clarity that many colleagues around me (sometimes myself incl) seem to lack. People talk of 'founding' a startup and 'i'm an entrepreneur' as if its like a roadtrip to tahoe. Its not. Period.

</comment><comment><USER41> Instead of comparing the equity of the first engineer with the founders, it is easier to compare how much his lower salary can buy him if he takes another job with full salary and invest the difference in the company as an angel investor. If there is an engineer whose salary is $120k/year and is joining a startup at $90K/year, he is taking a 30k/year loss. Let's say the startup has received $500K investment at the valuation of $2.5M. Since the startup has passed its valuation point already, its current value is somewhere between 2.5M and its future expected value.

Let's assume the prediction for valuation at the next round is $10M and there is 50% chance that the company gets there. This would make the value of the company about $5M at this point. This means that the engineer's discounted salary is worth about 0.6% equity (30K/5M=0.6%) for the company. Usually companies make the offer for 4 years worth of equity with a vesting plan. Again it is not correct to multiply 0.6 by 4 because the salary of engineer will reach to its market value after the next round of funding. It is fair to multiply it by 2x. This brings the total equity given to the engineer to be about 1.2%. I made a few assumptions here such as what the expected value of the startup would be in the next round of funding and how much the salary is lower than the market value. This calculation shows that the current amount of equity offered to the first employees is not that different from what it should be contrary to what the author of the blog post has suggested.

 _To offer a simple formula:_

Y (expected equity of the first employee for the first year) = X (loss in income for the first year) / V (valuation at the next round of funding) * P (probability of the startup getting to the next round).

 _For our example:_

Y = 30K / 10M * 0.5 = 0.6%

I know engineers often compare themselves to the founders and wonder why they should get so much less equity considering that they have similar skills and are putting equal effort into the company. One thing they ignore is that what founders have already put in. In most typical startups, the founders have been developing the idea at least for two years and have worked full-time on the startup for 6 to 12 months before receiving the seed funding. They have done this at the time that the possibility of getting to the seed funding round was less than 20%.

If we assume their market value was $120K/year, that means they each put in something about $120K at the time that there was less than 20% chance that the company would get to the point of $2.5M valuation. If there are two founders, this would be about $240K investment at the valuation of $500K (2.5M * 20%). That means the founders should get 48% in vested shares in the company. Instead they get all their share as unvested shares and have to work for the next 4 years in the company to earn them. Considering the remaining sacrifice they have to make, it is totally fair for them to receive 60% instead of 48%.</comment>


Ruby on Sails: a homebrew Google Wave provider - <AUTHOR> http://danopia.net/posts/12

<comment><USER2> Neat! Hopefully a good example of how Wave might have a quick uptake. Relatively easy to write for and against might mean a fast adoption rate.

</comment><comment><USER3> Sounds like Ruby on Snails for some reason...</comment>


The first and only smart window – Improves health, saves money, simple - <AUTHOR> http://www.smartfenestra.com/ <comment><AUTHOR> We are looking for feedback, questions, doubts, improvements, EVERYTHING! We need help from people like you. Please don't hesitate to contact me at email@example.com. Thanks!

<comment><USER2> Interesting device. This could be the poor man's HRV system.

How do you cope with the large variety of window opening mechanisms? Or does it work specifically with the sliding window?

<comment><AUTHOR> Our current prototype only works with horizontal sliding windows given these are the most common types of windows on newer type of construction in the US. After launch based entirely on feedback from people like you we will decide what the next type of window will be. Thanks for reaching out internaut!

</comment></comment></comment><comment><USER3> very clever idea. how are you connecting this to the internet? WiFi?

<comment><AUTHOR> Thanks! fenestra is powered by a small solar panel which means we are not using power hungry Wi-Fi but instead using the battery efficient SmartThings platform, this way fenestra is truly an eco-friendly solution. Thanks for reaching out kechu!</comment></comment>


Show HN: MarcelloDB, an embedded mobile nosql database for Xamarin/.net - <AUTHOR> http://marcellodb.org <comment><AUTHOR> Hi Everyone,

I just release MarcelloDB 0.6.0 MarcelloDB is an open-source Embedded NoSql database built for Xamarin and Windows Universal Apps.

I have been working on it for the last 2 years or so. It took me a while to stabilize the API and the file-format and to add all features I wanted in there for 1.0.

0.6 is the last version before 1.0.

So I want to invite everyone to give it a spin.

MarcelloDB saves entire objects trees (using Json.net), has a very flexible indexing mechanism and transactions.

All feedback is highly appreciated.

You can find the docs here: marcellodb.org

And the source here: github.com/markmeeus/marcellodb

kind regards, Mark</comment>


The Git Bell: post-commit → ruby → arduino → bell - <AUTHOR> http://www.urbanhonking.com/ideasfordozens/2009/02/the_git_bell_postcommit_ruby_a.html

<comment><USER2> Fun, but I think I still prefer the angry red test failure bear:

<http://blog.last.fm/2008/08/01/quality-control>

<comment><USER3> In the Yahoo office in London our resident build manager "Bob the builder" (real name Andy) had a Pilchard the cat (<http://www.nickjr.co.uk/shows/bob/pilchard.aspx>) which meowed whenever anyone on either side of the Atlantic broke the build.

</comment></comment><comment><USER4> Clever use of Arduino. I think it would be more useful if it rang when other members of your team pushed stuff to github (or wherever), for the project and branch you're working on.

<comment><AUTHOR> I'm working on that part. I'm going to setup a Sinatra app that can respond to the GitHub service hook API and which I can then poll from my local box to check for pushes.</comment></comment>


How to get an Internet connection to a field for a hacker camping festival - <AUTHOR> http://blog.emfcamp.org/post/27143646219/emf-camp-the-site-and-networking

<comment><AUTHOR> For anyone who wants to come to EMF, there's a £5 discount link floating around:

<https://www.emfcamp.org/tickets/token/hackspace>

</comment><comment><USER2> Their badges look fun too: [http://blog.emfcamp.org/post/28558155390/revealing-tilda- our...](http://blog.emfcamp.org/post/28558155390/revealing-tilda-our-camp- badge)

      > By default it communicates with all the other badges on site,
      > playing a networked game that encourages you to meet other people
      > with differing interests. They also communicate with things on site,
      > but more about that soon.

<comment><USER3> Defcon's badges were really fun this year as well and were also part of a game; some of us are still playing with them. The crypto game in them was designed to get attendees to meet new people and work together to problem solve.

Here they are: [http://forums.parallax.com/showthread.php?141494-Article- Par...](http://forums.parallax.com/showthread.php?141494-Article-Parallax- Propeller-on-DEF-CON-20-Badge-Start-Here)!

</comment></comment><comment><USER4> 2.8 km is pretty easy with two Ubiquiti Nanobridges for example, that's a short distance... Nice expensive COW trailer too.

<comment><USER5> Yep, our backup/second link will be a Nanobridge-M5, the primary is using 38ghz DragonWave kit. Nat (who wrote that blog post)

<comment><USER6> Does the UK have any regulation of the 38ghz band? Based on the FCC info here in the US (<http://transition.fcc.gov/oet/spectrum/table/fcctable.pdf>) the 38ghz area of the spectrum seems to have only a small subset of bands that qualify for this use. Do you know the exact frequency the DragonWave kit uses?

<comment><USER7> Yeah, it's all licensed up there. We've got a license from OFCOM (UK's FCC equivalent) for the radio link.

</comment></comment></comment></comment><comment><USER8> FWIW opendns blocks your blog.emfcamp.org domain by default but the main domain is allowed. Couldn't really see why, usually it tells you a category it's blocked under but not this time.

<comment><USER9> I don't have it blocked by opendns and I have quite a few filters active on the network.

<comment><USER8> Apologies, i should have checked <http://www.opendns.com/support/cache/> \- was a local rule for tumblr.

</comment></comment></comment><comment><USER10> a hacker camp is such a great idea. they should check a few club mates so nobody has to sleep... <http://www.club-mate.de/>

(german drink - german homepage...)

<comment><USER11> Do not worry. The hackspace london peeps are fully aware of club-mate and usually have a few crates in the hackspace!

</comment></comment><comment><USER12> It would've been nice to have a setup like this at Bonnaroo. Or, perhaps, cell phone service.</comment>


Innovation in America: A gathering storm? - <AUTHOR> http://www.economist.com/business/displaystory.cfm?story_id=12637160 <comment><USER2> I was really glad this article didn't focus on how we need to allow more immigration. I think immigration is good, and helpful for our economy, but it isn't the primary driving factor for making us an innovative nation.

We should look at what in our nation is different from less innovative nations, and work to protect or extend those differences.

</comment><comment><USER3> As long as there is rewards to innovation there will be innovation. The coming shift left makes me nervous.

<comment><USER4> I think the reward will still be there.</comment></comment>


Show HN: IDE for Create React App - <AUTHOR> https://medium.com/@alex_pustovalov/getting-started-with-webcodesk-53ada5b0dc1c <comment><AUTHOR> I want to present to you a tool that I think may be useful in developing single-page apps.

If you are not comfortable reading articles in Medium, I will be happy to post the article where you will be able to read it.</comment>


Is the term "lifestyle business" an insult? - <AUTHOR> http://boss.blogs.nytimes.com/2011/01/24/is-the-term-lifestyle-business-an-insult/ <comment><USER2> I've had "lifestyle business" used as an insult to what I'm building, Predictobot.com. It was from a guy who takes lots of VC money, builds big startups with a direct sales force, and then eventually sells them to Oracle. (At least he sold his last one to them.) It didn't bother me in the least, as that's not what I aspire to.

<comment><USER3> Excellent sign-up page, it describes exactly what it is in a succinct sentence, and puts the (very good) pricing right in front of the visitor. It enticed me to sign up right away.

When you reach launch, I'd suggest putting some examples on the site so potential customers can see your capabilities in some depth.

Absolutely love the robot logo. I'd wear that t-shirt.

<comment><USER2> Thanks for the feedback. I'm giving the first demo of Predictobot on July 28th at PyData Boston, so the "live" site should be up around then. It has nice demos.

Glad you like the logo. It is by the most excellent Ty Wilkins ([http://www.tywilkins.com/](http://www.tywilkins.com/)).

Send me your mailing address and shirt size via email, and I'll send you a t-shirt, with my cool robot logo. My email in is profile.

(That applies to any of you other HN'ers out there that want a t-shirt.)

</comment></comment></comment><comment><USER4> I sometimes wonder if this isn't an insult uttered in a moment of jealousy. Like when the unachieving youngsters reasure themselves that their more successful counterparts may have better school grades or better chances of employment, but surely they have no life.

I currently work for something that may be called a "lifestyle business". I also did a lot of independent work. Got burned in a "serious business" twice, and it will be a long time before I touch one again.

The money isn't all that great, but it's not bad, either. I can literally afford pretty much anything I want, and my lifestyle isn't frugal. I can try a new, interesting wine at every dinner, if I feel fancy I can eat at a fancy restaurant and I travel a lot; not business class, but I don't really feel I need it, either, and the people I meet in a train are worth far more than a premium lunch. I have time for all my hobbies, I can go for a walk with my girlfriend any time I want, and I have a secure, healthy lifestyle. I have less money than a corporate employee, but I am a lot richer.

Quite frankly, I also found the working conditions to be a lot better. My first job in a large company was an utter failure due to the culture clash; I'd literally have nothing to do for weeks at a time while the corporate drones were stroking each other in the beginning of a project, and while many of my colleagues were at least competent programmers, most of them were utterly horrified of the idea of learning anything new (and this was actually a large, successful company, not some dotcom-boom crap). I had regular clashes with my superiors because I'd finish my tasks well before half the day was over, there was nothing else for me to do, but I couldn't go home, either (you can't log hours if you aren't there, can you?). The long decision chain, questionable technical competence in the upper layers and slow reaction, even when I only had just 2 or 3 hours of coding a day, I'd smoke through almost every task they had. Work would occasionally overcrowd before a deadline (though for some reason that only happened in the teams of _some_ of the managers -- always the same ones), but other than that, the challenge level was so low I was eager to get the hell out of there just so that I can do my job.

<comment><USER5> Shameless plug: I am working on a book on how to find and test ideas for lifestyle businesses. Target demographic: HN coders who want to quit their jobs and become patio11* :)

[http://howtofindsaasideas.com/](http://howtofindsaasideas.com/)

(Yes, I know the landing page sucks. New one will be rolled out shortly. If you run into any problems email me directly: email@example.com)

Would love any ideas and comments!

* I'm happy to let you know this SaaS demi-god has agreed to be interviewed in the book. Should be interesting.

<comment><USER6> FYI: the link in referral emails is broken ([http://wwww.howtofindsaasideas.com/](http://wwww.howtofindsaasideas.com/))

<comment><USER5> Trying to fix it but I think it may be a Launchrock issue.

</comment></comment></comment></comment><comment><USER7> I'm the founder of a firm that has had investors reach out from time-to-time and some do ask "Are you trying to build a big business or a lifestyle business?" In this context, "lifestyle biz" is absolutely a pejorative term.

The implications/sub-text of that question is:

1\. If you don't plan to take money, you're probably not thinking big, are not ambitious, etc

2\. You'll need capital and expertise (probably ours) to build a big business

What I've found is that the better investors tend to ask a different question "At what point, if any, would you think of raising capital?" This question gives the investor the same info without the insulting sub-text.

Related notes: \- Most tech M&A exits are less than <$100M. If you're playing the odds, a "lifestyle" business may be the way to go. [http://www.cbinsights.com/blog/acquisitions/tech-mergers- acq...](http://www.cbinsights.com/blog/acquisitions/tech-mergers-acquisitions- deals-2012-report)

\- Building a real business (revenue > costs) and growing it gives you more leverage with investors down the road should you want to go down that path. That's our plan. [http://www.cbinsights.com/team- blog/investors/](http://www.cbinsights.com/team-blog/investors/)

</comment><comment><USER8> Put simply: No, it's not.

If your primary goal in life is to accumulate as much money as possible, then you should try and get VC funding, and aim for the biggest exit possible in the shortest amount of time.

If your primary goal in life is to enjoy yourself and/or gain satisfaction from your work, you should try and optimise for happiness. This doesn't require millions of dollars; it simply requires a work arrangement that you are happy with and provides you with a sufficient income to fulfill your personal desires.

Different people have different goals in life, and there's nothing wrong with that.

<comment><USER9> There are lots of bootstrapped companies that make as much as funded companies do.

</comment></comment><comment><USER10> It certainly is to those who've drunk the pg kool-aid, aka "the only valid definition of a startup is a company that prioritizes growth above all else, including a viable business plan".

<comment><USER11> Only kids in their 20's drink. Know thyself. Think different.

</comment></comment><comment><USER9> It's often a veiled insult trickling down from the people who have some "lifestyle" themselves, which usually is delivered by people who like the startup speak and are busy not creating any real value for customers.

A truth maybe some don't want others to know is this: Your ability to create, pursue and have a deeper life benefits greatly from a modest financial engine.

I believe in working incredibly hard all the time. My ability to do so and pursue other ideas has been helped greatly by having a financial engine. Learning this balance every day has been invaluable to me.

There is a fair point in learning to focus on a few things. HN doesn't lack technical skills. It lacks business acumen and experience. Like coding, you learn to walk before you run, or pretend you're a star athlete from day one in business?

Every large business started small. There is no harm, or problem in learning to build a business into a success be it smaller or larger. Just pay attention to whether you stop after success, and if it's what you want. The same business building skills are needed when growing the big idea.

Most people who give up their 20's for something, will end up with just that, giving up their 20's and not much else. Not my opinion, but a stat that seems apparent. Think ahead, and there's a chance to get ahead.

Entrepreneurship is about about finding your path to customers. Everyone here is smart enough to put software or technology to work for them with just a little bit of their talent, focused.

If you build yourself a financial engine that can set you up and serve you, you'll be building the habits to do what you want well into your 30's and 40's when everyone else has to pack up and call it a day to pay the bills that never go away.

<comment><USER5> Checked your profile page and you seem to be doing some fascinating things with your company. Mind telling us more? :)

(Emailed you btw).

</comment></comment><comment><USER12> I don't know where the term came from, but I suspect it came from investors trying to come up with a euphemism for "not investable". If your'e a VC, a lifestyle business actually is a bad thing - it just doesn't work for them.

Where the train goes off the tracks is when entrepreneurs start using the term in a way that roughly translates to "script kiddie". That is just immature.

<comment><USER5> I'm thinking there might be a market for micro-investing in lifestyle businesses. Like Kiva for micropreneurs.

<comment><USER13> Now that's a great idea. Is it possible to route around enough of the SEC-or- local-equivalent regulations to make it viable?

</comment></comment></comment><comment><USER14> Its not inherently one, but it seems to be used that way by some people heavily invested (mentally or financially) in the VC-funded startup world.

</comment><comment><USER15> Not by itself, but there are certainly people who use it in a condescending manner.

</comment><comment><USER16> "You mean, am I interested in starting something with a decent balance or do I want to ride a flaming train-wreck with burning money flying off it into the black abyss?...

Oh, I said that last bit out loud, didn't I?"</comment>


How to Install Ubuntudde onto Your Machine - <AUTHOR> https://ubuntudde.com/blog/how-to-install-ubuntudde-onto-your-machine/ <comment><USER2> This has been true for years. Decades? That people are still surprised about it astounds me.</comment>


On Reddit, Digg and Hacker News - <AUTHOR> http://antoniocangiano.com/2008/05/29/random-thoughts-on-social-sites/ <comment><USER2> My elitist half couldn't agree more with this article, however my capitalist half recognizes commercial potential. That said, what I find more intriguing are the frequent social migrations that have occurred since Friendster. And I believe many social sites are over-valued and over-hyped (signs of a web 2.0 bust?) given the fickle loyalty of internet-social-bees.

That said, the rise of me-too .com hives give others the opportunity to improve, but are they really making significant strides in innovation that are lasting and unique? For example, Digg significantly improved an old concept from the early 00's known at 'top sites' by shifting focus to relevant content as oppose to site-specific. But, what have followers of the Digg model offered besides servicing a niche audience?

When this same me-too trend happened in web 1.0, funding dried up for a few years while the internet cleansed itself...

</comment><comment><USER3> What's wrong with Italy?

</comment><comment><USER4> sorry but that format is not interesting to me. bullet points, headlines, something needs to be in there for me. just my opinion.

<comment><AUTHOR> It was meant to be an essay, although it admittedly came out not as poignant nor as convincing as I wanted.

<comment><USER5> I thought it was a rather nice read. It was refreshing to have a little bit of story telling along the lines of a personal experience instead of some quick snippets of facts and opinions mashed up together.</comment></comment></comment>


Making a Ransomware Payment May Now Violate U.S. Sanctions - <AUTHOR> https://www.bleepingcomputer.com/news/security/making-a-ransomware-payment-it-may-now-violate-us-sanctions/ <comment><USER2> Ramsomware (like any ransom) is a typical "tragedy of the commons" situation.

To pay is beneficial for yourself, as you get your data back that is more valuable than the amount of money that you pay.

Society losses as a whole as you are incentivizing their business model. But, you bet that it will not happen to yourself again.

> With the rise of ransomware, we have also seen a rise in data recovery > companies who claim that they are able to recover ransomware victim's files > for a fee. It has long been suspected that these companies are not actually > using any home grown techniques to recover victim's files, but are > negotiating with the ransomware developers and simply paying the ransom on > your behalf while tacking on a fee for their work.

And it makes sense. As it can become a big business.

Forbid the payment of ransoms and society is better-off as a whole. Even that some victims are going to be in a worse situation.

<comment> m-p-3 Cutting the financial supply to those who benefits from ransomware is the logical choice to move complacent businesses to properly secure their data and ensure proper backups.

If the data was valuable to start with, it should be backed up. Ransomware is just another cause of data loss, among with hardware failure, theft, etc.</comment></comment>


Chatterfall – Anonymous Real-Time Location-Based Messages - <AUTHOR> http://www.chatterfall.com

<comment><AUTHOR> This is something ive been working on in my spare time on and off for about 6 months. Mostly PHP and node.js.</comment>


Alleged NiceHash hacker's wallet: who's sending BTC to it and why? - <AUTHOR> https://bitinfocharts.com/bitcoin/address/1EnJHhq8Jq8vDuZA5ahVh6H4t6jh1mB4rq <comment><AUTHOR> I noticed the recent micro transactions (0.0001 BTC) into the wallet, following the alleged heist. Any ideas?</comment>


Star Wars Awakens Trailer Takes Down All Theater Websites - <AUTHOR> Looks like all major cinema websites are down due to Force Awakens trailer.
AMC Cinemark Fandango Regal
Anyone else having any luck? <comment><USER2> Alamo Drafthouse showed me a cached page from CloudFlare one time, an error page another time, and a Star Wars specific site another time but part of it ("ticket droid") was still loading.</comment>


Covid-19: is working from home the new normal? [video] - vanilla-almond https://www.youtube.com/watch?v=MxDVucUZCnc <comment><AUTHOR> I must be Abby-Normal because I still work in an office. Somebody in $Company has to. Otherwise why even have an office.</comment>


Unlikely hit app Yo is 'hacked' by students - <AUTHOR> http://www.bbc.co.uk/news/technology-27939799 <comment><USER2> I'm puzzled when new, "innovative" (well, in some sense) apps such as this get hit by simple hacks such as this one. I was puzzled as well when some idiotic misuse of encryption exposed WhatsApp data (I'm not sure if I remember correctly, but that was the gist of it). Startups bear a distinct culture around them, and for me at least it means very capable hackers behind them. But I would seldom consider anyone who'd commit such fundamental security no- nos a "capable hacker".

But, after all, this Yo thingy doesn't even look like a real startup.

<comment><USER3> I think its the size of the burden. If you're creating a thing from scratch and are responsible for pretty much every single aspect of it from dev to sysadmin PLUS you have CTO responsibilities on top of that you just lose track of stuff and make the odd mistake.

"I'll fix that a bit later" becomes "I have no idea what code is there anymore nor even the time to contemplate it".

Perhaps.

</comment></comment><comment><USER4> It's a data leak...very similar to snapchat's issue and the Apple iPad fiasco found by weev. It's pretty sad that an App with almost no functionality had any problem.

It's also interesting how these developers seem to repeat this exact mistake over and over. I don't understand how people don't see a public facing API call for mapping usernames to phonenumbers or phonenumbers to usernames as a bad idea...

<comment><USER5> Because security is not easy. Often when I ask these questions the responses range from not being worth bothering with because we still shop at Target, even though they've been hit, to just dealing with a breach after the fact, rather than being a little more proactive about it.

E.g. [https://news.ycombinator.com/item?id=7920558](https://news.ycombinator.com/item?id=7920558)

Like I said, security is hard. Microsoft is the only large corporate I know of with a published security development lifecycle, and while it's starting to benefit their products they're still not getting it 100% either. Security is also contentious, because doing it right means forsaking the idea of an MVP. It also requires design up front. And experience. These sorts of things are not exactly aligned with the hacker mindset, nor with startup culture.

<comment><USER4> Absolutely security is hard...and it's also not what `Yo' is really worried about. If they have to worry about security, then they already hit it big and they can just fix the issue ex post leako.

<comment><USER6> On the one hand, 'Yo' was created in a day. Though maybe the author should've spent say a week on it.

On the other, it's been proven possible to ignore or botch security until you have to make a minor show of apologizing for it, without fear of consequence, if you've already gotten enough traction. Unfortunately, this only seems to prove to businesses that security is a fruitless endeavor, and a waste of effort better spent making sure the UI is shinier. On the third, i've had to explain to people and their startups that SQL injection and XSS even _exists_ , much less that it's a problem worth dealing with _now_ so there might also be an education issue.

I think the answer would probably be more things which are secure out of the box. In particular, frameworks and the languages themselves (I'm looking at you PHP) which interface with the web should default to secure as much as possible.

</comment></comment></comment></comment><comment><USER7> The Game of Thrones producers should release a competing app called 'Hodor'.

</comment><comment><USER8> 'Yo' reminds me to Woof, [https://www.youtube.com/watch?v=8wfG8ngFvPk](https://www.youtube.com/watch?v=8wfG8ngFvPk)

</comment><comment><USER9> Because the app has very little purpose, its obvious why it exists at all: It enables the collection of networked data. But because it was built in 8 hours, you get what you put into it.

"built in 8 hours", "does basically nothing" but here, ping people through it and allow us to map this activity to your phone number and user name.

So when this data leaks, everyone gets puzzled. Are we conflating the importance of the data with the importance of the app?

</comment><comment><USER10> Discussion from when this happened a few days ago: [https://news.ycombinator.com/item?id=7920023](https://news.ycombinator.com/item?id=7920023)</comment>


iTunes Gift Cards Usable Towards Products Now - <AUTHOR> https://www.apple.com/shop/gift-cards <comment><USER2> It's always been annoying to have two separate gift cards for different types of Apple products (iTunes store vs. Apple store). I always assumed it was for some sort of accounting reason.

That being said, I once got an Apple electronic gift card, which I was able to convert into an iTunes gift card. It take calling up the Apple store online, which then needed a transfer to iTunes store support. But the on-hold time was minimal, and it was easy to get to a person. They had me provide the gift card info, along with proof of how I got it, via email. (I think it was for fraud prevention.) A day later, I got my iTunes electronic gift card.

So although it was possible to convert one to the other, it's really nice to know that won't be necessary now!</comment>


An immutable operating system - <AUTHOR> http://augustl.com/blog/2014/an_immutable_operating_system/ <comment><USER4> I wrote an operating system in a purely functional dialect of Lisp; [http://losak.sf.net](http://losak.sf.net)

There are a few things I learned in the process that I think are relevant here:

1\. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant that gives you just that; no pauses due to reclaiming free memory. The downside with reference counting is that it doesn't work with cycles in heap-allocated memory, but if your data is all immutable then you can prevent cycles from being created in the first place.

2\. Treat mutable memory as a form of I/O. Even if you just want to use memory mapped I/O, you will need some way to read and write to (some portion of) memory. Set aside a fixed block of memory (say, for instance, the first 10 MB), and only allow that memory to be read and written in an imperative fashion. Keep the managed heap completely separate from that mutable block, and don't allow any direct access to the managed memory.

3\. You can actually perform preemptive multitasking entirely at compile time (or at program load time for apps not included when you build a binary for your OS). I've done this for both my OS and for Scheme ([https://github.com/ojarjur/multischeme](https://github.com/ojarjur/multischeme)). It works extremely well and winds up being much faster than using the native primitives usually used for building multitasking support. For more details on exactly how to do it see the link to my Scheme implementation.

4\. The biggest difficulty the author will hit, and the most likely cause for performance issues, will be in code generation. Since the proposal is for a new bytecode, the author will have to implement their own interpreter and/or JIT compiler for it, and writing an efficient one is an extremely large chunk of work. I've built an operating system and a programming language, and the language is by far the harder project. This is why I went from working on a new OS written in a new language to re-implementing my compile-time multitasking technique for Scheme; it allows me to take advantage of all of the hard work people have done to make compilers for that language which produce fast code.

<comment><USER5> Author here. The language is the part I also dread the most, and is also the part that will be the least unique and the least interesting to "re-invent".. I'll look into finding an existing language that runs on bare metal and that has (or supports) immutable values.

<comment><USER6> Haskell

<comment><USER7> There's actually been a bit of work on this very idea!

[http://programatica.cs.pdx.edu/House/](http://programatica.cs.pdx.edu/House/)

<comment><AUTHOR> funny sidenote, one of House dev (Jeremey Bobbio) had a talk at FOSDEM2014 about reproducible builds for debian, similar to Nix (also immutable in spirit) I believe.

[https://fosdem.org/2014/schedule/event/reproducibledebian/](https://fosdem.org/2014/schedule/event/reproducibledebian/)

</comment></comment></comment></comment></comment><comment><USER8> I gave an un-conference talk at Clojure days Amsterdam called "Purely Functional OS" on this exact topic and we had an incredibly interesting discussion about the topic.

The conclusion we kept coming back to is that it's technically not all that difficult to implement, but that to make it usable in the real world would mean that computers would have to get a lot more cautious about source vs. derived data.

The main thing is that on the one hand it seems pretty feasible to store all _meaningful data_ a user generates over the course of using a computer and building an immutable persistent OS on top of that.

On the other hand though, when you think about doing this in the context of an actual computer as in use today you will very quickly run out of storage space.

What is separating these two scenarios is that a _lot_ of data is (deterministically) derived from source inputs, but in the current state of technology it's impossible to determine what is _derived_ data which can be easily recomputed and what is _essential_ data without which the current state could not be reached.

I happened to just be reading this article on unikernels which coincidentally is something that would help get us a bit further along in that direction: [http://queue.acm.org/detail.cfm?id=2566628](http://queue.acm.org/detail.cfm?id=2566628)

P.S. When thinking about this one key concept is to realize that you could can do things like implement a 'torrent file system' where a file is just a torrent hash which can be requested and signal when (parts of it) become available.

<comment><USER9> _in the current state of technology it 's impossible to determine what is derived data that can be easily recomputed and what is essential data without which the current state could not be recomputable._

Can you elaborate more on that statement? I see it as an expensive problem, but not impossible.

If you have a completely deterministic VM/instruction set, you can recompute any function output from any set of inputs. If you have non-deterministic input (network, input devices, randomness, etc) you can store those inputs to replay at a later time.

I don't know if it's _always_ necessary to store non-derived data. Do you need to save all keystrokes? All mouse moves? All network packets? Probably not. If those network packets just result in displaying a graph on the screen, they can probably be thrown away. Maybe you can throw away the headers and just compute based on the packet data. Or maybe you can simply store the fact that a stream of data that matches a cryptographic hash was received. It depends on what function receives that non-derived data.

So I think the difficulty would be designing a system that would isolate derived data and replayable/recomputable/refetchable data, and the processes that compute that data -- and do so with reasonable efficiency. I think this could be done at the process level rather than the instruction set level (though you would have to have a restricted instruction set -- i.e. limited floating-point).

<comment><USER8> At the process level there are already plenty of programs that work this way and it's exactly the kind of thing the Clojure ecosystem is geared towards.

That's why the Purely Functional OS is essentially a thought experiment in what it would take to extend this to the entire operating system.

When I said "impossible given the current state of technology" I meant exactly what you said in your last paragraph though: impossible without designing an OS that isolates derived data.

I believe such a system will come in the form of persistent data structures coupled with reactive programming but, while I believe it's inevitable in the long run, extending that concept all the way to the OS will be quite the challenge.

</comment></comment></comment><comment><USER10> _A garbage collector that knows that all values are immutable will be rather interesting, I think. Typically, a garbage collector will stop the world (i.e. halt execution) to do heap defragmentation of the old generation. When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value._

This might actually have significant performance benefits. When everything is immutable, GC can also be inherently incremental. You just do your defrag copy faster than new object creation. Then you cam limit your stop-the-world to a small "catch-up" so your copy-from can become a copy-to. Incremental GC nirvana!

<comment><USER11> I don't see how immutability makes much difference to garbage collection. Garbage collectors don't look at the value inside memory they are collecting, only whether something live is still retaining that part of memory. Whether the value is mutable or immutable has absolutely no bearing on the performance or logic of the GC. Either something is still using the memory, or it is free to collect.

Also you've just described existing GC systems - The Java G1 collector is very similar that (it's a lot more complicated though).

<comment><USER12> Generational GC usually depends on write barriers to detect creation of references to newer generations inside older generations.

Immutability prevents the mutation of older generations, so no new references can occur.

So I expect generational GC to be easier to implement. I wouldn't expect it to be faster or slower though, because programs will need to be written differently to cope with the limitations on mutability. O(1) algorithms will likely be replaced by O(log(n)).

<comment><USER10> In the case of Clojure, log is log base 32, so it's close enough to O(1) as to make no difference in most circumstances.

<comment><USER12> Many immutable algorithms replace arrays with trees. Trees are pointer-heavy, and pointers are less cache-friendly than arrays.

Memory access is often over 100x the cost of an L1 cache hit. It doesn't take too many of those to make a big difference if you're CPU bound.

My comments are general, I'm sure Clojure has access to arrays where necessary for interop at least.

<comment><USER10> Again, true, but the big problem I'm facing isn't raw performance so much as it's guaranteed latency.

</comment></comment></comment></comment></comment></comment><comment><USER13> I don't really know how feasible this is without pretty significant performance impact (esp. memory usage), but as a research project, it sounds fascinating. Go for it.

<comment><USER14> > don't really know how feasible this is

And I suspect neither does the author. I looked at the previous project (OpenGL Renderer) which comes in at 250 lines of code and barely any functionality. The current project is has no code at all.

I'm all for sharing ideas, but this is somewhat lacking. The design document touches on the memory model, but ignores all the other problems an OS has to solve (scheduling, networking, disk IO...).

<comment><USER15> The author could focus on an existing embedded RTOS and fork from there. Enough cherries to pick one.

<comment><USER14> But is he going to find one that follows his "all has to be immutable" approach? I somewhat doubt it. Do you know of any existing OS that works like what the author describes?

<comment><USER15> The reason I posted the idea was to start with a system that is working and where you can forego the filesystem and other parts that are typically found on a full blown OS. It's not uncommon for an RTOS to dismiss the GC and leave it to the programmer.

For example, there are discussions in the RTOS world to take a closer look at Rust (Google embedded Rust) which is why the terms "new OS", "GC" and "experimental" triggered my response to look over there for a starting point.

</comment></comment></comment></comment></comment><comment><USER16> Why make the system language a Lisp instead of a language that is by default immutable? I'd think Haskell is a shoe in for something like this and you'd have a head start with House: [http://en.wikipedia.org/wiki/House_(operating_system)](http://en.wikipedia.org/wiki/House_\(operating_system\))

<comment><USER5> Personally I'm more of a fan of immutability than purity, which is why I haven't considered haskell. As mentioned in the post, though, I'm not sure if the language should be static or dynamic or something else.. And I don't really want to invent my own language either. Food for thought :)

<comment><USER17> Pure functions would let many of your functions become immutable :)

EDIT: Well... not really I guess. But idempotence has similar properties I think.

</comment></comment></comment><comment><USER18> Just curious have you started looking into some of the LISP machines of old? You might be able to get a head start by studying their structure (and of course their decisions):

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

<comment><USER19> There are definitely interesting things there, but fwiw Lisp machines weren't based on immutable data structures. Common Lisp in general has an ethos of being multiparadigm and using imperative updates whenever convenient or performant. Functional constructs are probably used more than in C-like languages, but not exclusively, and are probably a minority approach in "production" Common Lisp. That's one place where Clojure differs quite a bit from CL; it sort of combines the "Schemey" preference for functional style, non-destructive functions, recursion, etc., with the CL ambition of a "batteries included" library and industrial-strength tooling.

However if you look at the first-order similarity as not being immutable data structures, but instead the idea of an OS entirely built within a managed runtime, the Lisp Machines and Microsoft's Singularity OS (C#) are two interesting examples.

<comment><USER5> Op here, thanks to both of you :) I would very much like to expand prior art to more than just Linux and Clojure.

</comment></comment></comment><comment><USER20> Related, a purely functional package manager, Nix, and a Linux distribution based around it: [http://nixos.org/nix/](http://nixos.org/nix/)

<comment><AUTHOR> I see a number of projects sharing similar traits:

      - <USER2>
      - btrfs,zfs
      - <USER3>
      - persistent datastructures (cons cells, fp trees)
      - nix package management, virtualenv, containers
      - react/pedestal (pushing ux delta upgrades)

<comment><USER21> Mutability/immutability goes pretty deep philosophically... all of those projects are basically built on persistent data structures, but persistent data structures can be seen as just one type of "making time explicit". In other words, with mutability, a variable (or data structure) takes different values at different times, while with immutability, you can still have time but you name each version through time explicitly. (Values vs. variables, etc.) Same concept exists in e.g. single static assignment (SSA) in compiler IR, or register renaming in high-performance processor design... pretty powerful concept.

<comment><USER22> As an aside: I'm pretty mind blown that I've never once considered immutability as "making time explicit". That's an extremely apt comparison.

</comment></comment></comment></comment><comment><USER23> An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.

<comment><USER24> Sometimes 'toy of professors' (research) is the point.

Not everything has to run a social network and not everyone is working on a twitter clone.

<comment><USER25> Isn't Twitter written in Scala, a programming language designed with immutability in mind?

<comment><USER26> Yes, but his comment was about an OS needing to be pragmatic and designed with performance in mind (which Scala was), not about it not being immutable.

</comment></comment></comment></comment><comment><USER27> Awesome! You should have a look at Urbit: [http://www.urbit.org/](http://www.urbit.org/)

<comment><USER28> There appears to be no "About" on that site. Who knows what on earth it is?

On the left sidebar, the "documentation" link is to a video. No thanks, I'm look for a sentence of text.

The next link down is a 404 error.

The community link is for insiders...lots of comments about people leaving the building,whatever that means.

Bottom of page, how to install. Why am I installing something when I don't know what it is?

Sites that expect you to already know what they are about, and do not deign to give so much as a sentence of explanation, are extraordinarily frustrating.

<comment><USER29> Sorry our site sucks. We released accidentally and are more or less in "semi- stealth mode." You probably shouldn't be interested yet. Unless you like playing with semi-broken stuff. When it's not broken we'll let you know.

Urbit is indeed a purely functional OS, not super dissimilar to the OP's project. And it works at least well enough to run a chat server on its own network (which generated all those logs with "leaves the building"). But we ship no code before its time and we probably shouldn't even have a site up.

You'll enjoy the video though - it has good music, at least.

<comment><USER28> That's fine -- but _please_ add an "About" link that says what "urbit" is.

That lack of explanation, that expectation of speaking to insiders, is unfortunately very common on web sites, not just yours.

Please add the About explanation even if you decide to take the site offline. At least that way, it will already be ready, later, when the project is further along.

I was just reading about the defunct House functional OS yesterday, coincidentally, so I'm interested in the general topic.

<comment><USER29> Thanks again for the advice.

Do you have a link to House? I wish people naming projects would realize that the Internet is dead and all we have is the Googlenet...

<comment><USER28> I totally agree, it's sad when interesting links die, and it's sad when a search term is extremely generic.

Here's what I've got, pasted out of my notes:

House has been successfully implemented in Haskell, I'd assume that Haskell would fit your criteria. Admittedly, House is an experimental OS, rather than production one. But they have managed to implement everything from kernel though network stack, to a rudimentary GUI. [link broken, see search results below] 2005 [http://lambda-the-ultimate.org/node/943](http://lambda-the- ultimate.org/node/943)

House is a demo of software written in Haskell, running in a standalone environment. It is a system than can serve as a platform for exploring various ideas relating to low-level and system-level programming in a high-level functional language. More details are available in our ICFP 2005 paper: A Principled Approach to Operating System Construction in Haskell. [http://ogi.altocumulus.org/~hallgren/ICFP2005/](http://ogi.altocumulus.org/~hallgren/ICFP2005/) [http://programatica.cs.pdx.edu/House/](http://programatica.cs.pdx.edu/House/)

terse wikipedia article on House [http://en.wikipedia.org/wiki/House_(operating_system)](http://en.wikipedia.org/wiki/House_\(operating_system\))

short LTU thread on functional systems programming [http://lambda-the- ultimate.org/node/943](http://lambda-the-ultimate.org/node/943)

...oh, also there's a book, "Unix System Programming with Standard ML" by Anthony L. Shipman 2001

Was free online, link is broken, available via archive.org:

[http://web.archive.org/web/20040531113417/web.access.net.au/...](http://web.archive.org/web/20040531113417/web.access.net.au/felixadv/files/output/index.html) [http://web.archive.org/web/20040531113417/web.access.net.au/...](http://web.archive.org/web/20040531113417/web.access.net.au/felixadv/files/output/sysprogsml.pdf)

I just found that, have not read it.

<comment><USER29> House is an OS in a very different sense than Urbit - the "boots on bare metal" sense. The core of House is a monad which represents the hardware state of a common Intel box.

Urbit is intended to run virtually in the cloud and is an OS only in the sense of "stores your data and runs arbitrary programs". As a cloud computer its "function" is simply (old state, packet in) -> (new state, packets out). For communicating with the host OS this generalizes to "event in" and "actions out." Eg, I got an HTTP connection so I send an HTTP response. So not only isn't it done, it isn't even very smart... but it is a function and it is an OS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> Sort of a sidebar: The term "atom" doesn't seem to have the same meaning in all languages.

Atoms in Clojure are reference types, and they are mutable in a controlled way (they can be changed to refer to another immutable value).

In Erlang, an "atom" doesn't refer an immutable value, it _is_ the immutable value. An Erlang atom by definition cannot ever be any other value.

</comment><comment><USER31> I'm not sure how this would look very different from current pure functional languages. Think about programming in Haskell. Everything is immutable but you can compile down to machine level binaries. So at some point the programmer is presented with an abstract immutable model and under the hood some runtime does real pointer arithmetic and all. Even garbage collectors could be optimized already for knowing that the programmer has no knowledge of memory locations.

If this kind of OS encourages hardware changes, that's one thing. But aside from performance, it probably won't look too different from current FP languages.

<comment><USER13> He's not designing a language; he's designing an operating system.

<comment><USER7> The GHC RTS (used in most Haskell programs) is practically a mini-operating system already.

</comment></comment></comment><comment><USER32> I haven't written any Clojure, but I have written a good bit of Erlang. My understanding of the Erlang Virtual Machine tells me that it solves a lot of the problems you describe regarding immutable data. For example, per-process garbage collection due to immutability, message passing via copying data, etc.

I think you would be well-served to experiment with and learn some Erlang to help inform your design. In fact, Erlang often feels to me like an operating system due to the independence of processes (and the multitude of tools built on top of it, but that's not directly relevant here). I've often dreamt of an Erlang Machine like the Lisp Machines of the past.

As an aside, Erlang's primary goal is fault-tolerance. It's other properties, such as immutable data, message passing, and functional properties were all design decisions made to achieve this goal. My point is that your OS could be very well suited to fault-tolerant systems.

<comment><USER5> I'm an Erlang noob, but afail the model is pretty different. I'm imagining a shared-everything system, where immutable values are freely passed around with no copying. Erlang is more of a shared-nothing system. Also, Erlang requires multiple machines to shine, but an OS is more about managing one machine.

I do think message passing have a bright future, though, and my OS will not work at all in a shared-nothing manycore system..

<comment><USER32> I see. You are correct, Erlang definitely falls on the shared-nothing side if you ignore some uses of ETS and ref-counted binaries (binaries above 64 bytes, I believe).

I disagree with the statement "Erlang requires multiple machines to shine," but my motivations, and my definition of "shine," are likely different from yours. Erlang only _requires_ >1 machines if you are creating a system with proper fault-tolerance. In my opinion, it has good SMP support and it performs well for general-purpose applications. You wouldn't use it to implement matrix multiplication, though :)

Anyway, the gist of my post is that the lessons learned from writing Erlang programs might be useful in your work.

Good luck! I look forward to hearing about your progress.

<comment><USER5> I once skimmed Armstrong's dissertation, it was mentioned how the JVM is bad for fault tolerance, because it's possible for a run-away thread to break the entire VM. Apparently, the Erlang VM manages isolation better, in such a way that it's impossible for one process to take down the entire system. That is definitely something I want to bring along to this OS :) I'm toying a lot with Erlang these days, to ensure Clojure and Linux isn't the only prior art..

And you're right, "shine" is a generalization, I actually had fault tolerance in mind when I wrote that.

</comment></comment></comment></comment><comment><USER33> _But garbage collected memory of immutable values and atoms, in hardware?_

Hardware transactional memory might help here. [http://en.wikipedia.org/wiki/Transactional_memory#HWIMPLEMEN...](http://en.wikipedia.org/wiki/Transactional_memory#HWIMPLEMENTATION)

</comment><comment><USER34> This idea reminds me of what Go is doing with their channels to solve concurrency issues: they're essentially sharing data by copying the data.

Copying data is slow and that's why Go's channels aren't the fastest solution, but they're less complex than dealing with the traditional concurrency issues.

I've written a toy kernel and I just can't imagine copying all process data because 1 little thing changed. However, there's no reason not to pursue this idea, as it may prove to be useful in certain cases. If real-time schedulers have their place, why wouldn't such an OS have its uses? I think Go (and other projects) have proved the concept works, so maybe it's time to see an OS?

Best of luck to you and I hope to hear good news in the future!

<comment><USER35> > they're essentially sharing data by copying the data.

No. Go only copies the immediate values, if you send a pointer the pointee is shared for instance. Go's concurrency is shared-memory.

Erlang copies (almost[0]) the data sent between processes, and has process- local heaps.

[0] binaries above 64 bytes (IIRC) are refcounted and shared.

</comment></comment><comment><USER36> I've always been baffled by Clojure's view on state. It seems like just a rename of the concepts present in most languages today. Ie atom is mutable variable and value is an immutable value. What's the novelty here?

<comment><USER37> The sole fact that one has to reach over themselves and make a great deal to invoke it when thinking within Clojure's mechanics - they become neither cheap to mentally fiddle around with, nor actually implement within.

(FWIW, though, Clojure's novelty to me was an STM system that I could get up and running without a night's worth of tweaking, and otherwise fall safely into a great deal of attention if something were to go hilariously wrong - most of the other solutions around "back then" seemed to regard themselves as research curios lagging behind in fit and finish.)

</comment></comment><comment><USER38> You mention that one of the benefits would be that memory can be shared across processes without any defensive copying or protection semantics, but isn't the entire idea that immutable values _are_ a special type of defensive copying and protection semantic?

I imagine that this would be useful if doing many calculations on readonly values, but would take a performance hit for readwrite operations.

I'm not one for purely functional programming, but this seems like an interesting concept. I'm interested to see where it goes

<comment><USER5> Interesting definition of immutable values, and a valid one. My perspective is different. An immutable value has a value add more than that of avoiding defensive copying, such as structural sharing. When you add a key to an immutable map, the new map can point to the old.

It has become more and more common to model systems with append-only as the only form of write (Event Store, Datomic), so readwrite can probably be avoided in some cases. And things like IP packets certainly makes sense to represent immutably - anything else is a bit of a lie :) But there is certainly a risk that the trafeoff of immutabulity becomes too costly for an OS..

Also, the system language will not be pure, like Haskell. Just immutable values, like Clojure :)

</comment></comment><comment><USER39> Maybe consider Fressian for EDN-like bytecode format...

<comment><USER5> Ah, thanks. When I said EDN, I meant Fressian :)

</comment></comment><comment><USER40> I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the advantage of abstracting the hardware as sth. without a state?

</comment><comment><USER40> I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the purpose of abstracting the hardware as sth. without a state?

</comment><comment><USER40> I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the purpose of abstracting the hardware as sth. without a state?

</comment><comment><USER41> Is there a list of research / alternative operating systems anywhere?

I don't know how an OS would qualify to get on the list other than not DOS, Windows, OSX (or any of the Apple OSs), Linux (especially not 'ubuntu with a different DE'), or the BSDs (i guess there are exceptions if they're on a toaster).

<comment><USER42> I was making a list of a few I knew, but it would be better to just check wikipedia: [https://en.wikipedia.org/wiki/Comparison_of_operating_system...](https://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels)

Those are more serious kernels I think. There are also a ton of research- related kernels. I guess you can find a few for some programming languages.

</comment></comment><comment><USER43> We already have a purely functional linux distro that is immutable and stateless, called NixOS

</comment><comment><USER44> 'Clojure has transients, which basically means "inside this function, use a mutable value under the hood while building up the value, but make it immutable before it's returned"' is this essentially a ... closure?

<comment><USER5> Transients in Clojure is an added feature to the built in immutable values. Essentialy, they are immutable. But Clojure does have mutable-ish versions you can use to build up a semi mutable transient, and when you're done, convert it into an immutable value before it's returned.

The key is to make it fast. Mutable -> immutable is not an O(N) copy.

</comment></comment><comment><USER45> Can someone tell me where I can find a primer on immutable vs mutable, state etc? I have tried to piece together an understanding from wikipedia etc but I'm not really "getting" it.

</comment><comment><USER46> So how do you load this into a VM?

<comment><USER5> The makefile builds a virtualbox image. But it doesn't do anything interesting yet. I didn't submit to HN, the project is a long way away from being demoable and testable.

</comment></comment><comment><USER47> how would a user interact with such a system?</comment>