Ask HN: Tech crowd – What are your ideas for solving gun violence using tech? - <AUTHOR> I want to hear the HN crowds ideas on how to utilize technology to help solve gun violence.
I have sat here all morning, as a software engineer, trying to think of ways that would HELP to solve gun violence.
I want to hear what others ideas are, from the tiniest, small impact ideas, to ones that would be a huge undertaking/thought impossible.
All I am seeing elsewhere today is, "ban guns..", "solve mental health..", "more strict gun control..", etc. We go through these same "solutions" every time a mass shooting occurs.
I DO NOT want to make this thread about any of those political/societal issues. I want to see what ideas are out there with regard to using technology. Please keep political blaming out. Pointing fingers is not the goal here.
And the more detail you have about implementing a tech solution, the better!
Some ideas I've had/thinking about:
- Using Machine learning image processing to identify weapons immediately in an area where there should not be any. Instantly setting off alarms/notifying the police when one is exposed. Recent examples, somebody walking down the street of a popular nightlife area with many bars, holding a gun. Or walking up to the entrance of a popular shopping center. Even if the authorities had 5 - 10 seconds more to respond, it have a major impact on the outcome. I think I've also seen some startups working in the space. Of course it won't be easy. But deployed in the proper areas, such as crowded nightlife areas, could make a huge difference.
- Better tracking of guns location and how guns are traded. This of course is already a law in many places, but I think there are many ways tech can be used to do it better. Including how we can source as much information as possible, within the limits of personal privacy, and put those points together. I don't have specific examples here, would love to hear peoples ideas! I believe there is a lot of low hanging fruit. <comment><USER2> This problem is inherently American - it's not that other countries have access to some secret tech that's keeping them gun-violence-free. Saying "let's not make this political" about an entirely political issue is laughable. So is "let's fix gun violence with ML".

To actually answer the question with tech solutions:

\- accurate fact-based media with no spin

\- accessible education

\- opportunities for people to be exposed to cultures, lifestyles and mentalities different from their own

Educated, informed and open-minded people are less likely to shoot up a school, or to buy into other people's "right" to do so.

<comment><AUTHOR> Agreed. But we are where we are now and have to face reality. The reality is, the political situation with guns is, and has been, stuck between a rock and a hard place. I want to keep those political arguments out of this thread and focus on how tech can help.

I think politically, you can get every side to agree that if technology could alert authorities that somebody is holding a gun in hand and walking up to the entrance of a retail store, it would be an improvement and can potentially save lives.

but yes, I agree with each of your bullet points. All three of those will have benefits far beyond solving gun violence as well.

<comment><USER3> While it remains between a rock amd a hard place, people will be killed. I know that you're trying to steer the conversation towards the forum's purpose, but I'm not sure technology has anything to do with it, anymore than technology can stop the globe from increasing in temperature in its current state.

One of the gunmen was stopped within 60 seconds. People still died. Unless the tech can precisely point out terrorists before they leave the house, it risks being just a bandage. Even if it did, what whitepaper could possibly give you the confidence that the system's tolerance is effectively adjusted? That's some iRobot level stuff, and that was... not without quirks.

It'd probably be easier to just change the dang government.

</comment></comment></comment><comment><USER4> I don't know the solution, but I think I have an idea of where to research the root causes. And maybe it can be crowdsourced.

From what I understand, these types of violent outbursts come from a feeling of isolationism paired with mental health issues. These people see those around them as being part of "the problem" and flock to online communities that "understand them". These communities become cesspools of reinforcement of their twisted "solutions", and they lose all connection with the real world.

To combat this, we need to get them some connections so they can get over that feeling of isolationism. Unfortunately, it's really hard to help someone who doesn't want help, so we need to be a bit tactful.

This idea isn't really fleshed out, but here are some notes:

\- social app where people can identify individuals they are worried about \- people get connected based on mutual concern, and each can share how closely they are related to the individual \- these groups are paired with a certified psychologist who will act as a mentor for the group \- the group finds ways to expand the support group of the target individual and find healthy outlets for that individual \- if the target individual accepts counseling, the support group can help fund it

I'm not a psychologist, so I'd need to discuss it with a few domain experts before trying to put this into production. That being said, there may be room to include gun stores and police into the mix to improve the ability of the community to prevent harm.

</comment><comment><USER5> Violence has generally fallen since the early 90's, or at least data collection of violence has fallen, and the suspected reason is technology. Cell phones, internet, video games, might not only lower street crime (by changing drug distribution) but also, through social atomization, by giving people alternative social outlets than ones full of people they'd get into altercations with.

So one angle is direct social technology designed to somehow lower the crime rate. Just spitballing here, how about some improved version of NextDoor?

Another angle: Make it easier to talk to the police. For example, in Baltimore, a lower proportion of murders are getting solved than a few years ago because people won't give police information, and there is now a higher rate of murders, too. To improve the rate at which people report crimes, make it much easier for people to talk to the police. Have the social networks expose the local police department as part of the community in some way. (I don't really know how to make this work.)

<comment><USER6> In the US, violence has fallen since the 90s for sure. I've heard of other reasons too. Less lead paint leading to development disorders, more economic prosperity, and more access to food.

I think the number one way to reduce violence is economic prosperity. It wont cure it, but it goes a long way.

</comment></comment><comment><USER7> Greetings,

This is an inherently societal (and by extension, political) issue as some have pointed out. Realistically speaking, legislative solutions do not appear imminent. Technological solutions could still be of use as follows:

1) predicting/detecting behavioural problems well in advance of the individual(s) in question becoming locked into a violent path (this would be challenging on both technical and ethical/privacy fronts)

2) more narrow-window prediction/detection of violent intent, and/or materials that would constitute threat to life (guns, as a prime example) and immediate notification of first responders. Essentially what some folks call a "sense and respond" system.

3) Environmental deterrents/safeguards coupled to the detection systems described in (2) above.

A multi-pronged strategy would likely deliver the best outcomess w.r.t minimising the loss of life. Solutions at each level could also be re-purposed for emergencies that aren't gun related, so the overall benefit to society would be meaningful.

Disclosure: I founded a startup over a year ago with the express purpose of solving such problems (== preventing loss of life in violent scenarios in general) and had to shut it down due to lack of funding. I have thought about these issues for a couple of years now and have some specific ideas on the subject. Happy to discuss further with anyone interested in collaborating, pointing me to funding opportunities etc.

</comment><comment><USER8> Tech solutions of any kind will just be a band-aid. This is a very sensitive topic so it is easy to get political but the fact is that we as a society in the US have collectively accepted the fact that this is the cost of our freedom to be able to bear arms (I personally don't believe that). But this is how it is with the society today. Until that mindset changes, nothing will happen. We can surely add some tech solutions to help a bit but I personally would like to see a mindset shift first. The actual solution can be a combination of things but lets start with the mindset.

<comment><AUTHOR> I agree. The complete solution involves many things at the societal level, and no one solution (that is actually practical in achieving) will be the ultimate fix.

Unfortunately, in today's political environment, band-aids might be our best hope at making progress right now, in the short term.

</comment></comment><comment><USER9> I'm certainly wrong here but my understanding is that any crime happens because of two main factors:

1\. Someone is not thinking straight. It could be from an ill, a temporary loss of judgement and other related causes.

Technology could aid in identifying these scenarios and trying to prevent such occurrences by treating the disease.

2\. People think they can get away with it. Or, in other words, the risk of getting caught is smaller when compared to the benefit of the crime.

In that case technology could be used to avoid that people get away with crimes, thus making it high risk to choose that option.

But still, even when the majority of crimes are punished (and they are not) there will still be some crime because there are people who think that getting something that they don't have is worth more than capital punishment.

I was born in Brazil where only 2% of murders are solved. Crime is not bigger than it is right now because people, to some extent, are inherently good. There is no expectation of punishment there.

</comment><comment><USER10> The best line of code is the line of code you don't write.

The best gun is the gun you don't have.

Less guns less gun violence, it's not rocket science!

</comment><comment><USER11> This is not a technical problem.

There is no amount of technical solutions you can apply that will actually solve the problem.

So far as I can tell, all the other real solutions are ones that are considered inconceivable.

So long as all sides refuse to budge on the real things that could actually solve the real problems, I don't see this situation changing. At least,not for the better.

<comment><USER12> Everything is a technical problem.

Armed police drones in the right spot could solve the problem, even if we do not want that for other reasons.

But everything is a technical problem.

</comment></comment><comment><USER13> I have been thinking about solutions for a few months now. However, there doesn't seem to be a solution that does not also create other problems (e.g. a system capable of detecting violent crime—or predicting it—is likely to encroach on privacy).

Another thought is that, systems that are/can be designed to recognize intent and predict events are (or would be) used to increase capital/revenue/market- share/etc.

I understand that people want to be both "free" and "safe." But the conversation and/or conception of the relationship between freedom and security seems to be a zero-sum game.

I'm interested in what others think about this. Is it necessary that we exchange one for the other?

</comment><comment><USER14> Tech like this [https://smarttechfoundation.org/smart-firearms- technology/fi...](https://smarttechfoundation.org/smart-firearms- technology/fingerprint-guns/) ?

<comment><USER15> Very few of us who own guns actually want this tech, for a variety of reasons:

* The reliability isn't there. These are weapons. They need to fire in an emergency, when the trigger is pulled, 100% of the time, or as close as is possible. Fingerprint readers don't work 100% of the time, or even close.

One of the major trends in handgun design over the last 40 years has been the adoption of striker fired guns without manual safeties. They are enormously popular. Many people are buying them because they don't want to worry about disengaging a manual safety when grappling with someone, or while injured, and while dealing with an adrenaline dump. A fingerprint reader even less reliable.

The litmus test is probably whether or not you can get police to adopt these. They're more likely to draw their guns, and likely to do so at close range, and if you can somehow make them reliable enough to satisfy police, then ordinary people are likely to start buying them too. But I don't think Police are anywhere close to accepting these.

* Nobody expects them to survive long. Guns are some of the most durable consumer goods you can buy today. With proper care, they'll easily last decades if not centuries. Consumer electronics, on the other hand, rarely survive long. I don't want to buy a gun that will be a brick in 20 years.

Optics tend to have a shorter lifespan, and gun owners accept that as a trade off because it gives them something far more capable than iron sights. And most people still opt to have back-up iron sights so that a dead battery doesn't render their gun useless. But a fingerprint reader doesn't offer much in exchange for the problems it brings.

* A large fraction of firearm purchases are by hobbyists who already own multiple guns. Smart guns aren't interesting to us, since we already need to come up with a way to secure all our other guns.

* There is a fear that once smart guns come on the market, they'll be the only thing we're allowed to buy. (New Jersey actually passed such a law in 2002). Because of this, anyone who tries to develop such a gun faces backlash. S&W tried, and the ensuing boycott nearly bankrupted the company.

* Finally, only about 1% of firearm deaths are accidental. The overwhelming majority of firearm deaths involve someone deliberately shooting themselves or others.

<comment><USER14> I brought this tech up precisely because of S&W's experience supporting it in NJ; you reminded me of the state and company that took the heat and backed off - thank you

As you're here on HN I'd be disappointed if you found the engineering points insoluble. Although I take your point that you're purchasing for the long haul, perhaps are a hobbyist, and that's cool, engineered solutions gong forward needn't ruin the shooting utility for collectors and hobbyists. Yet there'll always be a market for the old stuff. Firearms are not the only area where the old stuff is collectible and sometimes superior (tube audio amps, LPs come to mind) The social disagreements aren't as easily susceptible to fixing as the engineering problems. The questioner raised the question as if the social factors were subsidiary when in fact they are primary and trump all other considerations.

</comment></comment></comment><comment><USER16> This isn't a problem that will be solved by technology anytime soon. There are more guns in the U.S. than people. Even if you had a perfect tracking system for legally sold weapons, there are plenty of people willing to sell guns illegally, just like there are many people willing to sell drugs illegally.

A shooter can keep loaded guns in his car trunk, park in front of an establishment, and run inside in 20 seconds. It will be a long time before we have AI that can identify and subdue a gunman within 20 seconds.

</comment><comment><USER17> I am looking for a more scientific and statistical approach.

Demanding that our Gov make statistic about gun violence including demographic, geographic, social and economic data on that and then act strong to curb gun violence.

If there is a single group that is outlier causing more gun violence limit the access to the guns on this group.

Start from the low hanging fruit basic statistic.

We can't treat everyone as the same as nobody is equal to others.

</comment><comment><USER18> Well you have backed yourself into a corner. You only care about gun violence and start from the assumption that it will always happen. The only way to stop gun violence in this scenario is by increasing the efficiency of the police force which is an incredibly inefficient way of dealing with the problem at hand.

</comment><comment><USER19> You could use tech to improve the educational opportunities and equality within a society, thereby increasing societal cohesion. People with more stake in society are less attracted to the fringes, and people with genuine mental health issues are more likely to receive help.

</comment><comment><USER20> Hi, this was an idea [https://gtruceversionzero.carrd.co/](https://gtruceversionzero.carrd.co/) I had few months back about a platform mediating between violent gangs in the UK. Could this be re-skinned? All thoughts welcomed

<comment><USER21> G truce?

<comment><USER20> Gang Truce.

</comment></comment></comment><comment><USER12> The problem is the shooter, so lets look at them. Can we make an ML based system that tries to find people likely to end up as a shooter, but instead of being some Orwellian nightmare, sends a person out to listen to them?

</comment><comment><USER22> It's obvious that:

1\. Criminal who wants to mass-hurt people would try to hurt group of people who cannot protect themselves.

2\. Criminal who wants to mass-hurt people (and ready to die himself) will find a ways to [possibly illegally] acquire means to do that.

Should we disarm everyone in a hope that criminals will stop being criminals?

How many people die of knife wounds from the hands of bad guys vs. from guns? From drunk driving or road rage? Granted it's less CNN news-worthy (not mass enough). Should we stop selling knives? Cars?

<comment><USER23> Let's not be kidding here, e.g. how many people you can stab to death...

<comment><USER22> Let look into causes and problems that cause more people to die every year.

What CNN front page shows might not be the best guidance to focus on.

</comment></comment></comment><comment><USER24> I mean the obvious answer is Robocop / I, Robot. High frame rate cameras with deep learning algorithms trained from mass shooting footage that control sniper rifles on pan tilt zoom mounts. Someone starts doing something bad, BAM catches a .308 Winchester in their dome.

</comment><comment><USER23> unfortunately, there is no IT solution to this...

</comment><comment><USER25> Bullet proof armour, I think.</comment>


Mysterious illness tied to marijuana use on the rise in states with legal weed - <AUTHOR> http://www.cbsnews.com/news/mysterious-illness-tied-to-marijuana-use-on-the-rise-in-states-with-legal-weed/ <comment><USER2> _"It is certainly something that, before legalization, we almost never saw," Heard said. "Now we are seeing it quite frequently."_

Something doesn't seem right with that statement. Is the increase in usage because of legalization so dramatic that it resulted in a noticeable, significant number of people seeking treatment for this illness where it became "noticeable" among physicians? The article mentioned that people won't admit to usage if its illegal, but something still doesn't seem right.

And then it immediately segues to a "slacker pothead becomes ambitious again" with the quote ""Now all kinds of ambition has come back. I desire so much more in life and, at 37 years old, it's a little late to do it, but better now than never,""

I'm not going to dispute his experience or pot laziness in general, but the transition to that quote seems a little too opinionated to me.

<comment><USER3> Sounds like Reefer Madness Redux to me but instead of going insane from MJ use you get a tummy ache and it makes you lazy. The article sounded totally fishy to me too.

</comment></comment><comment><USER4> Standard FUD aka Fake News. We are going to see a lot more of this in our newly recognized Post-Truth society. Follow the money, who are the main opponents of legalization? Distilleries, brewers, mobsters believing it will diminish their market share. Don't quote some rando. show an actual study, stats, and peer reviewed conclusions.

</comment><comment><USER5> Could it be that this is not marijuana but the chemicals used to grow it? Certanly sounds like it

</comment><comment><USER6> What a load of conveniently-timed crap.</comment>


Ask HN: Why isn't Apple, Google, and Facebook's 30% tax illegal price fixing? - <AUTHOR> I've wondered for a few years why we don't see the standard 30% developer tax change like you might expect in a competitive market, and I'm hearing this question echoed by more and more developers. I am not accusing any of these companies of colluding to fix the fee, but I am interested to hear from someone with more insight whether this can be considered a form of price fixing.
Obviously, they know there's really nowhere else for third party developers to go (good luck building a competing platform), so as long as they keep their prices equal they could push that tax as high as they want. Weren't antitrust laws designed to address oligopoly situations such as this?
In a similar story, Visa and Mastercard recently settled for $7.25 billion in a class-action lawsuit related to illegally fixing their processing fees:
http://www.reuters.com/article/2012/07/13/us-creditcards-settlement-interchange-idUSBRE86C16H20120713 <comment><USER2> Apple isn't part of a competitive market (or at least they don't think they are), so there's your answer.</comment>


Killer robots and a revolution in warfare - <AUTHOR> http://www.alertnet.org/thenews/newsdesk/LM674603.htm <comment><USER2> I hate that we are building more and more robots that kill people.

I get a feeling that we are getting away from he nastiness of war (the risks of losing your own soldiers) and are _more_ likely to be aggressive when all you got on the line are some terminator/robocop type droids to lose.

Implement the 3 laws of robotics now!</comment>


Github Walrus Emoji - <AUTHOR> https://github.com/github/gemoji/pull/41

<comment><USER2> I guess they're supposed to be ironic, but I really don't get the point of being able to add cutesy icons to bug reports.

EDIT: Also, keep those damn kids off my lawn.

<comment><USER3> Why _not_ add some spice to one of the most tedious, thankless and tense (bug reports sometimes get accusatory and turn into finger-pointing) parts of the development process?

Going with your tongue-in cheek oldschoolness joke, I guess it's a relatively modern concept that serious work doesn't necessarily require a fake-serious demeanor. And yet clients would probably trust a lawyer wearing jeans less. Oh well, one step at a time, I guess.

edit: s/thanksless/thankless/

<comment><USER2> Walrus pictures, to me, feel like fake-fun, not a crack in the facade of fake- seriousness.

<comment><USER3> Okay, I can see that. I guess that lies squarely in to-each-their-own territory. Me, personally, I don't mind some dadaism in my bug reports:

"There's a race condition in your implementation of pthreads (cake emoji). Bugs are dead. Thirty seven. So (walrus emoji). That causes your... You didn't release the semaphore. Semaphore aphorism smidgen genetic tictac tactic. The lock is dead. Lock. Locke? Deadlock. (cake emoji)"

Just kidding, that'd be too cruel.

<comment><USER4> You'd be surprised how often that happens at GitHub. Seriously, next time you wanna express excitement about something just drop a little :boom::camel::shipit:. Weirdly addictive and hilarious.

Also on a more serious note, emoji can seriously help when discussions start feeling more heated than they should. Adds a little levity so people know you're not being a dick. Really important when you're both remote and only see each other once or twice a year.

<comment> jack-r-abbit > _Adds a little levity so people know you 're not being a dick._

Ah... the old "I'm not being a dick... I used a smiley" defense. :)

</comment></comment></comment></comment></comment></comment><comment><USER5> The first time I saw an emoji in a commit message I cried a little.

<comment><USER6> Cursing in a commit message bothers me far more than an emoji. It's an effective way to communicate a larger idea.

:sparkle: version bump to 0.1.0 :sparkle:

would be easily be seen in a list for instance. That said, emoji overuse is annoying (as with everything else).

</comment></comment><comment><USER7> Flagged. This does not belong on HN.</comment>


Meritocracy is the software engineer's delusion. - <AUTHOR> http://michaelochurch.wordpress.com/2014/04/11/meritocracy-is-the-software-engineers-prince-charming-and-why-thats-harmful

<comment><USER2> One of the problems I have with the jobs "above the effort thermocline" (to use the author's words) is that as an engineer, it just seems like a waste of time. My job as an engineer is to get things done and to get them done effectively. If I can automate something so that I never have to do it again, awesome. If something is broken, I fix it.

I don't beat around the bush. I address things head-on and fix them. I want to be successful, and I want my team to be successful.

But in the real world, you run into this issue where addressing things head-on is a no-no. Instead, you have to compromise. You have to make sure you don't hurt anyone's feelings. This is politics. And it just gets in the way.

No wonder I'm having such a hard time transitioning from "just an engineer" to management. I just want to solve problems, and I want to lead a team that solves problems. And sometimes the "leading" part isn't about solving problems at all, but instead kicking that can down the road to make someone else happy.

Annoying. No wonder I'm not cut out for management.

<comment><USER3> > Annoying. No wonder I'm not cut out for management.

Hope you see this! You can still solve problems head-on in a compassionate way; it's really up to the culture of the company you're at.

You sound like you'd be a great manager.

</comment></comment><comment><USER4> Ouch! Are you suggesting that I actually dress for success?

Your conclusion did not cheer me up at all: everyone is doing it so you should too.

It would be nice to get a system where these human flaws in aspiration would work against each other to some mutual advantage.

</comment><comment><USER5> Good article, but not surprising. I gave up on delusions of "meritocracy" in my early 20's.

</comment><comment><USER6> This was an eye opener for an engineer like myself. -Chris

</comment><comment><USER7> spot on.

[edit] Ok, thanks for the down vote on an article that hasn't got much rating and up votes.

<comment><USER8> Yes, that's wrong.

        Empty comments can be ok if they're positive.

From [http://ycombinator.com/newswelcome.html](http://ycombinator.com/newswelcome.html)</comment></comment>


Ask HN: IT illiterate farmer needs clarification - <AUTHOR> https://www.linkedin.com/pulse/do-you-actually-have-time-build-your-entire-agtech-solution-faleide<p>In simple language, can I have some clarity about the above post I found online ..and esp from the POV of Ag? <comment><USER2> I read it as "Lots of people tried to reinvent the wheel because they thought it's easy, but it isn't - it's complex and expensive. We're here because we realized that. Work with us so you have less work and we get a part of your revenue".

Essentially, they say "we have the expertise that you probably can't afford to develop on your own".

<comment><AUTHOR> Right.so..farmers have been going broke and collecting subsidies smoothly before the arrival of Big Data. Why would they bite?</comment></comment>


Instead of containers, give me strong config and deploy primitives - awinter-py https://abe-winter.github.io/blues/2017/04/27/config-vs-containers.html <comment><AUTHOR> So... systemd + Ansible?

I really disliked SystemD before I got my hands dirty with it. Assuming you're developing with any modern language, the language itself probably wraps OS differences anyways (Node / Golang / Rust / Ruby / Python / anything-libUV- based to name a few), not like you can convince developers to change their habits anyways.

People act like Docker makes builds reproducible by magic, then go on to not pin any Golang deps or curl internet resources or not generate lockfiles for NPM, ad infinitum.

There is and never will be a shield operations people can put around their developers. You just need good developers. If you want SoA scaling or automatic cloud configuration, why not just use the most established tools available? Linux's init system and kernel _already do_ resource management, even outside of LXC. People act like a "cloud scheduler" is the only thing that lets multiple processes work together.

This whole idea of isolation is also really inane. Each app will have different disk, io, network, cpu requirements. I also dream of the day Kubernetes can do this "sorting" better than an experienced operations team can, but that day is _far off_ (and I will die before I put redis/mysql/postgres/cassandra/any-other-mature-datastore behind docker and iptables)

<comment> awinter-py Yeah. Would be really interesting to see a container technology that people were eager to use for DB management. Persistent storage is the thing that hasn't clicked yet.

My guess is this technology will be some kind of cluster management. If there were a 'platform' for horizontally scaling data that managed sharding, rebalancing & backups plus gave me user-space hooks to override policies, databases might slowly & cautiously build on top of it.

Most DBs have their own of these (pgpool, mongos, redis sentinel, all of cassandra & hadoop) but would be cool to centralize the common reqs and collaborate.

<comment><USER2> smartOS gives you persistent storage btw. And its lovely ZFS storage..

<comment><USER3> saying smartos gives you persistent storage is like saying docker gives you persistent storage because you can use

      docker run .... -v /storage:/storage myapp

That's not what people are talking about. If you run a container on smartos and the physical machine it is running on blows up, what happens to your persistent storage?

<comment> awinter-py technically it still persists, just in the form of hawking radiation instead of bits & bytes. Some people think this is what makes amazon glacier so cheap.

</comment></comment></comment></comment></comment><comment><USER4>
      If you're deploying C programs that rely on system
      libraries, things may get tricky if you cross flavors or
      versions of linux. But you can probably deploy static-linked
      executables more easily than setting up docker.

For various reasons static linking isn't a good idea for C applications. glibc doesn't work well when statically linked. musl works well. But glibc has strong backward compatibility using symbol versioning. It's not usually worth the trouble to build and link aginst musl if your distro uses glibc. What you should be worried about are all the other third-party libraries, which aren't often written to be statically linked--because of namespace pollution, because of slightly different semantics between dynamic and static code, especially at application startup.

Fortunately, Linux supports packaging apps much like macOS bundles, where all shared objects are kept under a relocatable subtree. When building a binary that will be installed in bin/, for example, just use the following GCC flags:

      -Wl,-rpath,'$ORIGIN/../lib' -Wl,--enable-new-dtags

The first flag tells the linker to find libraries in the lib/ directory adjacent to the binary file itself. The second flag tells the linker to try LD_LIBRARY_PATH first rather than the embedded rpath. Debugging and regression testing can be very difficult without the ability to use LD_LIBRARY_PATH, and unfortunately LD_LIBRARY_PATH has lower precedence than embedded rpaths, thus the need for --enable-new-dtags to change the default behavior.

Note that $ORIGIN is a special string that is expanded by the runtime linker, not by the shell at compile time. It's an unfortunate choice of syntax. Getting $ORIGIN to pass through to the compiler without being evaluated by a shell can be tricky when dealing with recursive make and shell invocations, such as from an RPM spec file.

Another example: when building a Lua module I'll use

      -Wl,-rpath,'$ORIGIN/../..' -Wl,--enable-new-dtags

because Lua modules are usually installed under $(prefix)/lib/lua/5.?/, two directories below lib/.

<comment><USER5> Allowing LD_LIBRARY_PATH in production is a potential security risk.

<comment><USER6> And then you might just end up using setcap on it anyhow, perhaps to load privileged ports, which is treated like suid, making it so that the linker won't look at LD_LIBRARY_PATH, in which case you have to create a conf file with your paths and feed it to ldconfig after using ldd on the program because you're confused about why it suddenly doesn't load its libraries.

And there's another fun security restriction in there where chown erases any setcap permissions you had applied, just in case you had to adjust something and didn't understand why you suddenly lost your setcap permissions.

</comment></comment></comment><comment><USER7> > "If you develop on linux and run on linux and you're in a deploy-as-source > language, you may not care that much about repeatable builds."

If you develop in Elixir or Erlang, there's an additional issue that containers (such as docker) tend to interfere with hot code reload.

There are work-in-progress solutions (such as Elixir Distillery) that emphasize turning your app into a single package which can be deployed anywhere.

Even if you don't use Elixir, you may enjoy seeing how the Distillery packaging system works, and how hot code reload works.

A good intro is [http://www.east5th.co/blog/2016/12/26/deploying-elixir- appli...](http://www.east5th.co/blog/2016/12/26/deploying-elixir-applications- with-distillery/)

<comment><USER8> Hot code reload interferes with immutable deployments. I'd prefer the immutability over hot code reloading.

<comment><USER9> Nope, hot code reload is the same thing. They've just moved the immutability line even closer to the code.

</comment></comment></comment><comment><USER10> > What will it take to build this? 6 months x 3 smart devs who understand the > linux kernel. So like $600k.

It seems like PaaSes are the new JavaScript frameworks[0]. Kubernetes now has most of the "critical pieces" mentioned and Helm addresses the "rigid" config criticism. It's not newbie proof yet but I doubt your 1.5 man-year project would get anywhere close to K8s is in terms of maturity and stability. Please do your homework and consider contributing to an existing project before re- inventing the wheel.

[0] [https://github.com/search?q=paas](https://github.com/search?q=paas)

<comment><USER11> Do Linux kernel devs really make 6 figures on average??

<comment><USER12> The median salary for a software developer in the United States is six figures: [https://www.bls.gov/ooh/Computer-and-Information- Technology/...](https://www.bls.gov/ooh/Computer-and-Information- Technology/Software-developers.htm)

</comment></comment></comment><comment><USER13> Nomad [0] does some of this already:

      * config file for resources.
      * It does log capture/delivery mostly.
      * it does chroot exec.
      * it handles network ports, file paths, etc
      * handles batch workloads.

It can't handle the load balancer piece directly, but if you use the consul tie-in, you can make it work, since it does service discovery, and then something like fabio [1] /traefik can handle load-balancing.

[0] [https://www.nomadproject.io/](https://www.nomadproject.io/) [1] [https://github.com/fabiolb/fabio](https://github.com/fabiolb/fabio) [2] [https://docs.traefik.io/](https://docs.traefik.io/)

<comment><USER14> Using fabio with nomad and loving it.

</comment></comment><comment><USER15> Have you seen Nix? It can be used in this way, and its configuration language is relatively good.

<comment> awinter-py I love the idea of nix but haven't had a chance to try.

Can you post a link to how nix handles resource permissioning?

<comment><USER16> A note about nix: I've found the language to be very obtuse and the documentation out of date and fragmented. However the worst sin has been the attitude of several community members: insulting new developers, ignoring valid questions, and self-promotion at the expense of civility. I love the idea behind the system and like most of the community, but the very vocal jerks really put me off.

<comment><USER17> I just wish to report that I had only good experience in communicating with Nix/Nixos/Nixpkgs community.

When someone could solve something that didn't work for me, they did. When no one could or didn't have time, they kept silent or politely tried to help me find the solution myself. And everything absolutely for free!

</comment></comment></comment></comment><comment><USER18> People like the idea of isolation that containers (LXC) provide. We don't have to worry about stepping on toes, my container works with any number of other containers running on the same host, not sometimes, all times.

The env is moving fast, Kubernetes and Helm are on a tear. It's also worth taking another look at cluster standup CoreOS+Vagrant/Tectonic/Minikube/kubeadm are filling in gaps.

<comment> awinter-py minikube was not quite primetime when I tried it, but I saw release notes a few weeks later that fixed everything I ran into. (IIRC it was ingress or DNS problems).

<comment><USER19> Your impressions about Kubernetes sounded quite out of date when I read your post. I strongly suggest you give things another try. Things move fairly fast in this area.

</comment></comment></comment><comment><USER20> This reminds me of the awesome article by the founder of skyliner: [https://blog.skyliner.io/the-happy-genius-of-my- household-2f...](https://blog.skyliner.io/the-happy-genius-of-my- household-2f76efba535a)

Google built Borg/Kubernetes because they own all the host machines which are super powerful, and they need multiple apps on one machine to cut cost. But for the rest of us building apps, different VMs provided by cloud provider, such as EC2, already provides a nice way of resource isolation that is also cheap, so why do we need to run multiple containers per machine? Suppose c4.4xlarge is too big for your app, for cost effective reason, you want to leverage Kubernetes to run multiple apps on the same VM, why not just spawn multiple c4.xlarge or c4.2xlarge VMs, and run only one app per VM for you?

I admit this model won't fit us all, but for a significant number of us, this is already a good enough solution like containers, and it works today without needing to setup all kinds of fancy software defined networks, which we never know how long it's gonna last without signaling an issue.

</comment><comment><USER21> "It also gave me a duct tape feeling or batteries not included – like the critical pieces (docker support, DNS, load balancing) weren't integrated into the original design."

I'm sorry, this article^H^H^H^H^H rant isn't worth reading. I don't understand why people write these posts where they so poignantly display their complete ignorance alongside their strongly held opinions. It's tacky and doesn't reflect well.

Load balancing is literally built-in via kube-proxy, NodePort and/or CloudProvider integration. Kube-DNS has existed for years (and is intentionally removable, but not at all duct-taped on). And the claim that Kubernetes didn't have Docker support... I mean, I literally don't even know what to say to that.

<comment><USER22> These pieces were bolted on later, as an after thought. They are critical and should have been there for the start.

Many people have been forced into docker for a few years already, facing a ton of critical features that are completely missing. kube is a brand new project that only started to be usable recently, you seem to not take that into account.

It doesn't help that marketing around containers is "over promise and under deliver".

<comment><USER21> > _These pieces were bolted on later, as an after thought._

First, I don't know why you think this? Moreover, what is the practical implications of the claim? Have you ever had a problem with DNS service discovery in a Kubernetes cluster? Or else what is the point of bringing this up at all? (Nor does this change the inaccuracy of the other claims)

> _Many people have been forced into docker for a few years already, facing a > ton of critical features that are completely missing. kube is a brand new > project that only started to be usable recently, you seem to not take that > into account._

It's been 1.0 for well over a year and I still don't know what you're getting at in regards to docker. Kubernetes is (more or less) powered by Docker (at least historically, it's getting to a point where the container runtime is pluggable via CRI/CRI-O).

> _It doesn 't help that marketing around containers is "over promise and > under deliver"._

Also no idea what this means. Kubernetes and containers have done everything I've expected them to do. I usually see this comment from people who haven't actually ever used them for more than a day and gleefully point to articles talking about stale docker images with vulnerabilities, ignoring that nearly the exact same problem happens with naive VMs + CM deployment methodologies. Or otherwise think they're magic, when they're not.

Not seeing anything to change my initial conclusion here.

<comment><USER22> Judging by the comment. You're the one who used Docker for a day or on nothing critical. Maybe you're also lucky to have started with Kubernetes, maybe even fully managed on Google Cloud.

I used it for 3 years at different companies with more or less hassle. The route to container has been full of dangers.

<comment><USER21> > _You 're the one who used Docker for a day or on nothing critical._

Not really, but thanks for coming for me instead of offering any substance beyond hand waving.

> _Maybe you 're also lucky to have started with Kubernetes, maybe even fully > managed on Google Cloud._

I mean, sure, I think it's crazy to try to use Docker in Prod without an orchestrator and don't think Swarm Mode is mature enough for such a use case. And no, I don't use GKE.

Now that we've dropped anything that was really being discussed, let me agree with you, Docker itself is not my favorite, but that has nothing to do with containers or orchestrators in general and instead has to do with the QA of Docker and the frequency of breaks and regressions.

<comment><USER22> We both agree that orchestration is critical. Yet orchestrators are fairly new, the docker hype was strong long before they were viable, or existed at all.

You'll forgive me but implying that one one should just use an orchestrator points to one ignoring their history -or lack thereof-.

I have seen entire clusters taken out by a regression. Sadly, even the best orchestration cannot do much better than the core it is running on. You can google "docker in production" to get more substance.

<comment><USER21> >I have seen entire clusters taken out by a regression.

I think we agree a lot actually :). Not sure Docker would call this one a regression, but... [https://github.com/Azure/ACS/issues/3#issue-201986759](https://github.com/Azure/ACS/issues/3#issue-201986759) (that's me)

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I've started using K8s and so far so good. Minikube makes local dev easy. However, I use K8s with ansible. So now I can:

* Build a fully baked container for local use

* Build a container that mounts my local filesystem for the code directory so I can have a sane dev-test cycle with hot-code reloading

* Mount a directory when running locally containing credentials for accessing Google Cloud services

* Spin up a K8s cluster in arbitrary GKE accounts, template and deploy my deployment and service accounts, pin some with external IPs, etc

* Push containers to GCR

* Deploy my containers wherever - shared directory ones can only run locally.

This is for an architecture with about 4 microservices and that will probably grow.

Now I'm working on an ansible playbook to zip the code directory of one of my microservices, upload it to GCS, then run a build container on my cluster to build the docker image for my microservice and push to GCR from there so I don't have to waste time pushing large containers up to GCR. Once this is done I'll look at promoting containers through dev/test/prod environments since all config will be done with env vars.

I've never read about using ansible with K8s, but to me it's a no-brainer. Most people seem to cobble together bash scripts, but using the best of both has really led to a good experience.

The benefit we hope to get is isolation and cost efficiency.

<comment><USER24> That's interesting. I'm using docker-compose for local development at the moment. Do you have any experience with it and would you choose Minikube over docker-compose?

<comment><USER25> You didn't ask me, but here you are:

I'm using docker-compose as well but I'm looking at moving to Minikube, so I can more realistically test my K8s clusters before sending them down to CI/staging.

I also don't want to maintain both docker-compose and K8s as I basically am ops by myself and I have NaN tasks in my backlog.

</comment></comment></comment><comment><USER26> So many docker containers I use at work just have a ton of apt-get or yum statements (depending on a debian or centos base) and people rarely pin dependency versions. I really feel for the "repeatable build" issue, not to mention dependency rot.

If you want to keep things up to date, there are many examples scripts out there that either 1) checking to see if your base container is out of date (if someone updated jessie:8, you should rebuild) and 2) checking if any packages are out of date (sometimes limiting to just security updates) meaning you run apk, yum, apt, etc. within each container (or extract their package lists and examine them outside the container).

You gain a lot in the isolation, but debugging can become more difficult and you've introduced new areas of dependency rot.

I generally like containers, but hate how there are so many different orchestration formats (k8s, marathon, nomad, swarm, etc.) many different network layers (weave, flannel, etc.) and many different ways to package/fit components together (CoreOS, DC/OS, etc.)

The ecosystem is messy.

<comment><USER27> I'd like to build something that attaches cryptocurrency payments to API calls, basically a 402 payment required implemented with the Lightning Network.

With such a system in place, pulling updates could be pinned to a particular API call, with a particular payment address, which itself was attached to a particular data store. In theory, as long as you had access to the wallet that did the build before, you'd be able to do the same build at a later date.

I'm greatly simplifying this here, but my conclusion after getting a crypto payment OpenStack instance launcher PoC working was that applying crypto payments to deployment methods basically provided a lightweight federated layer that allowed logically linking processes, similar to what you would get with a Zapier/Apigee/IFTTT knockoff. Applied to microservice architectures it would allow deployments to be both trustworthy and repeatable at later dates.

<comment><USER28> Json web token (jwt) is probably what you're looking for

</comment></comment></comment><comment><USER29> "6 months x 3 smart devs who understand the linux kernel. So like $600k."

Show me that $400k/year linux kernel job.

<comment><USER22> An employee costs much more than just the salary he receives at the end of the month.

<comment><USER30> Show me the $200k job with $200k of overhead instead then.

<comment><USER22> Looks like any senior job at google/facebook/microsoft/apple.

150-200k in salary + 50-100k in stock + 50k-100k for health/401k/parentalleave/food//office/hardware/concierge/gym + employer taxes + ...

</comment></comment></comment></comment><comment><USER31> rkt seems to meet his "define resource access in a config file" requirement in principle.

The separation in rkt between setting up the isolation and handling the images or running of the code means that you can opt to launch a rkt image in anything from an _actual_ chroot to a full container or even a full VM, or you can write your own if you have weird needs (e.g. if you want to do a seccomp- bpf type sandbox, you can do that).

E.g. I have deployments with etcd in a chroot (using rkt), and the rest deployed as containers, which with rkt defaults to use systemd-nspawn, and which means they have systemd running as the init in the container too and logging goes straight to the journal just like everything else.

Cron really depends on scale. For small deployments it's simple enough to simply use a cron or systemd and use a simple wrapper that uses e.g. Etcd or Consul or even a database table to arbitrate who gets to run for jobs that shouldn't run more than once. In practice depending on exactly what you do it's often simpler/better to write the jobs so it doesn't matter if they're started more than once anyway. Seen too many nasty surprises in systems where people just assumed nobody would ever end up with the scripts overlapping in time only for something to slow down processing until they do just that anyway. If you're first doing that, all you need to do to handle a smaller distributed system is to put your locking mechanism somewhere shared.

At scale it becomes more complex, but the overall principle still holds, though you may want to separate scheduling aka. the various distributed cron's.

As for load balancer, I agree it needs standardising, but it really is a small enough issue for smaller setups that it's fairly easy to solve. I've come to rely on setups that uses Nginx and rewrites incoming hostnames to a local hostname (e.g. foo.com => foo.com.service) and use resolvers in Nginx to point them to a SkyDNS instance. That means all the container config needs to do is set/delete Etcd keys to receive traffic for a given hostname.

But there's several load balancers out there that now can pull config directly from a suitable shared datastore, be it Redis or Etcd etc.

</comment><comment><USER32> > _When I used kube in 2016 the cluster turnup support was bad; it seemed like > you could use it managed in the G cloud but not anywhere else._

You might like to look at Kubo[1], which was jointly built by Googlers and Pivots to make this more manageable. We built it based on requests from joint customers who want BOSH as their infrastructure-level platform and the choice of Cloud Foundry or Kubernetes for application-level platform.

[1] [https://github.com/pivotal-cf-experimental/kubo- deployment](https://github.com/pivotal-cf-experimental/kubo-deployment)

edit: forgot my usual disclosure. I work on Cloud Foundry for Pivotal, though not on Kubo.

<comment><USER33> Are employees of Pivotal really called "Pivots"? Am I shallow for finding this repulsive? Same with googlers for that matter.

<comment><USER34> Twitter employees call themselves tweeps, which might be the worst of the corporate self-nicknames.

</comment></comment></comment><comment><USER35> No real opinion about anything in the article except the use of config files.

After using Consul, I never want to go back to config files again.

[https://www.consul.io/intro/](https://www.consul.io/intro/)

<comment><USER36> Config files as copied around by scp and edited by hand are a pita -- but as checked into source control as a template and staged to machines by your deploy; the very simplest and most robust solution.

<comment><USER35> Compared to going on your Consul's website to change a value and that value automatically being updated in all of the systems?

<comment><USER36> Actually yes, I want to version control that change and deploy it like I deploy code. Not blindly fire changes that I can't track into the ether.

<comment><USER37> You could always disallow consul web interface updates and have `consul kv put` scripts in SCM and validated/deployed automatically.

<comment><USER36> Yeah man, I could setup a quorum of consul boxes, integrate consul's api into my application, figure out how to manage changes in that system, and then do as you say -- make a change management system to apply deltas on deploy.

Or, I could put one more file on each box in addition to the other 100,000 files I put on there...

<comment><USER38> Obviously you wouldn't choose consul for this one feature, but if you're already relying on consul as service discovery in your network, why not?

You don't need to invent a change management system, you just need to utilize from a myriad of existing consul OSS.

I'm not saying consul makes all the sense in the world for you, but there's definitely sound architectural thinking behind what the parent is talking about. It's not just a bunch of crazy talk :-D

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> >kind of like a fancy chroot

You might argue that containers are fancy chroots. They are just built from scratch and packed each time

</comment><comment><USER40> This exactly hits the problem with containers (and especially Docker and Kubernetes, but to a lesser extent CoreOS's model as well). The crows that seems to like/use it seem to be the people that aren't responsible for maintenance, security etc. and may not want to become the responsible party either. It's often developers that are either simply a lone wolf or part of a team that is big enough that release management falls on one or two people and 'the rest' just wants to churn out code in 'their way' and have that 'way' magically work in production too. Sadly, that is not how the world works.

You will always need some form of configuration management, release management, infrastructure and operations, no matter how compartmentalised and 'serverless' the software coders think they are. Right now, the idea seems to be that if you stick your code and practically a complete user land in a container, you don't have to do those things, as if old style deployments were the reason for those practises to be in place. Obviously, it is the other way around, and by trying to bypass them, you will run into the exact problems they are meant to prevent. (i.e. not knowing what is available/what is released, not knowing the configuration within the infrastructure in a global scale, not knowing the side-effects of two opposing configurations because you have no management for that, not knowing what versions are used because it is spread out over different/many unmanaged files inside containers somewhere, not knowing what is secure/patched, not knowing what else is influencing your environment, no control over parameters that should be globally overridden...)

We take a different approach: you get do write your software, and may only configure requirements within its context. Those have to be defined in a SaltStack Formula with sane defaults, that has to run in a local environment, but also DTAP-style chains of environments with no changes to the app. You don't get a say in what it will run on, but your required facilities will be available. If it doesn't pass automated testing (i.e. sticking it in a VM, running a highstate and expecting a working app) it doesn't get passed to DevOps and you're stuck until you fixed your stuff. With regards to scaling, we make sure that a few calls are always available to the app and/or it's formula, so that we can register where it is and connect it to the correct balancing pools (i.e. incoming requests, but also FS, DB, queue pools). When it's up, it registers, and as long as the automatic health checks pass it gets requests sent to it. If the load is too high, we scale up, if it's been idle too long it scales down. But the app/software/code isn't aware of that nor does it need to be, and using the reactor system, we don't need 'extra' management software to make that happen. You set your KPI's and health checks where you need them, just like you would on any other setup, and you're golden.

<comment><USER38> Your last paragraph could clearly be implemented in k8s / etc. but the defining characteristic is that you've built organizational controls to protect & optimize a distributed system. And the main problems you bemoan in the first paragraph are issues of, again, organizational control & maturity.

It's almost, like, technologies are just tools that can be either applied or misapapplied to a given domain, either for better or for worse. Huh.

<comment><USER40> It's obviously all about implementation and application, but instead of always reading 'Docker is the solution' it would be nice if it were listed as 'just another tool in your toolbox'. The problem I personally have with this and some other 'emerging' technologies is that they are touted as a 'replacement' for Ops, management, or infrastructure, while in practise, it's obviously not.

</comment></comment></comment><comment><USER41> I think the higher level goals are pretty much aligned with those of kubernetes. That it uses 'containers' to achieve this, is just a side effect.

And it's surprising flexible! You don't need any overlay networking, you can just define a IP range and it will 'just work' as long as your nodes are in the same ethernet segment. If you grow to more than, let say, 500-1000 pods, you need some routing but still can do without overlay networks.

I'm currently working on a project where I use the kubelet standalone. I can give it a pod manifest and it will make sure the specified containers are running. This doesn't need any cluster components or data stores and is already useful for tiny use cases. Also using this now for my tests instead of docker-compose.

</comment><comment><USER42> Isn't resource access like that found in CloudFoundry or Chef Habitat?

Isn't load balancer standardization found with Kubernetes Ingress? Though it doesn't let you select the lb algorithm though.

Isn't cron found in Kubernetes Cron Jobs?

</comment><comment><USER28> That's sort of what systemd could have been, before it tried to do everything.

Kiss is not something the systemd designers don't seem to understand, nor modularity

</comment><comment><USER43> > _my iterative dev setup often isn't that similar to my 'under docker' setup_

This seems like a strange complaint to me, because it's one of the best things about iterating with docker. Make a change, do a build (super quick because of fs layers) then run it. If it works, ship it!

Not only that, but now I can do the same thing in Windows. It's a wonderful time to develop linux applications.

<comment><USER44> I don't know about the OP, but a lot of people rely on hot code reloading to see live changes, be it a Node.js app or a React UI. The Docker build workflow is _way_ too slow for that. When I work on React apps, I expect the UI to seamlessly reload every time I save a file.

You can accomplish this perfectly well with Docker, of course, though you have to use volumes and so on. Docker for Mac's mounting support has inotify/fsevents on both sides, though the volumes are not fast. (Fast enough for a React app, but enough for a Postgres database.)

</comment></comment><comment><USER45> _" What will it take to build this?

6 months x 3 smart devs who understand the linux kernel. So like $600k."_

Really? $600k for three smart developers for 6 months?

So a smart Linux kernel developer costs $400k per year all-in?

How about various web and node.js developers LOL. Where are the other fields with comparable costs?

</comment><comment><USER46> kubernetes + vault is a powerful combo.

</comment><comment><USER47> Everything the author describes sounds like docker-compose to me. Combine that with Convox and you've got a powerful, easy-to-use cloud platform.

<comment><USER48> Can convox do docker compose?

<comment><USER47> Yes, the point of Convox is that it deploys your docker containers to AWS using your docker-compose config. It sets up a VPC for you, ELBs, autoscaling group, private docker repository, the whole deal :)

</comment></comment></comment><comment><USER49> I like this concept, but maybe add sandboxing too.

</comment><comment><USER50> Something like Ubuntu MAAS? [https://maas.io/](https://maas.io/)

</comment><comment><USER51> wisdom from (not-so-distant) past

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

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

</comment><comment><USER52> I'd be interested in a project like this if it was targetting FreeBSD.

</comment><comment><USER53> What's wrong with strong config and deploy primitives + containers?

</comment><comment><USER48> So you are asking for cloudron?

</comment><comment><USER54> Wouldn't all of this be provided by the Plan9 paradigm?

<comment><USER55> No, I think it's unikernels solve all problems.

</comment></comment><comment><USER56> I just want bare metal servers. I really don't get the craze over containers.

EDIT: spelling, sorry bears, no metal for you.

<comment><USER57> Anyone who serves metal to bears should be put in a container.

<comment><USER56> bare :(

You know, the entire time I keep telling my self "don't type bear, don't type bear" and my wife distracted me and I typed bear.

</comment></comment></comment><comment><USER58> Am I the only one that sees the container-stuff as an intermediate stepping stone until AWS lambda (or similar offerings) can be applied on every coding Problem?

<comment><USER57> > ls $home

No network connection.

> sudo ifup eth0 && ls $home

AWS coreutils: unable to connect to target filesystem host. Please open port 22 and ensure that the aws-guest user has full access to the filesystem.

> find -name aws -exec rm -rf {} +

> sudo apt-get install coreutils -y</comment></comment>


Adblock Plus: the tiny plugin threatening the internet's business model - <AUTHOR> http://www.theguardian.com/technology/2013/oct/14/the-tiny-german-company-threatening-the-internets-business-model <comment><USER2> Frankly, I hate advertising -- ALL advertising, not just web advertising -- and want the advertising industry to die in a fire. I recognize this is a bit controversial, especially with Americans (who seem unable to conceive of content industries that can exist in the absence of advertising: the BBC and the entire book publishing industry apparently exist in a cognitive blind spot), but advertising is mostly oriented around selling us stuff _we don 't want or need_, and as such it shares many characteristics with spam; it's insidious, intrusive, tries to steal your attention, and works by instilling uncertainty and self-doubt.

Yes, 90% of the web would die without advertising -- but I think we'd be better off with just the 10% left over, because it'd be the _best_ 10% (the stuff that has a viable business model that works without advertising).

<comment><USER3> I don't think you really hate advertising as much as you say.

You get to use tons and tons of great sites without paying money, because the good people of ADVERT_CO paid for your attention.

Advertising gives you something you want, so you pay attention to something you don't want. But unless you want to pay a subscription fee to every site you use, it's not a bad deal at all.

<comment><USER4> > _But unless you want to pay a subscription fee to every site you use, it 's > not a bad deal at all._

There are websites out there that do not rely on ads and do not require a paid subscription to be used (I built one, a CSE).

<comment><USER5> How do they stay in business? And, what is a CSE?

<comment><USER4> > How do they stay in business?

Make users happy, provide useful content, help them save time and make informed choices when purchasing. Has worked for 14 years so far.

> what is a CSE?

Comparison Shopping Engine.

<comment><USER5> So, they get a get money for sales? A percentage or something? Genuinely curious.

EDIT: I see you've answered this question above.

When I'm doing serious comparison shopping, I use a subscription site. I feel better about the reduced incentive to inflate recommendations.

Although the subscription site does make mistakes, it's usually in the durability side of things (they can't test a new product for three years and have the results by April).

The comparison shopping sites are quite nice once I know what I'm looking for, however.

</comment></comment></comment></comment></comment></comment><comment><USER6> There is a HUGE controversy about Adblock plus. One blogger uncovered some of their business methods. They have Mafia like structures and extort businesses. Unfortunately it's only in German and I have yet to find an English site report about it.

Main article (very detailed):

[http://www.mobilegeeks.de/adblock-plus-undercover- einblicke-...](http://www.mobilegeeks.de/adblock-plus-undercover-einblicke-in- ein-mafioeses-werbenetzwerk/)

They've been trying to cover up their methods and simply lied about it. Stay away from Adblock Plus.

Some shorter article:

[http://www.heise.de/newsticker/meldung/Adblock-Plus- Weitere-...](http://www.heise.de/newsticker/meldung/Adblock-Plus-Weitere- Vorwuerfe-und-Widersprueche-1909535.html)

<comment><USER5> Is there an alternative?

<comment><USER7> I use "Adblock Edge" as an alternative. It's basically a fork of adblock plus but without the "acceptable ads" feature.

<comment><USER8> I never appreciated the difference or history of the Adblock and Adblock Plus plugins. I'm currently removing ABP from all my desktops and laptops in favour of Adblock Edge. Thanks.

</comment></comment></comment></comment><comment><USER9> I've been happily using Adblock Edge (a fork of ABP without the acceptable ads feature): [https://addons.mozilla.org/En-us/firefox/addon/adblock- edge/](https://addons.mozilla.org/En-us/firefox/addon/adblock-edge/)

I allow ads on sites I support and respect, and everyone else gets blocked. I'd rather do that myself than have ABP decide that for me.

Unfortunately ABE is not available for Chrome (see [https://bitbucket.org/adstomper/adblockedge/issue/23/adblock...](https://bitbucket.org/adstomper/adblockedge/issue/23/adblock- edge-for-chrome)), so I still use ABP on Chrome. Is there an alternative out there yet?

<comment><USER10> Yes. AdBlock ([https://getadblock.com](https://getadblock.com)) is actually the most popular extension on Chrome, more than Adblock Plus. It blocks solely based on your filter subscriptions and custom rules and is funded solely by usrs.

[https://getadblock.com/adblock-is-not-adblock- plus](https://getadblock.com/adblock-is-not-adblock-plus)

</comment></comment><comment><USER3> Here's the problem...anything that _can_ be done, will be done. And ads can be blocked online. It's just reality. Like digital music will be copied and secret government problems will be leaked and embarrassing pictures of politicians will surface online.

It doesn't matter what you _want_ to happen. It's just going to.

So we, as people who profit from the web, need to think about structuring our businesses in such a way that the inevitable doesn't kill our work.

(FWIW, Adblock's business model is apparently extortion, which makes me sick.)

</comment><comment><USER10> Please note: This article is about Adblock Plus. AdBlock is a completely separate extension with different developers, and is 100% user-supported.

Details: [https://getadblock.com/adblock-is-not-adblock- plus](https://getadblock.com/adblock-is-not-adblock-plus)

</comment><comment><USER11> As an alternative, I switched to Adblock Edge: [https://addons.mozilla.org/en- us/firefox/addon/adblock-edge/](https://addons.mozilla.org/en- us/firefox/addon/adblock-edge/)

</comment><comment><USER12> Adblockers should just block ads, not be used to extort money once they reach a certain level of adoption.

</comment><comment><USER13> Given that the business model in question has come to revolve around highly targeted advertising achieved via extensive tracking and profiling of users, it certainly deserves to be threatened.

Unfortunately, the AdblockPlus "acceptable ads" criteria don't address the privacy issues. So the ABP folks are actually promoting advertising standards and ads that are intrusive. To make matters worse, this "ad blocker" that supposedly "protects your online privacy" is purposely equipped with a material defect in the form of an enabled by default whitelist that allows many ads through including those that are harmful to your privacy. Those unsuspecting users who fail to learn of this and/or those who forget to opt- out can get burned.

</comment><comment><USER14> Ads make for some interesting doublethink.

One one hand, I hate the consumer oriented society that wastes resources on a ton of useless products; I despise the scummy advertisers who manipulate people into pursuing the wrong goals. On the other, I like having stuff and will happily buy things to put inside my home and on my person. I am totally dependent on the consumer ecosystem and I enjoy creature comforts.

That said, when I truly need something I will make a targeted search for it. It's really rare to see ads that actually interest me. So I am generally extremely hostile to the ad business. I hate everything about them, because they symbolize the uncomfortable truths and compromises our society rests upon. They are everywhere and mostly do nothing but sap your mental energy.

</comment><comment><USER10> The advertising problem is very strange. There is content we do want which we could have by paying a small amount. But we're (by and large) unwilling. So we get ads.

A tiny fraction of the ads are clicked, and a tiny fraction of the money spent on that product goes back to the content producer. And that's enough to fund them.

We could avoid seeing 100 ads which end up giving 10 cents to the site if we'd just pay 10 cents each.[1] It would be nicer for us and simpler for the content producers. But we're not willing, apparently.

It seems perverse to claim that we value good articles and shows if we force the creators to sell us boots in order to make a living.

Oh, micropayments, when will we find a workable system for you?

[1] Made-up numbers

</comment><comment><USER15> > But sites are rarely paid "per click".

Doesn't google AdSense alone count for a non-trivial portion of internet advertising? Unless the rules are different for bigger partners, all AdSense revenue is per click.

</comment><comment><USER16> I don't like the implied threat stuff going on here. I may look for a different ad blocking solution. But that article was pretty shrill.

As far as I'm concerned, most online advertising is malware.

<comment><USER17> if you don't want to support eyeo there's a fork of ABP called adblock edge.

works just as well, without the acceptable ads racket

</comment></comment><comment><AUTHOR> Can anyone shed some light on the Hacker News story ranking algorithm?

After 1 hour, this submission was in third place on the front page, then I checked again about 15 minutes later and it had dropped to 93rd place, on page 4! There are many other stories that are both older and have fewer points that are higher up the rankings. Judging by the number of comments, this link is obviously a story of interest to HN.

Just curious what's going on..

<comment><USER18> Employes of a certain company that starts with G do this on stories harmful to their employer. I'd bet that's the reason.

<comment><AUTHOR> So the ranking isn't simply based on a combination of age and upvotes? I see.

<comment><USER18> I _think_ it also has to do with a rush new votes up or down. Sort of trending

</comment></comment></comment></comment><comment><USER19> I have written a short article on adds and 'peak advertising'. Might be of interest.

[http://mosermichael.github.io/cstuff/all/blogg/2013/10/14/po...](http://mosermichael.github.io/cstuff/all/blogg/2013/10/14/post.1.html)

</comment><comment><USER20> _" The Internet's business model"_

The internet is a single business with one business model? Holy shit. It must work well, as I hear the internet's all the rage with the young folks. Should've invested sooner.

</comment><comment><USER21> Hah. I recall antispam companies doing the same thing - once they got big enough, they demanded money from major mail exchanges. I'm sure companies paid out rather than risk long legal cases and poor PR.

</comment><comment><USER22> Thanks, due to this post I have switched from ABP on chrome to Adblock. Had no idea the ABP people were acting in this way, will try to spread the word.

</comment><comment><USER18> Ads are fine, up to a point. If the page is almost all ads and not marked clearly as so, then F that company.

But these AdBlock PLUS guys are extortionists. Google paid and their ads are "acceptable." all of the sudden. (Disclaimer: not a fan of Google at all) Google being the world's largest advertiser is leading the way in putting the entire business model at risk, ruining ads for everyone. They started with no ads, then a few ads on the side, then on top, then 2-5 on top and 12 on the sides, now ads everywhere and just a few results hidden by ads. Now the product search is 100% ads and I doubt that most people know (not everyone reads HN and Ars) I posted them before but this is a disgrace and it's not receiving the needed attention from the media:

[http://i.imgur.com/mhJhc5W.png](http://i.imgur.com/mhJhc5W.png)

[http://ho9od35yvs05ejqn.zippykid.netdna-cdn.com/wp- content/u...](http://ho9od35yvs05ejqn.zippykid.netdna-cdn.com/wp- content/uploads/2011/12/Google-Adwords-HD-Monitor.jpg)</comment>


What's new in matplotlib 2.0.0 - <AUTHOR> http://matplotlib.org/2.0.0/users/whats_new.html <comment><AUTHOR> Especially changes in the default plot styles: [http://matplotlib.org/2.0.0/users/dflt_style_changes.html](http://matplotlib.org/2.0.0/users/dflt_style_changes.html).

No more "good old 90s" as a default color scheme (#0000FF, #00FF00, #FF0000...). And perhaps also - no need to load [http://seaborn.pydata.org/](http://seaborn.pydata.org/) each time, just to patch it.</comment>


The Caves of Clojure part 3.1: World Generation - <AUTHOR> http://stevelosh.com/blog/2012/07/caves-of-clojure-03-1/

<comment><USER2> I didn't see anywhere to comment on your blog, but after reading part 2 I had a idea about solving the inventory-select problem.

What if instead of the UI "returning a value", it instead has a property that is a function describing what to do upon selecting inventory, something like this:

      [{:kind :play}
       {:kind :throw}
       {:kind :inventory-select
        :on-select (fn [game selected-item]
                       ; code here that returns an altered game:
                       ; * puts selected item into throw UI
                       ; * pushes targeting UI onto the stack
                    ) }]

That way whenever something creates the inventory UI, it can pass in a function that specifies what to do.

<comment><AUTHOR> This is basically the "pass a callback" approach that's popular in the JS world. Down this road lies madness.

Let's see how this might actually work. First the easy part, the inventory selector. It takes the user's input and figures out what item they picked, then calls the callback:

        (defn pop-ui [game]
          (update-in game [:uis] butlast))

        (defn push-ui [game ui]
          (update-in game [:uis] conj ui))

        (defmethod process-input :inventory-select [ui game input]
          (let [selected-item (get-item game input)
                callback (:on-select ui)]
            (callback (pop-ui game)
                      selected-item)))

That's not too bad. It calls the callback with the game (after popping itself off the UI stack) and the item they picked.

Now to the main play UI that's going to set up the throwing when the user presses t:

        (defmethod process-input :play [ui game input]
          ; ...
          \t (update-in game [:uis] concat (make-throw-ui-stack))
          ; ...
        )

Also pretty clean. We're going to be appending two UIs to the stack (throw and inventory select) so we use concat, but that's fine. You could have another multimethod if you really didn't want the play UI to know _anything_ about targeting, but that's irrelvant for now.

So far so good, but now it's time to dive down the rabbit hole:

        (defn make-throw-ui-stack []
          [(new UI :throw)
           (new UI :inventory-select
             :on-select (fn [game selected-item]
                          ,,,))])

Okay so we have the basic stack of UIs we'll need to start, all that's left is the callback. Well it needs to:

* Take the game and the item that was selected.

* Return a game with the throw UI storing the item for later, and a targeting UI after that so the user can pick a monster to kill.

That doesn't sound so bad:

        (defn make-throw-ui-stack []
          [(new UI :throw)
           (new UI :inventory-select
             :on-select (fn [game selected-item]
                          (push-ui (new UI :target))))])

Okay, a bit indentation-heavy but readable. At least we don't have to store the selected-item in the throw UI any more, because our callback closes over it. Let's make the targeting UI:

        (defmethod process-input :target [ui game input]
          (let [selected-monster (get-monster game input)
                callback (:on-select ui)]
            (callback (pop-ui game)
                      selected-monster)))

Cool, but wait, now we need another callback in the throw UI!

        (defn make-throw-ui-stack []
          [(new UI :throw)
           (new UI :inventory-select
             :on-select (fn [game selected-item]
                          (push-ui (new UI :target
                                     :on-select (fn [game selected-item]
                                                  (let [game (pop-ui game)]
                                                    (throw-item-at game selected-item selected-monster)))))))])

Okay this looks pretty bad. It's ugly, and all the logic is in the "make throw UI stack" call.

Now notice that we haven't handled the "user pressed escape to cancel" case at all. Oh god.

Contrast this to the "reduce over input" method:

        (defn pop-ui [game]
          (update-in game [:uis] butlast))

        (defn push-ui [game ui]
          (update-in game [:uis] conj ui))

        (defmethod process-input :inventory-select [ui game input]
          (let [result (if (= input :escape)
                         :cancel
                         (get-item game input))]
            (-> game
              pop-ui
              (assoc :input {:item result})))

        (defmethod process-input :target [ui game input]
          (let [result (if (= input :escape)
                         :cancel
                         (get-monster game input))]
            (-> game
              pop-ui
              (assoc :input {:monster result})))

        (defmethod process-input :throw [ui game item]
          (cond
            (= input :escape)          (pop-ui game)
            (contains? input :item)    (-> game
                                         pop-ui
                                         (push-ui (assoc ui :item (:item input)))
                                         (push-ui (new UI :target)))
            (contains? input :monster) (throw-item-at game (:item ui) (:monster input))))

        (defn make-throw-ui-stack []
          [(new UI :throw)
           (new UI :inventory-select)])

        (defmethod process-input :play [ui game input]
          ; ...
          \t (update-in game [:uis] concat (make-throw-ui-stack))
          ; ...
        )

Not only do we now handle escaping from the menus, but this looks much cleaner to me because we're no longer nesting functions inside each other. We've also decoupled the "make the throwing UI" from the "game logic of the throwing UI".

</comment></comment><comment><USER3> I don't recall if this was mentioned in the other threads on this project, but I would highly recommend the section in Chapter 3 of the really fantastic "Clojure Programming" where the authors step through the processes of converting various programs from an imperative to a functional style. This was really my aha! moment with Clojure.

</comment><comment><USER4> I find it odd that he is using the _new_ macro to create the record instances. I thought that it is meant to be used only in Java inter-op, as it requires that the class of the record is visible in the current namespace.

<comment><AUTHOR> I don't get what you mean. I like the way new looks as compared to the Record. syntax, but either way you need the java class visible in the current namespace:

        sjl at grendel in ~/s/caves
        ><((°> lein2 repl
        caves.core=> (use 'caves.world)
        nil
        caves.core=> (new World [:foo])
        CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: World, compiling:(NO_SOURCE_PATH:1)

        caves.core=> (import '[caves.world World])
        caves.world.World
        caves.core=> (new World [:foo])
        #caves.world.World{:tiles [:foo]}
        caves.core=> Bye for now!

        sjl at grendel in ~/s/caves
        ><((°> lein2 repl
        caves.core=> (use 'caves.world)
        nil
        caves.core=> (World. [:foo])
        CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: World, compiling:(NO_SOURCE_PATH:1)

        caves.core=>

Is there another way to create record instances that doesn't involve that warty (import) call that I'm not aware of?

<comment><USER5> As of Clojure 1.3, defrecord (and deftype) automatically define factory functions in the same namespace as the record itself. defrecord generates 2 such functions, one that takes positional arguments and one that takes a map. So once you have :use'd or :require'd the namespace, you can do stuff like the following without having to import anymore:

        (->World [:foo])
        (->World {:tiles [:foo]})

More details here:

<http://dev.clojure.org/display/design/defrecord+improvements>

<comment><AUTHOR> Oh cool, I didn't know that. I kind of blocked 1.3 out of my memory after the "let's remove clojure.contrib and break everyone's shit" mess.

It's good to know that progress toward patching all the places Java tends to leak through into Clojure is happening.

I can't say I'm a fan of the punctuation-laden syntax, but I'll pick my battles and not complain about it.

I'll switch over to this new form tonight and mention it in one of the later posts. Thanks!</comment></comment></comment></comment>