Work, Life And Side Projects - <AUTHOR> http://www.smashingmagazine.com/2012/06/19/work-life-and-side-projects/ <comment><USER2> I think there is no long term solution to this if you already have a family (with children to care about): Day job, side project, family: it is too much, at least one of them will suffer. I don't see this as something that can be balanced, I see it as a temporary state. For me the long-term goal is to eliminate the day job by making enough money from the side-product.

<comment><USER3> If only one suffered, that would be optimal. In my experience what ended up happening is all suffered. In noticing that one part of my life was starting to falter I would soon over compensate. What would happen is a juggling act, that ends with total burnout. In the mean time you disappoint a lot of people.

Side-projects are good, but you have to be careful about it.

<comment><USER4> The better way to describe it would probably be at LEAST one will suffer. Obviously if mishandled it can get even worse.

</comment></comment></comment><comment><USER5> In the past 10 years I was able to support my side-projects (see profile) and family life (we have 2 years old) by not having a day job, but instead carefully choosing freelance projects. Here's how it works:

Freelancing allows me the flexibility to dedicate pockets of time to side- projects that require a push. I simply don't book myself of 3-4 weeks if I know I need the time for a side project. This allows these side-projects to organically flourish rather than wither in the long term. If and when any of these projects become a source of income, I can easily turn my attention to it without having to change my lifestyle.

Regardless of their monetary success (some of my projects are not meant to be products at all), I've noticed that they act as magnets towards the kind of freelancing jobs I'd like to take. This creates a positive feedback loop, as the freelancing gigs often help me push forward at least one of the side projects (code wise or knowledge of the domain).

Overal, the trick is to keep your projects (paid or not) within your core curiosity-zone. If you're just starting out, the mission is to get closer to this zone with every new freelance gig. The end result is that enjoy both the side projets and my freelancing gigs. The line between them blurs more and more every-day.

</comment><comment><USER6> What are good side projects? I get this "cool stuff that I don't get to do at work" idea, but I think it's vitally important to have side projects that have a different gratification profile than one's main work. If you work as a developer of any kind, most work will be on massive projects spanning at least months, often years. For a side project to be fun, I think its important to have a different pace. For example trying out a new technology and doing some cool hack quickly, in a few hours, rather than "doing it right" slowly and meticulously. Maybe side projects should be mainly about learning or trying out things rather than doing things, exploration not exploitation of existing skills.

<comment><USER7> A good side project is anything you think it is. The most important aspect is that it must keep _you_ engaged, whereas a project at work has to be profitable as its primary aspect.

The "gratification profile" should be what works best for you and your personality and what you need to accomplish. If your side project is building a boat to cross Lake Superior, then it's fine if it takes years to complete. If it's automating your garage door to open when your car arrives, it might be done in a weekend.

The point of the project is that it should be about _you_. What _you_ want to do, on _your_ terms, at _your_ pace. Otherwise, you might as well just get a second job.

</comment></comment><comment><USER8> I recently struggled with balancing these three. When my ex-girlfriend started a mandatory "no computer Sundays", I knew something had to change. Here's what has been working for me: get up early. I wake up at 5am, have a few hours to work on side projects or freelance work, and then I head into work at 8am. After work, I don't touch a computer until the next morning. It's been just over a month and I'm loving the results.

<comment><USER9> I did the exact same while working full time and am trying to do the same as a freelancer now.

What I've found is that no matter how early I wake up I have about eight hours in me and then I lose the ability to focus. I have a feeling exercise and a better diet might help.

Don't get me wrong though, having an ultra productive 4 hours before 10am is awesome, and clocking off at 14:00 to read, play with my arduino or do other things is pretty good too. For me at least though it hasn't magically added any extra hard-focus time to the day.

<comment><USER8> Diet has made a huge difference in maintaining my energy levels throughout the day. In the morning I make a vegetable + fruit smoothie, lunch I usually eat plain chili or some form of meat and vegetables. I try to reserve carbs for before/after exercise.

On days when I splurge and eat pizza or some heavy carbs for lunch, I usually crash pretty hard around 2pm. That's why I save lunch beers for Fridays only! :)

</comment></comment></comment><comment><USER10> My solution has been to make my "side projects" my entire work. People often ask me.. "so, uh, you actually do this as your job?" because most of my projects look like frivolous side projects that I love and enjoy almost like hobbies, even the ones that bring in the money. (The annoying hidden part to this tale is it took having a significant "runway" in the bank to be brave enough to try this idea out..)

I've turned down some interesting jobs lately because I thought they wouldn't pay well or they wouldn't offer enough autonomy.. but this post has made me realize it's just because I don't want "a job," there'd be no time left over for "side projects"! :-)

</comment><comment><USER11> For the last two years, I have been trying, on and off, to develop a few ideas into maturity. You can call these my side projects. I started out, thinking that taking 5-6 hours out from my weekends and a couple of hours per weekday, would do the job.

My day job is quite demanding in terms of hours and energy that I put in.

After around one year of trying hard to perform well in my day job, keep on developing my side projects and have a decent social life, I gave up. It was not working out. Time and again, I found myself, totally tired mentally and physically.

I couldn't understand what was it that I was doing wrong. Then time and again, I would hear stories of people who were successfully juggling day-job, side- projects and family life. I just did not get it and still don't.

Is there some kind of strategy that you have to follow? Is my time-management not good enough? Is something missing in my attitude? Or is it just plain luck, that things work out sometimes and other times they don't.

<comment><USER12> My advice is keep the side project small and only work on one at a time. We often spread ourselves too thin and try and undertake something too big. If we cannot see fast results we become demoralised.

</comment></comment><comment><USER13> Take it from someone who has been doing this for some years now. I have 3 side projects. A job a girfriend and a son.

It is entirely possible but entirely depending on your spouse and on how much you are prepared to sacrifice.

I even took it up a notch and moved to the other side of the Atlantic.

Relying on Skype, Pair and monthly visits. Suffice to say it's not easy and not without it's challenges. But if you have a great spouse and are very clear on what the goal of you doing what you are doing is. Then it's possible.

<comment><USER14> The article is about developing a stable balance between family, work and side projects- how does monthly visits to your son create as a good balance? It sounds more like a temporarily tolerated situation rather than something feasible (or desireable) long term.

<comment><USER13> This is long term and this is the only way to combine two people with equal ambitions and unfortunately opportunities on two different continents.

Before that (up until a month ago) I was with them every day.

My point is that unless your spouse is in on it then it's never going to work.

<comment><USER14> I'm sorry to pry, I'm just curious- Why would you choose opportunities on the other side of the world over being with your family?

<comment><USER13> Sure :)

Because they are good opportunities.

Because I have lived here over the years (before I met my gf and got my son) and have large parts of my friends here.

Because my gf have a job she really loves and didn't want to move with me right away (but maybe later)

Because sometimes you have to think strategic about your families future. (of course with the danger of destroying the very family you are trying to create)

What can I say. Life's complicated :)

</comment></comment></comment></comment></comment><comment><USER15> Sidenote to my past self: you should work on "side products" rather than "side projects"!

<comment><USER16> Hey Thibaut!

The way I see it, there's a time and space for both. "side products" require much more upfront time investment than "side projects" (market research, competition evaluation etc). It depends what one is looking for at the moment: is it a potential business? (->side product) or exposure to a new technology to help you grow as a developer? (->side project).

<comment><USER12> I agree. I am not a great fan of side products because that is a whole other goal. That is all about making money rather than learning more. Its just not me.

</comment></comment></comment><comment><USER12> Hey guys, I am glad my post has kicked off such an interesting discussion. It seems to have struck a nerve with people.

It has also inspired me to write a followup post on my own blog looking at the subject of side projects in a little more depth: [http://boagworld.com/working-in-web-design/side-projects- can...](http://boagworld.com/working-in-web-design/side-projects-can-cure-our- woes/)

</comment><comment><USER17> My thinking about my future prospects as a potential employee (finishing school soon and thinking about the future) has led me to think about the things suggested in this article very seriously: I enjoy my hobbies involving the outdoors. I love hiking, climbing, cycling, and any other form of enjoying the outdoors. If I'm now trying to get a job at a technical company doing technical work, many founders and recruiters expect (sometimes even assume) that I will have some side projects I'm working on.

But I don't want to work on a side project for the heck of it. I want to stay healthy and enjoy my times outside. There is a brand of people out there that aren't just obsessed with the technical, and recruiters and companies who want all kinds of talent are going to have to be open to different lifestyles - including healthy ones.

<comment><USER12> Absolutely! As I say at one point in the post, if I had to choose I would choose life over side projects any day of the week. Although I prefer to hire those who do side projects I have also hired people precisely because of what they did outside of the web.

<comment><USER18> Me too. I'd choose life over side projects anyday! That's why I do a side project, so I can choose more life.

</comment></comment></comment><comment><USER18> "I don't believe the answer is work hard, play hard"

Playing hard means squeezing as much high adrenaline, pleasurable activities in a short amount of time, and rushing through vacation spots. Just as stressful as 60 hour work weeks.

</comment><comment><USER19> Great results be it in your family, work, or side projects require great sacrifices. You cannot have all be extremely successful while you are building all of them simultaneously from scratch.</comment>


"The evidence suggests I was completely wrong about UK tuition fees" - <AUTHOR> https://www.theguardian.com/science/the-lay-scientist/2016/jan/28/the-evidence-suggests-i-was-completely-wrong-about-tuition-fees <comment><USER3> "In the last decade, in spite of rising tuition fees, students are more likely to apply for university, poorer students are more likely to apply for university, and the inequality gap – while still a problem – has closed."

That's just ridiculous. What we are actually seeing is a very strong sheepskin effect where not having a university degree pretty much guarantees you a menial, low paying job. The poor push for a degree but that does not "the inequality gap has closed", because there is still strong inequality among degrees themselves.

People go to university not to learn (that's just a side effect, in some schools, for some students) but to signal to society and to a future employer they are the type of person willing to commit themselves to a career in the field, by irreversibly burning money and years of their lives doing busywork. So clearly, a more expensive or exclusive school is a better signal. Everybody goes to university nowadays but that does not mean degrees are equivalent.

I agree throwing public money at this mess is not a solution, we have to devise more efficient ways for people to signal their competence and willingness to learn.

<comment><USER4> "having a university degree pretty much guarantees you a menial, low paying job"

Evidence?

<comment><USER5> Read it again; I think you missed the "not".

<comment><USER4> I missed putting the not in the quote. My bad. I'm still sticking with it though - I don't think having or not having one makes much difference either way.

</comment></comment></comment></comment><comment><USER6> A definite mix up of correlation & causation.

There's no definition on disadvantaged / advantaged areas. Might be that the given figures: 72% 63%, 39% and 36%, just reflect the relative populations. Combined with the ongoing trend of people getting more educated, this might account for all of these figures.

Also the article simply dismisses the size of tuitions. A tuition of say < 10000 £ / a year probably won't be a strong inequalizer. But the whole notion that Ivy league tuitions vs. no tuitions wouldn't effect the possibilities of people is foolish.

The second point / infograph was more interesting though, and might bare more fruit for thought. Resources probably would be better allocated to pre uni. times.

</comment><comment><USER7> I'm relatively convinced that tuition fees don't promote inequality, based on stats I've seen over the last 10 years or so. Also, as a student, some of the richest people I knew didn't pay tuition fees due to creative accounting of their parents' personal finances.

That said, £27,000 for a bachelor's degree represents terrible value for money in most cases. The UK's old targets of getting everyone into higher education have had a terribly negative effect on universities; they now chase student numbers and have a 'grow or die' mindset.

The improvement of apprentice systems over the last few years is a step in the right direction, but I fear the damage has been done. Students don't want a challenging experience for £27k, they want the piece of paper they've paid for. For best value for money, I personally would rather take out a student loan without attending an institution and undertake self-guided learning at a slightly later age.

<comment><USER8> The increase in faux apprentices in the last few years is down to Mc Job employers(coffe shops and supermarkets) gaming the system and using apprentices as cheap unskilled labor.

Hell they haven't manged to increase the number of trade apprentices chipy sparkies etc

<comment><USER9> > Hell they haven't manged to increase the number of trade apprentices chipy > sparkies etc

I think the problem here is that small firms and one man bands, who used to be the backbone of the apprenticeship system, are no longer willing to take the risk of investing in someone only to see them get snapped up by a bigger firm once they have served their time?

There needs to be some kind of system in place that either prevents this happening or that compensates the firm who made the initial investment.

</comment></comment></comment><comment><USER10> I'm not convinced the "evidence" is suggesting anything without further data, and this article is glossing over "correlation != causation". Without a baseline (a situation where, over the same years, tuition fees weren't introduced/raised), how do we know what the equivalent situation would be? Perhaps there would have been even more people from poorer backgrounds applying.

<comment><USER11> It _is_ evidence. No need to put it in scare quotes. We can debate the correct interpretation and applicability, but it's certainly evidence of a sort.

It's impossible to run the kinds of controlled large scale socio-economic experiments you describe. If we ignore the evidence that doesn't meet your high standards, we'll have no real world data.

<comment><USER12> Recently it was discovered that working 20 hours a week while going to school results in worse grades - after decades of believing the exact opposite. When they did better studies - comparing like students (same school, same background, and other characteristics), they discovered that all the prior studies were just showing the success of students who really should have been even more successful. So I prefer to think of most studies such as this as a datapoint, rather than any type of evidence.

<comment><USER13> A datapoint is evidence, just not proof.

<comment><USER12> You might want to look up the definition of evidence. My reading of three definitions just doesn't quite match your definition. But no big deal. I think we agree, and this has become about word interpretation.

</comment></comment></comment></comment></comment><comment><USER14> That a reasonable amount of tuition combined with manageable payment options does not deter low-income students (at least not statistically) is not new [1].

That said, the potential deterrent effect is not the only thing to be considered. We also have to look at fairness.

Normally, a fixed [2] benefit paid out of flat or progressive taxes is itself progressive (because it provides proportionately more financial relief to low- income recipients).

However, in the case of free tuition, middle- and high-income households are more likely to be recipients; this makes it potentially regressive and is one of the major arguments for not having free tuition; you might end up with low income households paying tuition disproportionately for high income households.

Yet the UK's system (paying back tuition as an additional tax on your income, but only if you earn enough) does not really fix it; while it addresses the low/middle income disparity, it creates a regressive bump in the middle of the income scale; the cost hurts middle class students the most. Once you hit a point where you will pay your entire tuition, it's a fixed cost that is borne by everybody and then it becomes regressive.

Creating a flat or progressive hypothecated tax for college graduates might address the issue of social fairness, but at this point it's not clear whether it's worth the complexity or whether just financing tuition (and also other forms of tertiary education) out of a sufficiently progressive income tax might not be easier. After all, governments do a lot of things that are likely to benefit richer people more and we don't create convoluted hypothecated taxes for all of them.

The article is of course right that the problems that cause unequal access to college occur a long time before you worry about tuition, but this is really not an either-or situation. Free or affordable tuition isn't all that expensive (by the standards of the budgets of Western countries), not to mention that investing in human capital is generally a good idea. And, obviously, providing options for tertiary education and careers other than college is also a primary concern.

[1] That said, I'm pretty sure that on an individual level, there are still plenty of cases where it _does_ deter potential students – I know some myself – and there are other detrimental effects, such as the financial burden on dropouts.

[2] Tuition varies by university, of course, but on balance it's close enough to a fixed expense to call it that.

<comment><USER15> Completely agree that subsidizing university tuition is a regressive policy - taxing all of society to benefit the 33% of the population or so who go to college.

However, upfront fees of course are a big deterrent to poorer students, and that's not the only way to charge for tuition.

I like Milton Friedman's proposal to tax a certain percentage of future earnings of students in exchange for paying for their fees. Australia has a similar income-contigent repayment system which has been very successful.

I think it's fair that college graduates pay for the bulk of (all of?) their education, but I think it would be much better for college graduates (and society) if those fees were collected later in life and didn't cause crippling debt.

</comment></comment><comment><USER16> > In England, 18 year olds living in disadvantaged areas were a staggering 72% > more likely to apply for higher education in 2015 than in 2006. In Scotland, > Wales and Northern Ireland the figures were 63%, 39% and 36% - lower, but > still a huge increase.

As other commenters have pointed out, students from Scotland who are studying for their first undergraduate degree at a Scottish university don't pay any tuition fees.

</comment><comment><USER17> Does anyone know what percentage of these loans are being repaid? I recall that a couple of years ago the press were quoting figures like 85% will never be repaid.

</comment><comment><USER18> How about looking at countries which actually have no tuition fees and learning by example, instead of guessing what might or might not happen? Scotland is the most obvious example, but if you want a larger one, Poland does not have any fees for higher education eiter. I know a few people who started from really poor families and went on to become doctors and engineers, mostly because education didn't cost them anything.

<comment><USER19> Russia: reasonably accessible tuition fees with free education easily available based on entrance exam scores. Compulsory military service as a main motivation for degrees for males.

High graduation rate, but _horrible_ education quality exactly because of these factors. Judging by my personal experience, a CS graduate from any not first-rate (and there's about 5 of truly first-rate places left) Russian uni/college is, on average, significantly worse than a self-taught programmer.

Also, incredibly high corruption: professors extorting bribes at exams (not just accepting bribes from low-perfoming students, but actually extorting bribes from students who would able pass tests otherwise) isn't something far out of the ordinary.

<comment><USER20> Also lots of jobs require higher education when they shouldn't as a result of this "education overabundance".

<comment><USER19> They don't actually turn you away if you don't have a degree, they just write is as a requirement in job description. But like a lit of other "requirements", it's never strictly enforced.

</comment></comment></comment></comment><comment><USER21> Interesting premise given Britain now has the most expensive public university system on the planet:

"While student fees can be higher at many ivy league and other top colleges, the £9,000 annual charge for attending an English institution pushed the British average above the US's public colleges for the first time, the Organisation for Economic Cooperation and Development said. OECD data showed that fees for a bachelor or equivalent degree on average in public institutions was $9,019 a year in the UK compared with $8,202 in the US. Fees at private institutions – attended by 40 per cent of students -- in the US are on average $21,189 a year."

[http://www.ft.com/intl/cms/s/0/62a1d4e0-9213-11e5-bd82-c1fb8...](http://www.ft.com/intl/cms/s/0/62a1d4e0-9213-11e5-bd82-c1fb87bef7af.html)

[http://www.theguardian.com/education/2015/nov/24/uk-has- high...](http://www.theguardian.com/education/2015/nov/24/uk-has-highest- undergraduate-tuition-fees-in-industrialised-world-survey-finds)

</comment><comment><USER15> I was curious, looked up the numbers for the US vs UK:

UK annual tuition: $9,000 - $13,440 (the max for public) [1]

US avg annual tuition, public: $9,410 [2]

US avg annual tuition, private: $32,405 [2]

It's possible fees might not matter too much up to a certain range... investing in yourself could be justified economically up to a certain amount, after which the fees could be too much to justify (unless you have wealthy family to help out).

[1] [http://www.topuniversities.com/student-info/student- finance/...](http://www.topuniversities.com/student-info/student-finance/how- much-does-it-cost-study-uk) [2] [http://trends.collegeboard.org/college- pricing/figures-table...](http://trends.collegeboard.org/college- pricing/figures-tables/average-published-undergraduate-charges-sector-2015-16)

<comment><USER22> Compare that to France where it's $500 annual tuition (health insurance included).

<comment><USER23> I think supporting young people, up to a point, is a great idea, but comparing the numbers there is meaningless. France has chosen a higher amount of support, but that means that society at large is bearing the costs, not that France is educating students for $500 a year.

<comment><USER22> Well comparing expenditures in education in both countries France spends _less_ than the UK. So both societies are bearing similar costs with differing benefits.

Education expenditures in France: 5.9% of GDP UK: 6%

Source: CIA World Factbook.

<comment><USER23> Meaningless was a poor choice of word. The $500 a year will obviously impact the decisions made by students. But I think it is useful to compare the total costs, not just the costs observable by the student.

The outcomes in the US certainly aren't impressive, college degrees are becoming basic credentials, with little consideration of their utility. Not all academic pursuit needs to be measured against the economic utility it provides, but at a systemic level you probably want it to be at least roughly balanced against that utility.

<comment><USER22> I agree and that's why I cited total education expenditure. Not how much a student pays. So the total cost of education in France is 5.9% of GDP.

Yes, of course it should be at least roughly balanced against that utility. But that's an entirely different debate, than one about equality of opportunity in education by cost paid by the student.

</comment></comment></comment></comment></comment></comment><comment><USER24> The argument here is that highschools are underfunded, therefore any money that would have to be spent on scrapping university tuition should be spent on highschools instead. This would be a sound idea if the government weren't conservative and hadn't elevated austerity to a quasi-religion.

</comment><comment><USER25> No real mention of Scotland here which is interesting because it doesn't have tuition fees (I think). So surely it would stand as an example that either supports or disproves the theory in the article.

<comment><USER26> No tuition fees for Scottish students attending Scottish universities.

<comment><USER27> The be precise, Scottish and non-British European (EU/EEA/CH) students.

<comment> k-mcgrady Also, I'm not sure if they've closed it or not but there was a loop hole a few years ago that allowed students in Northern Ireland to go to Scottish Universities without paying fees due to dual Irish/British citizenship.

</comment></comment></comment></comment><comment><USER28> I see a lot of talk in the piece about applications to university but no data on attendance or graduation. I'd be more interested in those numbers. Does it really matter how many people apply?

<comment><USER29>
        > Does it really matter how many people apply?

When a key argument against tuition fees has been "it'll discourage poorer students from applying", yes it does.

<comment><USER30> Then the question is skewed. Technically, it costs NOTHING to "APPLY" to a school, whereas it costs tens of thousands to COMPLETE school.

In the US, the ROI on a degree is sad. with hard numbers to back it up - especially from a 'private' school. $100k debt to get a $45k/yr job - <USER2> thats if you can find one in your field of study.

It doesn't seem (to me) that people think about the ROI on these things. At this point it makes more sense to pay < $10k to become a plumber or electrician - things people will need no matter the economic situation, with an ROI through the stratosphere.

</comment></comment></comment><comment><USER31> I am leaving UK mainly because of tuition fees. It's really expensive for overseas, I am just a regular software engineer and someone from my family wants to finish the studies.

£24k p.a...

</comment><comment><USER22> This article is such bullcrap. The writer needs to see the situation in France and Germany (better but not without problems).</comment>


Why would anyone choose Docker over fat binaries? - <AUTHOR> http://www.smashcompany.com/technology/why-would-anyone-choose-docker-over-fat-binaries <comment> friend-monoid * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write.

* We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.

* sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.

* Its possible for me to namespace everything myself with unshare(1) and "ip netns" and cgroups and chroot and iptables... but that would consume all my available time. Docker can do that for me.

* When you reach more then 20 or so services to keep track of, you need tools to help you out.

* load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier.

<comment><USER4> > * If my colleagues don't have to understand how do deploy applications > properly, their work is simplified greatly. If I can just take their work, > put it in a container, no matter the language or style, my work is greatly > simplified. I don't have to worry about how to handle crashes, infinite > loops, or other bad code they write.

Of course you do, you just moved the logic into the "orchestration" and "management" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig.

> * We have a whole lot of HTTP services in a range of languages. Managing > them all with fat binaries would be a chore - the author would have to give > me a way to set port and listen address, and I have to keep track of every > way to set a port. With a net namespace and clever iptables routing, docker > can do that for me.

Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing.

> * sometimes, I have to deploy and insecure app. Usually, it's a badly > configured memcache or similar. With net namespaces, I can make sure only a > certain server has access to that service, and that the service cannot ruin > my host server.

You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.

> load balancing. Luckily, I don't have to deal with extreme network loads > which would require hand-made solutions, but just pushing up that number a > little to do ad-hoc load balance makes things a lot easier

The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.

<comment><USER5> I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.

<comment><USER4> In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

<comment><USER6> Yes. Each time you start a container, you are basically saying "make clean" as well.

<comment><USER4> Except that people who write software to be put in containers cannot write that Makefile to save their life so for something that should be a ten line dependency they manage to build entire Linux, entire X and all unneeded tool chains.

</comment></comment></comment></comment></comment></comment><comment><USER7> I admit: I find the argument for "fat binaries"[1] over containers compelling. There's just one problem...

...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future.

I can just about see how we can package up all our existing code into docker containers, sprinkle some magic orchestration all over the top, and ship that.

I can also see, as per the article, an argument that we'd be much better off with fat binaries. But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? And if your answer is "rewrite your entire codebase in golang", then you clearly don't understand the question; we don't have the resources to do that, we wouldn't want to spend them on a big bang rewrite even if we did, and in any case, we don't really like golang.

All of which makes this article seem oddly academic to me. There's a lot of value to something that can be layered on top of your existing solution for those of us who aren't starting greenfield projects.

[1]: Also, while "fat binaries" is a great term, it's one that already exists and means something totally different.

<comment><USER8> _But here 's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one?_

For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.

<comment><USER9> Yes, and we all know every shop in town has resources comparable to Facebook's...

<comment><USER10> You can compile a statically linked PHP interpreter. Probably a bit of messing around with configure and makefiles, but doable.

<comment><USER11> More to the point, if this became the commonly-accepted sane way to do things, php would support it directly and it would be easy.

</comment></comment></comment></comment></comment><comment><USER12> > Docker is a tool that allows you to continue to use tools that were perfect > for the1990s and early 2000s. You can create a web site using Ruby On Rails, > and you'll have tens of thousands of files, spread across hundreds of > directories, and you'll be dependent on various environmental variables. > What ports are in use? What sockets do you use to talk to other apps? How > does the application server talk to the web server? How could you possibly > easily port this to a new server? That is where Docker comes in. It will > create an artificial universe where your Rails app has everything it needs. > And then you can hand around the Docker image in the same way a Golang > programmer might hand around a fat binary.

Anyone who thinks that all modern web applications are made in Golang or on the JVM is in a pretty weird echo chamber. Server-side rendering with React or Angular Universal practically requires you to be running Javascript on the server, and while you can theoretically statically link V8 to Golang, it's much easier to use Node and have native code-sharing. And the reference implementation for GraphQL is in Javascript as well. Web application servers never stopped moving towards scripting languages (though arguably the microservices split from them did move towards compiled languages). So there will continue to be, for the foreseeable future, an industry-wide need for deployment of non-fat binaries with these types of dependencies. And in that case, Docker is significantly more sane than trying to synchronize all those files.

<comment><USER13> I don't see where he claims anything like that. The strongest statement seems to be "move to languages that support fat binaries" \- which doesn't preclude a loftier aim "your favourite language should start supporting fat binaries".

(I'm replying to clarify - not sure if I agree. I'm a Python guy - I think everyone should switch to languages with significant white space ;-) )

</comment></comment><comment><USER14> Fat binaries solve _one_ of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue.

That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure.

And the statement that the Go language is the pioneer for fat binaries is, well, just wrong. People were using static binaries (with, in some cases, built-in data resources) to solve that problem for literally decades. MacOS, for one.

I also remember working with one of the eventual co-founders of Red Hat back when MIT was interested in a proprietary math analysis tool for SCO, but which we were planning on running on Linux. MIT had purchased a site license, which he was going to implement by checking the network address to see if it was 18.x.x.x. He was going to provide a statically linked SCO binary that had this check. The funny thing was that his development system was Linux (it was more developer friendly), and he was cross-compiling to create a statically-linked SCO binary --- which we were then going to run on Linux using SCO emulation. But that statically-linked binary was basically a "fat binary", which would work on any system (including any Linux distribution) that supported the set of system calls SCO used. (Ah, the early-90's, before Red Hat was founded and before IBM had "discovered" Linux, were simpler times....)

<comment><USER15> The "DLL hell" problem is not the only problem it solves, but it is the only problem that docker solves reasonably well.

<comment><USER16> That's true. The other dependencies of an application are handled as well, but abstractions are leaky.

Storage (and file system uids), networking, are all elements of the outer system that inevitably leak in the container. Using just Docker does not save you from having to deal with those, and IMHO, those are the really hard problems.

</comment></comment></comment><comment><USER17> The article makes sense if portability was the only reason to use containers. Fat binaries solve the portability problem in a way that may or may not make sense for a given project, but fat binariries don't address any of the other issues that container technologies provide solutions for (sandboxing, resource management, etc.). Either the author isn't aware of these other issues, or is purposefully sweeping them under the the rug, because arguably they are more important than simple binary compatibility. I'd be pretty down on containers too if I thought they only existed in order to distribute portable binaries.

<comment><USER18> Precisely. As a real world example, I have a repository that basically is a large collection of code modules that runs on three different runtime environments. One of these run times is a Hadoop cluster, where we could happily shadowJar all of our massive dependencies (like Spark) into a giant multi-hundred-mb jar file and have no issues. Another one is a client desktop environment that is shipped to thousands of desktop users with each version release. Most of the code is reused between the two runtimes so it makes no sense to separate them. Therefore we build the project without the fat dependencies in the binary so we can ship the slim version to the client runtime without forcing huge download every release.

</comment></comment><comment><USER19> "A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name." [1]

What does having an x86 and x64 binary in the same executable have to do with dependency management? You can have a fat binary that is dynamically linked. If you have an x64 OS then the 64 bits run, but they still call OS libraries if the app is dynamically linked.

Static linking [2] is what compiles all the dependencies into one big executable, but every compiled language has that. It is not exclusive to Go.

[1] - [https://en.wikipedia.org/wiki/Fat_binary](https://en.wikipedia.org/wiki/Fat_binary)

[2] - [https://en.wikipedia.org/wiki/Static_library](https://en.wikipedia.org/wiki/Static_library)

<comment><USER7> I assume you knew this and were just making a point, but: OP is using the term "fat binary" in a totally different and incompatible way to how your wikipedia link defines it.

> every compiled language has that. It is not exclusive to Go.

I don't think the article claimed it was. But it _is_ a lot harder with C than Golang for various technical reasons, and it's much, much harder still with most scripting languages.

<comment><USER20> It is super easy to do static binaries with C, I was already doing it in 1992, the first time I actually used C on my life.

It only hard if one happens to mix glibc, a specific implementation of the ANSI C standard library, with any implementation of it.

<comment><USER21> Hahaha that is soooo wrong. You might think you make a static binary with C by passing -static but trust me you do not. I believe it is still actually impossible to link with glibc statically. It's only been possible to do a static binary on Linux since Musl was written and that was not in 1992. In the 2000's there was an attempt to make true static binaries possible on Linux (think it was called Autopackage) but they eventually gave up due to the effort required.

The story on Windows is much better of course, but even there making a proper dependency-free (as much as possible) binary is _much_ easier with Go than any other language. It's possible in Go because they don't depend on the C standard library and wrote their own linker.

<comment><USER22> It is not impossible to link glibc statically, and in older versions of libc this did occur. However, the Linux community at the time decided that the tradeoff of disallowing the system NSS to be modular was too great -- Go developers disregard this and don't believe anyone does anything other than the defaults.

Even still, it's possible to compile glibc such that those NSS modules are statically linkable. See here for further information: [https://stackoverflow.com/questions/3430400/linux-static- lin...](https://stackoverflow.com/questions/3430400/linux-static-linking-is- dead)

However, in 1992 it was entirely possible to statically link an application to libc4 and have it have no run-time dependencies other than the kernel ABI.

<comment><USER23> Go doesn't disregard anything. It tried to parse NSS configuration, if there is no Go implementation available for the user conf it parsed, it falls back to glibc.

<comment><USER22> Only if you use "cgo", otherwise it doesn't have access to the run-time linker.

<comment><USER23> No, by default.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> This works for one Go or Rust executable but any real system is a mix of technologies e.g A Go service talking to a Java application server proxied with a C webserver that was configured with a bash script.

Once you have a mix of different technologies its easier to just say "everything in Docker".

The ship container analogy on the old Docker website was a great illustration of this. Its a shame the new website is not so clear about the benefits and is full empty phrases such as "accelerating innovation".

<comment><USER25> Does it even work well for go or rust executables? I seem to recall that Docker itself was written in golang because "fat binaries1111", but now docker is one of the hardest to install applications that I know of, and certainly isn't simply one executable file to be copied onto the system.

Managing resource files in fat binaries is really problematic.

<comment><USER26> I've never had trouble installing Docker anywhere, whether from package managers or installers. Where have you, and what kind of trouble? If I might run into something similar down the road, better I should know about it now.

<comment><USER27> It used to be that docker could be installed literally by downloading the docker binary, then it was a single curl command. Now the documentation looks like this: [https://www.docker.com/get-docker](https://www.docker.com/get- docker)

You press "get docker community image". Then you find your distro. Go to "download from the docker store", discover that there is no dowload link [https://store.docker.com/editions/community/docker-ce- server...](https://store.docker.com/editions/community/docker-ce-server- ubuntu) then you click on the long form link to the docs. Which gets you here: [https://docs.docker.com/engine/installation/linux/docker- ce/...](https://docs.docker.com/engine/installation/linux/docker- ce/ubuntu/#install-docker-ce-1)

And then that is not simple at all.

So much for fat binaries making things easy. Good-ness grief.

<comment><USER28> If you simply want the latest stable docker version, try:

      curl -o /tmp/get-docker.sh https://get.docker.com && bash /tmp/get-docker.sh

or even just

      curl https://get.docker.com | bash

You can also use this script to update to the latest version, if you previously used it to install.

</comment></comment></comment></comment></comment><comment><USER29> This article failed to mention the most important thing: An actual advantage of fat binaries. The closest he comes is saying that he feels the docker way is "old"... As compared with fat binaries, which is how desktop applications have been shipped for decades. Hell, size, the only clear would-be advantage, is only mentioned in a throaway sentence.

> Yes, the network can be very powerful, but trying to use it for everything > is a royal pain.

He says this after saying docker is unsuited for the massive scale of microservices... Where everything communicates through the network anyways.

Also I have a feeling he doesn't know the distinction between kubernetes and docker. They don't actually compete with each other, I don't even understand the comparison. Kubernetes _uses_ docker.

All in all, I'm _not_ convinced.

PS: At least in python, there are ways to create fat binaries anyway. And I have no doubt that this guy is very good at operations, as he seems to have not found problems with go's dependency management and even implicitly compares it favorably with those of the scripting languages.

<comment><USER30> _" I have a feeling he doesn't know the distinction between kubernetes and docker. They don't actually compete with each other, I don't even understand the comparison. Kubernetes uses docker."_

Docker (the company) is itself responsible for this confusion. They're redefined what "docker" means a whole bunch of times.

<comment><USER31> I had this discussion [0] with their CTO a while back and, suffice it to say, there's a profound lack of understanding of what early adopters like me had to do to lobby for the use of their products in enterprises.

[0] [https://news.ycombinator.com/item?id=13775732](https://news.ycombinator.com/item?id=13775732)

</comment></comment></comment><comment><USER32> Well, the author is definitely missing the point.

In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what's the difference?

* With containers I can put a Python app right alongside my binary but with total isolation. No need to futz around with chroots or making a static build of Python and embedding my scripts into it.

* What if I need libc, for example to link to SQLite or something? Suddenly my Go binary requires libc. The isolation is broken!

* Systemd can use Cgroups to limit RAM or CPU, but schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there's no equivalent tooling for doing this with fat binaries.

* Without Docker, I have to manually manage each container port. Can't run two apps with pprof servers on the same box. With Docker, I only have to care about public ports, and can port-forward into debug ports manually, and with Kubernetes I never have to care about port conflicts.

* Kubernetes, with enough hackery to work around bugs, can actually do seamless deployments where it checks your internal health endpoint or command before making the container available. As far as I know, the alternative to this is writing crappy scripts that try to do this without declarative logic to back it.

You could go on and on. It doesn't have to be Docker. Could use rkt as well, or really any container engine. The point is that the container engine + scheduler pattern is immensely useful, and if it weren't, Google would already be on the next thing.

If you're just setting up a single server with a single program, fine. Drop a binary on it and call it a day. But when you want to implement CI/CD and schedule applications across multiple servers and do load balancing and so on, you might feel like you're reinventing the wheel a bit considering those problems were all already solved by Kubernetes.

<comment><USER33> > but other than that, what's the difference?

The need to configure, manage, monitor and maintain a whole extra set of programs. Also, systemd can just as easily start the binary in a cgroup, eliminating most of the following concerns.

> The isolation is broken

Worth noting that behind the scenes, Linux is using the same in-memory versions of libc, even for containers. That isolation you speak of already doesn't exist.

> [...] scheduling [...]

Ansible, Chef, Saltstack, etc.

> I have to manually manage each container port

You have 65,000 ports available to you. I don't think this is as big an issue as made out to be - people are lazy, which is the only reason there are so many conflicts over 8000 and 8443.

> Kubernetes, with enough hackery to work around bugs

Given the context that I am someone currently attempting that hackery - <USER2> shit just kinda works, some of the time. And when it fails, it's a morass of conflicting documentation, and responses of "well, you're not using the default distribution for your environment" (no shit, it's no longer supported) and "works on my single node minikube cluster". Give me ansible/chef/saltstack any day of the week. Hell, I'll even take cfengine at this point.

Kubernetes was built for Google's use case, in Google's environment. Attempting to use it with other restrictions and requirements is a nightmare.

<comment><USER34> > Kubernetes was built for Google's use case, in Google's environment. > Attempting to use it with other restrictions and requirements is a > nightmare.

That's a tremendous overstatement. The first part is just wrong, as was pointed out in earlier responses. The second part just smacks of your having been soured by a poor experience. We started with kubernetes in production at very small scale, just a few supporting services to begin with since there was a lot to learn. Currently we're running five or six of our core production apps on the GKE version of the platform and the experience has been very positive.

</comment></comment></comment><comment><USER20> > The Go language is the pioneer for fat binaries.

I had to laugh on this one.

<comment><USER22> Especially since it's nowhere near where Tcl was with Starpacks nearly a decade ago.

</comment></comment><comment> open-source-ux Golang didn't pioneer 'fat' binaries as the article claims. It may have made them popular again, but we have had compiled, self-contained, dependency-free executables for decades. If people are not aware of that, perhaps it's because scripting languages (or languages that use a VM) have come to so thoroughly dominate programming language discussions?

<comment><USER20> I guess so.

Usually everone that somehow thinks Go compilation model is inovative, never has used anything beyond scripting languages and possibily C in addition to them.

MS-DOS used to call them "XCopy installs", NeXTSTEP had its fat binaries with directory structure, Windows and MacOS(pre OS X) can store all dependencies inside the .exe file and so on.

In any case, fat binaries don't cover the dependencies with file system, other running servers or sandboxing.

<comment><USER35> > MacOS(pre OS X) can store all dependencies inside the .exe file and so on.

On macOS / OS X, it's actually a .app _folder_

<comment><USER20> Yes, but on Mac OS pre-OS X you could use resource forks for that.

</comment></comment></comment></comment><comment><USER36> > It seems sad that so much effort should be made to keep old technologies > going,

I strongly disagree with this part. To make progress as a technological civilization, without constantly wasting time reinventing things, we need to keep old technologies working. So, if Docker keeps that Rails app from 2007 running, that's great. And maybe we should still develop new apps in Rails, Django, PHP, and the like. It's good to use mature platforms and tools, even if they're not fashionable.

That word "fashionable" brings me to something that really rubs me the wrong way about this piece, and our field in general. Can we stop being so fashion- driven? It's tempting to conflate technology with pop culture, to assume that anything developed during the reign of grunge music, for example, must not be good now. But good technology isn't like popular music; something that was a good idea and well executed in 1993 is probably still good today.

Besides all that, as others have explained, platforms like Kubernetes have other advantages over just dropping a self-contained binary on a Linux server.

</comment><comment><USER37> Its INCREDIBLY naive of the author to be slamming docker usage because they think everything should be a fat binary - and what are they even calling a fat binary? How do I make my node app a fat binary? Would they be happier if we wrapped up docker + images in an executable and called that a fat binary?

Also, I think the author is simply confused about what docker itself is, complaining about its lack of network orchestration - and comparing it directly to kubernetes!

<comment><USER18> This is not intending to diminish your point because I agree with you, but you can in fact make a fat binary with Node: [https://github.com/nexe/nexe](https://github.com/nexe/nexe)

I have used it when I cannot guarantee to have Node.js installed on location I am deploying app to. It works pretty well, but the C compilation of all the Node bindings took quite awhile when I was using it (about 2 years ago). I think a build of a small project took around 10 minutes at the time.

<comment><USER38> This would copy the runtime for every app you need.. Pretty sure if you used docker this wouldn't be the case but I'm 100% sure. Obviously space isn't the biggest of deals, just mentioning it.

</comment></comment></comment><comment><USER39> Not all developer tools and languages let you compile to fat binaries. Also I don't think that they were pioneered by Go. Java .jar files have been around long before Go even existed. Jar files are probably even better in fact because they can run on any operating system without any sort of virtualization.

Docker standardizes containerization. Kubernetes relies on a standardized container platform like Docker in order to be able to automate the running of different systems in a consistent and repeatable way.

Also, from the point of view of someone who has to provide support for software for multiple customers, it helps to know that the Linux environment between all customers is consistent... That way you don't get strange issues that only happen to one customer and not the others because of some slight OS level differences.

<comment> DC-3 > Jar files are probably even better in fact because they can run on any > operating system without any sort of virtualization.

What did you think the V in JVM stood for?

<comment><USER40> Harsh tone for a comment that's confusing OS virtualization with virtual ISA and its runtime.

<comment> DC-3 I'm aware of the difference, I just don't think it matters here - in either case there's an additional level of indirection when compared to Golang fat binaries.

</comment></comment></comment></comment><comment><USER41> With fat binaries you are looking to isolate your application from environment -- by providing the dependencies (library code) along with your base application code. This way you don't have to make sure the user of your application provides the correct libraries in correct versions.

Docker container is an extension of that idea. If you can distribute some of the libraries, why not distribute entire execution environment? Why not isolate your application from external environment even further?

The more you control the environment the less work you have to do to make sure the application will work.

My point of view, there are two types of applications with diametrally different development process:

1\. applications where you have to invest a lot of effort into making it resistant to the environment -- it has to work regardless of the differences in user environment. Think for example in terms of a PC game that must run on different GPUs, with different driver versions, on different OS versions, with different applications installed.

2\. applications where it is enough to show that there is a set of circumstances when the application works correctly -- think in terms of typical enterprise application where DEVs would place it on the server and then the environment would be religiously preserved to not risk application breaking.

Developing type 2 applications is much, much, much less effort.

By distributing type 1 applications along with the environment we basically reduce the cost of developing them because now it would be enough to develop them up to type 2 applications standard.

For example: you may create a simple bash script to do something. If you distribute it as just script file, you need to make the script work on every bash on every type of mainstream Linux distribution.

If you distribute the script as a docker image it is enough for you to make that script work on that particular image (for example Ubuntu x.x) and you don't need to worry about other possibilities.

This is the essence and value in distributing of applications as Docker images.

</comment><comment><USER42> Just moves the problem rather than solving it. You now have a Go dependency management problem and all the fun that causes.

It won't be long before we see Go library distributions with versions in packages and security fixes rolled out to them...

What we've missed over the years is an agreed improvement to the Unix process abstraction that the kernel manages. IPC was never solved. So now we're trying to do ipc over http with JSON

</comment><comment><USER43> It's a bit idealistic to think people can "just" use fat binaries; sure, Go mostly handles that (not completely; by default most nontrivial Go apps are dynamic, which you can fix but not _that_ easily) but that's not exactly any comfort if I've got 30,000 lines of Python which I'm not keen on rewriting. Technologies like pex can help but in practice require some work, especially with a codebase that hasn't been written with it in mind or when dealing with third-party libraries that aren't expecting such an environment - and that still doesn't solve what you're doing with the interpreter itself.

I'm far from a big fan of Docker, but can definitely see the appeal for providing a solution to those problems, even if some see it as unprincipled. In our case we'd already put a lot of effort into building mostly self- contained binaries and Docker is still useful (admittedly mostly just as a component of Kubernetes; we'd cheerfully replace it with rkt or something if there was a good option).

<comment><USER18> We bundle our apps in binaries and stick them in docker as well. This lets our devops team take advantage of unified deployment strategies and configuration management. For example app A is a node app and app B is a fat Scala Play binary. They can both use same docker deployment and environment configuration strategies through Docker as well as make pluggable items for Kubernetes.

Why take an all-or-nothing approach when you could pick the best of both approaches and use them in tandem? :)

</comment></comment><comment><USER44> A typical service has many types of dependencies including filesystem layout, the presence of specific executables at specific versions, rpm/deb packages at specific versions. Different services make different assumptions and evolve at incompatible paces. Docker can isolate an assumption about FS layout as well as an assumption that a deb is at a specific version.

This article is confusing in its focus on docker. It really proposes a much more restricting way to build apps, in which all assumptions except linking- level dependencies should be portable. Its answer to filesystem isolation: don't rely on the filesystem being a certain way. Or, rely on it being a certain way and push the complexity into your deployment layer.

</comment><comment><USER45> I developed stowage.org to get a closer binary-like experience with Docker. What is great is being able to use containers like a generic any-language fat binary compiler.

However, there is a bunch more stuff in Docker (or equivalent runtimes) that this article doesn't touch on. It's similar in some ways, for some use cases. It could be interesting to see what a fat binary orchestration tool would look like, but I would bet you end up reinventing 99% of what Docker already does.

</comment><comment><USER26> Because choosing Docker requires boiling fewer oceans, and whether those oceans should or should not be boiled has no bearing on whether I can afford to boil them right now.

</comment><comment><USER46> Fat binaries don't solve the same problems as Docker does (there is some overlap though!).

The author is right about k8s. And what do you need to run stuff in k8s? Containers. And what is a pretty good container format? Oh yeah, Docker.

Although other containers exist, let's be honest, people running k8s are almost always running Docker containers in them. And it all works amazingly well.

How do I run fat binaries in k8s? In a production ready and battle tested way please.

</comment><comment><USER47> Even if you build fat binaries, it's helpful for them to run in a container for a bunch of reasons:

      0) security
      1) container overhead <<<< vm overhead
      2) better bin-packing because of 1
      3) enforce resource constraints (I know what your app
      requires)
      4) enforce 12-factor app patterns, build apps that don't rely on local state

<comment><USER48> Where does he say you should run fat binaries in a VM?

</comment></comment><comment><USER49> Fat binaries solve only for dependency. Containers also deal with isolating environment variables and filesystem.

Each program doesn't have to worry about what else is running on the machine. It also helps you deal with the differences between say Ubuntu and redhat. Not all nix os have the same filesystem directory setup.

<comment><USER50> Containers are overkill if you're just trying to isolate environment variables and filesystems. I mean really, if that was your problem and you came up with containers as the solution I'd say you over-engineered the solution. Environment variables -- trivial -- set them in the wrapper script used to launch the binary and you're done. Filesystem -- use separate _nix accounts for your binaries and set appropriate permissions, for additional security use tools like se-linux if needed. Somehow, somewhere along the line it seems like there 's this huge echo-chamber of 'containers for all things' and we have thrown out all we ever new about basic _nix.

Contrarian views like the one in the article are healthy!

</comment></comment><comment><USER51> I really don't see how this is an argument - Docker containers are like zip- files for deploying these very same app binaries, whether fat or lean - <USER3> containers are very easy to define, are able to run anything inside, can easily be uploaded/downloaded over HTTP, and abstract away all the systemd/init/background service nonsense into a clean API.

That alone is worth it, and it's what makes Kubernetes so powerful, by taking that basic runtime abstraction and further lifting it up beyond the VMs/nodes themselves.

<comment><USER52> > and abstract away all the systemd/init/background service nonsense into a > clean API.

hm?! what?!

> That alone is worth it, and it's what makes Kubernetes so powerful, by > taking that basic runtime abstraction and further lifting it up beyond the > VMs/nodes themselves.

how is a damn yaml file over 40 lines simpler than a 7 lines systemd? (i didn't even count the setup of kubernetes, since you prolly never did)

also anything you actually said makes no sense.... since you actually compared the things that are comparable...

edit: yes, both have pro's and cons, still your things make no sense

<comment><USER51> It that really the argument? Because "40 lines" are more than "7 lines"?

Both are simple to write, but K8S services for me are much easier to define. They're also far more configurable and usable across machines. Write it once and you're done, and add in the ability to use service-oriented storage and networking policies and it provides far greater power and flexibility than ever before.

My point is that there is no point comparing these things since a docker container can hold all the fat binaries you want inside... so it's not either/or at all.

</comment></comment></comment><comment><USER53> The post starts from the assumption we should all use microservices because web scale. I'm curious, how many people here are actually using that "new style", and enjoying it?

</comment><comment><USER54> It's sad when people have a myopic view of the use of technology.

Docker is a way to distribute an executable environment, very similar to distributing an application platform.

A "fat binary" is literally just a single monolithic executable application. It isn't an environment. It isn't a platform. It's ridgid and difficult to work with and, as the name implies, BIG.

There are many cases where a "fat binary" simply can not, does not, will not work. It's a very limiting way to distribute and run an application. Suggesting that a "fat binary" is somehow superior to a Docker environment is not only missing the forest for the trees, it's forgetting that there's a forest. The binary is just one tree.

Docker isn't more complex than what we had before. People just haven't been trained on the different patterns of deploying environments and platforms, in addition to applications. We used to build Docker-esque application platforms all the frigging time before Linux containers even existed, and they still exist without Docker. If you have a problem with Docker, that's fine, but it doesn't mean you have to box yourself into a totally different restrictive model.

People in this industry need to wake up and admit there are no simple solutions to complex problems. Don't believe the hype.

</comment><comment><USER55> Is pyinstaller a sufficient solution for creating fat binaries in python? I'm not interested in using go, and I also have C++ binary dependencies that need to be deployed but which come to me already built.

EDIT: "Or rather, if the problem is resource and dependency and configuration management, we should solve the problem by moving to those languages that support fat binaries."

Oh, so this article is really just an advertisement for Go. That sure spoils it.

</comment><comment><USER56> Containers are not only a solution for dependencies. It's also protection boundary.

<comment><USER42> It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. We just didn't have a massive PR budget

<comment><USER57> > It's just a process with a fancy chroot. Don't believe all the docker hype. > Sensible admins have been doing something similar for years.

You can easily break out of a chroot jail: [http://pentestmonkey.net/blog/chroot-breakout- perl](http://pentestmonkey.net/blog/chroot-breakout-perl)

Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Docker gives you networking isolation and especially RAM/CPU usage limitation, which is a real headache doing with chroot.

<comment><USER58> > Thats not possible in Docker

Believe this at your own peril.

<comment><USER57> At least right now, I do not know of a way to break out of a Docker container and the last bug I know of was fixed in 2014 ([https://blog.docker.com/2014/06/docker-container-breakout- pr...](https://blog.docker.com/2014/06/docker-container-breakout-proof-of- concept-exploit/)).

The only ways I know of that can be used to jailbreak are, as documented on [https://security.stackexchange.com/a/153016](https://security.stackexchange.com/a/153016): kernel vulns (which are not inherent to Docker, and can hit you on any kind of Linux environment as soon as you achieve RCE in a hosted application), running a container with --privileged, and being careless with bindmounts - either by bind-mounting /dev, /proc and friends which you shouldn't do in any case unless you're aware of the pitfalls or by bind-mounting the Docker socket file.

The latter is something that I see far too often (especially with docker-in- docker setups for Jenkins slaves), but if you're avoiding this, you're safe from that vector.

<comment><USER58> Docker is comparable to a chroot in this regard. You can not break out of a chroot either, unless you are being careless with super user privileges or bind mounts. Which (unsuprisingly) people are, and that's why it's generally not recommended to use chroot alone for security. Not because chroot somehow is insecure or doesn't work as intended.

Docker for the longest time didn't even try to constrict the root user. Later versions does, but the results will vary depending on your configuration. That's why the Docker documentation states it should not be depended on for security. It is wise to heed that recommendation.

</comment></comment></comment></comment></comment></comment><comment><USER59> I can create a Docker image for just about any app written in any language that runs on Linux with a few lines of Dockerfile, whereas you need fat binary support from each programming language compiler/interpreter/linker/whatever.

Correct?

</comment><comment><USER60> > I don't know if Kubernetes is better at orchestrating network resources than > a system built around etcd or consul

Isn't Kubernetes build around etcd?

I really don't get this blogpost, it seems like "I don't have this problem, so nobody else has."

</comment><comment><USER61> This echoes our experience, which is that deploying go binaries is easier and more reliable than using docker, but that docker is useful for legacy python and other things that are difficult to turn into FRUs (field replaceable units).

</comment><comment><USER62> What I've been wanting to do lately is find some way of packing up conventional apps which I would otherwise dockerize.

It feels like the Linux Kernel Library project would be a way to do this - redirect all the filesystem calls into mapped portions of the binary to abstract over the filesystem which I think would get you 90% of the way there practically?

</comment><comment><USER63> but why did a class of developers use inferior open source languages like ruby, python and php over enterprise fat binary java and dotnet stack. if you did not get that change you won't get it this time too.

docker helped alleviate fears of vendor lock-in with cloud providers.

wait some more time and you will see unikernel applications as new thin binaries

</comment><comment><USER64> I use Docker mainly in situations where the required dependencies (Java, GTK, etc) conflict with the versions on my system. In this case, the service running in the container is required, unless I want to upgrade the operating system, and I'm on CentOS 7 for a reason (stability and security).

<comment><USER30> You could also use guix or nix for this.

</comment></comment><comment><USER65> It's hard to say what Docker means now since the company has lots of products called Docker, doing wildly different things, but for Mac and Windows users it's a nice virtual machine frontend for running/developing containerized Linux apps.

</comment><comment><USER66> I like Go a lot, but it doesn't always build fat binaries.

go build xyz.go

xyz: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

<comment><USER67> Try: CGO_ENABLED=0 go build xyz.go

</comment></comment><comment><USER68> Docker is not only used to solve dependency issues.

</comment><comment><USER69> I would perhaps agree if this was about desktop rather than web...

</comment><comment><USER70> Equating docker containers to fat binaries is naive and shows that you don't really understand what docker does. At my workplace, we use containers instead of VMs or emulators. The entire system of a virtual host runs inside a container (multiple apps, multiple namespaces, multiple network interfaces). Please tell me how to do that as easy as "docker run <some options>".

</comment><comment><USER27> "Or rather, if the problem is resource and dependency and configuration management, we should solve the problem by moving to those languages that support fat binaries. Because fat binaries solve the main problem, without creating additional problems." This is the same attitude as the Javascript attitude. "Javascript is portable, so therefore all other languages are irrelevant."

This attitude is wrong. It is wrong because programming is hard. We have spent many decades trying to figure out how to program effectively. To produce simple maintainable code. Solving the hard problems, the interesting problems, is still too hard for us. The idea that "any language will do so long as it is portable" might as well lead us to write in LLVM-IR!</comment>


Ontario Municipal retirement fund (OMERS) to launch $180MM early-stage VC fund - <AUTHOR> http://www.theglobeandmail.com/globe-investor/omers-to-launch-180-million-venture-capital-fund/article2188093/

<comment><USER2> If you weren't worried about a bubble, you ought to be now.

<comment><USER3> How so?

Canadian investors have traditionally been extremely risk-averse, and the country has needed this kind of VC activity for years now. Maybe something like this will go towards bringing back some of the legions of Canadian expats (like myself) who are currently in the US because the state of the software industry in Canada is, in a word, pathetic.

</comment></comment><comment><USER4> Tag for later. Thanks.</comment>


Show HN: Saulify: Generate clean, responsive articles with just a click - <AUTHOR> https://www.saulify.me/

<comment><USER2> It seems it does not work well on other languages than English, e.g. Chinese. I checked this url "[http://qinmishu.org/article.php?id=articles-num- phoneticmnem...](http://qinmishu.org/article.php?id=articles-num- phoneticmnemonicsystem"), and it give me messy result.

</comment><comment><USER3> Nice but can you adjust the contrast? All the text on the front page fails WCAG. And the links on the cleaned pages fail as well.

</comment><comment><USER4> I love it. What I want now is a bookmarklet for my web browser so I can use the site quickly.

<comment><USER5> Here you go: [https://chrome.google.com/webstore/detail/saulify- me/eibhjmf...](https://chrome.google.com/webstore/detail/saulify- me/eibhjmfhkejkonblfmeiejgdofndlkih)

</comment></comment><comment><USER6> Did you use one of the readability clone libraries or roll your own?</comment>


On the horrific state of JavaScript frameworks - <AUTHOR>

Is it just me or are Javascript frameworks among the most horrendous libraries in software development right now? I've tried several Javascript MVC frameworks and the glue libraries that come with them (Angular, Backbone, Sails, Waterline, etc.) and the one common theme among all is that they have the absolute minimum feature set to put together a simple application like a TODO app but completely fall apart when developing a real-world rich client application. To give an example, most ORMs like Waterline have extremely basic relational support with little or no support for querying beyond basic operators against numeric or string properties. Waterline can't query an object based on a property of a child association, for example, and is thus almost useless in real world scenarios.
The state of debugging is also shockingly terribad. How can people seriously debug a client side application in Chrome or Firefox's developer tools?
What am I doing wrong? Are Javascript client frameworks really this bad? <comment><USER3> Not sure where to begin, but I'll take a crack at this one...

I used to be like you. I was out at every meetup -- flirting with all the new frameworks in town. We would start off hot-n-heavy, staying up late into the night, making big plans. But just as things were about to get serious, I back- peddled and started to better-deal -- thinking there is a "better framework" out there. I didn't want to make the wrong choice.

Backbone was the hot new sexy, and we got along great. We breezed through TODOMVc, and everything just "clicked." She showed me a better way to javascript. This was great! I took the relationship to the next level, and we were off on our enterprise app. Sad to say, the romance ended the moment I realized what two-way data-binding was, memory leaks when destroying views, and the need for good message passing. Backbone had none of it, and I told her about it. Then one day she came home dressed as Marionette (marionettejs.com), and I hardly recognized her. I found her to be complex and abstract. She was no longer the simple and elegant framework I knew, and so I moved on...

And soon enough, there I was out at the meetups again. That was when I met Angular. I found her opinionated, and a really domineering. However, she was from a well known and respected family. Besides, I was happy to be with someone who took care of so many things. But that comfort came with a price. She wanted me to do things her way, and do it without much documentation. She just wanted to me to "get it." But it didn't click. And so I gave her the "its not you, its me" talk, and I moved on.

See a pattern here? I think many devs can relate. Let me explain:

TL;DR

Frameworks are like relationships. The only way you can get the most out of it is to fully commit yourself to it -- using the good parts and working around the bad. The sooner you realize this the better, because you will stop wasting your time with frameworks who don't do more than offer a weekend thrill with TodoMVC.

BTW: I'm now in a polyamorous relationship with Flux and ReactJS, and it is wonderful.

<comment><AUTHOR> What did you do when the infatuation with Angular wore off? Did you see the project through to production release? Was your employer satisfied with the outcome?

<comment><USER3> Fortunately there was no app built in Angular -- it was Backbone. We saw it through to the end, and everyone is happy (at least no one was fired). But you don't want to look at my git commit messages. Lots of cursing at callbacks and async hell.

Big lesson kids: When learning a new toolkit or framework, build a toy project you can discard when it is over. That way there is no technical debt, and you will be better able to analyze and decide if this is right for the Big Project(tm) ahead.

That is what I did for React and Flux. I took some hours at work and at home to get up to speed with a small PhoneGap app. Once I was satisfied, I presented to my team. There were some questions and feedback, and it made evangelizing much easier -- it sold itself.

</comment></comment></comment><comment><USER4> They're not, depending on how much experience and understanding of Javascript you have it can be a painful experience. In my opinion, I've experienced AngularJs in a few projects, the learning curve was a bit longer then I expected but the community helped me a lot, plus there's lot's of tutorials and also, you don't need to learn everything and it's not that big in comparision with Backbonejs that depends on Underscore, jQuery or ZeptoJs, etc.

On SailsJs I tried for a bit, but all the NodeJs frameworks are in a different league, so I think you shouldn't really compare them.

Some tips, there's this website called echojs.com (like hacker news for the js world), there's also frontendmasters.com with really good learning resources for a small monthly fee from experts all around the world.

I've been working as a Full Stack Developer for a long time and now decided to do just front end development and I couldn't be happier with the state of tools we have nowadays, specially for debugging: Chrome, Firefox, etc. For example, have you checked the new Firefox feature that allows you to get the list of event listeners attached to a DOM element ? That's sick! What about remote javascript debugging ?

In the end of the day, maybe javascript is not for you or you need some more time.

The new kid on the block is famo.us! Have a look!

<comment><AUTHOR> Thanks for those resources, I will keep an eye on them.

 _The new kid on the block is famo.us! Have a look!_

That's sort of my problem with these frameworks. A neverending explosion of new frameworks that haven't been thoroughly field tested. Meanwhile existing frameworks move on from their 5 minutes of fame and fall into obscurity / deprecation.

</comment></comment><comment><USER5> The Flex community (before steve jobs killed it) had the same issues - <USER2> week a new client-side framework would come out and try to re-define client- side MVC.

The best framework I found back then was RobotLegs, which was an MVC(s) framework which I loved because it was more of a set of patterns you followed. Dijon.js [https://github.com/creynders/dijon](https://github.com/creynders/dijon) is a port of Robotlegs to JS which seems cool. It just provides dependency injection and leaves the MVC part up to you.

Flux seems like the way to go, IMHO. It is more of a set of patterns rather than a "framework". It's a lot to grok at first though.

I'd look at Fluxor [http://fluxxor.com/](http://fluxxor.com/), or Reflux [https://github.com/spoike/refluxjs](https://github.com/spoike/refluxjs), which both seem to make Flux a bit simpler.

(I do agree with you that the state of frameworks now is ridiculous)

</comment><comment><USER6> It's not clear to me what you're expecting from a JavaScript 'framework'. It seems like you're looking for an all-encompassing backend and frontent framework?

Try to go for a more loosely coupled approach and look beyond MVC[1] frameworks in general. I'd suggest trying React for the front end. It's not a framework, but it will definitely influence the general architecture of your app. That is, you'll probably end up using some form of 'Flux'. [http://facebook.github.io/react/docs/flux- overview.html](http://facebook.github.io/react/docs/flux-overview.html)

[1] Nothing wrong with MVC as an architecture, but most attempts to reify in a framework don't work out IMO. Pretty much same goes for OOP.

</comment><comment><USER7> I completely agree. There's something really wrong with the approaches.

They're both too complex and too simplistic at the same time. BackBone and Angular in particular demand a lot of code to do simple things and still fall apart in large scale production.

The best I've seen is [https://muut.com/riotjs/](https://muut.com/riotjs/) which is basically just a collection of JS-objects and a router. But it's far from useable because they've tried to cut corners, and lacks all sorts of documentation.

<comment><USER8> It might just be the complexity of the language almost lends itself to complex approaches for relatively simple tasks.

<comment><USER7> True. But odder still that frameworks would need even more complexity.

</comment></comment></comment><comment><USER9> It's a consequence of too many choices. A new framework pops up showing great promise. Nothing is every fully polished to begin with but before it can gain widespread adoption where contributors fill in the blanks, a new kid on the block shows up and any momentum with the first one is lost as people move on looking for grassier fields.

</comment><comment><USER10> Maybe you've outgrown frameworks in what you do? Frameworks are built up to take care a host of situations usually in a specific way or another, but they aren't a panacea.

Sometimes you have to take down the "rails" and chart your own path.

</comment><comment><USER11> It's not that these are 'just bad', it's often that these frameworks often did not have much time to mature.

You just can't compare the JS libary ecosystem to something like e.g. the Java ecosystem which had much more time to grow and mature.

</comment><comment><USER12> Good question, wondering the same. Although not tried many JS libraries and supposedly the Chrome dev tools are top notch. Going to follow this..</comment>


The History of the Diode - <AUTHOR> http://hackaday.com/2016/08/15/history-of-the-diode/ <comment><USER2> I'd never seen a mercury-arc rectifier before. I'm going to guess those couldn't be deployed outside. Apparently there were still some in use until 2012, though.

Can't imagine the clean up effort if the glass breaks.</comment>


High-Assurance Crypto Software (DJB and Tanja Lange) [video] - <AUTHOR> https://media.ccc.de/v/36c3-10893-high-assurance_crypto_software <comment><USER2> Did something come out of the accusations against both? Did the University Eindhoven investigate?

[https://news.ycombinator.com/item?id=13891513](https://news.ycombinator.com/item?id=13891513)

<comment><USER3> The 'accusations' seem quite mild to me. It was alleged that DJB and Tanja did not take appropriate steps when someone approached them with a warning that one person they were engaging with (who has since become somewhat infamous in those circles due to the sheer amount of serious allegations against them) was possibly a bad actor. It strikes me as something that happens all the time, and while ultimately suboptimal and perhaps less than professional, I'm not sure that it should reflect all that badly on them.</comment></comment>