Ask HN: Better deals - ruder customers? - <AUTHOR>

This question was triggered by something http://news.ycombinator.com/user?id=david wrote: "The better deal you offer someone, the more demanding they get and the more they are convinced that you're ripping them off." I keep reading and hearing this.<p>It might be a) the result of some cognitive bias, i.e. not quite true, or b) the result of your feeling undervalued and underpaid, which in turn makes you more likely to perceive what is actually an usual amount of problems as unusually annoying, or c) true, which raises the question, why? <comment><USER2> In my previous company, as it was reaching the end of its life (I was becoming burned out on the idea and the business) I made dramatic price changes over the span of a couple of years. I increased the prices by about 50% every six months, and made minor tweaks to the model lineup to make them more profitable even without the price changes. The result was generally happier, but more demanding, customers. As tptacek mentioned, it was a filter...we got a different _kind_ of customer with the price changes. They were less educated about our products, Linux, and technology in general, but were more enthusiastic about the benefits we provided for them, especially our unlimited technical support. We also made more money; sales volume didn't decline remarkably, but the revenue per unit sold went up. Nonetheless, the hours I had to put in to support those units increased. If I had kept that business running I would have needed to raise prices even more or stop offering unlimited support (making support a paid for option has always seemed somehow wrong, to me, but it works for many enterprise companies).

With Virtualmin, we started out charging 50% the price we knew (and everybody else also knew; it was listed as being "on sale") we would eventually charge. I did find that the number of customers demanding even lower prices dropped to almost nothing when the 50% off discount ended. Those customers simply weren't in our market segment, and went back to second-tier products that cost dramatically less and offer dramatically less capability. And, I suspect, but don't know for sure, that cPanel and Plesk customers became more likely to migrate to Virtualmin after the price increase. But, I believe that has more to do with perception of value in an existing market with existing price expectations, rather than any particular price point.

Anyway, I believe the rule of thumb is roughly true. Cheaper products certainly attract a buyer that has weaker loyalties (as soon as they find a better price, they're gone). They probably are also more demanding.

We have a range of prices from $138 to $998, and I would wager that the $138 buyers are at _least_ twice as likely to ask for support as the $998 buyers. I don't know how to make that more fair for us or the $998 buyer, however, since the pricing is based on usage, and a natural result of using the product more is being more familiar.

The point of all this rambling is that I don't think there are any hard and fast rules, but I do think charging more is worth an experiment for most companies. You can always revert your prices (and refund the "suckers" who bought at the higher prices) if things go badly. At worst, you'll learn that lower prices were a better position for you.

<comment><USER3> Very interesting, and a good lesson for startups.

Paraphrased: if price is your selling point, you're likely to attract customers who care only about price and tell you they want it even cheaper or they'll go somewhere else.

The infamous race to the bottom, which is a place where very few companies thrive.

</comment></comment><comment><USER4> Because price is a filter; the more restrictive the filter, the more valuable your product actually is to your customer, and therefore the less likely they are to squander the relationship.

<comment><USER5> Also, people who are able to pay more are generally more likely to be mature and good communicators.

This is also a well known phenomenon in the web hosting industry.

</comment></comment><comment><USER6> In my experience (supporting 3 very different types of products with 3 very different companies), the amount of money a customer pays is somewhat inversely proportional to how demanding they are.

My guess is that companies that pay more for software also tend to hire people to manage and provide tier-1 support for the applications they use. They also tend to take more time making purchases and thus better understand the capabilities and limitations of the software.

That's not to say that large customers (or customers that have paid more money) can't be demanding, but they're usually more understanding and less likely to be unreasonable when they contact us, and have more reasonable expectations around resolution times.

</comment><comment><USER7> Because if you offer competitive deals, that opens you to market segments who purchase based on price. That often means they are lower income, meaning a lower hourly rate, meaning spending time haggling may be rational for them.

Also low income is correlated with low education/working class demographics, which have associations with being more demanding, rude, etc.

Your situation sounds like consulting/contract work so this is probably quite painful. But it's the right segment to target for mass market and volume products...

</comment><comment><USER8> Another point is they think that if one company has a low price on some thing it can go even lower. Furthermore, they think they should get lower prices for all other products, too.</comment>


The importance of "http://" - <AUTHOR> http://dropsafe.crypticide.com/article/3962

<comment><USER2> This reminds me of what happened when Microsoft decided to trim known suffixes off displayed filenames. Has everybody forgotten the hot-babe.jpg.exe viruses? With unicode allowed in domain names, it's only a matter of time before someone registers http://gmail.com.

<comment><USER3> They still do that. One of the first things I do on a new Windows system is to turn that "feature" off.

<comment><USER4> To be fair, Mac OS X does the same by default.

<comment><USER5> And worse, I have never figured out how the hell to disable that "feature" on OS X, I'm sure there is a way, but I wasted enough time pocking around the configuration options.

<comment><USER6> Finder > Preferences > Advanced > Show all filename extensions

</comment></comment></comment></comment></comment><comment><USER7> Jeez. I really don't get the fuss about this. 99% of web users probably won't even notice, except they might be pleased with the removal of the incomprehensible (and, for years now, unnecessary for input) code in front of the part of the website address they recognise and understand.

And for everybody else, what exactly is the problem? Copy/paste? I'm sure that can be fixed, even if it means the user setting "show <http://> in my address bar" as a preference.

I read a lot on this and other websites about opinionated design. This is one of those things. The chrome team think this is a good idea. Some people disagree. As anyone who has ever run any kind of open source project can tell you, you can't just react to objections with "Okay then let's switch it back". At some point you have to actually make your own decision, weighing up the benefits against the costs, taking into account the number of people experiencing each.

In this case, it seems like a massive improvement for simplicity for most web users, and a trivial, surely quite easily fixed bug for an unknown percentage of the small percentage of users who would ever need or want the '<http://> there.

Just my opinion. I would be interested to hear what other people think.

<comment><USER8> \- it makes the system second-guess in more places. Means more complexity - understandingly some bugs to fix (tinyurl.com/http-strip)

\- the users will alter their behavior when mentioning the URLs (as I did just above). And will wonder why they are not linkable.

Now either the site owners have to jump through the hoops to replicate the second-guessing logic to their sites, or everyone who views the URL, will have to copy/paste manually.

Another couple of questions I will start asking as a user: why does the ftp:// thing pops up in front of the URL if I use it ? And, what is <https://> and why is it suddenly there when I only want to go to gmail.com ?

This change noticeably increases the number of places which violate the principle of least surprise. But maybe I am a corner-case :-)

EDIT:

And, if we look at the whole "address bar" under the same UI angle - the path and the query string is equally a useless technobabble for anyone non-geek. So, I think we would go further and just show the host name, while we are at it.

<comment><USER9> _\- the users will alter their behavior when mentioning the URLs (as I did just above). And will wonder why they are not linkable._

What?! I know of no one who ever, ever, ever said <http://> when mentioning a URL. I certainly don't do that.

<comment><USER8>
      #define mention(url) type_or_paste_into_facebook(url)

Sorry that my wording was unclear. "referencing in writing elsewhere" might have been a better one.

<comment><USER10> People have been using "lol, hey, go to www.google.com" for years without problems.

</comment></comment></comment></comment></comment><comment><USER11> I find it mindboggling that instead of removing the silly and superfluous "www." they are trying to remove the meaningful and important "<http://>.

It doesn't solve any actual problem and creates a slew of new ones.

<comment><USER12> "www" is only superfluous at some sites, and there is no way they can tell which. Even doing a name lookup on both and checking if the IP is the same is not sufficient, because they could be different virtual hosts on the same IP.

</comment></comment><comment><USER13> In all honesty I have only just noticed that the machine I am working on has this feature.

I see the draw backs but the fact I haven't noticed for about 48 hours or more is, well, telling IMO.

<comment><USER7> Agreed. People seem to be upset mainly because of what they imagine certain users will do, rather than what they have actually seen happen.

</comment></comment><comment><USER14> Using the latest daily build of chromium I couldn't reproduce a single one of the "issues" that the post presented.

It seems they've all been fixed before he wrote the post.

</comment><comment><USER15> try it - if you copy from the bar it adds <http://> into the buffer

<comment><USER16> I did and it _doesn't_. On OSX. When pasting into adium.

It seems to work when pasting into a terminal. Haven't tried other apps, yet.

And yes, that's a big problem. I don't want to double-check my urls when pasting them into various messengers, skype or whatever. Here's a tip google: If you can't implement it 200% reliable then don't f-ck with something as essential as URL copy/paste. People will not be amused at all.

<comment><USER8> Check if your behaviour matches one of these:

code.google.com/p/chromium/issues/list?q=label:HTTPStripping

and file a new one if not.

EDIT: I am intentionally not including the "<http://> since:

* after looking at it in the omnibox, I decide I like it better this way indeed, and 6 less keystrokes. The others will have to copypaste or the webapp writers will have to figure a way to highlight it :-)

* the copypaste is not working in the linux case either, but that's one of the logged bugs.

It's really the first point that I am trying to say is the biggest impact that this change will have. "If it works in Chrome, it has to work everywhere".

<comment><USER17> > EDIT: I am intentionally not including the "<http://> since:

And I am intentionally not clicking the link because ... it's not a link. I have a greasemonkey script that automatically turns plain text URLs into clickable links. But the text in your post is not a URL. It's a domain and a path, but with no scheme it is not a URL.

</comment></comment></comment></comment><comment><USER10> Removing choice from users _is_ bad...

But how many average users do you know actively pick what protocol to use? None of them. For them, HTTP is it.

Only geeks use FTP anymore.</comment>


SourceTree 1.0 Released, including Mercurial support - <AUTHOR> http://blog.sourcetreeapp.com/2013/06/25/sourcetree-1-0-released-including-mercurial-support/ <comment><AUTHOR> And here ([http://www.sourcetreeapp.com/update/WindowsReleaseNotes.html](http://www.sourcetreeapp.com/update/WindowsReleaseNotes.html)) are the release notes.

I've been really enjoying SourceTree, using it for git, and I know a lot of users were looking forward to Mercurial support. If you have to use Windows, it can be a lot less of a paradigm-breaker than dropping into bash.</comment>


Wolfenstein: Ray Tracing on Using WebGL1 - <AUTHOR> https://reindernijhoff.net/2019/03/wolfenstein-raytracing-on-using-webgl1/ <comment><USER2> This reminds me of the Quake 2 Path/Tracing Ray Tracing with Nvidia RTX.

The lighting becomes hard to accept because I've been accustomed to the fast, "fake" lighting in current games, but suddenly with Ray tracing the lighting becomes completely different.

[https://www.youtube.com/watch?v=BRCAfdBMe2Y](https://www.youtube.com/watch?v=BRCAfdBMe2Y)

<comment><USER3> Man, I'd like to see Descent (I/II) rendered like that. Or Quake 3 Arena. :)

<comment><USER4> A ray tracing renderer for Quake 3 was demonstrated in 2004: [http://www.q3rt.de/](http://www.q3rt.de/)

</comment></comment></comment><comment><USER5> This is very cool. I really like the style that is the result of retro graphics and then raytracing added on top. I hope it will become a common style in games!

</comment><comment><USER6> Wait, isn't this kind of a big deal?

I didn't know real time ray tracing was already feasible on non RTX cards.

<comment><USER7> I've noticed a few people say similar comments recently. Ray tracing is done via software that (typically) doesn't require any specific hardware. It may be _faster_ on specific hardware, but it's plenty feasible in most GPUs. The whole RTX thing is marketing

<comment><USER8> In the 90s you could say rasterization is done via software that (typically) doesn't require any specific hardware. It may be _faster_ on specific hardware, but it's feasible in most CPUs. The whole 3DFX thing is marketing.

More seriously, RTX adds custom acceleration hardware (fixed function hardware ray box and ray triangle intersection). Whether or not this hardware is _required_ (or enough) for feasible mainstream adoption of real-time raytracing in commercial games is up in the air, but at the very least it turns making a performant, GPU accelerated, real-time raytracer from very hard and only usable in toy applications to relatively straightforward and almost usable in real applications. The RTX name is marketing but the hardware does add some value. As with anything once (if?) raytracer hardware is cheaper, more powerful and more ubiquitous it could have major effects on real-time rendering.

</comment></comment></comment><comment><USER9> It reminds me my own ray-traced WebGL game, that I made six years ago :) [http://powerstones.ivank.net](http://powerstones.ivank.net)

</comment><comment><AUTHOR> amazing how much the music and door sfx add to the experience/nostalgia. makes me want to fire up DOSBox and play it through again. it looks like you can actually mouse-look in this version. i don't think that was possible in Wolf3D. also enabling the reflections definitely takes a lot away from the retro feel - too shiny!

<comment><USER10> If you really want to play through it with some enhancements, you probably want ECwolf [http://maniacsvault.net/ecwolf/](http://maniacsvault.net/ecwolf/).

</comment></comment><comment><USER11> Unfortunately, this article crashes my tab on Firefox 63.

<comment><USER12> Not that it helps you but on Firefox 65 on Windows 10 (core i7 6th gen quad core mobile) it ran great.

</comment></comment><comment><USER13> Wow, FF run rings around Chrome! this demo is almost 70% faster in FF...

</comment><comment><USER14> It's good to see that after all these years Reinder is still working on (new) raytracers :D

<comment><USER15> haha :)

</comment></comment><comment><USER16> In honour of a famous game review system, I propose an objective, measurable way of rating ray-tracing demos: the 'time-to-sphere': how long is it before a shiny sphere appears in the visuals? It signifies the point at which the creator ran out of ideas and gave up on doing anything original.

Unfortunately, this Wolfenstein demo score 0 seconds. As another reviewer once wrote: It's observably, undeniably bad. It's as if the designer arrived at work on day one, sat down at his desk, sharpened a pencil, threw up his hands and said "well, I can't think of anything."

:) (But on a serious note, what use is ray-tracing if no-one can come up with anything original to show with it?)

<comment><USER17> That's because true reflections are a feature of ray tracing, which other technologies cannot achieve.

It's quite impressive for me to have a real time Ray tracer in my browser.</comment></comment>


Show HN: Updated wave method of building color palette - <AUTHOR> In colouristics there are several methods for constructing a color palette (color gamma) based on the arrangement of colors relative to each other in the color circle and, usually, having the same brightness. Harmonious perception of which is not sufficiently substantiated from the physical point of view.
The wave method of building color palette based on the relationship and color and acoustic waves, and also the concept of consonance (harmony) in music theory. More detailed description of the method is here - https://wavepalette.com/about/
A few days ago, the algorithm was completely finalized and posted on the site - https://wavepalette.com/. There is also a mobile application and ready-made palettes - https://wavepalette.com/palettes/ <comment><USER2> This looks interesting. Posts without URLs get penalized, so you should make a new post that points to your site, then post your text as a first comment in the thread. If you do, email firstname.lastname@example.com so we can make sure that it doesn't get flagged.

You might also include the backstory of how you came to work on this and explaining what's different about it. That tends to seed discussion in a good direction. Good luck!

<comment><AUTHOR> Thank you. Did this.</comment></comment>


Building Python modules with Go 1.5 - <AUTHOR> https://blog.filippo.io/building-python-modules-with-go-1-5/?hn

<comment><USER2> Using the blog post I tried the same for PHP extensions:

[https://gist.github.com/beberlei/3c89c86d3a9f96e4c9f2](https://gist.github.com/beberlei/3c89c86d3a9f96e4c9f2)

It compiles and works for php -m and php --info, but calling the function segfaults sadly. Wondering if it is just a small fix necessary to get going.</comment>


The Rumsfeld Hazard - <AUTHOR> http://jasonmbaker.com/the-rumsfeld-hazard

<comment><USER2> I always thought it was unfair that Rumsfeld got criticized for that quote.

<comment><USER3> What was the nature of the criticism anyway?

<comment><AUTHOR> Rumsfeld wasn't exactly known for being straightforward with reporters, and it's easy to get the impression that it's an evasive, nonsensical answer. It even won an award for that!

<http://news.bbc.co.uk/2/hi/3254852.stm>

<comment><USER3> I'll buy that. It makes sense that one who evades the facts of reality would evade questions as well.

EDIT: Rumsfeld was in denial over what it took to do the job of invading Iraq. And he never caught on. The "surge" was simply sending enough manpower to do the job. Finally.

Not to say it made any sense to invade Iraq to begin with.

<comment><USER4> It's worth observing that the surge was part of Condoleezza Rice's "clear, hold build" strategy. Rumsfeld was fired and she was brought in to implement it.

I think that should help put Rumsfeld and criticism of him in a little bit of context. Yes, he was a Bush administration official heavily involved in the Iraq war and got a lot of criticism from that. But he was in rare company by being someone who was fired in disgrace from the Bush administration as things came apart under his watch. The only other guy I can think of offhand who is in that group is Micheal Brown.

<comment><USER3> Rumsfeld was replaced by Robert Gates after the mid term election in 2006. Rice was secretary of state for the entire second term.

<comment><USER4> Sorry, yes, you're correct, Rice remained Secretary of State.

But Rumsefeld's firing was a repudiation of his "Light Footprint" strategy in favor of the "Clear, Hold, Build" strategy being championed by Rice.

[http://books.google.com/books?id=dhff3C6xhvkC&pg=PA271&#...</a>

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I've always found it unfortunate how many people joke about this quote while at the same time praising folks such as Nassim Taleb. I think it's fair to say that a Black Swan is analogous to an unknown unknown. I'm no fan of Rumsfeld, but the idea itself seems valid to me.</comment>


Geoffrey Hinton: Introduction to Deep Learning, Deep Belief Nets (2012) [video] - <AUTHOR> https://www.youtube.com/watch?v=GJdWESd543Y <comment><USER2> Unfortunately this talk is kind of dated already. Most people don't stack RBMs or autoencoders to pretrain the weights anymore. If you use dropout with rectified linear units, you don't have to pretrain, even for large architectures.

<comment><USER3> It's not just ReLUs that have helped, its also better random initialization before starting training, such as using Xavier initialization ([http://andyljones.tumblr.com/post/110998971763/an- explanatio...](http://andyljones.tumblr.com/post/110998971763/an-explanation- of-xavier-initialization))

Also, batch normalization helps with convergence as well. In addition, LSTMs work when dealing with recurrent neural nets.

</comment></comment><comment><USER3> I completed this course over the last year. It's fantastic and from one of the founders of the field.

I'd stick to the first half to get a good sense of back propagation and working with standard neural nets. I'd hold off on the second half, which delve more into Restricted Boltzmann Machines (RBMs) or autoencoders; these aren't used as much anymore.

To augment your education for things that have happened since 2012, I'd learn about ReLUs rather than sigmoids for activation values, as well as studying up on convolutional neural networks (CNNs) and the recent work in sequence-to- sequence NLP translation via neural networks.

</comment><comment><USER4> His coursera lectures are awesome

</comment><comment><USER5> This looks fantastic. Exactly the kind of intro for deep learning I've been looking for.</comment>


Can solar paint power our world? - <AUTHOR> http://boundless.utoronto.ca/impact/solar-paint/ <comment><USER2> I remember a Stephen Baxter novel had a coating like this in - it generated power and did computation too..it may have also been a screen Anyway, that would be the ultimate coating: paint-on solar power source, parallel processor and screen</comment>


Ask HN: What's your favorite newsletter for DevOps stuff? and Kubernetes? - <AUTHOR> <comment><USER2> I am the co-host of [https://kubernetespodcast.com/](https://kubernetespodcast.com/) and I think we do a great job summarizing the week's news, as well as having an in-depth interview every week.

</comment><comment><USER3> These guys have great content:[https://opsfleet.com/resources/](https://opsfleet.com/resources/)</comment>


Ways ZFS Can Make Postgres an Even Better Database - <AUTHOR> https://blog.2ndquadrant.com/pg-phriday-postgres-zfs/ <comment><USER2> We've done a decent bit of testing with ZFS on Linux. And every time we've observed it as unstable in production. We saw great performance gains as well, but under several real world workloads it repeatedly crashed. Some of this was as of about 9 months ago so it's unclear if they've fixed some of the bugs... but generally I'd say proceed with caution.</comment>


Chris Burden turned late-night TV commercials into conceptual art - <AUTHOR> http://www.openculture.com/2015/05/chris-burden-r-i-p-turns-late-night-tv-commercials-into-conceptual-art.html <comment><USER2> I had never known of the continuing output of Chris Burden and it is very interesting! Chris was one of a number of students who attended Pomona College at a time when it's teaching of art was radically modern. Should anyone take interest they can read about the interesting output of some of the other students here: [https://www.goodreads.com/book/show/12497845-it-happened- at-...](https://www.goodreads.com/book/show/12497845-it-happened-at-pomona)

</comment><comment><USER3> I was surprised there was/is? restriction on individuals purchasing commercial slots. Anyone know why? Esp since it's pretty trivial to circumvent.

To ensure only commercial speech gets broadcast? Can't have those free- thinkers, radicals, and artists being heard by the masses?

</comment><comment><USER4> Saw an interesting photographic exhibition in Paris recently of Harry Gruyaert, who shot the German olympics with an analog camera on his TV in London, making it pretty conceptual set. See [https://www.magnumphotos.com/C.aspx?VP3=SearchResult&ALID=2T...](https://www.magnumphotos.com/C.aspx?VP3=SearchResult&ALID=2TYRYDKGACJF)

</comment><comment><USER5> I used to go the Museum of Modern Art in NYC with my dad as a kid -- one of the most memorable pieces for me has to be Burden's "Medusa's Head" [1]

1: [http://www.moma.org/collection/object.php?object_id=81157](http://www.moma.org/collection/object.php?object_id=81157)

</comment><comment><USER6> Can you still do something like this? What would it cost nowadays?

</comment><comment><USER7> I remember seeing a video about him at the art museum in Philadelphia and cracking jokes at the noises he made while crawling on glass with a young love.</comment>


Arrow Function Syntax in JS.Next - <AUTHOR> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

<comment><USER2> I actually like the word "function" better. I also like money.</comment>


Configuration (mis)management or why I hate puppet, ansible, salt, etc. - <AUTHOR> http://www.scriptcrafty.com/configuration-mismanagement-or-why-i-hate-puppet-ansible-salt-etc/ <comment><USER3> I think couple of our engineers have said it really well, so I'm going to quote them both.

1\. All config management systems suck in equal measure, but in different fashion. This is why you pick the tool that sucks the least _for your particular usecase_ , and hope that two years down the line you made the right choice.

2\. People who don't know how to write proper code end up creating two kinds of things. Either they write a config management system, because they believe it doesn't require deep diving; or they try to write a monitoring system, because they don't understand what they are getting into. One way or the other, the hidden and emerging complexities will eat them all.

Config management is hard, and the more stuff you have to massage on various hosts, the harder it gets. (For the record: I'm a big fan of slim hosts and immutable infrastructure movement.)

<comment><USER4> I've started using terraform and packer since I wrote that post. I'm going to stick with those tools for the time being. Configuration management is solving a problem that no longer exists. Pre-bake your infrastructure and then download the rest at runtime if you can't do it at bake time.

Coupled with docker, hashicorpt vault, and fpm I think the problem of deploying and configuring anything is pretty much solved and the remaining issue is basically how you go about doing orchestration for things like rabbitmq clustering which I don't think any of the existing configuration management tools try to address anyway. You either need to configure the topology ahead of time which kinda defeats the purpose of having a reactive infrastructure or you have to write some kind of custom thing on top of what you are using already which again kinda defeats the purpose since most of these configuration management tools try to be declarative and you often need imperative things to configure something like a rabbitmq cluster.

<comment><USER3> Terraform is a neat tool. From my limited experience so far, it manages to hide most of the complexity when dealing with EC2 network setup. We haven't tested it with VPC peerings yet, but do expect to see that one in a near future too.

I don't quite agree with you about config management being useless, but its role certainly can be reduced. A real life example: database hosts with dedicated high performance volumes, their read replicas, and due to regulatory compliance, always up-to-date off site replicas on physical hardware.

Same holds for load balancers, btw.

And as for docker, I have mixed feelings. I disagree with quite a few of their design and engineering decisions, let alone with their QA so far. However - <USER2> do think that they _nailed_ the basics of the devs' workflow UX. Anyone can write a dockerfile, and the deployment story is pretty well thought out. (I happen to disagree with the registry address being part of image namespace, tbh.) Things start to get a bit iffy when you need to consider exported volumes, and host interaction in general; why can't you declare per-image default export paths on the host configuration? Why is restart policy controlled by arguments to dockerd, instead of metadata inside the built docker image?

I know the engineer in us all screams "that's a job for the orchestration engine, stupid!" but the fact that you need to accept and integrate with a lot of external complexity tells me that a lot of questions in this space are still open.

</comment></comment></comment><comment><USER5> To the author: I know that TFA includes Ansible in its list of crazy tools, but after reading the list of complaints I think Ansible is actually more or less what you're looking for.

\- Ansible needs no centralized server.

\- Ansible does everything over SSH, so you don't need to install client software on all your machines.

\- Ansible can be configured to fail loudly when it fails ("ansible -vvvv"), so if a task you specify doesn't work it's generally not hard to figure out why.

\- YAML as used in Ansible isn't really a DSL; it's just used to produce a very human-readable text recipe for bootstrapping a system. You can complicate things beyond that if you want to, but by default you're just specifying a list of tasks to be run on the target machine serially. You don't have to learn a programming language like Ruby to be productive with it.

\- Ansible has a bunch of modules to make things like creating users, setting up popular applications, etc. easy, but if you want to you can ignore all that and just specify each task in your "playbook" as a shell command. So if you can provision a machine by hand from the shell, all you need to do to write a functioning Ansible playbook is learn a little YAML syntax and Ansible's "shell" and "command" modules.

\- Vagrant supports Ansible as a provisioner, so if you want to do local testing you can pick up your Ansible playbook and feed it to Vagrant to produce a local VirtualBox VM configured to your specifications. Then once it's working you can use the same playbook to configure your remote machine(s).

I resisted configuration management when the choices were Chef and Puppet for many of the same reasons articulated in the post; they were heavyweight, complicated solutions designed for large-scale use. Ansible removed all my complaints. It's easy to pick up, requires very little software, and when making design decisions generally goes with the simplest thing that could possibly work.

<comment><USER6> > \- Ansible needs no centralized server.

No, but it requires the same centralization on a different level: SSH key. Good luck migrating to another one once a need arises (e.g. one of the sysadmin leaves).

> \- Ansible does everything over SSH, so you don't need to install client > software on all your machines.

Once you start configuring SSH, you risk cutting off your debugging channel.

Also, you wouldn't put your database connection management in user session handling code in your application, would you? So why mixing two totally separate things in one service?

> \- YAML as used in Ansible isn't really a DSL [...] You don't have to learn > a programming language like Ruby to be productive with it.

We've all seen how this was claimed for XSLT: "it's not code! it's human- readable! you don't need to learn anything beside XML!". It didn't end pretty. Why YAML-encoded programming language would be any different?

Ansible is not a configuration management tool. Its very architecture (push- based SSH+sudo shell commands) sucks heavily for this task, even if you only have a dozen servers. It was never designed to keep OS state as encoded in intents. Ansible is just a tool that somebody hacked for their specific deployment case and then advertised as a general-purpose tool.

</comment></comment><comment><USER7> This summarizes the post:

> Why the fuck are build/ops folks making decisions about how the application > should be deployed and configured?

The answer is really easy -- the build/ops team is configuring, deploying and running the application.

Config tools aren't perfect, but they are better than the old school manual configuration or letting individual developers cook up special snowflakes to do things the "right". Way.

You should be using as close to one configuration management tool as possible, and as a developer, you should learn how that tool works.

<comment><USER8> This is exactly right. Ops are making decisions about how the app runs because they are the ones get paged at 4 am when it suddenly does not.

<comment><USER9> One of the best strategies I've seen with this is: put devs on call. As soon as they are woken up at 4 am, you can see entire teams turn around their attitude on how things are run.

<comment><USER10> Yep, this. PagerDuty and Slack can help. Many alerting and monitoring services now work with these. Info / debug stuff goes to slack, urgent and important stuff goes to PD. Make a quadrant of how important and how time-sensitive each alert is to respond to and make them go to the respective mechanism. Email can stand in for Slack, but people tend to ignore emails and filter them if they start getting spammed with important-but-not-their-problem things, then they'll miss the important-and-their-problem alerts later because their filter matches those too.

Suddenly, everyone is writing tests, testing locally, deploying canaries, getting demos ready 2 days ahead of time, and not deploying at 6PM on Friday.

<comment><USER9> Sorry, but I fail to see how

A) That is exclusive/special to things like slack or pd. Seems like a lot of tools could handle this.

B) How those tools are related to being woken up. I exclusively use email for work notifications. Chat is purely for BS and chit-chat. The last thing I would do when woken up at 3 is check chat.

</comment></comment></comment></comment></comment><comment><USER11> The Unix equivalent of your Powershell scripts is bash scripts. You can go pretty far that way.

I have looked at the many configuration management tools out there and I think they do add more complexity than they remove.

<comment><USER9> I've used puppet, chef, ansible, and probably others that I can't remember. I eventually just gave up and wrote everything in bash-scripts, because it's quicker, easier and simpler.

If you have a crazy environment, I see how config-management would be better, but if you (like most sane shops) have a homogeneous environment, simple shell scripts are probably the best way to do things.

<comment><USER6> Only if your environment is cluster-like set of clones of a golden image, dutifully kept up-to-date with it. If you happen to have two or more roles for the servers, shell scripts start tearing at their seams.

<comment><USER9> > Only if your environment is cluster-like set of clones of a golden image, > dutifully kept up-to-date with it.

That's kind of what I mean by homogeneous. A lot of this depends on your environment, so it's very much a YMMV thing, but for me, it has worked out much better.

> If you happen to have two or more roles for the servers, shell scripts start > tearing at their seams.

I guess it depends on how you set up your scripts. I made mine "config- management-esque", which is very modular, and it works well for me.

<comment><USER6> > That's kind of what I mean by homogeneous.

Then I have a bad news for you: except for rare case of overgrown startups, virtually nobody else has this kind of environment. Larger, established companies need file servers, external web servers, application servers to run internal services (multiple of them), directory services, print servers, and many others I couldn't remember at the moment. Heck, even development vs. production environments can have significant differences in configuration.

>> If you happen to have two or more roles for the servers, shell scripts start tearing at their seams.

> I guess it depends on how you set up your scripts. I made mine "config- > management-esque", which is very modular, and it works well for me.

Of course it depends. CM systems are regular programs and not magic, after all. One _can_ write one from scratch. I just really doubt your is a sensibly generic one instead of being "mine set of scripts that only works for my environment". It takes a lot, lot of experience in both programming and system administration to develop such a thing.

<comment><USER9> I think our definition of homogeneous might be different then. I have file- servers, web-servers, app-servers, etc, and I would consider my environment homogeneous. I use the same base-os, and I can reuse the same scripts for each type of server because of how modular my system is. For my setup, just using shell scripts works much simpler and easier. But I'm also not advocating that shell-scripts will work for everyone. For many situations, a full-fledged config-mgmt system is the better solution. I've just never been in one.

<comment><USER6> > I think our definition of homogeneous might be different then.

Well, you said yourself:

>> Only if your environment is cluster-like set of clones of a golden image, dutifully kept up-to-date with it.

> That's kind of what I mean by homogeneous.

Apparently you meant something different than I understood from this.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Fabric is a good example of config management as code. While all the app- specific configs are much easier to do this way, it feels like many other tasks (install packages, create users, etc) could be "outsourced" to some sort of shared recipe. So I guess it depends on how "custom" your deploy and configs are. If you're doing something standard, ansible/chef could be a good fit, less so if there are many tweaks etc.

If anyone is interested in pursuing fabric for their config+deploy, check out these libraries of higher-level system functions: [https://github.com/sebastien/cuisine](https://github.com/sebastien/cuisine) or [https://github.com/ronnix/fabtools](https://github.com/ronnix/fabtools)

<comment><USER13> Config management? We use it as a build tool. It's _lovely_ because your DSL is Python and the Fabric bits are libs. Certainly lovely having come to it from Ant, whose DSL is Brainfuck in XML. I just wish Fabric had a decent Java story (it totally doesn't).

</comment></comment><comment><USER14> it pains me to see this divide between operations and development perpetuate. the developers (whether internal or external) ship some nonsense. it needs excessive configuration. of course it needs to be keyed. it doesn't manage its own resource usage properly. it needs to be protected from malicious agents. it has a ton of ever-shifting external dependencies.

so the ops (or devops) people, not being developers, and more importantly not having a mandate to spend months or years trying to address the fundamental issues try to wrap the fragile broken thing in a blanket. they deploy it, and build up an equally messy infrastructure around it.

this goes on to such a degree that the developer, probably suffering from his/her own limits on time, and scope limitations, finds themselves unable to deploy or even test the system in question without becoming a full time ops person.

so the process gets worse, and we have 'canaries', which is basically an admission that developers cant even test simple changes to make sure they work before they are deployed.

ops has to deal with poorer and poorer software

developers have the scope of change cranked down so low that basically nothing can be done

we hire more and more people to try to get things to happen, and none of them can get anything done because its all so gridlocked.

the answer is clearly repeatably and trivially deployable builds, without any secret commands and passwords that only billy really knows. including all the configuration and state required to being up an instance of the service from both a development and operational context. this, apparently, is akin to asking for an honest politician, or a perpetual motion machine.

</comment><comment><USER15> I'll definitely echo the sentiment about layers of incomprehensible crap in CM tools.

I wrote my first set of Ansible scripts recently, and found myself deeply pondering, "who on Earth thought YAML was the best option for a Turing- complete language?"

CM tools should be saving me time. Writing under an isomorphism from BASH to YAML does not save me time.

<comment><USER16> Don't program in Ansible, declare desired state.

Use the Turing complete language under the hood, Python, to program. Use Ansible to compose: declare and configure your stack, invoking the things done by the real language.

<comment><USER15> Okay, except I was already writing Python scripts to deploy, so now I'm where I started off except I have one additional engineer yelling at me for not doing things The Ansible Way.

This is the exact problem the article was describing -- CM tools promise ease- of-use and simplicity, then that premise is inverted entirely when the developer is now doing additional work to satisfy the operations team's standards.

<comment><USER16> Separating config from code or separating declarative environments from orchestration of components aren't to satisfy your ops team standards, they're things you probably want to do as a developer thinking of infra as code.

Also, DevOps: It doesn't mean same person doing all things, but it does mean you don't think in us vs. them.

Think about your app/service cradle to grave, do the right thing.

<comment><USER15> As a developer, I'm trying to meet deadlines with good-enough code.

I'm not stupid and I certainly understand why someone would develop a general deployment strategy, and then each case can be described as a set of parameters. Again: the use case is clear to me.

All of this makes sense in a world where the ops team is world-class and responsive, and you have the schedule and resources to delay deployment for another 2 weeks while you lovingly craft an Ansible module instead of hardcoding a BASH script.

That does not describe business environments.

</comment></comment></comment></comment></comment><comment><USER17> The author's experiences are fairly horrific, and they stem from their workplace's misunderstanding of what config management tools are for and how to deploy them properly.

The key quote is this:

"Doesn't take a genius to see that process is broken and that there is some kind of impedance mismatch and the tools are not helping."

</comment><comment><USER18> > Umm, why can't I just have a token in the code base I can use to query a > service to give me that data?

Wait, is he arguing for including privileged tokens in source code‽

<comment><USER19> I got that impression as well.

I think he's on the right track with some frustrations but the whole piece kind of sounds like me a few years ago which can basically be summed up as: "fuck this is fucking stupid. why did they do it this way? fuck this." I'm not saying he's wrong but it does smell a bit like a lack of experience. That can result in some great new ways of thinking and doing things but it also has the downside of not realizing that sometimes decisions were made because they were the best ones given the circumstances or there's serious blind spots in one's experience that keep them from seeing the true value of a decision.

<comment><USER20> Since decisions are often made under the pressure of business goals from a technical standpoint they are almost always the wrong decision. In instances like that it takes a certain amount of experience and backbone to either say no to horrible hacks or put in the right kind of mitigation and fixes as soon as the business goals have been met. If it intuitively feels wrong then I don't really care what justifications people had at the time for writing a horrible mess. Objectively it is a horrible mess still even if I forgive the people that made the decisions that led to that mess.

Since I wrote that post I've seen the same mistakes repeated over and over again. My tools of choice at the current time are terraform, packer, some kind of secure storage mechanism like hashicorp vault, and plain old shell scripts or rake files.

I'm also not advocating checking in secret tokens into the code base but you need something that gives you access to the place that holds the secure tokens. It is important to draw that distinction since the extra layer of indirection actually provides you enough control to revoke and recycle tokens much more quickly than if you had checked everything into the code directly.

<comment><USER19> I agree, it does take experience and backbone and even then it may not be enough. It's basically technical debt and unfortunately that's still something many organizations struggle with today.

While I think you're right about many things being objectively bad from a technical perspective there are a lot of decisions that aren't just technical. You may end up using the lesser of two options of the lesser one is more compatible with the expertise present in your organization. Sometimes it's not clear cut at all and only time and real world usage reveals the pitfalls. It's easy to point at that and say "that's stupid and this is terrible" a few months or years down the line. The hard part is trying to make those decisions.

Let's look at Puppet as an example. Let's say you have an organization that has a couple people out of a dozen that can write shell scripts that aren't spaghetti. But if everything depends on them they become a bottleneck. You know there's a bunch of halfway decent modules written out there for a lot of stuff you need and your two people can close the gap. The rest of the team can build knowledge and skill over time but can start putting modules together to build infrastructure today. So you can choose shell scripts and fixing your personnel/skill issues or you can choose Puppet and deal with the warts. Training or hiring new people would be obvious but given the reality of budget and politics at $bigcorp it's a no-go or you're looking at years of effort. Even if it's cut and dry technically it's really not always a simple decision.

<comment><USER20> I have seen this argument

> Let's look at Puppet as an example. Let's say you have an organization that > has a couple people out of a dozen that can write shell scripts that aren't > spaghetti. But if everything depends on them they become a bottleneck. You > know there's a bunch of halfway decent modules written out there for a lot > of stuff you need and your two people can close the gap. The rest of the > team can build knowledge and skill over time but can start putting modules > together to build infrastructure today. So you can choose shell scripts and > fixing your personnel/skill issues or you can choose Puppet and deal with > the warts. Training or hiring new people would be obvious but given the > reality of budget and politics at $bigcorp it's a no-go or you're looking at > years of effort. Even if it's cut and dry technically it's really not always > a simple decision.

at least 5 different times and each time whoever argued that point ended up being wrong 3 months down the line. What I don't get is why it keeps being propagated. You should indeed take those 2 people, make them a bottleneck, and let them build the organizational tools and expertise around what they consider is correct instead of doing what you suggested.

I think this argument is propagated because it provides the illusion that programmers are interchangeable. If somehow you can leverage all the Puppet knowledge in the world you will reduce your risk and dependence on single points of failure like one programmer that understands how the tower of shell scripts fit together. I think this is based on a false premise. Programmers are not interchangeable and no matter how many frameworks and tools you layer on it will not be possible to get rid of the dependence of good programmers doing what is right from a technical standpoint. The alternative just doesn't make sense really. You can't take a bunch of idiots and make them brilliant through tooling.

</comment></comment></comment></comment></comment><comment><USER21> You should take a look at [https://bosh.io/](https://bosh.io/) . It does what you want wrt devs being responsible for defining how the software runs, environment reproducibility, etc. Unfortunately, the learning curve is pretty steep.

</comment><comment><USER22> Use a script to build a container; once deployed, never touch it again. Of you need a new config, build be container, roll the old version out.

</comment><comment><USER23> I feel this sentiment all the time from devs. "Why are you making me work harder?"

As apps get larger, we as devs have to stop and think about how things are going to run in production. We have too often made the ops team's life worse, because we would rather just hardcode stuff.

Yes, these tools make it harder FOR DEVS, but now the Ops team has a hope of actually managing the platform.

<comment><USER20> My point is the distinction is artificial. I've worked on both sides of the fence and the more you know about the other side the better programmer you can be. Being an application developer that is completely oblivious of deployment, build, configuration pipelines means you won't be able to build the best application you possibly can if you knew about those things. Similarly being a generic UNIX sysadmin that worships at the altar of Puppet et al means you will constantly be fighting with application developers about how to do things because you'll be unaware of their needs.

</comment></comment><comment><USER24> Years ago I made a post analyzing the failures of this class of tool, which I entitled _Post-facto Configuration Tinkerers_

Read: [http://stani.sh/walter/pfcts/](http://stani.sh/walter/pfcts/)

I actually built a solution: [http://stani.sh/walter/cims/](http://stani.sh/walter/cims/)

</comment><comment><USER6> The same clueless developer as seven months ago: [https://news.ycombinator.com/item?id=10857173](https://news.ycombinator.com/item?id=10857173)

</comment><comment><USER25> Configuration mismanagement, or why I hate puppet, ansible, salt... and chose chef?

Right.

</comment><comment><USER26> This post makes me want to meet the ops team at his company and find a better programmer than the author.</comment>


Discussion on changing name from PostgreSQL to Postgres - <AUTHOR> http://wiki.postgresql.org/wiki/Postgres

<comment><USER2> This is a wiki page created to _discuss_ the steps that would have to be taken _should the decision_ to change the name be taken.

As far as I know, the core team's position is that the product is called PostgreSQL, with Postgres being an acceptable alias.

If you ask me, this comic sums up the issue adequately: <http://xkcd.com/747/>

Alternatively, if you want to have a few laughs, check this out: [http://wiki.postgresql.org/wiki/File:05_-_Gabrielle_Roth_- _p...](http://wiki.postgresql.org/wiki/File:05_-_Gabrielle_Roth_- _pg_pronounce.pdf)

</comment><comment><USER3> As mentioned, this page has been up for ages (I've actually _read_ it previously). At this point its sort of pointless, it is normally referred to as 'Postgres' by people giving PG talks at conferences and such.

</comment><comment><USER4> Too much thinking about something which does not ultimately matter.

I regret even bothering to write these two sentences.

</comment><comment><USER5> At Heroku we call it Postgres in all things and at all times unless we're referring to official community stuff.

It's a much better name, and it's the original name, and I hope some day it will be the only name.

</comment><comment><USER6> Finally, i was never sure how to pronounce that damn thing! :P

</comment><comment><USER7> This is just a wiki page, not an official announcement.

</comment><comment><USER8> Maybe, just _maybe_ , people might actually be able to spell and pronounce it now. I mean, even the leaders in the feel fuck it up all the time.

</comment><comment><USER9> Having gone through a company rename with much less history than the PostgreSQL name, I would say this is a shockingly bad idea.

<comment><USER10> It's not much of a rename, though. Lots of people call it Postgres anyways. Besides, most people don't know how to pronounce PostgreSQL anyways, whereas Postgres is easily pronounceable.

I think it's a great decision.

</comment></comment><comment><USER11> some other names that I often use when refering to postgresql:

pgsql

psql

postgre

In the end postgres might end up just as confusing as postgresql, and in favor of the current name, at least it is status quo.

</comment><comment><USER12> I've (and all of my developer friends) have been calling it Postgres for years.

</comment><comment><USER13> This is not an announcement, and is a misleading HN submission. The history of that page makes it fairly obvious:

[http://wiki.postgresql.org/index.php?title=Postgres&acti...](http://wiki.postgresql.org/index.php?title=Postgres&action=history)

The text is almost verbatim since it was written in 2008. The last discussion on this was 2007/2008, as I recall:

[http://andyastor.blogspot.com/2007/08/postgresql-or- postgres...](http://andyastor.blogspot.com/2007/08/postgresql-or- postgres.html)</comment>


A protocol for detection of Covid-19 using CRISPR diagnostics [pdf] - <AUTHOR> https://www.broadinstitute.org/files/publications/special/COVID-19%20detection%20(updated).pdf <comment><USER2> Legit! We're also working on the same exact type of CRISPR (Cas13) to treat/prevent CoV (as an extension of the Bit Pharma Bio Firewall project we've been thinking about for ~7years) here:

[https://github.com/bionicles/coronavirus](https://github.com/bionicles/coronavirus)

Goal is to use gene therapy to make the lung cells delete the virus. Just imagine a Bio Firewall, that's what we're working on. We don't modify the cells' DNA, we add a new chromosome, and it's possible to make that self- destructing, which we'll do. got the side effect prediction algorithm working and posted a video on Twitter here: [https://twitter.com/bitpharma/status/1240986466437791744?s=2...](https://twitter.com/bitpharma/status/1240986466437791744?s=20)

Right now we're expanding the side effect prediction index from lung CDS to the whole transcriptome with LevelDB ( multiple orders of magnitude more data but we can reuse this algorithm and the prebuilt index across a number of different CRISPR projects) you could use the same exact process for a number of bugs, Flu would be a good one!

Please hit me up at email@example.com if interested to assist on stuff like plasmid design, computational directed evolution of stealth CRISPR, in vitro/vivo testing, or business stuff (we're hackers not MBAs!)

/yolo</comment>


Show HN: A full-featured public spreadsheet you can share and forget - <AUTHOR> http://sheets.alhur.es/s/z6nric <comment><USER2> Where does the computation happen? Is it all handled by JS in the browser, or is any done on the server side?

<comment><AUTHOR> All on the client side. If you look at the network tab, you'll see that the sheet information is just just a JSON file fetched directly from S3.

</comment></comment><comment><AUTHOR> Any feedback is appreciated.</comment>


Perl: Language, Community, and the Future - <AUTHOR> https://www.activestate.com/blog/2016/09/perl-language-community-and-future <comment><USER2> Why would I choose Perl over Python other than it's what they use where I work?</comment>


How many billable hours do you work? - <AUTHOR> If you're a freelancer or work for a consultancy or agency (especially if you're a dev), how many billable hours per day/week do you work on?<p>Also what do you bill for or not bill for? Do you bill for coffee or bathroom breaks, for example? <comment><USER2> I do bill for small breaks as well, not including lunch break for sure.

As I wanted to keep track of every single hour I work on, I did build Waywo a small tool to ask me every few minutes what I am currently working on: [https://byrly.com/waywo/](https://byrly.com/waywo/)

<comment><USER3> A tool that never let you focus on a task and pull constantly from your flow? That's great! /s

<comment><USER2> Give it a try. Thought about that the same, but it is so in my muscle memory now that is not pulling me away from any flow :D</comment></comment></comment>


Ask HN: Do developers need Architects? - <AUTHOR> How does your company architect systems? Is it left to senior devs in the team or you have architects who does this ? How has been the experience so far and which works the best from your experience? <comment><USER2> It is usually best to leave architecture design to architects however dev can architect a system if they have the necessary experience/skill.

It depends on the Dev, the size of the company, other resources. If a company can expand resources and have a dedicated team for architecture and design, then it makes the most sense that they can gain the greatest efficiency in the system by also having dev that is dedicated to the task of development.

</comment><comment><USER2> That's a very vague question... need more information.</comment>