Stop participating in hackathons just to win - <AUTHOR> http://venturebeat.com/2013/03/30/entrepreneurs-stop-participating-in-hackathons-just-to-win-them/ <comment><USER2> I feel like I've lived some kind of sheltered life now, in that I didn't even know winning was a _thing_ at hackathons until I read this article. I don't think I've ever been to a hackathon that had prizes and winners.

When I think of the term "hackathon", what comes to mind are events like the OpenBSD hackathons (<http://www.openbsd.org/hackathons.html>), the Wikimedia hackathons (<http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013>), and SuperHappyDevHouse (<http://superhappydevhouse.org>). You can't _win_ any of those, at least not in any kind of formal sense.

The use of the term "hackathon" here seems to mean something else, less of a dev-party and something more like, a time-limited, minimum-viable-product startup competition. Is that a recent thing?

<comment><USER3> I'm not trying to get involved with defining what a hackathon is (or isn't), but I do know that Startup Weekend (www.startupweekend.org) has been hosting events that have prizes and winners for quite some time now.

<comment><USER4> Yes, But SW it's not a hackathon (at least not in Dallas).

</comment></comment></comment><comment><USER5> You know you've pretty much hit rock bottom as an industry when people are complaining about Robert Scoble being mean about their fake business that they created while on a bus to an expensive party.

<comment><USER6> The problem is that Silicon Valley has been flooded in recent years by people who watched The Social Network and took it literally, believing this is how startups are done. This Hollywood fake version of a startup has become the model for so many folks trying to do real startups. I believe Baudrillard should be compulsory reading for entrepreneurs.

<comment><USER7> Any evidence to back that up? I haven't observed this at all.

</comment></comment></comment><comment><USER8> What should really happen is for hackathons to stop awarding prizes. There's no need for them. Most people go to hackathons because they want to meet people, try new things and learn stuff.

<comment><USER9> The problem is, the OP isn't talking about hackathons. He's talking about... Startup Weekend or other business oriented events.

Hackathons aren't about slides or business plans. They are about building something.

</comment></comment><comment><USER10> I quit going to hackathons when they started to turn into "do something with our web service" instead of "X straight hours of whacking away at whatever project you're working on, surrounded by like minded people doing their own thing, that you can bounce problems off of when you get stuck".

There are two local hackathons coming up, neither of which I'm the slightest bit interested in, since both are based around handfuls of companies and their products' web-based APIs. It's obvious that they are not interested in you turning out a product, or even getting a start on a product. They're using you to determine possible areas their company could branch into, and like Tom Sawyer, they're getting you to pay to help them.

<comment><USER11> FWIW those product/company sponsored hackathons aren't all hackathons. StartupWeekend happens with some regularity in tons of cities across the US, and their schtick is "build-a-business-in-a-weekend". So you're free to come up with whatever idea and build that.

</comment></comment><comment><USER12> Here is the number one reason people don't win hackathons (even if they have an amazing creation) - they suck at explaining.

I was at one recently where a guy showed off what promised to be a very interesting way of analysing data. He spent his 5 minute demo slot talking about how he rewrote a webserver in "Go"...

I mean, ok, from a geek point of view it's kind of interesting that he wrote an amazing server but a) this wasn't a server hackathon and b) he couldn't explain his way out of a wet paper bag.

At the last hackathon I went to, one losing team spent their slot arguing about why they couldn't connect their Macbook to the 800*600 projector used for demoing. Ok, we all experience technical difficulties, but this team had sat through 30 minutes of presentations and at no point thought "Hey, we'd better make sure we don't waste time like these other teams - let me quickly Google how to set my external screen resolution."

Honestly, the biggest thing standing between you and victory is (probably) your inability to succinctly explain your idea in such a way that you will captivate the judges.

</comment><comment><USER13> What I don't get so much is the push to take the result of a hackathon and turn it into a company. Several occasions I have seen investors promise to invest in winners, but most of the time it is just a group of people together for the weekend with already their startup or a dayjob. Lauch, Angelhack have this actually built in. Result: more focus on business and already existing teams (companies?) that come in together to use the event as a launching platform. Which is not the goal for me for a hackathon: trying out technologies, meeting new people, have fun. I already have my startup, don't need another.

<comment><USER14> Except it can be a fantastic way to launch a company. Social proof, publicity, and credibility all in one weekend. Look at companies like Roximity that effectively launched by winning Ford's contest at Disrupt. That's a real startup now.

If you don't have a current venture you're working on, why not use a hackathon as an accelerant?

<comment><USER13> because it is cheating to the judges, competitors and to possible people that join up with my team and would put in hours for free. I am already out there with my company. The number of successful startups that come out of a hackathon is actually quite low I'd say.

</comment></comment></comment><comment><USER15> I'm a big hackathon fan and participant and I can sympathize with the emotional high of "hey, we built something really cool" to the low of "the judges didn't just didn't understand what we've built". Most of the hackathons in which I've participated use a panel of judges from the VC or general "tech community" but whom aren't usually hackers themselves. I'd love to see an event where the judges know what it takes to produce something that works in a compressed timeframe and don't ask the inane questions like "how are you going to make money?" or "who are your competitors?"

I'm also bootstrapping my startup primarily for the same reasons. I don't particularly want or need validation from VCs, many of whom aren't hackers, to distract me from figuring out whether what I've built is of any value to my customers.

<comment><USER16> Have hackathons really turned into a prototype show-and-tell crossed with a business plan competition? Because that's what a lot of these hackathon contests seem like.

</comment></comment><comment><USER17> I really agree with this post. Hackathons can be used as a great way of energizing, educating, and building a community of passionate, motivated hackers.

I'm really interested in using this force to build the next generation of technologists, and we're currently doing this via an event called CodeDay.

High school / college students are always busy -- they have tests, homework assignments, jobs, and other things that prevent them from spending time on the things they want to do. A hackathon provides these students an opportunity to focus, and for the students that are learning some tech on the side to actually create something. At the same time, beginners who are interested in technology get started and feel empowered to start learning and experimenting in their own time. They all become friends, and create amazing things.

Through CodeDay,

* A High School student made $20,000+ building an android app he thought would be useful called Sidebar Pro: [https://play.google.com/store/apps/details?id=mohammad.adib....](https://play.google.com/store/apps/details?id=mohammad.adib.sidebar)

* High school students made a replica of Leap Motion's capture device: [http://blog.studentrnd.org/post/46637262311/studentrnd-profi...](http://blog.studentrnd.org/post/46637262311/studentrnd-profile-from-sf-codeday-to-dinner-with-leap)

* We created countless technologists, provided students with connections to jobs, and more!

Other news:

* [http://www.king5.com/news/Students-in-code-heaven-at-Code-Da...](http://www.king5.com/news/Students-in-code-heaven-at-Code-Day-193177871.html)

* [http://blogs.splunk.com/2013/02/19/studentrnds-1st-code-day-...](http://blogs.splunk.com/2013/02/19/studentrnds-1st-code-day-sf-success/)

We're currently in 6 cities, and looking for people to help us take this across the country to more cities! Check it out: <http://codeday.org/>

<comment><USER17> Psychedelic Frisbee Hospital is probably my favorite thing from CodeDay:

<http://zaqthefreshman.com/FlyingDiscHospital/>

</comment></comment><comment><USER18> Question: I've been wanting to attend a hackathon, but I have no idea where to find when/where they happen? Is there some sort of list, or do I just need to keep my ear to the ground?

<comment><USER6> I will probably get torn down by the HN crowd for this one, but I think the best one around is still the TechCrunch hosted one annually at Disrupt. If you've never been to one that's a great starting point, and it's free - I am a skeptic of the new trend of for-profit hackathons with entry fees, personally.

I still think that's a good starting point.

The Startup Digest is a good source of information on upcoming Hackathons.

</comment></comment><comment><USER6> I think part of the problem here is that there are so many Hackathons around nowadays, it's hard to attract attention to your hackathon, and attendees. This is even worse for the for-profit ones rather than the more social affairs. As a result they seem to have chosen to focus on prizes and big money as their core marketing angle. This raises the stakes and makes it far more about pursuing the dollars for many participants.

I've seen people pitching their startup idea in the one minute presentation for the hackathon, thinking that this is the best way to launch a company (spoiler alert: it's not!). Yes there have been some nice positive stories coming from projects that started at hackathons, but that's the exception.

I love hackathons. I have a couple of buddies and we go to every TechCrunch hackathon, and some of the others from time to time. We do it because it's fun. We love the social aspect of it. We don't go expecting to win. We go because we enjoy it.

I like the little side prizes $x free services for the best on Y platfom; a free iPad for the best using Z platform. But when it's become about $50,000 grand prizes, and places in unproven incubators/accelerators I think we risk destoying the atmosphere of hackathons. We'll drive away the social participants and it'll just be competitive hackathoners, and when they realize it's not the best way to achieve their startup goals they'll move on...

Let's just go back to fun hackathons, like the old TechCrunch ones used to be. Good food, social activities, fun atmosphere, lots of vendors and partners to teach us about their APIs and perhaps a few side prizes that are nice-to-wins but don't have people thinking this will make or break their startup.

</comment><comment><USER3> From my experience, different people view Hackathons differently. I wouldn't want to make any blanket statements about why one should or shouldn't go, or what the focus should be. I don't really think there is anything wrong about being competitive and wanting to win. I think what's important is recognizing what you want, and building a team of people that match. Some people will be competitive and serious about winning. Others may be more laid back, and just want to enjoy the experience. Some may want to actually create a product and start a business. Others may just want to work with new technology, or learn something new. Building a team that is aligned with your views and expectations is important. If you don't build the right team, the experience can become frusturating. In extreme cases, it might even pull the team apart.

</comment><comment><USER19> Wait, what happened with Scoble?

</comment><comment><USER20> I am shocked, shocked I say, that people who have just gone three days with almost no sleep get grouchy, whiny, and stupid. Not getting enough sleep isn't cool, it doesn't make you more productive, and for many people it makes you a horrible person to be around. Unfortunately, it seems that many coders still view it as a badge of honor, not the symptom of poor decision making. (See the author of this post, cheering on the group who made a 'bold' decision to go out drinking instead of getting sleep.)

</comment><comment><USER21> > Once I realized that, I looked around me. I saw a group of people whom I > know will be successful as they push onward, because I've seen them go > through hell and still come out on top.

The phrase 'have gone through hell' is not at all applicable to losing this competition. The competition comes with a two/three day investment and allows one to focus on the social aspect of the gathering.

</comment><comment><USER22> It shouldn't be possible to win a hackathon. Building things is fun, and the fun of one team is not worth more than the fun of another.

</comment><comment><USER23> Been to design-a-thon's (same, same but different) and haven't met anyone there to win, people enjoy working on a problem with others. There were prizes, but more as tokens, not anything worth shouting about.

</comment><comment><USER24> Title is misleading; the story is about not being a sore loser.

</comment><comment><USER25> Why don't they just give away prizes randomly in a raffle at the end?

Teams can still win, but losing a contest that has no prize is seldom as stinging.

</comment><comment><USER26> Lol. That's like saying stop doing startups just for money.

Do you see the irony?</comment>


Amundsen – Data Discovery from Lyft - <AUTHOR> https://github.com/lyft/amundsenfrontendlibrary <comment><AUTHOR> Amundsen is a metadata driven application for improving the productivity of data analysts, data scientists and engineers when interacting with data. It does that today by indexing data resources (tables, dashboards, streams, etc.) and powering a page-rank style search based on usage patterns (e.g. highly queried tables show up earlier than less queried tables). Think of it as Google search for data. The project is named after Norwegian explorer Roald Amundsen, the first person to discover South Pole.

It includes three microservices and a data ingestion library.

amundsenfrontendlibrary: Frontend service which is a Flask application with a React frontend. amundsensearchlibrary: Search service, which leverages Elasticsearch for search capabilities, is used to power frontend metadata searching. amundsenmetadatalibrary: Metadata service, which leverages Neo4j or Apache Atlas as the persistent layer, to provide various metadata. amundsendatabuilder: Data ingestion library for building metadata graph and search index. Users could either load the data with a python script with the library or with an Airflow DAG importing the library.

</comment><comment><USER2> They did a very interesting podcast on this tool describing it in more detail: [https://softwareengineeringdaily.com/2019/04/16/lyft-data- di...](https://softwareengineeringdaily.com/2019/04/16/lyft-data-discovery- with-tao-feng-and-mark-grover/)</comment>


Ask HN: Is 10 yrs exp too 'Senior' for a Senior Dev? - <AUTHOR> <comment><USER2> The problem is new devs thinking they're senior right out of college.

</comment><comment><USER3> _Too_ senior? I'd say there's really no such thing, so long as the engineer is suitable for the job in terms of what she's looking for and what areas of expertise she has.</comment>


Ask HN: Why is Microsoft not part of FAANG? - <AUTHOR> <comment><USER2> FAANG doesn't make a lot of sense as a category, but it the kind of glib thing that rolls off the tongue.

For instance, Apple is a hardware manufacturer. The other ones aren't. Amazon has a major presence in e-commerce. The others do not. Netflix has more in common with the Walt Disney Corporation and 20th Century Fox than the others. Facebook and Google do look similar if you squint, however.

In another world not too far from this one, Netflix might be off the list, Microsoft might be on. Maybe Tesla would be on the list.

</comment><comment><USER3> Microsoft may be part of that sooner than later. They are actively discouraging folks from using the Office suite of products and instead using their cloud solutions, similar to Google docs.

Then there is the gaming side of the fence. With time, less people will have games installed locally. As is, you may find it difficult to play any M$ games without internet connectivity. Combine this with cortana staring into your soul, and they might start to slip into the name.

What can you spell if you add the letter M?</comment>


Estimates Number of Asteroids Worth Mining (Spoiler: Not Very Many)  - <AUTHOR> https://medium.com/the-physics-arxiv-blog/e0063699d199 <comment><USER2> Got me thinking - what would happen to the earth's orbit if we mined all the asteroids?</comment>


Apple iMessage and Poor User Experiences - <AUTHOR> http://mgalligan.com/post/13214024991/apple-imessage-and-poor-user-experiences <comment><USER2> I think a thing to remember is that Apple will probably iterate on this, much like any other technology, and make it better with each release. At least, that is my hope. I sadly don't have enough friends with iPhones to notice… so I'm stuck keeping my unlimited text messaging for the time being.

</comment><comment><USER3> Thing that sucks the most about it is that I can only use this service from my iPad. I SMS mostly from my browser when I'm at my computer. Sometimes my iPad when I'm away, otherwise my phone. I'd like to be able to communicate with more Apple users a bit more freely.

<comment><USER2> There have been rumors of iChat getting iMessage integration of some kind.

But I'd like it to be taken a step further. I'd really like to be able to have my phone in a charger a la a WebOS device and have text messages and iMessages go directly to my computer or iPad so that I could reply from there. The messages can go through the internet from those devices, or directly through the iPhone. I don't care which, so long as I have the ability to use my Mac and iPad without having to use my phone for every message.

</comment></comment><comment><USER4> The author seems to have missed the fact that iMessage only lets you send non- sms messages when the other contact is online (blue "send" button), otherwise it's sms only (green button).

They never said you'd be able to send free SMS from an internet connection, so that table is kind of obvious. In the end, the user doesn't have to care, it just works. The only case where you might lose a message is if the recipient disconnects right before you send it, and even then you'll know it wasn't delivered. FaceTime is in much worse waters.

<comment><USER5> >iMessage only lets you send non-sms messages when the other contact is online (blue "send" button)

in theory yes, in practice it tries to send imessage when _i am_ online, but my recipient isn't

<comment><USER4> Just tested here. It will do that, but after a few minutes without confirmation, it will resend the message as SMS. You can explicitly tell it to do that by holding over a message baloon.

<comment><USER5> Right, though I would think it checks recipient status right away</comment></comment></comment></comment>


Ask HN: Which configuration management software would/should you use in 2020? - <AUTHOR> What is your team using at work? What should be used at scale (FAANG, or similar)? What are you planning to switch to? <comment><USER2> Not FAANG but for small to medium "cloud native" businesses I like to use this approach with minimal dependencies:

Managed Kubernetes cluster such as GKE for each environment, setup in cloud provider UI since this is not done often. If you automate it with terraform chances are next time you run it, the cloud provider has subtly changed some options and your automation is out-of-date.

Cluster services repository with Helm charts for ingress controller, centralized logging and monitoring, etc. Use a values-${env}.yaml for environment differences. Deploy with CI service such as Jenkins.

Configuration repository for each application with Helm Chart. If it's an app with one service or all services in a single repo this can go in the same repo. If it's an app with services across multiple repos, create a new repo. Use a values-${env}.yaml for environment differences. Deploy with CI service such as Jenkins.

Store secrets in cloud secrets manager and interpolate to Kubernetes secrets at deploy time.

Cloud provider keeps the cluster and VMs up-to-date, CI pipelines do the builds and deployments. No terraform/ansible/other required. Again, this only works for "cloud native" models.

<comment><USER3> Yeah, in a decent architecture the only place state is located is in the datastore layer.

The goal is to make servers disposable, able to be destroyed and created at will, so configuration management becomes kind of a legacy technology at that point.

<comment><USER4> Yes, but created from what? This can be called config mgmt too.

<comment><USER2> For traditional datastore, I usually do:

Dev/QA/Similar: Either containerize and back to persistent volume, or use a managed DB service such as RDS or Cloud SQL and create a schema per environment. Include a deployment pipeline argument to reset to known state. CI pipeline can be tuned to handling dynamic environments in either case.

Stage/Prod: Use managed DB service such as RDS or Cloud SQL.

The time and cost to automate a DB upgrade with every edge case considered is huge. Rarely makes sense for small/medium business.

<comment><USER5> Nitpick: I really don't suggest a divergence in the DB/stack-of-choice between Dev/QA/Stage/Prod. I've chased so many issues that were in the planning process dismissed as "yeah that's an edge case and most likely won't happen".

The reasons I've seen for doing so are usually penny-wise, pound-foolish. Penny-wise in saving a few dollars (conceptually) on a spreadsheet for per- env/per-cycle, while neglecting the long-tail consequence of your labor factor just growing, potentially forever, without regard for total cost of ownership.

Sorry didn't mean to rant. Hope this helps.

</comment></comment></comment></comment></comment><comment><USER6> I still prefer the Open Source edition of [https://puppet.com/](https://puppet.com/) to manage larger, diverse environments - which may include not just servers, but workstations, network appliances and so on. It's well established with lots of quite portable modules. But it can also be a bit on the slower side and comes with a steeper learning curve then some of the others.

[https://www.ansible.com/](https://www.ansible.com/) is surely a good solution for Bootstraping Linux cloud machines and can be quite flexible. I personally feel like its usage of YAML manifests instead of a domain-specific language can make complex playbooks harder to read and to maintain.

If all you do is to deploy containers on a managed Kubernetes or a similar platform, you might get away with some solution to YAML templating (jsonnet et al) and some shell glue.

I am keeping an eye on [https://github.com/purpleidea/mgmt](https://github.com/purpleidea/mgmt) which is a newer contender which many interesting features but lacks more complex examples.

Others like saltstack and chef still see some usage as far as I know, but I've got no personal experience with them.

<comment><USER7> Ansible amazing for configuration management, much better than Puppet. Storing the config in YAML makes it super easy to read and maintain, also much better than Puppets method.

As you mention, puppet has a steep learning curve, whereas Ansible has a very shallow one. It's easy to get running in a few minutes!

We use both Puppet and Ansible at work, and its constant complaints and delays with Puppet whereas Ansible is little complaints and no delays.

<comment><USER8> > We use both Puppet and Ansible at work, and its constant complaints and > delays with Puppet whereas Ansible is little complaints and no delays.

That's probably because you are not running masterless, which means your puppet master is a bottle neck.

<comment><USER7> The master is part of the bottleneck, but a lot of the complaints are trying to get it to do what it says. But a big benefit of puppet is the master feature, so if that's taken out, why puppet?

<comment><USER8> Puppetmaster took off because it conceptually easy to understand to people who were used to managing servers by hand.

I would argue that masterless puppet is a superior pattern for both scaling creating a hierarchical structures.

</comment></comment></comment></comment></comment><comment><USER9> I favor Ansible for 2 main reasons:

\- If you have SSH access, you can use it. No matter what environment or company you work for, there's no agent to install and no need to get approval to use the tool. It's easy to build up a reproducible library of your shell habits that works locally or remotely, where each step can avoid being repeated in case there's a need to rerun things.

\- If you get into an environment where performance across many machines is more important you can switch to pull based execution. Because of that, I see very little advantage to any of the other tools that outweighs the advantages of Ansible.

<comment><USER10> > If you have SSH access, you can use it. No matter what environment or > company you work for, there's no agent to install

I don't get why is this always brought up as a major advantage when discussing CM. Ansible actually installs its Python runtime to target systems. Once I had a server that had full disk root and Ansible failed to work because there was no space left to copy tons of its Python code.

<comment><USER11> Ansible doesn't install a runtime on the target machine, it temporarily copies over the scripts that do the work and removes them after the run is complete. These are a few kilobytes typically.

No configuration system is likely to work with a full root partition, though.

<comment><USER12> Agree. Although I personally prefer Ansible to the alternatives, the one thing I don't like is that it does require python to be installed on the target hosts for most modules. That's not a problem usually, but every now and then it is. Also, sometimes additional python package requirements are needed, managing those in an automated manner is usually a hassle....

I've had this idea for a config management system that compiles all provisioning code to posit shell. One of those years I'll finish it... :-)

<comment><USER13> > it does require python to be installed on the target hosts for most modules

I recently learned that ansible supports binary modules, in addition to the OOtB support for modules written in any already-configured scripting language (including shell): [https://docs.ansible.com/ansible/2.9/dev_guide/developing_pr...](https://docs.ansible.com/ansible/2.9/dev_guide/developing_program_flow_modules.html#binary- modules)

However, while I know you meant "all the provided modules," it seems they are headed toward a less "batteries included" style and more (pypi|maven|npm|rubygems) style of "the community will sort it out" mechanism of distribution: [https://docs.ansible.com/ansible/2.9/user_guide/collections_...](https://docs.ansible.com/ansible/2.9/user_guide/collections_using.html#using- collections)

Which I welcome wholeheartedly because landing even the simplest fixes to ansible modules is currently a very laborious and time intensive operation

</comment></comment></comment></comment></comment><comment><USER14> I'm curious why people use configuration management software in 2020. All of that seems like the old way of approaching problems to me.

What I prefer to do is use Terraform to create immutable infrastructure from code. CoreOS and most Linux variants can be configured at boot time (cloud- config, Ignition, etc) to start and run a certain workload. Ideally, all of your workloads would be containerised, so there's no need for configuration drift, or for any management software to be running on the box. If you need to update something, create the next version of your immutable machine and replace the existing ones.

<comment><USER15> "Immutable infrastructure" what a laugh. In a large deployment, configuration somewhere is _always_ changing - preferably without restarting tasks because they're constantly loaded. We have (most) configuration under source control, and during the west-coast work day it is practically impossible to commit a change without hitting conflicts and having to rebase. Then there are machines not running production workloads, such as development machines or employees' laptops, which still need to have their configuration managed. Are you going to "immutable infrastructure" everyone's laptops?

(Context: my team manages dozens of clusters, each with a score of services across thousands of physical hosts. Every minute of every day, _multiple_ things are being scaled up or down, tuned, rearranged to deal with hardware faults or upgrades, new features rolled out, etc. Far from being immutable, this infrastructure is remarkably _fluid_ because that's the only way to run things at such scale.)

Beware of Chesterton's Fence. Just because you haven't learned the reasons for something doesn't mean it's wrong, and the new shiny often re-introduces problems that were already solved (along with some of its own) because of that attitude.

<comment><USER16> Are you sure you two are talking about the same thing?

My understanding of immutable infrastructure is the same as immutable data structures: once you create something, you don't mess with it. If you need a different something, you create a new one and destroy the old one.

That doesn't mean that the whole picture isn't changing all the time. Indeed, I think immutability makes systems overall more fluid, because it's easier to reason about changes. Mutability adds a lot of complexity, and when mutable things interact, the number of corner cases grows very quickly. In those circumstances, people can easily learn to fear change, which drastically reduces fluidity.

<comment><USER17> Yup. We do this. When our servers need a change, we change the AMI for example, and then re-deployment just replaces everything. Most servers survive a day, or a few hours.

<comment><USER18> Configuration Management is still present in this process, it's just moved from the live system to the image build step.

<comment><USER15> Probably the most insightful comment in this entire thread. Thank you. In many cases, an "image" is just a snapshot of what configuration management (perhaps not called such but still) gives you. As with compiled programming languages, though, doing it at build time makes future change significantly slower and more expensive. Supposedly this is for the sake of consistency and reproducibility, but since those are achievable by other means it's a false tradeoff. In real deployments, this just turns configuration drift into container sprawl.

</comment></comment></comment></comment></comment></comment><comment><USER19> Surprised more people here are not using Salt. Having used both Salt and Ansible, I much prefer Salt, especially when working with larger teams.

When working solo I use Guix, both Guix and Nix are _seriously_ amazing.

<comment><USER20> What's salt? Any link? I found something called SaltStack but that appears to be enterprise security software.

<comment><USER21> [https://github.com/saltstack/salt](https://github.com/saltstack/salt)

Salt (also known as SaltStack) was right.

> Salt is a new approach to infrastructure management built on a dynamic > communication bus. Salt can be used for data-driven orchestration, remote > execution for any infrastructure, configuration management for any app > stack, and much more.

<comment><USER20> Thanks!

I'm ultra confused about their marketing btw. Their website doesn't even say it's open source. You have to sign up to "try it now". It's like they don't want customers? Or are people who want to understand what they're buying not the target market, somehow?

For reference, this appears to be the Salt primer: [https://docs.saltstack.com/en/getstarted/system/index.html](https://docs.saltstack.com/en/getstarted/system/index.html)

<comment><USER22> I think there is a small subset of users where open source is actually a buying decision

<comment><USER20> Sure, but understanding what the thing is, that's part of the buying decision right? I have _no clue_ what [https://www.saltstack.com/](https://www.saltstack.com/) is about.

How do I get from this:

> _Drive IT security into the 21st century. Amplify the impact of your entire > SecOps team with global orchestration and automation that remediates > security issues in minutes, not weeks._

to "it's a provisioning tool for servers, like ansible but faster"?

<comment><USER23> The docs landing page have me an easier to grok picture of what it does, purely based on seeing what the doc headers are - [https://docs.saltstack.com/en/latest/](https://docs.saltstack.com/en/latest/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> I use Ansible, mostly because it works pretty well for deployments (on traditional, non-dockerized applications), and then I can just gradually put more configuration under management.

So it's a very good tool to gradually get a legacy system under configuration management and thus source control.

</comment><comment><USER25> My default tends to be Ansible because it is really versatile and lightweight on the systems being managed. That versatility can bite you though because it's easy to use it as a good solution and miss a great one. Also, heaven help you if you need to make a change on 1000s of hosts quickly.

I also use (In order of frequency): Terraform, Invoke (Sometimes there is no substitute for a full programming language like python), Saltstack (1000's of machines in a heterogenous environment)

If I were going to deploy a new app on k8s today, I would probably use something like [https://github.com/fluxcd/flux](https://github.com/fluxcd/flux).

I haven't really had a pleasant time with the tooling around serverless ecosystem yet once you get beyond hello worlds and canned code examples.

<comment> yjftsjthsd-h > Also, heaven help you if you need to make a change on 1000s of hosts > quickly.

Why? I would have seen that as Ansible's strong point.

<comment><USER26> It gets terribly slow and eats up literal 10s of gigabytes of RAM. Extensions like mitogen can help, though.

[https://mitogen.networkgenomics.com/ansible_detailed.html](https://mitogen.networkgenomics.com/ansible_detailed.html)

<comment> yjftsjthsd-h Re: performance: That's fair. I didn't realize it scaled _that_ badly.

Re: mitogen: Thanks! I saw that once, a long time ago, but couldn't find it again. I'll have to try it; vanilla ansible is fine for me so far, but I'm hardly going to ignore a speed boost that looks basically free to implement.

</comment></comment></comment></comment><comment><USER27> I might be fanboy of the type safety and having a quick feedback loop, but I cannot imagine a better configuration management system than just straight configuration as code e.g. in Go: [https://github.com/bwplotka/mimic](https://github.com/bwplotka/mimic)

I really don't see why so many weird, unreadable languages like jsonnet or CUE were created, if there is already a type safe, script-like (Go compiles in miliseconds and there is even go run command), with full pledged IDE autocompletion support, abstractions and templating capabilities, mature dependency management and many many more.. Please tell me why we are inventing thousands weird things if we have ready tools that helps with configuration as well! (:

<comment><USER28> I agree. I wish we could just use EDN and Clojure, but your DevOps guy is not writing Go or Clojure code.

They are also not doing code reviews to enforce security policies.

If you have DevOps guys who are also software developers, more power to you, but if I approach my DevOps team with:

Hey just code your scripts in this turing-complete languages, they will ask me "what's your username again?" BOFH-style ;)

<comment><USER29> Holy gods yes! Please let me use a real programming language instead of an unholy mixture of yaml and jinja. Clojure would be such a dream!

<comment><USER30> Check out Spire,

[https://github.com/epiccastle/spire](https://github.com/epiccastle/spire)

</comment></comment></comment></comment><comment><USER31> Hashicorp tools are quite solid, and give you a lot for free. Ansible can automate host-level changes in places where hashicorp cannot reach. There shouldn't be many such places.

Alternatively, if you have the option of choosing the whole stack, Nix/NixOS and their deployment tools.

I would recommend staying away from large systems like k8s.

</comment><comment><USER32> Here's what we're using which I'm pretty happy with:

0\. Self-hosted Gitlab and Gitlab CI.

1\. Chef. I'd hardly mention it because it's use is so minimal but we have it setup for our base images for the nitpicky stuff like connecting to LDAP/AD.

2\. Terraform for setting up base resources (network, storage, allocating infrastructure VMs for Grafana).

3\. Kubernetes. We use a bare minimum of manually maintained configuration files; basically only for the long-lived services hosted in cluster plus the resources they need (ie: databases + persistent volumes), ACL configuration.

4\. Spinnaker for managing deployments into Kubernetes. It really simplifies a lot of the day-to-day headaches; we have it poll our Gitlab container repository and deploy automatically when new containers are available. Works tremendously well and is super responsive.

</comment><comment><USER33> Nix (nixos, nixops) is worth looking into if you want a full solution and can dedicate the time and energy.

<comment><USER34> Also Morph, which is like NixOps, but stateless:

[https://github.com/DBCDK/morph](https://github.com/DBCDK/morph)

<comment><USER35> Morph is lovely because it ends up being a very thin layer over the existing Nix toolkit. All it does is deploy your NixOS config to a remote machine.

</comment></comment></comment><comment><USER36> We use Ansible with Packer to create immutable OS images for VMs.

Or Dockerfile/compose for container images.

Cloud resources are managed by Terraform/Terragrunt.

<comment><USER37> I think this is the ideal scenario for Ansible— one-time configuration of throwaway environments, basically as a more hygenic and structured alternative to shell scripts.

My experience trying to manage longer lived systems like robot computers over time with Ansible has been that it quickly becomes a nightmare as your playbook grows cruft to try to account for the various states the target may be coming from.

<comment><USER38> Could you say more about why ansible is better than shell scripts for one-time configuration? In my mind, ansible's big advantage over shell scripts is that it has good support for making incremental changes to the configuration of existing resources. In a situation like packer, where the configuration script only gets run once, I prefer the conciseness of a shell script.

<comment><USER37> I see the incremental piece as a dev-time bonus rather than something to try to leverage much in production— it lets you iterate more quickly against an already-there target, but that target is still basically pristine in that any accumulated state is well understood. But that's very much not the case if you're trying to do an Ansible-driven incremental change against a machine that was deployed weeks or months earlier.

Even in the run-once case, though, I think there's a benefit to Ansible's role-based approach to modularization. And again for the dev scenario, it's much easier to run only portions of a playbook than it is to run portions of a shell script.

And finally, the diagnostics and overall failure story are obviously way better for Ansible, too.

Now, all this said, I do still go back and forth. For example, literally right now in another window I'm working a small wrapper that prepares clean environments to build patched Ubuntu kernels in— and it's all just debootstrap, systemd-nspawn, and a bunch of shell script glue.

</comment></comment></comment></comment><comment><USER39> Dhall: [https://dhall-lang.org/](https://dhall-lang.org/)

<comment><USER40> I haven't used either (yet) but Dhall or Cue lang should be on your list of candidates IMO.

[https://cuelang.org/](https://cuelang.org/)

(To me things like puppet or ansible seem like thin layers over shell and ssh, whereas both Dhall and Cue seem to innovate in ways that are more, uh, _je ne sais quoi_ ;-) YMMV)

<comment><USER41> Just started using Cue, it is fantastic. It was built for this problem

</comment></comment></comment><comment><USER42> You can never go wrong with bash, you should not put secrets in 169.254.169.254 metadata and you should not have IAM profiles that have overreaching privileges. Any IAM profile that you use or whatever you use on azure or gcp you should always consider what somebody can do with it if they get access to it.

<comment><USER42> Probably also just straight up docker and docker compose is another good idea, and terraform and possibly hashicorp vault are real high on the list, too. Ansible and chef and puppet are all pretty esoteric and I thought chef was great till I just got good with bash and gnu parallel

</comment></comment><comment><USER43> Salt because it's declarative and runs on linux, windows and osx.

</comment><comment><USER44> I have been using Ansible for over four years now, my current use case has around 1k VMs and a handful of baremetal in a couple of different datacenters running 100s of services.

No orchestration as well FWIW, we usually have ansible configuring Docker to run and pulling the images...

As for the future I have been meaning to explore Terraform and some Orchestration platforms (Nomad).

</comment><comment><USER4> I would go with Ansible for side projects/smaller tasks, and use Puppet at large.

<comment><USER45> Any reasons for those choices?

<comment><USER4> Ansible is just extremely easy to begin with, and comfortable to use since it is an agentless solution using SSH. As for Puppet, well, it could largely depends on your team. Is it a devops one or a strictly dev one? Puppet seems to be the perfect balance for us (devops mostly, but devs can touch it with confident too)

</comment></comment></comment><comment><USER46> Shameless plug for a thing I maintain, which is in the config management space but a little bit different from the usual tools: [https://github.com/sipb/config-package-dev#config-package- de...](https://github.com/sipb/config-package-dev#config-package-dev)

config-package-dev is a tool for building site-specific Debian packages that override the config files in other Debian packages. It's useful when you have machines that are easy to reimage / you have some image-based infrastructure, but you do want to do local development too, since it integrates with the dpkg database properly and prevents upgraded distro packages from clobbering your config.

My current team uses it - and started using it before I joined the company (I didn't know we were using it when I joined, and they didn't know I was applying, I discovered this after starting on another team and eventually moved to this team). I take that as a sign that it's objectively useful and I'm not biased :) We also use some amount of CFEngine, and we're generally shifting towards config-package-dev for sitewide configuration / things that apply to a group of machines (e.g. "all developer VMs") and CFEngine or Ansible for machine-specific configuration. Our infrastructure is large but not quite FAANG-scale, and includes a mix of bare metal, private cloud and self-run Kubernetes, and public cloud.

I've previously used it for

\- configuring Kerberos, AFS, email, LDAP, etc. for a university, both for university-run computer labs where we owned the machines and could reimage them easily and for personal machines that we _didn 't_ want to sysadmin and only wanted to install some defaults

\- building an Ubuntu-based appliance where we shipped all updates to customers as image-based updates (a la CrOS or Bottlerocket) but we'd tinker with in-place changes and upgrades on our test machines to keep the edit/deploy/test cycle fast

<comment><USER47> Thanks for posting this. I've rolled my own version of this in the past and was very happy with the end results.

</comment></comment><comment><USER48> Ansible for dev boxes or smaller deployments. For large-scale deployments CFEngine3. When deployed within a cloud environment one doesn't even need a master node for CFE3 but the agents can just pull the latest config state from some object storage.

</comment><comment><USER49> If you want massive parallel remote script execution, none beat gnu parallel or xargs + "ssh user@host bash < yourscript.sh".

All of cofiguration management tools( ansible, puppet, chef, salt etc ..) are bloated.

We already have FINE SHELL. Why do we need crappy ugly DSL or weird yaml ??

These days, Newbies write ansible playbooks without even basic unix shell & commands knowledge. What the hell?

I like ssh + pure posix shell approach like

Show HN: Posixcube, a shell script automation framework alternative to Ansible [https://news.ycombinator.com/item?id=13378852](https://news.ycombinator.com/item?id=13378852)

</comment><comment><USER50> I typically use terraform and ansible. tf creates/manages the infrastructure and then ansible completes any configuration.

<comment><USER51> This is the approach we take. We don't track states or do continuous config management either as we're all in on cattle > pets (and we don't typically have the time to maintain terraforms properly enough to do anything but cut new environments). Something gets sick? Shoot it and stand up another one.

</comment></comment><comment><USER52> Funnily, I wrote my take on this not too long back:

[http://madhadron.com/posts/choosing_your_base_stack.html](http://madhadron.com/posts/choosing_your_base_stack.html)

Don't be distracted by FAANG scale. It's not relevant to most software and is usually dictated by what they started using and then deployed lots of engineering time to make work.

My suggestion is to figure out how you will manage your database server and monitoring for it. If you can do that, almost everything else can fall into line as needed.

<comment><USER53> Why did you leave out DigitalOcean and Terraform?

<comment><USER52> Terraform isn't equivalent to Puppet, Chef, or Salt. It's a tool for specifying cloud deployments, not a configuration management system.

DigitalOcean might be fine. So is Arch Linux. But if someone just wants to get on with what they're interested in with a minimum of fuss over time, it wouldn't be the right recommendation.

</comment></comment></comment><comment><USER54> I've prototyped ansible for rolling out ssl certs to a handful of unfortunately rather heterogeneous Linux boxes - and it worked pretty well for that.

I still think there's too much setup to get started - but am somewhat convinced ansible does a better job than a bunch of bespoke shell would (partly because ansible comes with some "primitives"/concepts such as "make sure this version of this file is in this location on that server - which is quick to get wrong across heterogeneous distributions).

We're moving towards managed kubernetes (for applications currently largely deployed with Docker and docker-compose on individual vms).

I do think the "make an appliance;run an appliance;replace the appliance" life cycle makes a lot of sense - I'm not sure if k8s does yet.

I think we could be quite happy on a docker swarm style setup - but apparently everything but k8s is being killed or at least left for dead by various upstream.

And k8s might be expensive to run in the cloud (a vm pr pod?) - but it comes with abstractions we (everyone) needs.

Trying to offload to SaaS that which makes sense as SaaS - primarily managed db (we're trying out elephant sql) - and some file storage (100s of MB large Pdf files).

For bespoke servers we lean a bit on etckeeper in order to at least keep track of changes. If we were to invest in something beyond k8s (it's such a big hammer, that one become a bit reluctant to put it down once picked up..) I'd probably look at gnu guix.

</comment><comment><USER55> Fabric [https://www.fabfile.org/](https://www.fabfile.org/) (just one step above shell scripts using python), using 1.x as the 2.x stuff is still missing things. The key is having is structure to almost be like Ansible where you kind of have "playbooks" and "roles" (had this structure going before Ansible) ... probably have to move out of this soon though

<comment><USER56> Could you please explain why you think you'll have to move out of it soon?

<comment><USER55> Works for smaller teams and smaller # of hosts. I would say that it would start getting harder with 5-6 people and > 100 hosts. But for small stuff, it is the most awesome thing in the world. I had a structure I used a long time ago ([https://github.com/chrisgo/fabric- example](https://github.com/chrisgo/fabric-example)) but have broken it up now differently in the last 2 years (looks more like Ansible)

... and peer pressure (which is probably not a good reason)

</comment></comment></comment><comment><USER57> I use OPS [https://ops.city](https://ops.city) which uses the nanos unikernel [https://github.com/nanovms/nanos](https://github.com/nanovms/nanos) and since I work on it would appreciate any suggestions/comments/etc. on how to make it better.

</comment><comment><USER51> I'll tell you the one tool I DON'T use. Cloudformation. I've touched it a grand total of once and it burned me so hard I set a company policy to never use it again.

It's like terraform, except you can't review things for mistakes until it's already in the process of nuking something. Which is terrible when you're inheriting an environment.

<comment><USER58> Isn't that what changesets are for?

<comment><USER59> And a set of environments along the lines of at least, Dev, Test, preview, production.

</comment></comment></comment><comment><USER60> I enjoy using mage ([https://github.com/magefile/mage](https://github.com/magefile/mage)). I like having a full language at my disposal for configuring things rather than yaml or json or whatever else.

<comment><USER51> I like Chef for similar reasons. It's just Ruby code.

</comment></comment><comment><USER61> I operate a couple of Elixir apps and so far a simple Makefile with a couple of shell scripts has been enough. This simplicity is due to the fact that the only external dependency is a database server, everything else (language runtime, web server, caching, job scheduling, etc.) is baked in the Elixir release. One unfortunate annoyance though is that Elixir releases are not portable and can't be cross-compiled (e.g. building on latest Ubuntu and deploying to Debian stable won't work) so we have to build them in a container matching the target OS version. So to be really honest I should mention that Docker is also part of our deployment stack, although we don't run it on production hosts.

<comment><USER20> How do you handle multiple servers? Eg for fallback, vertical scaling, whatever

</comment></comment><comment><USER62> Easy, flexible, ansible but not super fast (ssh) Still pretty easy but very fast saltstack (zmq)

</comment><comment><USER63> Terraform for everything 'outside' your runtime (VM, container), SaltStack for everything 'inside' (VMs and containers) and for appliances (where Terraform has no provider available) as well.

</comment><comment><USER64> I think we've developed multiple layers in our infrastructure (Cloud Infra - AWS, GCP.., Paas - Kubernetes, ECS.., Service mesh - Istio, linkerd.., application containers..). So it depends on how many layers you have and how you want to manage a particular layer. Companies at `any` scale can get away with just using Google App Engine (Snap) or have 5+ layers in their infrastructure.

I find Jenkins X really interesting for my applications. It seems to solve a lot of issues related to CI/CD and automation in Kubernetes. however, still lacks multi-cluster support.

<comment><USER65> Hey, there! I'm a product manager working on Jenkins X. We are at work right now on multi-cluster support, actually.

I'd love to talk to you about it in more detail and get you involved in the experiments around it - feel free to email me at firstname.lastname@example.com if you'd like to be involved or chat more about it.

</comment></comment><comment><USER66> I'm pretty happy using both Puppet and ansible. I use Puppet for configuring hosts and rolling out configuration changes (because immutable infrastructure isn't a thing you can just _do_ ; there's overhead and it does not fit all problems) and ansible for orchestrating actions such as upgrades. They work well together.

I very much dislike ansible's YAML-based language and would hate to use it for configuration management beyond tiny systems, but it's pretty decent as a replacement for clusterssh and custom scripts.

<comment><USER8> I'm using puppet for everything, including nearly immutable infrastructure ( if you can't mount your disks read only and run that way you dont have immutable infrastructure )

Puppet maintains the base image with the core system.

Special systems are recreated by applying system specific classes to a base image.

Application software is installed via packages with git commit-ids being versions.

Nothing is upgraded, rather a new instances are rolled out and the old instances are destroyed.

This also ensures that we always know that we can recreate our entire infrastructure because we do that for rapidly changing systems several times a day and for all systems at least monthly.

This makes our operational workflow match the disaster recovery, which is god sent.

</comment></comment><comment><USER7> Ansible Ansible Ansible for me!

I've tried Puppet and SaltStack, and I constantly find they are harder and more complex than Ansible. I can get something going in Ansible in short order.

Ansible really is my hammer.

</comment><comment><USER67> We use terraform to describe cloud infrastructure, check all k8s configmaps and secrets into source control (using sops to securely store secrets in git).

<comment><USER68> Curious about why you're using SOPS [1] instead of say, hashicorp vault or AWS/GCP's integrated keystores or git-crypt, etc?

[1] [https://github.com/mozilla/sops](https://github.com/mozilla/sops)

<comment><USER67> I found vault a pain to setup and maintain. I think security solutions should be as simple as possible so people use them and understand them.

What I like about SOPs is that we still leverage AWS keystore to store our master key, but we store encrypted secrets in git. This is helpful as we have a history of rotations (great for rollbacks, audits, etc). Additionally, SOPs doesn't encrypt yaml keys, so one can tell what a secret is but not its values.

</comment></comment></comment><comment><USER69> I won't talk much about FAANG scale, because that is hyper specialized.

A small startup shouldn't use any configuration management (assuming configuration management means software like Puppet, Chef, Salt, and Ansible). That is because small startups shouldn't be running anything on VMs (or bare metal). There are so many fully managed solutions out there. There is no reason to be running on VM, SSHing to servers, etc. App Engine, Heroku, GKE, Cloud Run, whatever.

Once you get to the point where you need to run VMs (or bare metal), there are many options. A lot of systems are going to a more image + container based solution. Think something like Container-Optimized OS[1] or Bottlerocket[2], where most of the file system is read-only, it is updated by swapping images (no package updates), and everything runs in containers.

If you are actually interested in config management, I'll give my opinions, and a bit of history. I've used all four of the current major config management systems (Puppet, Chef, Salt, and Ansible).

Puppet was the first of the bunch, it had its issues, but it was better than previous config managements systems. Twitter was one of the first big tech companies to use Puppet, and AFAIK they still do.

Chef was next, it was created by people to did Puppet consulting for a living. It follows a very similar model to Puppet, and solves most of the problems with Puppet, while introducing some problems of its own (mainly complexity in getting started). In my opinion Chef is a clear win over Puppet, and I don't think there is a good reason to pick Puppet anymore. One of the biggest advantages is that the config language is an actual programming language (Ruby). All the other systems started with language that was missing things like loops, and they have slowly grafted on programming language features. It is so much nicer to use an actual programming language. Facebook is a huge Chef user.

Salt was next. It was created by someone who wanted to run commands on a bunch of servers. It grew into a configuration management system. The underlying architecture of Salt is very nice, it is basically a bunch of nodes communicating over a message bus. Salt has different "renderers"[3], which are the language you write the config in, including ones that use a real programming language (Python). I'll back to Salt in a minute.

Ansible... it is very popular. This is going to sound harsh, but I'm just going to say it. I think is it popular with people who don't know how to use configuration management systems. You know how the Flask framework started as an April Fool's joke[4], where the author created something with what he thought were obviously bad ideas, but people liked some of them. Ansible is so obviously bad, at its core, that I actually went and read the first dozen Git commits to see if there were any signs that is was an April Fool's joke.

There was a time a few years ago when Ansible's website said things like "agentless", "masterless", "fast", "secure", "just YAML". They are all a joke.

Ansible isn't agentless. It has a network agent that you have to install and configure (SSH). Yes, to do it correctly you have to actually configure SSH, a user, keys, etc. It also has a runtime agent that you have to install (Python). You have to install Python, and all the Python dependencies your Ansible code needs. Then it has the actual code of the agent, which it copies to the machine each time it runs, which is stupidly inefficient. It is actually easier to install and configure the agents of all the other config management systems than it is to properly install, configure, and secure Ansible's agent(s).

Masterless isn't a good thing, and a proper Ansible setup wouldn't be masterless. The way Ansible is designed is that developers run the Ansible code from their laptops. That means anyone making code changes needs to be able to be able to SSH to every single server in production, with root permissions. And it also risks them running code that hasn't been committed to Git or approved. Any reasonable Ansible setup will have a server from which it runs, Tower, a CI system, etc.

Fast. Ha! I benchmarked it against Salt, wrote the same code in both, that managed the exact some things. Using local execution so Ansible wouldn't have an SSH disadvantage. Ansible was 9 times slower for a run with no changes (which is important because 99.9% of runs have no or few changes). It is even slower in real life. Why is it so slow? Well, SSH is part of it. SSH is wonderful, but it isn't a high performance RPC system. But an even bigger part of the slowness is the insane code execution. You'd think that when you use the `package` or `apt` modules to ensure a package is installed, that it would internally call some `package.installed` function/method. And that the arguments you pass are passed to the function. That is what all the other configuration management systems do. But not Ansible. No, it execs a script, passing the arguments as args to the script. That means every time you want to ensure a package is still installed (it is, you just want to make sure it is), Ansible execs a whole new Python VM to run the "function". It is incredibly inefficient.

Secure. Having a network that allows anyone to SSH to any machine in production and get root isn't the first step I'd take in making servers secure.

It isn't just YAML. It is a programming language that happens to sort of look like YAML. It has its own loop and variable syntax, _in YAML_. Then it has Jinja templating on top of that. "Just YAML" isn't a feature. To do config management correctly you need actual programming language features, so use an actual programming language.

If I had to pick one again, I'd pick Salt. Specifically I'd use Salt with PyObjects[5] and PillarStack[6].

But I'll reiterate, you shouldn't start with a config management system. Start with something fully managed. Once you need a config management system, take the time to do it correctly. Like it should be a six week project, not a thing you do in an hour. Chef and Salt will take more time to get started, but if setup correctly they will be much better than any Ansible setup. If you don't have the time or knowledge to do Chef or Salt correctly, then you don't have the time or knowledge to manage VMs correctly, so don't.

[1] [https://cloud.google.com/container-optimized- os](https://cloud.google.com/container-optimized-os)

[2] [https://aws.amazon.com/bottlerocket/](https://aws.amazon.com/bottlerocket/)

[3] [https://docs.saltstack.com/en/latest/ref/renderers/](https://docs.saltstack.com/en/latest/ref/renderers/)

[4] [https://en.wikipedia.org/wiki/Flask_(web_framework)#History](https://en.wikipedia.org/wiki/Flask_\(web_framework\)#History)

[5] [https://docs.saltstack.com/en/latest/ref/renderers/all/salt....](https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.pyobjects.html#module- salt.renderers.pyobjects)

[6] [https://docs.saltstack.com/en/master/ref/pillar/all/salt.pil...](https://docs.saltstack.com/en/master/ref/pillar/all/salt.pillar.stack.html)

<comment><USER29> > One of the biggest advantages is that the config language is an actual > programming language (Ruby). All the other systems started with language > that was missing things like loops, and they have slowly grafted on > programming language features. It is so much nicer to use an actual > programming language.

This is the most important thing I've learned from using all of the mentioned options, as well as older options like cfengine. Please make it easy to work in an actual programming language instead of an unholy mix of yaml and jinja! I think Ruby excels for this, as well as Clojure or a Scheme, because it's so easy to write "internal" DSLs.

</comment></comment><comment><USER70> If you already know and/or use Ruby, use Chef.

It is silly to ask "what should be used at FAANG scale", because either you are working at a FAANG and you are using what they use, or you are very unlikely to ever be at that scale -- and somewhere along the journey to getting there, you will either find or write the system that you need.

<comment><USER3> Some FAANGS I've heard about roll all their own config management tools.

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

;)

<comment><USER3> Odd reply to my statement that FAANGs roll their own config management tools. Are you smoking a lot of weed during this quarantine? You can google linkedins version of docker 'locker', facebooks hydra, etc etc. Alot of these big companies roll their own tools because consumer tools aren't scale enough. Linked In rolled Kafka for just this reason as well.

Also, odd and a little creepy that you're stalking my comments but I hope you enjoyed my brain droppings. ;)

</comment></comment></comment></comment><comment><USER72> For anyone here who isn't yet using and end to end setup like terraform, ansible, puppet etc and has more basic needs around managing environment variables and application properties, I highly recommend [https://configrd.io](https://configrd.io).

</comment><comment><USER73> I used to use Chef, but I really didn't like it. For small projects now, I just use a set of shell scripts, where each installs and/or configures one thing. Pair it with a Phoenix server pattern. It has treated me very well the last two years

</comment><comment><USER74> What about Nix?

</comment><comment><USER75> puppet is pretty good in my experience

</comment><comment><USER76> For most teams: Docker or Ansible all the things.

For teams that have a large IaaS footprint: Chef (agent-less actually adds complexity in this environment.)

</comment><comment><USER77> Ansible where possible, Chef when I have to (for legacy reasons, usually), and Terraform/Docker/Packer when given the option.

</comment><comment> den-is I'm working with both Ansible and Puppet for the last 6 years on a daily basis. Ansible for: \- i absolutely love and adore Ansible \- extremely easy and much much much pleasant to read. Sometimes ansible feels like poetry to me. \- ad-hoc SysAdministration - I do not mean "ansible" command, but actual style of work when you need to do something right here and right now. \- prototyping, Dev and staging environments setup, experiments.

Puppet for a polished production. Puppet has robust and stable ecosystems and infrastructure. It is a client-server model from the beginning. It is easier to create and put in the production library of all your puppet modules. It has hiera for central config values and secrets management. At the same time, I hate the Puppet's resource relations. Puppet's architecture feels like something developed in 1991, an ugly monster monolith and extremely heavy.

Terraform. For actual low-level infrastructure management. And I don't like to put whole high-level host configuration into IaaC! IaaC has minimal host configuration capabilities. Set hostname, set IP, register with Puppet or call ansible - only a few lines in user-data or bash-script on boot, which then calls actual configuration management!

Gitlab-CI - switched from Jenkins. Concourse-ci looks extremely interesting! Also reviewing some GitOps frameworks. Kubernetes - bare-metal runs self-made puppet-based pure k8s. Also, kops and EKS for AWS. Applications in k8s are managed via Helm.

Compared to Puppet Ansible is less enterprissy, it is more like a hipster tool. I would like to replace the Puppet with Ansible. But maybe I need the help from all of YOU who have voted for Ansible. How do you achieve Puppet's level of management with Ansible? How do you achieve client-server setup with ansbile - somehow I do not see lot's of people using ansible-pull? (Without using Tower!) You create cronjob with ansible-pull on a node boot? :D Or whole your ansible usage is limited to running ansible-playbook from your console manually? Ok maybe you sometimes put it in the last action of your CI/CD pipeline ;) Nodes classification and review? Central config values management for everything?

I use hashi Vault and lots of other things too. Some questions are rhetoric. I've just expressed my mistrust in ansible which doesn't feel complete. :(

How to do you manage a fleet of 1000, 500 or even 200 hosts with ansible? When after provisioning you need to review your fleet, count groups, list groups, check states. Ah, you want to suggest Consul for that role? :)

Kubernetes for the win. It will replace config management diversity. It gives you node discovery, state review, and much much much more.

</comment><comment><USER78> We're using Terraform for infrastructure and Ansible for deployments with great success.

</comment><comment><USER79> Shameless self-plug: ChangeGear. We're cheapest in-class for medium-sized companies.

</comment><comment><USER80> At G scale you could never afford to run something as grossly wasteful as chef. It would be cheaper to have several full-time engineers maintaining a dedicated on-host config service daemon and associated tools, than it would be for some ruby script to cron itself every 15 minutes.

<comment><USER69> That's strange, because the closest company to Google scale is Facebook, and they actually use Chef in production[1][2][3] on hundreds of thousands of servers.

[1] [https://www.chef.io/customers/facebook/](https://www.chef.io/customers/facebook/)

[2] [https://engineering.fb.com/core-data/facebook- configuration-...](https://engineering.fb.com/core-data/facebook- configuration-management-community-and-open-source/)

[3] [https://github.com/facebook/chef- cookbooks/](https://github.com/facebook/chef-cookbooks/)

<comment><USER80> 100s of 1000s. Adorable.

</comment></comment></comment><comment><USER81> Salt + Serverless.

</comment><comment><USER82> I'm also really interested in what companies at scale are using. Anyone here from FAANG?

<comment><USER83> Facebook uses Chef to manage its base hosts [0] and its own container system [1] to manage most workloads.

[0] [https://www.chef.io/customers/facebook/](https://www.chef.io/customers/facebook/) [1] [https://engineering.fb.com/data-center- engineering/tupperwar...](https://engineering.fb.com/data-center- engineering/tupperware/)

</comment></comment><comment><USER84> docker-compose + custom stuff + reduce all dependency on tooling

<comment><USER85> Here also docker-compose. Easy to separate tenants using same stack (nginx+django+postgres+minio).

Question though: how do you manage the possible rebooting-containers-loop after a host reboot? I had to throw in more memory to prevent this but it feels like a (expensive|unnecessary) workaround. Anyone figured out how to let multiple containers start after each other (while not in 1 docker- compose.yaml)?

</comment></comment><comment><USER86> Kind of surprised there isn't really a consistent answer for this. Just skimming through these answers.</comment>


Modern Maturity: Create More, Consume Less - <AUTHOR> http://artofmanliness.com/2010/04/06/modern-maturity-create-more-consume-less/ <comment><USER2> I'm not sure why they had to take the rather sound message of "make useful stuff and you'll be happier" and dress it up with all of that "Be A Real Man" wankery.

<comment><USER3> Agreed. This for example, why should it apply to men any more than to women? :

"[Consumerism] might work with your toothpaste, but the most important things in life can't be replaced on a whim. They require the discipline necessary to build something strong and valuable and special, the ability to stick with something through thick and thin. The shopping around mentality is devastating to true manhood."

<comment><USER4> You clearly appreciate the central theme of the post but have less use for the manliness trappings that surround it.

It's illustrative for the author to share the personal experiences and thought process that led him to this conclusion. It's equally interesting to see other people reaching the same conclusion after approaching the problem from a completely different perspective.

It looks like there's another level of analysis left to be done here. If "making" is a marker of true manliness but not specific to men, then what is it that we're really saying? Making is adulthood? Making is being in touch with oneself? Making is not buying into corporate consumerism?

I'm still digging for the simple truth at the heart of both this post and the ensuing discussion.

</comment></comment></comment><comment><USER5> _"Where men used to play baseball and football, they now control avatars who play for them. Where men used to play an instrument, they now press buttons on a plastic toy."_

How is pressing buttons on a plastic toy inherently worse than pressing buttons on a wood and ivory toy? Given time, some of today's toys will gain prestige, too.</comment>


App.net And The Need for Social Networking Standards - <AUTHOR> http://continuations.com/post/29335242698/app-net-and-the-need-for-social-networking-standards <comment><USER2> Dalton has announced that APP.net will use Activitystream.es, Webfinger, RSS, pubSubHubbub. (not sure about Salmon, an excellent open web standard)

Albert Wenger is a venture capitalist at Union square Ventures (earliest investor in Twitter).

So it's genuine statesmanship that he would praise APP.net for its effort on openness.

@Blaine (a world-class expert, open web protocols) Applauded the article, as did I and nearly all 17 commenters.

It just that kind of "crossing the aisle" collaboration the tech world (and Silicon Valley) needs to produce a protocol as superb as email or HTML for social networks (federation). Beautifully written.

</comment><comment><USER3> Sounds good, but how does this fit with the app.net, $50 per year model? AFAIK, app.net is still supposed to be a walled-in social network, but with supposedly better support for third-party developers, no ads, and less spam.

<comment><USER4> I think the $50 model is going to get changed. My bet is that businesses building social into their sites off of the app.net infrastructure will end up paying. That was just to see if it was pursuing. Its not better support for 3rd party devs, the entire focus is 3rd party devs.

</comment></comment><comment><USER4> Dalton did back standards

<http://daltoncaldwell.com/a-response-to-brennan-novak></comment>


Humans and Neanderthals had sex. But was it for love? - <AUTHOR> http://www.vox.com/2016/9/14/12887956/human-neanderthal-sex-love-genetics <comment><USER2> My own thesis is that when modern humans and Neanderthals co-existed, they would have appeared uglier to our ancestors than they do to us - because we are no longer subject to selective pressure to avoid mating with Neanderthals.

[http://thinkinghard.com/blog/WereTheNeanderthalsUgly.html](http://thinkinghard.com/blog/WereTheNeanderthalsUgly.html) (2006)

</comment><comment><USER3> A few years back body hair was considered attractive, and now it's not (or maybe it is, I haven't kept track). This change in preferences was within a span of 20 years. So I don't find it surprising that a strong neanderthal man or woman would have been attractive to our ancestors.</comment>


The Biography Of Wordpress – With Matt Mullenweg  - <AUTHOR> http://mixergy.com/the-biography-of-wordpress-with-matt-mullenweg/ <comment><USER2> I had an opportunity to meet Matt when he had come to India. He is such an awesome guy.

Very approachable. And really one of the few people I've met who have such a clear understanding of the big picture.

A lot of people have complaints about how WP is not very secure and how Automattic can be more aggressive (me too on this - I think a plugin and themes marketplace is essential - will give developers a better opportunity to make money) - but I think Matt and co. have done a wonderful job.

He is one of my heroes.

</comment><comment><USER3> Andrew, I'd really like raw transcripts for _all_ interviews. It was really nice to have.</comment>


American Supercar Takes Title of 'World's Fastest' from Bugatti - <AUTHOR> http://www.wired.com/2014/02/hennessey-fastest-production-car/

<comment><USER2> This story is a year old.</comment>


Google WHOIS OneBox - <AUTHOR> http://googlesystem.blogspot.com/2008/04/google-whois-onebox.html

<comment><USER2> Good use of integrated results. it takes you to a horrible looking site though with cheap generic seo information</comment>


The Nuclear Energy Option by Bernard L. Cohen - <AUTHOR> http://www.phyast.pitt.edu/~blc/book/BOOK.html

<comment><USER3> And that's where the global warming theory came from : opposition to coal plants, in favor of Nuclear plants. Since then it has been picked up an run with by everyone as a reason to use their product / not use a competitors.

The resulting water is so muddy nobody can see through.

I would have thought that the non-greenhouse pollution from coal, plus the deaths caused from mining put Nuclear in front. Even in the extremely rare events of Nuclear accidents the total deaths are lower than the ongoing toll from coal mining and shipping. But nobody wants to discuss that, all we get now is OMG NUCLEAR WASTE and OMG GREENHOUSE GASES!

The worst outcome of it all is the obsession with wind power over all else, despite all the drawbacks as mentioned in this paper : land use, siting issues with regards to transmission to demand areas, wildlife impact, noise pollution and what happens when the wind stops. The greenhouse gas debate started as a support to transition from coal/oil to nuclear, and we ended up talking about going from coal to wind power because the wrong interest groups got control of the dialogue.

<comment><USER4> For the human species to survive on Earth over the long haul, we need a way to sustain our lifestyle with the energy coming from the Sun. In Oil / Gas / Coal, we're just living off previously stored solar energy.

There is only a limited amount of nuclear fuel on Earth (not counting something like deuterium deuterium fusion reactions which likely will never be feasible in full scale) - granted, the amount of fuel we have with right technology (fast breeder reactors, thorium reactors, etc) will last a period measured in centuries, not decades.

Even as someone who's working in the wind energy industry, I believe that nuclear power is clean and safe energy source that we should be actively developing and perfecting, and I'm in agreement with you that nuclear option has gotten the short end of the shaft.

However, the pure renewables like Wind and Solar do have a place in the conversation, and many of issues you cite are overblown (wildlife impact/noise) or technically solvable (wind stopping - there are papers showing that by tying the entire eastern seaboard into a single grid, you can ensure certain amount of base load capacity). There are still unexplored places for wind energy (deep offshore, high altitude) that hold a lot of promise, with technology that already have been developed.

If we have the will to go ahead with a full blown nuclear option, then by that time, we'd have the will to go ahead with updating our transmission infrastructure. And if we ever end up in a pure electric transportation sector, we'll have 250 million batteries-on-a-wheel that can soak up the extra generating capacity on windy/sunny days and dump it out on cloudy/still days, with nuclear likely providing the baseload capacity.

I see transitions from coal to natural gas, then to nuclear, but as a stepping stone while we perfect the pure renewable solution which is the only thing that will ensure the survival of human species unless we decide to go gallivanting across the universe collecting resources from other planets. Even then, energy dense nuclear fuel will be too valuable to waste in heating up homes and food - they'll be closely guarded as a means to get to those said energy dense planets.

<comment><USER3> These are the points I strongly disagree with: >many of issues you cite are overblown (wildlife impact/noise) Pelicans get covered in oil and die = bad, evil, oil drilling. No pelican should die from oil drilling! Eagles and bats get hit by wind generators = overblown and acceptable loss, some birds will get hit, oh well. This particular issue really gets me riled up.

Noise is an issue for people who live close to the generators. I've heard them going and it's not a pleasant noise.

>There are still unexplored places for wind energy (deep offshore, high altitude) that hold a lot of promise, with technology that already have been developed No they don't, not at least on any sort of acceptable cost basis. It's just pure fantasy to build offshore wind turbines in deep water and think they are going to be economical as compared with any of the other onshore options. Deepwater offshore oil and gas platforms rigs cost a fortune to build and run, but they effectively produce millions of joules of energy during their lifetime. There's simply not enough harvestable energy in the wind to justify anything like that sort of spend for a fraction of the energy produced. It's also fantasy to think you can cover an entire coastline in wind generation and think it's going to come out at anything like a cost effective solution, and particularly when two or three nuclear generators would provide the same coverage with less environmental impact.

Wind energy is an interesting niche product useful for certain areas. It's current status is largely as a result of tax incentives, and it has all the hallmarks of an industry that is overinvested because of available government subsidies. Once those subsidies die (and they will) the market mostly dissappears.

I commend you for coming out in defense of your industry but disagree with pretty much everything.

And as for nuclear fuel only lasting a couple of centuries - for a start I highly doubt the accuracy of that - and further, a couple of centuries is plenty enough time to develop other alternative energy sources. Large scale energy as we know it is barely 100 years old. The big problem 100 years ago was what to do with all the horseshit in the streets, and whether there was enough whale oil around to light reading lamps. The problems facing society 200 years ago are unrecognisable and unthinkable today. It is arrogance in the extreme to think that technology and society in 200 years is going to hinge on decisions made today. It's pointless and a misuse of our time on earth to try and make decisions with that sort of time frame in mind.

<comment><USER4> Most studies indicate between 2 and 3 bird strikes per wind turbine, with far more birds being killed by cats, buildings, glass, cars, etc. Turbines are also below 500m, which typically is the floor for the path of migratory birds.

The noise for the wind turbine comes from mostly the gearbox, though there are efforts under way to reduce that, including completely eliminating the gearbox from the design.

But at this point, I think debating with you on point to point is a little... pointless, so I'll just leave this:

On earth, there are 5 sources of energy. Unlike in 1900, we now have a pretty damn good understanding of physics to know that this is all we get.

\- We have energy coming from the Sun. There's a fair bit of it, and there might be enough to sustainably allow us to live. This gives us Wind / Solar power. \- We have energy coming from the moon. Tidal power does work in some places, but it's magnitudes smaller than the energy from the Sun. \- We have carbon fuels \- We have nuclear fuels \- We have geothermal energy... though efforts to tap that has produced only earthquakes so far.

That's all we get, unless someone goes out and develops cheap fusion power (highly unlikely situation - fusion reactions produce a lot of neutrons which are very difficult to deal with). I don't think there is any other "alternative energy sources".

<comment><AUTHOR> I hope you understand that fission was the first time we have ever created energy. All other forms are just scavenging it from the sun.

Nuclear fusion is unlikely but nuclear fission has been proven over the last 60 years and as Bernard Cohen lays out, could provide us with enough energy for millions of years (<http://www.phyast.pitt.edu/~blc/book/chapter13.html>).

<comment><USER4> And I hope you stop putting words into my mouth. I just said that there are 5 sources of energy (solar, lunar, geothermal, nuclear, and fossil fuels) on earth. Also, you're also factually incorrect regarding the Sun being the only energy source. The lunar / tidal energy is due to the gravity between the earth and the moon, and the geothermal energy is due to the gravity of the earth itself. Fact of the matter is that there is no silver bullet that'll solve all our energy problems ala Star Trek unless there's a breakthrough in something like nuclear fusion.

The paper you cite assume 100% uranium recovery from uranium contained within the Ocean waters, which holds most of recoverable uranium on Earth. The Japanese have some interesting research that they're doing to recover the seawater Uranium using a giant sponge like device, but it hasn't been proven yet whether it's possible to extract uranium from seawater in net-energy- positive manner, not to mention most of the seawater being fairly inaccessible.

I don't understand your hostility, as I've mentioned over and over again that I am in agreement that Nuclear power has gotten the short end of the shaft, and that more investment is needed. All I was trying to do is to say that there are benefits of investing in pure renewables like wind and solar - <USER2> energy is already almost cheap enough to compete with other conventional energy sources even without the PTC. And as a working engineer in a tiny startup struggling to fix the very issues that you bring up (and completely re-imagine the wind industry as it exists if we succeed), I'm not a mouth piece of this large wind power conglomerate that you seem to make me out to be.

I'd highly recommend reading David MacKay's "Without the Hot Air" which is available free on PDF at <http://www.withouthotair.com/> . David is much more eloquent than me and has done far more research into the issues at play here.

<comment><AUTHOR> Sorry, If I appeared hostile. You seemed to be quite the renewable-only supporter and hadn't taken into context alternative nuclear fuels.

I'm not a fan of wind or solar as a form of large scale energy production. They have there place in certain locations but I think it is downright dangerous how a large majority of people seem to think that they can satisfy our energy needs.

Loved DavidMacKay's book.

</comment></comment></comment></comment></comment></comment></comment><comment> rm-rf As someone degreed in Physics, I have far less fear of the long term consequences of nuclear power and nuclear waste than many of the other byproducts of western civilization.

<comment><USER5> Can you expand on that and tell us why this is so? Are we on the brink of sanitizing nuclear waste?

<comment><USER6> I need to go to sleep, but I'll give you the tl;dr version of how you sanitize waste from most of the reactors currently in operation.

First, let it cool off for a while. We're doing this. Since the volume of the waste is so small, and it's so well contained, there's really no rush to process it right away.

Second, chemically separate it into its parts. Deal with them in different ways:

Uranium and plutonium can be recycled and used as fuel again. Hooray for recycling! France does this; other countries are just storing the waste for later, since non-recycled uranium is cheap these days.

Short-lived isotopes can be left to decay. They are short-lived, after all. This is happening as we speak.

Medium-lived isotopes are the really troublesome ones. Hit them with some spare neutrons to transmute them into something shorter-lived.

Put the remaining, much-diminished waste in storage. It should become harmless after a few hundred years, rather than a few hundred thousand.

Fun fact: it's a lot easier with something like a liquid fluoride thorium reactor, which makes the chemistry really easy and prevents a lot of the nasty isotopes from forming in the first place. You can skip most of the rigmarole.

(Huh. I guess that was longer than I thought. Oh well; who needs sleep, anyway?)

<comment><USER7> An open fuel cycle (without reprocessing) makes nuclear power pretty worthless, as has been shown in the US over the past 30 years.

President Carter banned reprocessing in the US over bogus weapons proliferation concerns; IMO, one of the worst things a President has done in the past 60 years.

I am a bit torn between "just build a lot of 3rd generation reactors" vs. going for the fourth gen designs.

<comment><AUTHOR> Quite true that Carter put the breaks on it. However, in the early 80's this ban was actually repealed. Now the whole situation is just mired in political/regulation muck. IMHO, (I just left my job in the nuke industry) the NRC should be dissolved and replaced by an entirely new commission. They do more harm then good. INPO (the Institute of Nuclear Power Operations) does a much better job of regulating the U.S. industry.

</comment></comment></comment></comment></comment><comment><AUTHOR> Bernard L. Cohen wrote this book back in 1990. It's astonishingly still very applicable.

<comment><USER8> Goes to show that unlike political moods, the laws of physics don't change all that frequently. I wish more policy makers would make decisions based on facts rather than popular opinion. Maybe govt. needs some Google engineers?

<comment><USER9> France is probably the ultimate model for how to work rationally in the nuclear energy space. Some interesting facts and history: <http://www.world- nuclear.org/info/inf40.html> and <http://en.wikipedia.org/wiki/Nuclear_power_in_France>

<comment><USER6> China is the one to watch right now. They're making massive investments in nuclear. Their CPR1000 reactor (based on 70's French reactors) is now cheaper to build than modern coal plants of the same size. They're working on doing the same cost-reduction for the more modern Westinghouse AP1000, and they're developing variants on the AP1000 which are the same size, don't cost much more, but produce 40% and 70% more power.

They're working with Russia to build some BN-800 liquid metal fast breeder reactors, a successor to the BN-600 and earlier BN-series reactors that Russia has been operating successfully for decades. They're also importing some Russian VVER-1000 light water reactors, apparently for variety.

They're building their first commercial pebble-bed modular reactors, and I believe they're working on how to incorporate thorium into the fuel mix. This isn't nearly as good as LFTRs, but it's nice to see.

They're doing some other nuclear things, but those are the big ones.

</comment></comment></comment></comment><comment><USER10> Looks interesting, but the background color, and font makes it hard to read.

<comment><USER5> <http://lab.arc90.com/experiments/readability/></comment></comment>


Vittorio Colao's ambitious plan for Vodafone - <AUTHOR> http://www.economist.com/research/articlesBySubject/displayStory.cfm?story_id=13642641 <comment><AUTHOR> "A software firm must write several versions of its applications for different platforms, for example, and the owner of a particular handset is usually restricted to a particular platform. Mr Colao's other chart, titled "Tomorrow: One relationship", is centred on a big, red box labelled "Vodafone Services". This is an über-platform that would allow programmers to write an application which could then run on other platforms, and would also provide essential sub- services, such as determining a user's location and, most importantly, charging for downloads. Mr Colao promises not to be "too greedy": Vodafone intends to pass on 70% of revenues to developers, the same share as Apple does."

Ok - but how does he propose to do that?</comment>


Dril - <AUTHOR> https://en.wikipedia.org/wiki/Dril <comment><USER2> >The Fact Remains That Your A Guy From Reddit, And Im A Guy Who Posts On A Website Thats Somewhat More Prestigious Than Reddit

Dril is the Shakespeare of our age.

</comment><comment><USER3> God, for a Wikipedia page to dance around the identity of an author (Paul Dochney), for what amounts to essentially a well-received daily comic strip in a newspaper, really says a lot about what's wrong with the world as we know it.

It's just too much to plainly state:

      @dril is Paul Dochney

Once you have a book to sell, and have been interviewed by Vice, it shouldn't be a big deal to say that. At the very least, it's also reasonable to give the author his own wikipedia page, and cross-link to the persona's wiki.

</comment><comment><USER4> If I could only bring one twitter account to a deserted island it would without a doubt be dril/wint.

</comment><comment><USER5> This reminded me to buy his book.

There is something very relaxing about reading 75% nonsense, 25% satire posts.</comment>


Netscape's Jim Clark new company is a passwordless solution - <AUTHOR> https://www.beyondidentity.com/blog/journey-beyond-how-we-got-and-then-beyond-passwordless-authentication <comment><USER2> The only technical detail this article lists is that they use self-signed certificates to authenticate client. No details on how they do it across devices, handle revocations, etc.</comment>


Botox for the brain: enhancement of cognition, mood and blunting of unwanted memories - <AUTHOR> http://radian.org/notebook/wp-content/uploads/2009/04/brain-botox.pdf

<comment><USER2> Better living through chemistry.</comment>


Liquid shell gives inertial confinement fusion a smoother burn - <AUTHOR> http://arstechnica.com/science/2016/12/partially-liquid-hydrogen-cooperates-with-lasers-for-better-fusion-yield/? <comment><AUTHOR> _Early success turned to disappointment. Even with the new laser cranked up to 11, the amount of fusion measured was orders of magnitude smaller than the amount of fusion expected. As the power went up, the way the pellet collapsed seemed to be increasingly sensitive to imperfections in its spherical shape. This resulted in material squirting out of the pellet rather than being crushed. This was a big problem, because making hydrogen ice of the correct density and shape is already difficult._</comment>


Keeping Abreast of Pornographic Research in Computer Science - <AUTHOR> http://gandolf.homelinux.org/~smhanov/blog/?id=63 <comment><USER2> The author claims that the Lena image is porn. Give me a break!

<comment><USER3> As explained in the article it's the top half of a playboy centerfold (there's a link to the full version in there).

<comment><USER2> I have worked in image processing and I have looked at Lena many times. I know it's the top half of a Playboy centerfold:

<http://www.lenna.org/full/len_full.html>

What I see is a rather artistic photo. It surely contains nudity, but it's nonetheless a work of art. If nudity is porn, then Picasso was a pornographer:

<http://en.wikipedia.org/wiki/Les_Demoiselles_d'Avignon>

And Feynman was also a pornographer then:

<http://www.museumsyndicate.com/item.php?item=11504>

To cut a long story short. Just because there's nudity, it doesn't mean it's porn. Are we, HN'ers, that prude??

<comment><USER4> It's not a question of being prudes. The definition of pornography is "sexually explicit pictures, writing or other material whose primary purpose is to cause sexual arousal". I think we can all agree that Playboy fits that definition. Hence, the full Lena picture _is_ porn by definition. Secondly, labeling it as porn can only be considered prude behaviour if you're offended by porn. Personally, I do not find porn offensive. Do you? Lastly, something can be pornography and still be artistic. I think the real prudes are those who think that there can be no overlap between art and porn.

<comment><USER2> You wrote:

 _"Hence, the full Lena picture is porn by definition."_

The author wrote:

 _"One cannot do research in image processing without an encounter with Lena (pronounced Lenna). The image of the woman with a feathered hat has become the de-facto test image for many algorithms, and appears in thousands of articles and conference papers. And it is porn."_

So, the author is claiming that the image that is showed in all those scientific papers is porn. And that image is not the full Lena image. Thus, according to your definition, the author seems to get aroused by women's faces and feathered hats. I rest my case...

<comment><USER4> Well, if we really must...

The definition merely states that material is pornographic if its primary _purpose_ is to appeal to the erotic instincts, without mentioning that it actually has to _succeed_. It can be easily shown that this is also the commonly understood definition by making the simple observation that most people would agree that granny porn _is_ still porn by virtue of the fact that it was created with the intent to arouse, even if neither you nor I are, in fact, aroused by it. In other words, you _have_ no case, even if I were referring to that, which I wasn't. (Incidentally, that definition came from a dictionary, and is not "my definition", just so we're clear.) Now that we've established that the author need not have been aroused by a picture for it to be considered porn, we can, I suppose, argue forever and a day about whether the author was referring to the full Lena picture or not when he said it was porn, but I won't do that. I interpret it as the author referring to Playboy, the source of the picture, which is by definition porn, but if you interpret it to mean that the author is saying that pictures of "women's faces and feathered hats" are porn, well, then we must agree to disagree, even if I think that is a weird position to take :)

Now, to get down to cases, in the comment I was actually replying to, what _you_ said was this:

 _What I see is a rather artistic photo. It surely contains nudity, but it's nonetheless a work of art._

Since Lena as used in CS does not contain nudity, you must have been referring to the original Playboy picture, which I doubt you can honestly argue was not created with the intention of appealing to the erotic instincts.

<comment><USER2> I agree with you. I don't want to keep discussing what is and what is not entitled to be labeled as porn, though. On the other hand, we have the word "nudity" which is more specific than the word "porn". The full Lena image qualifies as nudity for sure. Moreover, there can be porn without nudity. Whatever...</comment></comment></comment></comment></comment></comment></comment>