A Life Apart: The Toll of Obesity - <AUTHOR> http://www.slate.com/blogs/behold/2015/04/02/lisa_krantz_a_life_apart_the_toll_of_obesity_photos.html?wpsrc=fol_fb <comment><USER2> obesity, even if not at this levels, is an understated problem, and seems to me the US is one of the worst hit.

If you can, I'd recommend watching "Fed Up" [0], a documentary which tries to show that the problem is a bit more complex than just people being lazy ("light" food being effectively worse, complete lack of food education, lobbying at it's worse etc). As many documentaries, it has a rather clear agenda, but it's interesting nonetheless.

[0] [http://en.wikipedia.org/wiki/Fed_Up_%28film%29](http://en.wikipedia.org/wiki/Fed_Up_%28film%29)

<comment><USER3> I'm on the opposite camp and think Fed Up is not a good movie to watch and seems the author (Kuric I think) had a bone to grind mostly with the fast food and shitty food industry.

I remember a scene about a mother going to the store, and buying 'light' oreos/chips/other stuff, and giving that to their kids instead of the regular ones to their kids and then complaining he didn't lose weight and taking as a conclusion that 'dieting' and 'exercise' doesn't really work. Never considered that maybe a carrot stick or an apple would be better, she would just buy diet soda/cookies/chips.

<comment><USER2> that is way I said that the movie has a clear agenda, but what you point out is exactly what she said is one of the problems:people believe that they can buy "light" stuff and that will be ok when it's in fact worse than non-light.

This is very much the same as for cigarettes, and why the "light" label on those has been banned for years.

<comment><USER3> I watched it a few months ago so I maybe confused, but wasn't one of the main ideas the movie tried expose is that "move more, eat less" didn't work? I may be confused, but I think she spent a good part of the movie trying to explain why that didn't work by using cases like the 'light' food family for example.

<comment><USER2> yes, the movie makes a big deal of the fact that "just be more active" is not enough, and I agree with you that she seems to push it too hard.

But she made it in relation to the fact that for some categories (i.e. the US has had a constant increase in obesity for kids ages 2-5 which are not naturally not "sitting all day" types) moving more is not enough, and I felt the underlying points are still valid (school food is crap, adults are unable to understand what "healthy food", that "eat healthy" is not "eat less" etc).

</comment></comment></comment></comment></comment><comment><USER4> Personally, I feel like the media frequently tries to over complicate the issue of obesity and make excuses for people who can't lose weight. The individual depicted here clearly has underlying psychological and substance abuse problems, but in no way is he reflective of the general population of obese individuals.

Baring psychological issues, it's really not hard at all to pick a diet and adhere to it. It literally requires a few hours of upfront effort and a bit of time each day. I was able to go from about 300 lbs as a 6'3" male to 210 lbs with significant muscle mass added by following a basic diet and lifting 3 times a week, and I literally started on a whim.

If you want to lose weight, I would start by getting an idea of what you already eat using [http://www.myfitnesspal.com/](http://www.myfitnesspal.com/)

Once you get an understanding of your habits, head on over to [http://iifym.com/iifym-calculator/](http://iifym.com/iifym-calculator/) and select a diet plan which will make you the happiest (low carb, low fat, zone, stricty calorie deficit etc). Every morning, plan your meals using myfitnesspal and the output from iifym.

It's really that simple.

<comment><USER3> It really isn't and I say this as someone that never went over 180 pounds and is usually around 12% body fat.

Just the 'lifting 3 times a week' will take out a lot of the working population out of the picture. Why? If include commute to gym, working out time and shower/etc, we are looking at least 6 hours per week. Add the gym costs/going to the gym costs and you have maybe 100 bucks a month as a cost. We are fortunate we can spend that time/money on ourselves, but seriously, a lot of people can't. Heck, if you take 80% of the comments here in HN how they work 60+ hours a week in their startups, I doubt even us techies will have the time to do so.

In my country (and I think the USA as well) obesity is highly correlated with low income.

Then you have the psychological aspects to it. Stress is a major contribution to over eating. If everyday you are worried if you have enough at the end of the month for rent, you wont stop, go online, get a recipe, go to the grocery store to get fresh vegetables, come on, cook for an hour to have a nice healthy meal... You most likely will pick up a microwavable lasagna and be done with it.

I don't disagree with you that losing weight is easy, it is, basically "eat less than what you need", but being able to do that, based on many many factors isn't as easy.

(congrats on the weight loss)

<comment><USER5> The average American spends 3 hours per _day_ watching TV. To find 6 hours/week, it's just a matter of turning off the TV for 2 hours, 3x/week. [http://www.bls.gov/tus/tables/a1_2013.pdf](http://www.bls.gov/tus/tables/a1_2013.pdf)

As for not affording a gym, that's nonsense. Bodyweight fitness exists and it works great.

Last year I met a super skinny tall Indian dude. He asked my help on how to get in shape (I'm tall but not so skinny), so I invited him to join me for a bodyweight workout in the free public park. He joined me, stuck with the program ("if you do 7 pushups today, try 8 tomorrow"), and got into considerably better shape.

He works 6 days/week and probably earns about 10,000rs/month ($150, maybe $300-400 after adjusting for cost of living). He can't even afford an internet-capable phone to visit the /r/fitness FAQ. Rather than making excuses, he just decided that fitness was more important than TV and made it happen.

<comment><USER6> > Bodyweight fitness exists and it works great.

Damn right it does. I struggle with weight, and have done so all my life. After my divorce 7 years ago i piled on the kilo's. Combination of overeating, and being lazy. I started a gym a few times, and got personal trainers involved at some point. All the same thing: pound the treadmill and stairmaster for an hour, and go home.

I have been on and off diets and few, if any, are long term doable for me.

Last October, I hooked up with a personal trainer who is totally awesome, and got me into the "if you do 7 today, try 8 tomorrow" perspective. The first weeks were brutal, and very, very hard, but his approach was to find my limit, and push me ever so slightly over it. I used to go 3 times a week, half an hour, early morning. Now I also join in with evening sessions.

Everything we do is bodyweight training, boxing, kickboxing, and some cardio workout. No running (it would destroy my knees anyway), just simple stuff: squats, pushups, pull ups (from a horizontal position, working to "proper" pull ups), etc. His mantra is "small victories, every day".

It works. Although he does give me gentle nudges about my eating habits every now and then ("eat less meat, more green veg. Drink water with lemon") he emphatically doesn't want me to worry about dieting. "Get fit, and the weightloss will follow".

I have lost about 20 kilo's so far, feel better than I have in a very long time, and have an unbelievable amount of fun doing it (I am lazy, and I hate working out)

Bodyweight training is where it's at.

</comment></comment></comment></comment><comment><USER7> This was almost me at some point. Thankfully I got out but it's a constant struggle.</comment>


JavaScript API for authenticating your users without requiring a password - <AUTHOR> https://github.com/handshakejs/handshakejs-script

<comment><USER2> This is less interesting than I thought it would be. I wrote something similar a few years ago, but it would text you a code (as opposed to email).</comment>


Can Linux use the (supposedly) expired font hinting patents? - <AUTHOR> http://brainstorm.ubuntu.com/idea/24276/

<comment><USER2> My understanding is that this is pointless, or perhaps counter-productive.

While the patents are owned by Apple, they are not necessary to achieve the Mac OS X look, rather they are needed for old skool Windows style fonts. Think about how old this technology must be if the patents are expiring and what fonts looked like then.

I set Ubuntu to ignore hints entirely and it looks just like Mac OS X. Just compare a simple free font with no hints on Mac vs. Windows or read here about CSS fonts looking rubbish on Windows.

[http://www.fontsquirrel.com/blog/2009/11/what-to-expect- from...](http://www.fontsquirrel.com/blog/2009/11/what-to-expect-from-our- font-face-generator)

This site tells you how to get the windows look on Linux, I've not tried it because that's the last thing I want but it talks about the patented code I think.

<http://www.sharpfonts.com/>

<comment><USER3> Isn't hinting taken into account even with sub-pixel antialiasing? I believe that's why Windows fonts appear more crisp

[http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0120a86...](http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0120a86d908c970b-pi) vs [http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0120a86...](http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0120a86d90b0970b-pi)

I miss the sharp glyphs :-/ Now that Win7 has vertical subpixel antialiasing for smoother scrolling, I really feel OSX needs an improvement of it's font rendering system.

<comment><USER4> If you would read the update to the article that those images are from, you would see that the differences are due to OS X and Windows using the same information differently. Neither one completely ignores any of the hinting or sub-pixel information. The Windows font renderer is optimized to improve Microsoft's idea of readability on moderate-resolution displays. The OS X font renderer is designed to preserve the look of a font more, so that your screen is a more accurate reflection of how it would look on paper. In reality, the readability of large amounts of text is substantially the same across both platforms. (Spacing issues, such as the differences between Word and TeX, affect readability far more at typical desktop resolutions.) The stylistic differences are simply large enough that it can be distracting when you are used to one renderer and you end up in front of another one.

</comment></comment></comment><comment><USER5> This is exciting to me because I firmly believe that installing Linux and getting the feeling that it's just not as fun to look at is important. The idea that ubuntu could have some weight to throw around is exciting too. Is there a way someone could donate to this cause specifically? Maybe it's not that far along yet..

I hope this goes somewhere!</comment>


Comcast wants to put bandwidth hogs on a diet; Considering 250-gig monthly cap - <AUTHOR> http://www.alleyinsider.com/2008/5/what_does_comcast_s_250_gigabyte_download_cap_mean_

<comment><USER2> It starts off with a 250GB cap...

1\. What happens when they institute plans based on a cap?

2\. What happens when we become more media rich and everyone is downloading HD content?

</comment><comment><USER3> See <http://news.ycombinator.com/item?id=183436> for a more active discussion on this topic.</comment>


The Spectre of Caste in Silicon Valley - <AUTHOR> https://www.nytimes.com/2020/07/14/opinion/caste-cisco-indian-americans-discrimination.html <comment><USER2> As a Hindu myself, I am completely disgusted that our religion is perverted in the name of discrimination. The caste system is a horrific remnant that has to be eradicated no matter where we see it.

If you cannot protect our fellow humans with compassion, no matter their creed — then you do not deserve to be a Hindu and you bring shame to all of us.

</comment><comment><USER3> Second and third generation Indian kids will leave all of it behind. It is an anomoly there are so many first generation Indians in the United States at once. It will change. Getting to top level jobs ($500k +) in any workplace is always a struggle.</comment>


Google currency arithmetic with conversion - <AUTHOR> https://www.google.com/search?q=1000+AUD+%2B+135000+JPY+%2B+3000+USD&ie=utf-8&oe=utf-8

<comment><AUTHOR> You can append 'in AUD' or 'in JPY' for example to see the result in another currency.</comment>


Gaussian Processes with Clojure - <AUTHOR> https://www.yieldbot.com/blog/gaussian-processes-with-clojure/ <comment><USER2> For some reason, the typeset math is huge in my browser (Chrome 47 on OSX). The article is difficult to read like this.

[http://imgur.com/nf5wBlo](http://imgur.com/nf5wBlo)

<comment><USER3> I also experience this on my phone (Oneplus X), on both Chrome and Firefox. Opening it on my laptop displays them fine, but if I narrow the window to half the screen, the responsive flow makes them huge again.</comment></comment>


We have a new way to compress text files, watch a stream of its implementation - <AUTHOR> https://www.twitch.tv/fabricnature <comment><AUTHOR> Its hard to get traction huh. :( Anyway I just uploaded some teaser files in hope to intrigue! [https://github.com/fabricnature/index_1337](https://github.com/fabricnature/index_1337)

</comment><comment><AUTHOR> The stream will start today (Friday) somewhere around 10:30 Pacific Time, or 17:30 UTC, or 19:30 Paris, or 02:30 Tokyo (Sat.!). We will be available to answer questions, hear from you, and just talk later on today.</comment>


Fucking Shell Scripts - <AUTHOR> http://fuckingshellscripts.org/ <comment><USER2> Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult.

In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: [https://devopsu.com/blog/ansible-vs-shell- scripts/](https://devopsu.com/blog/ansible-vs-shell-scripts/)

I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing the 2nd edition ( [https://devopsu.com/books/taste-test- puppet-chef-salt-stack-...](https://devopsu.com/books/taste-test-puppet-chef- salt-stack-ansible.html) ). Even for an experienced sysadmin, using Puppet and Chef to do even a trivial project (replacing a ~10 line shell script) took a painful couple of days. Why? They're overly complex and have confusing broken documentation (that mostly haven't been corrected even 6 months after I gave them a full breakdown on the issues). Salt was pretty smooth, but Ansible was downright easy.

Using a shell script to set up a server generally indicates that it will then be managed manually afterwards (sadness and despair!).

A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely.

An idempotent command will verify that the system is how you defined it and will only make changes to bring the system back into alignment with what you defined. That means you can define your system in the language of the CM tool and use it not only for initial system setup, but also for monitoring, updating, and correcting a server's configuration over the life of the server.

A CM tool can ultimately act like a self-healing test suite for your systems - neat!

Your systems are the "app" that your app runs on. They're the foundation. Not using a CM tool is like not having any tests for your app. Sure, it might seem faster at first, but you'll pay for it in chaos, slowness, bugs, and misery later.

Shell scripts are a great first step, but if you're serious about your systems, you need to be using a CM tool. Modern ones like Ansible are simple, easy, and have great docs so there's little excuse left for not using one now.

<comment><USER3> I use a Bash script to set up Arch with Btrfs on LUKS and optionally enable SSH [1]. Assuming you have a base machine running, config management tools are great and quickly start to make sense. If you're starting from scratch with a blank physical machine, I think the answer is still shell scripts and then add on CM afterwards.

1: [https://github.com/atweiden/pacstrapit](https://github.com/atweiden/pacstrapit)

<comment><USER4> "I think the answer is still shell scripts and then add on CM afterwards."

I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.

<comment><USER5> you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.

<comment><USER6> Actually, to use Ansible you need only ssh access (with password or public key) to root user. Everything else can be done easily in a simple Ansible role.

<comment><USER7> In fact you can specify the user, you can have a dedicated user with sudo for instance.

</comment></comment></comment></comment></comment></comment><comment><USER8> Coauthor here. Well, this is a surprise! This project was mainly borne out of our frustrations with Chef and then Ansible for configuring our servers.

A few thoughts: 1) This project is incomplete and is more of a concept than anything. We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time.

2) There _is_ value in what Ansible provides. It does a lot of things for you. FSS did not replace ansible where we work.

All that being said however, I feel like this (or a project like this) does have merit, if executed properly. I feel that once you get used to how FSS works, it might be a good solution for you. We intentionally tried to keep it as simple as possible.

<comment><USER9> It's pretty funny, but it's an example of where we do NOT want to be headed.

The Unix philosophy is a set of tenets based on assumptions that held in the 1970s and 1980s, but don't really hold today. One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct."

This may have been true in an era when every site had to roll a homegrown solution for pert-near everything that didn't come with the base OS, but in this era of open source it is far more important for the implementation to be correct, because the Right Thing can be written once and everybody can use it, and save themselves the accumulated hours of frustration incurred by simple- but-subtly-incorrect implementations.

This is why the Linux world is standardizing on systemd -- to get AWAY from Fucking Shell Scripts and towards a more deterministic, declarative model of what we want done. In the case of configuration management, what you want is a tool that accepts a description of what the system configuration should be, diffs that against the current configuration, and enacts a plan of changes to get from point A to point B automatically. NixOS seems to be a good step in this overall direction.

Fun fact: I used to do instancing of robotic control computers running a specialized version of Debian with Fucking Shell Scripts (FAI, to be exact: [http://fai-project.org/](http://fai-project.org/) ). It was pure hell. We would have killed for a more deterministic solution.

<comment><USER10> Simple is almost always Correct.

Conversely, complex is almost always incorrect.

<comment><USER11> Strongly disagree. Often complexity in your implementation is necessary to present a simple interface to your user.

<comment><USER12> The primary user of your implementation is the next developer to maintain it.

<comment><USER11> The user of a piece of software is more important than its current or future maintainers.

<comment><USER13> Yes but current or future users want reliability, features, and speed. If you care about your users in the long term you should care about the project's maintainers.

<comment><USER11> I suggested a relative ordering of importance; nowhere did I imply that one was important and the other was not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14>
      "Wanna just use fucking shell scripts to configure a server? Read on!"

      Step 0: Install the gem

      # gem install fucking_shell_scripts
      # gem: command not found

wat.

<comment><USER15> Most people coming from chef would have done the drudgery of msking surr ruby works.

<comment><USER16> chef installs as omnibus, so you're suggesting that people should install the massive chef stack, and then the FSS gem?

_brilliant_ !

<comment><USER15> Well this is clearly aimed at people who are frustrated with Chef, above and beyond the frustrations of figuring out how to install ruby (just install from source, rvm sucks).

If someone doesn't already have Chef installed, why would they even have clicked on this link?

</comment></comment></comment></comment><comment><USER17> Honestly this is not a bad idea. Since bringing up a new instance VM will always be in exactly the same state, the shell script is completely deterministic. If any line fails to run, you could simply log an error and automatically shut down the VM.

The bash script itself is also extremely straight forward and is easily testable with a built in REPL (you know, bash). Anybody who vaguely knows unix is also going to be able to understand and maintain the shell script. Adding in new dependencies is simple. It's easily portable and you don't need to do any extra work to add in new features. I can't even think of a drawback.

<comment><USER18> Typically shell scripts are fine in the beginning, but over time the complexity rises and it becomes an unmaintanable mess, and you'll end up reimplementing it in a proper programming language.

Shell scripts are not easily portable either, unless by "portable" you mean "works in Linux". Node.js scripts, for example, really (mostly) work on Linux and other platforms like Windows.

Until you hit some nasty "path is longer than 254 characters" bugs. Oh well..

<comment><USER19> Shell scripts are extremely portable and should be the preferred method for a large set of tasks. Properly written, a shell script can run on a 20 year old Solaris machine, any version of Windows (with installed tools like Cygwin) and any modern Unix variant... claiming Node.js is more portable is ridiculous on so many levels.

The problem is so many programmers don't take the time (or care to take the time) to learn to use the well thought out design of Unix tools opting instead to see every problem as a nail corresponding to the latest trend in hammers (programming languages).

This has led a lot of programming types to create advanced tools for managing Unix systems which largely ignore the design of Unix.

<comment><USER20> It's _hard_ to write a portable shell script. My dotfiles need to be portable, and they involve a lot of shell. Every time I introduce a new OS, I have to make changes. Various oddities get you. These, for example, look really innocent but aren't portable:

      find -iname 'foo*'  # [1]
      ... | sed -e 's/ab\+c//'  # [2]
      ... | sed -i -e 's/abc//'  # [3]
      tar -xf some-archive.tar.gz  # [4]
      python -c 'anything'  # [5]

Things like messing around with /proc are more obvious, but things like curl (is curl installed? what do we do if it isn't? try wget?) can be hard too.

[1]: find doesn't assume CWD on all POSIX OSs [2]: "+" isn't POSIX. You have to \\{1,\\} that. [3]: -i requires an argument on some OSs. [4]: This is stretching the definition of portable a bit; I've worked on machines where you _had_ to specify -z to tar, given a compressed archive. (tar has been able to figure out compression on extraction for well over a decade now, so -z is usually optional, but some places are _really_ slow to upgrade.) [5]: Unless anything is a Python 2/3 polyglot, you'd better hope that you guess correctly that Python 2 was installed. (And it's really hard here: python is either python 2 or 3 on some systems, depending on age & configuration, with python2 and python3 pointing to that exact version, but on some machines, python2 doesn't exist even if Python is installed, despite PEP-394.)

<comment><USER19> It's a well known fact that GNU tools have plenty of extra features which you have to be careful about using if you want portibility AND that many of the legacy commercial Unix implementations have positively ancient implementations and feature sets. I wouldn't really say it is so very difficult though.

Every script you write isn't going to be portable, but it's not that much of a stretch to endeavor to keep your script simple, not make assumptions, and be mindful of the potentially missing features of some implementations.

I take a special objection to [5], `python -V` isn't difficult at all to run, hoping and guessing are not necessary.

There's a good guide here: [http://www.gnu.org/software/autoconf/manual/autoconf.html#Po...](http://www.gnu.org/software/autoconf/manual/autoconf.html#Portable- Shell)

<comment><USER20> > I take a special objection to [5], `python -V` isn't difficult at all to > run, hoping and guessing are not necessary.

I mostly meant that in a simple statement of:

      python -c "code"

…you're probably forced to assume that it's Python 2 (or write a 2/3 code) and hope that your assumption is right. You can't run `python -V`: you're a script! The point is that it is automated, or we wouldn't be having this discussion.

Of course, you can inspect the output of python -V (or just import sys and look at sys.version_info.major) and figure it out, but now you need to do that, which requires more code, more thought, testing…

<comment><USER21> I'd argue that you should probably stick to one subset of things in your bootstrap script -- and I'd say grep, awk, sed and (ba)sh go together, anything "higher level" like python/ruby/perl/tcl does _not_ fit within that. You might want to check for python with a combination of "python -V" and the dance described above -- and, as part of bootstrapping, make a symlink (or copy, if you need to support windows and/or a filesystem without symlink support) to eg: python2. Save that tidbit as "assert-python2.sh" and then first "assert-python2.sh" then "check-bootstrap-deps.sh" and finally "bootsrap.sh" :-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> After 4 years of heavy Cheffing, I completely agree with most opinions expressed here. I'm pretty sure Puppet is just about the same, I have 0 experience with it though, I won't claim otherwise.

I got frustrated enough with the Capistrano, Fabric, Puppi lot that I wrote a pure bash deployment tool with a fitting name htpps://github.com/gerhard/deliver.

Ansible on the other hand is something else though. There is some learning curve, agreed, but it's not as bad as awk or sed. And seriously, if you know your bash, you will know both awk and sed. I consider my shell scripting to be above average, and I've attempted a Docker orchestration pure bash tool [https://github.com/cambridge- healthcare/dockerize](https://github.com/cambridge-healthcare/dockerize), but Ansible just makes the same job easier. It's not everyone's cup of tea, but before you dismiss it, give it a real chance. I should know because I have initially dismissed it thinking that it's too complex, yet another Chef circus, yada yada, but trust me - it's worth it ; )

</comment><comment><USER23> I spent the last year and a half cross-training from dev to ops.

One of the most important lessons I learned: use operating system packages for production; don't compile from source.

Compiling from source:

\- Wait minutes for each instance to come up, as each time requires a fresh compile

\- Have to download from ruby-lang.org -> you have a dependency on this site being up, bad idea when you hit a load spike, need to scale, and ruby-lang.org is having a bad day

\- Loss of dependency management. Now you can't tell whether your environment has the right packages installed, nor can other things express a dependency on your code being installed

\- Very difficult to remove packages for upgrades/maintenance/security fixes

Packages:

\- Host your own repo, removing the need for external dependencies (can do this with source as well, but it's much better when packages know to discover themselves from a repository)

\- Much cleaner rollback -- almost impossible to trash a system with apt- get/yum, they'll always leave you in a good state in case the package fails to install, or other mayhem ensues

<comment><USER10> Agreed. Tracking all those versions for security vulns is a major pain as well. Unless you absolutely positively must have X new feature that's only in upstream, DON'T compile it yourself unless you're prepared to pay that price.

</comment></comment><comment><USER24> The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you can just write in whatever scripting language you like/gets the job done and not need to worry about learning a new domain-specific configuration language.

Does anyone else here see value in a configuration management system that centers around installing files and running scripts, much like FSS? I'm contributing to, and using in production, a configuration management system that takes this approach. It's a lot more mature than FSS, but unfortunately the primary author isn't ready to open source it yet. If there's some demand for it, maybe I can convince him to hurry up.

<comment><USER25> This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons.

Bottom line, if you are just running a small startup with a few servers and a few people, then by all means use FSS, but eventually you will need real CM.

<comment><USER24> The CM system I'm using "journals" every change it makes to the system, so if you later remove or change a file or script in your CM repository, it undoes the old change. This eliminates virtually all configuration drift, provided you aren't making changes by hand outside of the CM system (which you should never do anyways).

This system has been managing about 100 servers and several hundred desktops at a single site since 2009, so the approach does scale. It has some problems that declarative solutions like Puppet solve, but at the same time it solves problems that Puppet/Chef/others have.

<comment><USER26> Which CM system?

</comment></comment></comment></comment><comment><USER27> Having begun using Chef over the last year I've found that my problem has not been so much with chef (a major issue with how it deals with when/whether to restart services aside) itself but with the community cookbooks. This is where the overcomplexity tends to come in in my experience.

I'm not sure you can genuinely have a good provisioning script that treats _all_ of these things as variables in a matrix:

\- OS (sometimes including windows as well as linuxes and bsds)

\- OS version

\- Using system packages or building from source

\- Package/source version

\- Every single config variable the program/service can have

Every time we use a community cookbook, which includes several hundred plus lines of code to deal with platforms we will never ever deploy to, it ends in tears eventually.

Having a 20 line recipe that works on the Ubuntu LTS we've standardized on is much closer to what FSS can achieve, but even then it does often make simple tasks considerably more difficult.

</comment><comment><USER28> > gem install fucking_shell_scripts

This fucking sucks.

</comment><comment><USER29> So... this is basically just one module from Ansible, plus some obscenities?

<comment><USER30> Which is another way of saying it's Ansible without all of the stuff you don't need (plus obscenities).

<comment><USER31> We can add obscenities if you want :) We do have cowsay integration though. (There are some questionable cowsay modes!)

That all being said, the thing missing here between any of these tools is most obviously the resource model -- and the templating system and where you put variables and things to manage variance between systems. Thus, it will blast out some commands for you, but that is the easiest part of the equation -- not too much different than say, doing something from Capistrano or Fabric.

Even in Ansible, that's the part we built first.

Achieving idempotence in shell scripts is the reason most people move away from shell scripts, and also ... well, the desire to program less :) Then you'll want the rolling update features, or provisioning, or dry run, or a way to pull inventory from cloud sources, or... and you'll streamroller a bit.

The balancing act for us is achieving the right level of features vs language complexity and keeping in that sweet spot.

I still think you should have an easy time getting started, see also things like [http://galaxy.ansible.com](http://galaxy.ansible.com) for community roles to download to go faster -- most people should be able to do basic things in a few minutes. The _script_ module in particular is a great way of pushing a f'n shell script :)

[http://docs.ansible.com/script_module.html](http://docs.ansible.com/script_module.html)

(full disclosure: I created Ansible, but I did not shoot the deputy)

<comment><USER32> You just sold me on trying ansible.

</comment></comment></comment></comment><comment><USER33> I too think the name is bad, but for a different reason than everybody else. Without context, it sounds like the name is complaining about shell scripts; where the project itself endorses them. Before I clicked the link, I was expecting to come here and write a defense of shell scripts.

</comment><comment><USER34> Every time I go to write a shell script I'm like "do I need to put quotes around this variable to interpolate it? How do I do looping again?" then I give up and use Python or Perl or something.

<comment><USER15> I guess you could load your favorite language runtime. That sounds like a one line change. In your shell script. Which is the point. I'm betting at some point you look back and realize that much of your config doesn't need a secondary language.

<comment><USER35> How would you take a template file, fill in some values, copy it to a certain path on the server and give it the right permissions? With, say, Python, I'd have to read the file, using mako or jinja to fill in the values, scp the file to some temporary file, then somehow run Python code on the server using SSH to copy the file and give it the right permissions.

With Ansible, this is a single line.

<comment><USER15> Let's see... I would take the template file, fill in some values, scp it up to it's final location on the server, and run chmod on the server.

I guess I could learn the "one-line" ansible way to do it, but I'd also have to learn to set up ansible. And I'm guessing it's not as flexible as, say, shell scripts.

<comment><USER35> The cool thing about Ansible is that there's no set up. You install it, write the config and run "ansible-playbook <config>". It connects to the nodes using SSH and runs without having to be installed in them.

As for not being as flexible as shell scripts, I'd say that's technically impossible, since it has a command for running shell scripts :) Personally, I never had to use it, but it's there.

</comment></comment></comment></comment></comment><comment><USER36> I _really_ like the idea, but the name is somewhat offputting, especially if I were in a position where I had to sell it to management (luckily I'm not). Will definitely give it a whirl, but I strongly suggest considering a name change.

</comment><comment><USER37> It would be nice if there was a way to use this without having to deal with obscenities. Not everyone finds this funny. Useful idea though :) At least for early stage projects, I can imagine it getting complicated quickly.

</comment><comment><USER22> And one more thing: the point of a system management tool is to have no dependencies. If you need to install or use anything other than the provisioner to setup a vanilla distro, you've been hustled. Bash is guaranteed to work everywhere and that's what most love about it - myself including. But Ansible works on my RaspberryPies, on my FreeBSD storage servers and on my production Debians, Ubuntus and ArchLinuxes with no crutches or aids. I had bash scripts before, was really close to open sourcing them, but then I realised there is a much better way ; )

</comment><comment><USER38> 1\. You use unprofessional obscenities in your project title

2\. I don't take your project seriously (perhaps unfortunately)

<comment><USER39> Agreed. It's like some 17-year-old trying to sound cool.

<comment><USER40> Or someone trying to be Zed Shaw.

</comment></comment></comment><comment><USER41> I originally thought this was a lament about how shell scripts suck, like along the lines of "man, those fucking shell scripts ..."

My surprise when I saw this is the _exact_ opposite of that ...

<comment><USER42> This stuff is all fine and good for a few VMs. I wouldn't try to run a serious endeavor using them, unless I really wanted to spend a bunch of time diagnosing, debugging, and sweating.

The reason automation, CM, and devops have taken hold is because people are so goddamned tired of serving technology like it's some kind of god to which we owe worship. Screw that. I want the VMs to go make ME a sammich, not the other way around. Trying to build serious infrastructure using nothing but shell scripts is a quick trip to the temple of server-worship.

</comment></comment><comment><USER43> Got a good laugh out of me, seems a little hypocritical to depend on ruby (which chef et al. use)

So far I only have experience with puppet, and it seems really annoying to tie phases like "install postgres" -> "Reinitialize the database in UTF-8, but known to work on ubuntu" -> "Update the configs so non-localhost connections can actually connect" -> "Okay, now it can start."

The above problem is something I do not want to deal with when it comes to a provisioning system.

<comment><USER44> Author here: fair point. Ruby is only required for the client that's building machines. Ruby is our primary language so it's on all of our servers and laptops. Less about thought and more about lowest barrier to entry ;)

<comment><USER43> Seems like bash (or insert your favorite shell here) would be THE lowest barrier of entry on any Linux, BSD, whatever host--perfect for this project! :-)

</comment></comment></comment><comment><USER45> Who in their right mind wgets and builds software on a production machine...?

<comment><USER46> I actually do this with one piece of software, and that is PostgreSQL. I know it in and out, it's easy to upgrade via source, and I prefer to put the database in a bundled location e.g. /data/postgres or /home/postgres... instead of /var/lib/postgresql/9.1/main, /etc/postgresql/9.1 et cetera.

<comment><USER35> Why not just build your own packages? fpm[1] is very simple to use.

[1] [https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm)

</comment></comment></comment><comment><USER47> Hahaha, I love that the install process is more complicated than the example shell script.

</comment><comment><USER48> Please do not wget files over HTTP (no S) and just run them, as the example script does. Have the script run the downloaded file through sha256sum and check the output matches what you expect.

I know that was only an example script, but we don't want to be encouraging bad practices here.

</comment><comment><USER49> Having managed 10's of thousands of servers and multiple hundreds of configurations at a big web company for many years, I completely see where OP is coming from.

I think a huge problem with puppet/chef is that they try to do it all, ie deployment and OS state management and make it work with vendor specific package management systems.

Unfortunately rpm/debian based package mgmt systems are not well suited for complicated deployment strategies. Most companies I worked at come to a solution similar to:

      * Install everything you need in /package_versionstr (except say glibc)
      * Point the current version with a symlink

This enables you to do a simple atomic rollback/rollforward and is much easier to reason compared to complicated pkg state.

For simple OS config management (say usermgmt, sysctls), we used a system similar to the ideas expressed by OP.

1\. Keep it simple. puppet/chef have horrendous DSL's that make it really complicated to reason about. I shouldn't have to debug a backtrace 15 levels deep to understand why an useradd didn't work.

2\. Server side logic. Don't try to do "intelligent" stuff based on client side state, it will be almost impossible to get it right. All data needed for state needs to derived by group membership. This helps in * validating all changes upfront * diffs for state changes across a group of nodes.

3\. No orchestration. Except any changes to be applied at any time. This acts as an enforcing function to make your scripts idempotent.

</comment><comment><USER50> This actually looks like as much if not more work to set up than Ansible. As soon as you start talking about required directory hierarchies, you've lost the "just f###### do it" feel. Then I still have to write a special YAML file, and then my scripts.

The Ansible setup for my personal server started as two files: an inventory file consisting of an ip address, and site.yml. My ignorance (and some installation issues) notwithstanding, it has scaled pretty smoothly from there to copying up config files, templated nginx config, and so on. I don't see much room for anything between that and a literal "just f###### shell script".

</comment><comment><USER51> If you really want some fucking shell scripts:

[http://www.nico.schottelius.org/software/cdist/](http://www.nico.schottelius.org/software/cdist/)

</comment><comment><USER52> This is simply brilliant! I've dreamt about such tools. And now you have reached into my dream and turned it into a reality. We might as well be soul mates you and I.

</comment><comment><USER53> I've been doing almost exactly this for years, always ashamed that I didn't take the time to learn a "real" tool like puppet. Solidarity.

</comment><comment><USER54> There are two ways to debug something:

1) Step through the program, try to think of logic errors etc.

2) Do a binary search through your latest commits and see where something broke.

Those are your two clues.

</comment><comment><USER55> As someone in the PHP community, I've made something similar (Vaprobash - "Vagrant Provision Bash Scripts") with the goal of helping people learn more about what goes on when setting up servers for use (installing web servers, databases, configuration, etc).

[https://github.com/fideloper/Vaprobash](https://github.com/fideloper/Vaprobash)

</comment><comment><USER56> It's not a good name. Outside of the Valley, where youth and irreverence do not dominate, the name makes this a non-starter.

<comment><USER57> Actually, i think the name goes over rather well in London, where we like swearing (and shell scripts) quite a lot.

</comment></comment><comment><USER58> Don't get me wrong, I'm the biggest fan of shell scripts and chapeau for writing opinionated software.

However, not having idempotent configuration files seems to be not only missing some of the power of shell scripting but also missing a huge principle of "good" server configuration.

</comment><comment><USER59> If you're going to use ruby, you may as well commit and use sprinkle. You still get to use all the shell scripts you want and you get the deployment power of capistrano. I've really enjoyed using it for my small provisioning requirements.

</comment><comment><USER60> The name is bad.

</comment><comment><USER61> If you're going to go this direction wouldn't it make more sense to just upstart another script that runs your scripts? How much time and code does this actually save?

</comment><comment><USER62> A wrapper for shell scripts with a dependency on Ruby but lacking determinism, templating, etc? In other words a remote command dispatch and execution tool.

</comment><comment><USER63> I gotta know...

Do the scripts reproduce with all that fscking going on?

</comment><comment><USER64> I'm all for anything that makes managing servers easier, but why use swear words in the name? It is unprofessional.

</comment><comment><USER65> another project that needs to discover rdist

</comment><comment><USER66> I ♥ Ansible ...

'nuff said.

</comment><comment><USER67> why do I have to use ruby to install shell scripts? Why not wget or curl or GET?

</comment><comment><USER68> Wait, a gem, a yaml file? What exactly is this doing with my scripts? Can I really expect this to make my shell scripts work across clouds?

</comment><comment><USER69> Guiys, the fucking swearing in the name suks alot. Not all the managers like it. That's why we have perfesionalism, cause prfesionalism is good. Guiys, we haf to get along. We cant do it with swearing. Please, think about pleasing everyone and offending none. Otherwise ur milenials, ruining our designated corprate productivity spaces.

<comment><USER70> _Shrug_

If you want people to use your software -- and you do or you wouldn't be promoting it -- you should consider how you present it. Bad words don't offend me, but they do suggest immaturity and inexperience... qualities I tend to avoid in systems orchestration.

<comment><USER71> I think they were joking =)

> That's why we have perfesionalism, cause prfesionalism is good.

<comment><USER70> Yes, it's sarcastically making fun of people who complained about the name.

</comment></comment></comment></comment><comment><USER72> Wow that fucking sucks. Installing rails to run a shell script, no thanks I think I would rather blow my brains out.</comment>


Show HN: Real time CSS inliner for emails with live preview - <AUTHOR> https://htmlemail.io/inline/ <comment><AUTHOR> Even in 2017, and even with recent Gmail improvements, it is still a best practice to inline your CSS before sending email to ensure they don't fall apart in one of the many clients out there. This tool inlines your styles in real time and provides a handy preview so you can see what's happening.</comment>


What are the crawling horrors of PHP? - <AUTHOR> http://www.quora.com/What-are-the-crawling-horrors-of-PHP

<comment><USER2> I believe this author just doesn't like PHP and doesn't consider that some of these "weaknesses" are actually strengths in the eyes of many. Some of the points are fair, but never show-stoppers, _for the domains that PHP is used in_. You're not going to want to write general purpose or especially heavy duty low level algorithmic code in PHP. It's a web/database glue language at heart.

> # Arrays and hashes treated as the same type

We like this! More specifically, there is no "array"; they are manufactured as dictionaries with integer keys. In practice this works fine, and it's not even algorithmically different, since a hash access is a constant time operation.

> Hash syntax versus class syntax - i.e. $key['value'] versus $key->value

We like this a lot! $array['key'] will access a dictionary. We know it's not going to go through things like subclass rules and overrides, the way an access would in JavaScript, avoiding one of the worst parts of the language, including having to use "hasOwnProperty" for rigorous code.

> # Functions/methods always require parenthesis

Yes, and it's really not clear to me that the "cure" is better than the disease here, and this comment seems a little out to lunch. The standard practice I would think would be to not expose a $person->first_name variable directly in the first place. If you want an object with a flexible key-value coding system, you're free to write one. (And you can override dictionary access [] if you like.)

> No macros

I tremble.

> Writing an array literal requires literally writing out the characters a, r, > r, a, y, ( and ).

Oh boo-hoo. Comments like like this, to me, separate out perfectly the programmers who are interested in getting something done versus seeking a sort of pursuit of academic idealism for its own sake. I can tell he only just managed to resist saying it has braces and semicolons too.

> It depends what version of PHP.

Use PHP 5.

> How do you delimit HTML from output PHP code? <?, ?>, <?php ?>, <% %>? Well, > it depends on some global setting in php.ini.

Use <?php ?> always.

> PHP doesn't have multiple inheritance, fine, but it doesn't have > mixins/modules, either.

We do not want! Locality of code is worth more to us, especially for those of us who have tried to navigate a maze of categories in an unfamiliar Objective-C codebase or something like that.

> If you do enable PHP's E_ALL warnings, you get warnings and errors for all > kinds of crazy things you don't want warnings for.

You're wrong, you really do want those warnings. If you want to turn off deprecated warnings for legacy PHP4 code, you should make that explicit.

> PHP is exceptionally slow unless you install a bytecode cache such as APC or > eAccelerator.

So when it isn't fast enough by default (and it usually is), do that.

> People often abuse include(). Rather than using it to pull in functions and > classes, they use include for actual code execution,

Like in a template mechanism, which is a legitimate use for it.

> Because it is designed to be run in the context of Apache, PHP doesn't work > very well as a command-line scripting language,

A hammer doesn't drive screws very well.

> There is a lack of standards and conventions.

This is called flexibility. You can code within CakePHP or Zend Framework if you want conventions.

> There are a variety of ORMs available all of which suck in different ways,

This is not just a PHP problem:)

<comment><USER3> >> # Arrays and hashes treated as the same type > We like this! [...]

Maybe you do. But I've always found it annoying.

> In practice this works fine, and it's not even algorithmically different, > since a hash access is a constant time operation.

It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. The former is O(n) if you use array_key_exists. From zend_hash_exists:

        while (p != NULL) {
            if ((p->h == h) && (p->nKeyLength == nKeyLength)) {
                if (!memcmp(p->arKey, arKey, nKeyLength)) {
                    return 1;
                }
            }
            p = p->pNext;
        }
        return 0;

>> PHP doesn't have multiple inheritance, fine, but it doesn't have mixins/modules, either.

> We do not want! Locality of code is worth more to us

Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose.

>> Because it is designed to be run in the context of Apache, PHP doesn't work very well as a command-line scripting language,

> A hammer doesn't drive screws very well

This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request.

You can get around that in some cases, but some core language features have been blocking this until relatively recently. E.g. create_function() would always leak memory, but in 5.3 PHP finally has support for anonymous functions.

<comment><USER2> > It is actually. Read the array.c and zend_hash.c code. It's only a constant > time operation if you're not interested in the difference between whether a > hash key actually exists, or whether it exists and its value is set to NULL.

That's weird, and does seem like a wart. But is this really a problem in practice that leads to performance difficulties in real code? (This is not a snippy rhetorical question, I'd be interested in a real world example.) It seems to me that if I'm using a PHP dictionary as an array, I'd know the length, and thus I'd be guaranteed that any access exists.

I also like that arrays being dictionaries gives me the ability to do foreach($array as $index=>$value) if I want, which is nicer than some other languages, though admittedly some dynamic languages do such things better.

> Code that I'd write in Common Lisp or Perl that takes advantage of multiple > inheritance and the composition it offers is a lot uglier in PHP when I have > to hack around not having multiple inheritance. It leads to bigger and > monolithic classes that you can't easily compose.

This is a holy war, obviously, and you do get interfaces at least. It suffices to me to know that I do have some intelligent supporters on the side of disliking multiple inheritance and mixins very much. If you're one of the people who can be extremely productive building large programs in a Lisp style, much respect and power goes to you, and anyone has to concede that PHP will be too limiting in that case.

> This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp > etc. you can't easily run most PHP code persistently, so the execution model > for most applications is to parse, compile and execute the application for > each request.

Agreed, and it is a huge pain when you want to do something after a request but yet you don't want to tie up the user in the mean time.

I'm not sure I'd want PHP to be a language that makes it easy to have a persistent execution model though; that simplicity (and restriction) is one of the things that has made the language so popular and scalable. PHP's model _usually_ works fine for the kind of web-based problems it's intended for.

<comment><USER3> > That's weird, and does seem like a wart. But is this really a problem in > practice that leads to performance difficulties in real code?

Here's some code I wrote in 2005 that ran into this issue: <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/10549>

> It seems to me that if I'm using a PHP dictionary as an array, I'd know the > length, and thus I'd be guaranteed that any access exists.

The use case is the common idiom of populating a hash, and then iterating other hashes and checking if their keys exist in the original.

In the example above I was loading ~50 files with 1000 key hashes each to check if there were any leftover translation strings in the translated files that weren't in the English original.

Because the values could never be NULL I could get away with not using array_key_exists() which reduced the runtime from 60 to 2 seconds. But it's pretty silly that the core datastructures of the language have pitfalls like these.

>> This is actually a major problem [...]

> Agreed, and it is a huge pain when you want to do something after a request > but yet you don't want to tie up the user in the mean time.

> I'm not sure I'd want PHP to be a language that makes it easy to have a > persistent execution model though; that simplicity (and restriction) is one > of the things that has made the language so popular and scalable. PHP's > model usually works fine for the kind of web-based problems it's intended > for.

In some ways, especially the built-in template language. But overall I think PHP as a isn't simple or newbie friendly at all. Its main advantage was that it offered a really simple execution model + Apache module. Which ISPs and others could easily offer along with MySQL, with little administration time compared to offering equivalent shell services.

It was also was one of the first to have friendly online documentation with lots of syntax highlighted example code, and comments where people could submit more examples.

But as a language it was never very competitive, and due to some of the tradeoffs made PHP never acquired a real community of module writers and re- usability. Thus most large PHP code bases end up being big balls of mud compared to equivalent code written with Catalyst, Django or even Rails.

These days it seems to be mostly heading for being a worse Java with more bugs. Unless you have existing code in PHP other languages are probably a better fit for web applications these days.

</comment></comment></comment></comment><comment><USER4> Some of these complaints don't even make sense:

He doesn't like the lack of strict mode, but complains that E_ALL tells him too much; maybe it's telling him too much because he's not writing things correctly, just like 'use strict' would.

He complains that you need to remember the parenthesis for a function call, but short of Ruby, I can't think of any other "normal" language that doesn't. C/C++/C#, Java, Python...

He complains that a whole bunch of things are considered false, but when using the === operator, they aren't.

Always use <?php ?>, and your code will always work, everywhere.

Just because people abuse include() doesn't make it a flaw of the language. Strawman ftw.

Plugins written for one framework won't work in another. Gasp! News at 11...

<comment><USER5> Python has properties to abstract away function calls.

<comment><USER4> So does PHP: [http://www.php.net/manual/en/language.oop5.overloading.php#l...](http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members)

</comment></comment></comment><comment><USER6> Is there any point to this kind of discussion? These kinds of questions have maximum entropy, i.e. if you put a monkey at a keyboard and let it bash the keyboard I bet these are the kinds of questions you would get. One can type up questions of the form "What is horrible about X?" ad museum and not be any closer to creating any kind of value in any form whatsoever.

<comment><USER7> It's not the question that's relevant, it's the answers.

<comment><USER8> And as usual it'll end up with the same old list of reasonable problems, 'unforgivable' omissions and miles upon miles of ridiculous hyperbole. It's started already. Is abuse of includes or goto an inherent problem of PHP? I was abusing includes 15 years ago when I messed with C and my earliest BASIC was the code equivalent of snakes & ladders.

All this kind of thing tends to do is embolden the snobs, put the backs up of the faithful and be of no practical use to any reasonable person looking for honest answers. It doesn't even have the virtue of being a humourous discussion since it's been flogged to death over the whole internet for a decade.

<comment><USER9> Just to pick on the includes example, I think it's fair to point it out as a deficiency if there exist other languages and environments which enable/encourage/force you to get it right. It's not a defence that other languages also get it wrong.

</comment></comment></comment></comment><comment><AUTHOR> Most of these gripes are fixed in PHP 5.3, although the lack of ability to access $this in closures drives me nuts. Aside from that, all languages have minor syntactic issues. Take your pick.

I think the far bigger problem with PHP comes from the culture that surrounds re-use. Writing re-usable PHP is hard, we lack decent package management systems and systems for distributing light-weight packages of code with simple dependancies (I'm looking at you PEAR).

The end result is a culture where re-inventing the wheel is standard practice or at best copy and paste.

</comment><comment><USER10> There's plenty to hate about PHP, but most of my gripes have been repeated ad nauseam all over the internet. Yet one issue that really drives me bonkers doesn't seem to have received the opprobrium it deserves: _Functions can take default named arguments, but insist on referencing named arguments by order, not name._ This is just utterly asinine.

<comment><USER4> That's because PHP is heavily influenced by C and Perl, both of which exhibit the same behavior.

<comment><USER10> What's the point of named arguments if you can't do something like the following (e.g. Python)?

        >>> def some_func(a=1, b=2, c=3):
            return (a + b) * c

        >>> val1 = some_func()
        >>> val1
        9
        >>> val2 = some_func(b=3)
        >>> val2
        12
        >>> val3 = some_func(c=5)
        >>> val3
        15
        >>>

<comment><USER4> I completely agree with you, and I much prefer Python's method of handling it. I was at explaining why PHP acts the way it does.

<comment><USER10> Yes, of course. I wasn't holding you responsible. :)

</comment></comment></comment></comment></comment><comment><USER11> Is there any reason for this: "If a function returns an array, you have to assign it to a variable before accessing an element, you can't just add an index after the function call." ? I cannot grasp why PHP's authors "designed" it this way.

<comment><USER12> PHP's parser/syntax is a bit of a mess. I'm guessing it could incur some sort of inconsistency.

<comment><USER13> Yeah, this is one of the most annoying things about PHP for me. Another similar one is that you can't use empty() on the result of a function call without assigning it to a variable first, and the error you get is something about an invalid write context, which is pretty opaque if you don't just happen to know what it means already.

</comment></comment></comment><comment><USER14> # Arrays and hashes treated as the same type

For me this is an advantage over other languages. I'm looking at you, Perl.

<comment><USER3> It's not just Perl, every language I've seen or heard of except PHP has a clear distinction between its unordered key-value datatype, and an array datatype. That includes Python, Lisp, Lua, and others.

PHP has a Frankensteinian mix between the two. You /can/ implement it in any other language by just keeping an array along with your hash that indicates the order in which elements were inserted: <http://search.cpan.org/perldoc?Tie::StoredOrderHash>

But you almost never want to do this. I've only used it once in all the PHP code I've written. And having to deal with the ambiguity of PHP's key-value array datatype wasn't worth it elsewhere wasn't worth that.

<comment><USER15> Actually PHP arrays are ordered dictionaries. Python got standard implementation of this kind of collection type just recently.

This 'Frankensteinian mix' is the most versatile collection type I have seen so far and I attribute large part of PHP success to having this as first choice when in need to keep collection of elements.

You can build vector, list, stack, tree, map without even knowing what those are just confronting what abilities you require with what PHP arrays can do.

</comment></comment></comment><comment><USER16> I don't have much experience with PHP, so I don't hate it and curse the people who inflict it on me the way I curse, say, perl programmers. My complaints are basically: I tried it once and didn't like it. It was hard to write the abstractions I wanted and the results were buggy. It could just be me.

Several years ago I wrote a feature simultaneously in Python, Perl, and PHP. It was a fairly simple task-- retrieve a list of formatted strings, parse the data with regular expressions, and transform the 3-dimensional information into a 2-dimensional table.

In the python version, the regexp functions were ugly, but idiomatic and also separated into independent functions. The logic was clear and 3 years later it's still easy to understand what it's doing.

I can't find the perl version, but I remember having to use a retarded workaround because references weren't working as documented in one tiny (but essential) edge case. Basically I had to duplicate the entire program to handle two different cases. There is was probably some completely different strategy that would work better, but I didn't have three days to spend digging through perl docs to find it.

In the PHP version, I seem to have had some trouble using abstractions. The program is just one monolithic while loop with some comments. Also, I see some weird hacks in the PHP version and I don't remember why I had to use all of them. At one point I'm populating an array with empty values using 'array_fill()' and I see some temporary-looking variable names like $start_end, and there are a bunch of comparisons to arbitrary index values. For example $start_end[1] is 'start' and $start_end[2] is 'end'. There's none of this crap in the python version.

Ultimately I went with the PHP version. Because the rest of the app was already written in PHP it was far easier to deploy. A year later the feature broke for some reason and I never had the time to fix it.

So ultimately, I would probably tend to avoid PHP in the future because it doesn't seem to support my style of programming very well and I don't see many advantages to indoctrinating myself to its quirks.

<comment><USER17> can you post the code in a pastebin or is it proprietary/too involved w/ rest of the system to make sense in isolation?

</comment></comment><comment><USER18> _There are at least three ways of handling errors - return codes, trigger_error(), and exceptions, all of which are handled differently and used inconsistently by functions and libraries, and require messing with various combinations of global settings to cause errors display or not display to the user. There are furthermore no agreed-upon conventions for handling errors, so libraries freely mix all of these methods along with directly printing errors to the output which is impossible to trap._

For me this was a show stopper for using PHP for anything other than maintaining existing stuff that we inherit (and only for clients we really like).

error handling is at its core a foundation to quality, without proper error handling you have to put in significant effort to build a quality product because the structure has to be reinforced at every level. Having multiple ways to handle errors is almost worse than having none at all. This is one area that really needs to be standardized and have "the one way" to do it. Good or bad, it allows everyone to know what to expect.

It is just my opinion but, this one flaw makes PHP one of the worst languages I have ever use, which is sad because Wordpress and Drupal are great products but I can't stand to have to work in PHP, if I have a project that I know will not require custom development, I use Wordpress or Drupal I really wish they supported alternative languages for writing custom modules,It would be nice to be able to write them in Python or hell even JavaScript has proper error handling.

</comment><comment><USER15> I'm extremely annoyed about how there is no native datatypes for HTML and SQL and they are just plain strings and are allowed freely to be created from strings glued together with any arbitrary data without any default escaping what leads to SQL injections and XSS attacks.

Oh wait. That's true for (almost?) all languages that are used to writing webapps.

</comment><comment><USER19> _There are a variety of ORMs available all of which suck in different ways, such as bloated syntax, forcing you to write SQL statements as a bunch of function calls (i.e. $something- >select('column')->where('condition > 0')->...), or excessive configuration. The one decent ORM (DMZ Datamapper: <http://www.overzealous.com/dmz/>) is maintained by one person, and limited to the Code Igniter framework._

This is a complaint I'v made before... Currently I am using Jelly [1] for the Kohana framework and it is wonderful compared to most of the PHP ORM offerings.

1\. <http://jelly.jonathan-geiger.com/>

<comment><USER17> hah [http://jelly.jonathan- geiger.com/docs/api/Jelly_Field_Behavi...](http://jelly.jonathan- geiger.com/docs/api/Jelly_Field_Behavior) \- I wanted to see what his approach was in regards to defining custom types etc.

<comment><USER19> Uh, there is no class Jelly_Field_Behaviour, instead you need to look at the various classes in Jelly_Field_Behaviour_* - I don't know where it linked you to that but it was obviously in error.

Here are the behaviours: [http://github.com/jonathangeiger/kohana- jelly/tree/master/cl...](http://github.com/jonathangeiger/kohana- jelly/tree/master/classes/jelly/field/behavior/)

<comment><USER17> Thanks, if I can find where I got that link I'll try and ping the owner on github.

</comment></comment></comment></comment><comment><USER20> I thought this was going to be an article about the difficulties in writing a web spider in PHP (which is not PHP's strong suit).

I once wrote a crawler loosely based off Snoopy (<http://snoopy.sourceforge.net/>) and it was a nightmare.

</comment><comment><USER21> One problem is that the people in charge of PHP and their ongoing bad choices.

<comment><USER22> Yeah. I'm cherry-picking here, but if the creator of the language says something like the following, it's probably a bad sign.

"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I'll just restart apache every 10 requests."

But because that could sound like either DHH or Rasmus Lerdorf, there's also this:

"I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

The lack of overall direction and ball-o-mud hackery is exactly what one would expect to underlie PHP in its present state.

<comment><USER23> It's a feature though, it's not like there aren't web development languages that have been designed in a much beter way. I think it's good to have one from the "it get's the job done" mindset.</comment></comment></comment>


Show HN: Micro - Convert Any Site to Single Page App - <AUTHOR> https://github.com/sgoran/micro <comment><USER2> I don't understand the need for single-page websites. They are slow to load, hard to navigate and if javascript is disabled the entire website is broken. I can understand this need for mail apps for example, but I don't understand why everyone throws webapp everywhere today..

<comment><AUTHOR> In contrary.. content is lazy loaded so when you navigate, only small part off app is loaded via ajax. For example if you are using bootstrap, jQuery etc, those files will not load again when you navigate. So you save bandwith and have better user experience because site is not reloaded which is heavy.

Take a look of this case: [http://micro-js.com/examples](http://micro- js.com/examples)

<comment><USER2> I have a very slow internet and cache a lot. When changing pages, it just loads the new files instead of the entire bundle. I noticed that the website loading was much faster when dealing with a light page but with lots of light pages than a single huge website loaded in one time. Not to mention that most docs for new tools & libs are bundled in one single loong document that is absolutely horrible to navigate through

</comment></comment></comment><comment><AUTHOR> 3kb library with features like: client side routing, templates and caching.

Will turn your new or existing site to SPA without need to use React, Angular etc</comment>


Is it worth selling software on Ubuntu Software Centre? - <AUTHOR> Do you have experience selling your apps on Ubuntu Software Centre? Is it worth to develop software for Ubuntu/Linux(moneywise)?<p>I'm more interested to hear stories about non-game software, but game developers can also share their thoughts, <comment><USER3> I think that most of the people you talk to here are going to tell you to avoid it. A lot of us have apt-get engrained in our minds as the defacto interface for managing software on Debian based systems.

That being said: why not? For Apple, the App Store is great. It shows you what is popular and what others find useful. It adds a layer of social proof to your applications. I was using an HTTP REST client for the longest time that was a pain in the ass to use. A lot of user interface inconveniences existed. After Google failed me, I cracked open the App Store and was fortunately able to find the app Rested. It's not perfect in my opinion, but it's been a breath of fresh air when developing my API.

We can argue all we want on the walled garden approach of the App Store, but it's a great platform. We also need to remember that it's still an infant, and it's going to evolve and improve. The more we use it when building software, and the more our customers and users use it to discover and rate our stuff, the better it will become. Apple certainly doesn't let the community dictate their moves, but they certainly allow us to influence their decisions if enough people are on board.

For this reason, I think you should definitely start using the Ubuntu software center. If it provides a simple and more pleasant experience for your users, great! Hopefully there will be more and more people looking at desktop Linux in the future who will need a place to find applications. If you can help evangelize and shape their platform with the weight of a successful app, then the whole ecosystem will grow and flourish from it.

<comment><USER4> As a Linux user, I pay developers whenever I can and if there are no official channels like Ubuntu Software Center then I just donate directly.

</comment></comment><comment><USER5> Judging by the ratio of upvotes to answers, this seems like a topic that a lot of people are interested in but nobody knows about.

Personally, as a user of Ubuntu, I never use the Ubuntu Software Centre - <USER2> even for free software - I much prefer apt-get, and I'm not aware of anything (aside from paid software, which I didn't even know about until you mentioned this) that Ubuntu Software Centre does that apt-get doesn't.

<comment><USER6> As a side note, aptitude is a superior package management tool to apt-get. The syntax is the same, but aptitude has 3 main advantages:

1) Keeps track of system state. Tracks packages installed as dependencies, and remove them when necessary meaning no orphaned packages.

2) Handles recommends well. apt-get fails to handle recommends, which many packages depend on to pull in dependencies.

3) Searching. More intuitive and better formatted than apt-cache search. There is also the text UI when running aptitude directly. For example, how do I find all installed python packages?

        $ apt-cache search python
        Returns all packages with python in title or description.

vs

        $ aptitude search '~ipython'

or

        $ aptitude search python | grep ^i # installed packages are flagged with i on the first line

<comment><USER7> "apt-cache search" does AND search over everything by default which is neat to find software for _something_. with aptitude you have to use some cryptic flags for that.

to look for packages that you have installed use "dpkg -l"

aptitude is otherwise great and I prefer it over apt-get

<comment><USER6> With aptitude you would use the description flag (~d) like so:

        $ aptitude search '~dautojump'
        p   autojump                                 - shell extension to jump to frequently used directories
        p   jumpapplet                               - autojump notification icon, to jump to frequently used directories

</comment></comment></comment></comment><comment> jarek-foksa Short answer: no, it's not worth it.

I'm selling the same app on both Ubuntu Software Center [1] and Mac App Store [2]. Between June and December I have sold 29 licenses on Ubuntu store and ~2000 licenses on Mac App Store.

Chrome Web Store [3] seems to be a much more promising distribution channel for Linux apps. With the new APIs it will be possible to access native window manager, USB ports, filesystem or webcam. Besides, you don't have to deal with incompatibilities between distros.

[1] <https://apps.ubuntu.com/cat/applications/type-fu/>

[2] [https://itunes.apple.com/us/app/type- fu/id509818877?ls=1&...](https://itunes.apple.com/us/app/type- fu/id509818877?ls=1&mt=12)

[3] <http://developer.chrome.com/apps/about_apps.html>

<comment><AUTHOR> Thank you for you comment. This kind of comments I was looking for.

What I've been looking into this today...It seems that it's not really worth it, as you said. I would kind of want it to worth it, maybe some day it will be.

</comment></comment><comment><USER8> Ubuntu software centre has always felt a bit lacklustre to me as a paid software place. Most of the stuff on the front page is either listed as free, have bad icons and screenshots (sometimes Unity,sometimes Gnome 2 or something else) or all 3.

Not to mention that the UI is kinda slow and clunky.

Basically gives the feeling of being in a neon lit discount store rather than a premier software showroom.

I think it might do better to get rid of it as an application altogether and just build an attractive webpage that gives a lot of space over to highlighting the best, most polished commercial apps with a handful of the higher quality open source desktop software. Use a browser plugin to trigger installation.

Installing open source libraries, dependencies and dev tools could be handled by a more utilitarian ncurses front end to apt or something.

<comment><USER9> Since Debian 4 I usually use synaptic as my package manager. It's really just a GUI frontend for aptitude but I've never had any issues using it.

</comment></comment><comment><USER10> There seems to be only a few commercial packages in the Ubuntu Software Centre. As a commercial developer that probably means one of two things: (1) The market is yours for the taking or (2) There is no market.

I'd be curious to know if it is worth it as well. Have you spoke with any commercial developers directly?

<comment><USER11> If I want to sell Linux apps, what is the alternative?

<comment><USER12> Put it on your website and take payments in the form of Paypal/credit card/bitcoins/whatever in exchange for a download link.

If you want to sell for Android (which is, of course, a type of Linux), try the Google or Amazon app stores.

Dominions 3 [1], a commercial game with a native Linux build, recently changed publishers and is now sold on Desura [2].

If you enjoy making your users put up with horrible DRM, I've seen multiple HN articles about how Linux support for Steam is in the works.

[1] <http://en.wikipedia.org/wiki/Dominions_3:_The_Awakening>

[2] <http://en.wikipedia.org/wiki/Desura>

<comment><USER9> "If you enjoy making your users put up with horrible DRM, I've seen multiple HN articles about how Linux support for Steam is in the works"

It's an open beta right now with about 40 games listed under Linux.

</comment></comment></comment></comment><comment><USER13> Super Meat Boy, which has over 1M sales across all platforms, has a whopping 77 sales from the Ubuntu Software Centre.

<comment><USER14> Which those 77 sales are really pirate copies as Ubuntu Software Centre sold SMB without permission and hasn't paid the SMB any either. I'd stay away from them if they're willing to pull this type of shenanigans.

[http://www.kotaku.com.au/2012/12/ed-mcmillen-ubuntu-store- so...](http://www.kotaku.com.au/2012/12/ed-mcmillen-ubuntu-store-sold-super- meat-boy-for-a-year-without-permission-has-yet-to-pay-team-meat/)

<comment><USER15> From Jono Bacon at Canonical:

[https://plus.google.com/114419073019603780828/posts/KA5vKChg...](https://plus.google.com/114419073019603780828/posts/KA5vKChgwDQ)

\--->

Regarding the Super Meat Boy issue, here is a response from David Pitkin who runs the Ubuntu Software Center at Canonical and works with developers:

"I just looked into it and the check to Tommy and Edmund from Canonical is in process for the 77 copies of Super Meat Boy. We have been working together since November to get it resolved, no piracy here just some miscommunication".

</comment></comment></comment><comment><USER16> According to the earlier story about Super Meat Boy, it was on the store for a year and only sold 77 copies.

<comment><USER17> That's meaningless by itself -- SMB was sold through a lot of other channels, both on other platforms and on Linux, before it was put in the store. It's placement in the store was also accidental, and so probably didn't get promoted much!

</comment></comment><comment><USER18> Software center... never use it, in fact the way it had mixed the non- installed stuff with installed software really ticked me off (this is probably my biggest gripe with unity, wheres the menu of all the installed apps??? I don't want to shop ALL THE TIME!). I had installed gnome classic (for getting to whats installed) and Synaptic/Web sites to get to what's not.

So went to find software center - not in the classic menu, but entering software-cetner got it from the terminal.

Seems it suffers like all the others, only one level of hierarchy, looking for Desktop publishing, select office and start reading through the hundred plus entries, most of which have a clever name and icon which does nothing to relate it to desktop publishing at all.

You want o make big bucks at your app, help develop better app stores, so people can find your app.

</comment><comment><USER19> I would be pessimistic. Most people in the Linux community aren't in the habit of paying for software.

Also, I avoid the Ubuntu Software Centre as much as I can. I find the Ubuntu desktop to be atrocious and I log in via ssh as much as I possibly can to Ubuntu machines.

If there's any market here it would be for a $500+ product that customers want bad enough to deal with the USC than it would be for $5 games; even in that case most of your marketing work is going to be outside the USC.

Why hasn't anybody come out with a Linux distribution that contains an Android personality so that you can run Android apps side to side with normal Linux apps kinda like Windows 8? It seems Linux could use this to close the usability gap with other OSes.

<comment><USER20> That's not really true: If you develop a nice and polished desktop application which can be better than an opesource alternative we are disposed to pay.

For example check the Humble Bundle: Linux users always pay more than average. Although I'd not sell in the Ubuntu Software Center: As you would miss a lot of users from other distros (or people who don't use the Software Center).

<comment><USER21> Not quite true. Linux users are the 'true average'. The problem is, Windows Humble Bundles are bought for $0.01 en masse with the intention of reselling, sinking its average price.

<comment><USER22> Can you cite some data that indicate Windows HB license are bought with the intention to resell them?

<comment><USER21> I know a few places reselling the bundles. steampay.com/bundle is an example.

</comment></comment></comment></comment></comment><comment><USER23> The Humble Bundle Linux version usually sells well.

<comment><USER24> I doubt that Humble Bundle's Linux sale would perform that well if the games aren't playable on Windows/Mac, considering the games that claim to be playable on Linux ends up buggy on it.

</comment></comment><comment><USER25> If I could get it working on Mint, I'd use it, and I am happy to pay. I am disinclined to switch my distribution for it though.

</comment><comment><USER26> I use the software center whenever I can. I like the reviews, screen-shots, description, and link to official website.

It's a pretty ugly piece of software with unrefined edges all over the place but it gets the job done for now. That being said I've never bought anything through the software center, just installed free software.

</comment><comment><USER27> Not speaking from direct personal experience, however the Humble Bundles have found that linux users tended to pay more than average, which goes against the common assumption that linux users want everything for free.

<comment><USER28> Kind of users on Linux and Windows and Mac is different, so same app would have different sales. Most of Linux users has good computer knowledge therefore some apps like Type-Fu should have bad sales. Also most of gamers living on windows not Linux... Can anybody share his sales statistics on Ubuntu Software Center?

</comment></comment><comment><USER29> I'm guessing that people using the "free" side of the Ubuntu Software Center are not required to have a credit card on file. This is probably one of the most significant barriers compared to the Apple app stores.

</comment><comment><USER30> I hate how most stores look on Linux, and they are slow. The only one that seems decent is Deepin:

<http://www.youtube.com/watch?v=XY_OAWYCEv8>

There are still a lot of things that don't seem ready for prime time for the consumer market in Linux distros, and I wish it wasn't like that.</comment>


Can we please stop saying the market is efficient? - <AUTHOR> http://blogs.harvardbusiness.org/vermeulen/2009/06/can-we-please-stop-saying-the.html

<comment><USER2> I don't buy it. The example of ISO9000 for instance. Customers value it because it's cheaper and easier than researching a companie's business practices to see if they're stable and predictably repeatable. When it sucks innovation out of a company long term, that company gradually loses business and control of capital until it goes under. The market effeciently reallocates resources to those who provide the greatest value for least amount of consumed resources. Of course it's not efficient at keeping every company alive and healthy, no matter how wasteful and worthless its products.

</comment><comment><USER3> Was anyone else confused by this article? I assumed he was going to be talking about the efficient market hypothesis

<http://en.wikipedia.org/wiki/Efficient_market_theory>

Anyway, this seems an uncharacteristically juvenile HBR article. Of course businesses are not 100% efficient, they are run by humans after all. But firms which are more efficient then others have lower operating costs, better R&D, higher margins, more innovation, etc. - these are the competitive advantage that 'efficient' firms use to get the edge on competitors. That's not to say that each one doesn't do something to make you as an investor go crazy.

<comment><USER4> > Anyway, this seems an uncharacteristically juvenile HBR article. Of course > businesses are not 100% efficient, they are run by humans after all. But > firms which are more efficient then others have lower operating costs, > better R&D, higher margins, more innovation, etc. - these are the > competitive advantage that 'efficient' firms use to get the edge on > competitors. That's not to say that each one doesn't do something to make > you as an investor go crazy.

Cut him some slack, from his bio he looks like a pure academic who hasn't done business. They all have lofty ideas about how easy and organized business should be, as opposed to a gritty, murky, sorting-it-out type thing.

</comment></comment><comment><USER5> Yes we should. Vermeulen says the idea of Darwinian economic competition is wrong. Even Darwin wouldnt buy it. He gives examples of why the flu doesnt kill everyone and why ISO9000 in the long run saps the vitality out of a company. Hey, look at Motorola.

I think the whole idea of market efficiency came about because economics wanted to be a science, and everyone simplified their models to the the point that they were understandable, except that they were all wrong. First perfect efficiency requires perfect information. With the internet we are getting the first hints of perfect information, and we are being overwhelmed. Adam Smith certainly didnt have it. Second all decisions are to some degree irrational, based on taste, beliefs, friendships, bribes, etc. Kahneman got a Nobel prize in 2002 for that insight. (This is the same group the gave Merton and Scholes a prize for the derivatives pricing model that brought down the universe.) If all decisions were completely rational, we would all be programming Python. ;-)

<comment><USER6> There was nothing wrong with using Black-Scholes to price stock options. The problems started when people started using it to price their own Grandmothers.

<comment><USER5> It didn't work so well at Long-Term Capital Management where they were among the resident geniuses.

<comment><USER7> What? Long-Term Capital Management didn't use Black-Scholes. It hired Merton and Scholes, but used a completely different trading strategy.

They tried fixed income arbitrage with very high leverage. Black-Scholes ONLY applies to options.

The work that won the Nobel Prize had nothing to do with the downfall of Long Term Capital Management. Get your facts straight.

Variations of Black-Scholes are still used successfully in the trading world. The only difference is that no one thinks that returns follow a normal distribution anymore (but the Black-Scholes formula allows you to choose any probability distribution you want).</comment></comment></comment></comment>


I'm a Freelancer - I'm Not Lazy - <AUTHOR> http://www.jannahagan.com/2013/06/im-a-freelancer-im-not-lazy/

<comment><USER2> I haven't gone through your blog, but if you have a post on how you become a freelancer, I'd be interested. It seems exciting and I like the idea of having complete control over my schedule.</comment>