Don't stage off Starship - <AUTHOR> https://caseyhandmer.wordpress.com/2020/02/15/dont-stage-off-starship/ <comment><USER2> If you are still unsure about the scale of SpaceX' plans for Mars, here is a very concise summary by Robert Zubrin (president of the Mars Society):

 _It 's not Apollo. It's D-Day._

It is from an interview with Zubrin who, among other things, discussed mini- Starship with Elon Musk at the Boca Chica job day recently. It can be found here [0], with an automated transcription at [1]. Discussed in /r/spacex at [2].

[0] [https://www.thespaceshow.com/show/11-feb-2020/broadcast-3459...](https://www.thespaceshow.com/show/11-feb-2020/broadcast-3459-dr.-robert- zubrin)

[1] [https://hastebin.com/raw/ozimiqenop](https://hastebin.com/raw/ozimiqenop)

[2] [https://old.reddit.com/r/spacex/comments/f34fqm/zubrin_share...](https://old.reddit.com/r/spacex/comments/f34fqm/zubrin_shares_new_info_about_starship/)

</comment><comment><USER3> This is by far the most interesting aviation/rocketry development I've ever seen. After watching the two Falcon 9 lower stages come back simultaneously from the first Falcon Heavy launch, I realized how different things were going to be.

Starship, even if Musk is off by quite a large factor on the cost to launch, is still going to be extremely cheap to fly compared to everything else out there.

Other people copycatting the ideas off of Starship will drastically improve the space industry costs, regardless if the Mars venture is successful or not (and I want it to be). This will literally put us in a different era. It wouldn't surprise me if Starship spins off other industries for vehicles not focused on Mars, but elsewhere in the solar system, or based on much longer space voyages.

The next hurdle for deep space, aside from shielding, will be power. Lower solar flux in deep space and the interest to save weight will likely see the use of more nuclear power.

Regardless, I'm much more hopeful about the space industry that I was in early February, 2003...

<comment><USER4> > The next hurdle for deep space, aside from shielding,

Zinc Bromide for radiation protection?

<comment><USER3> Probably not. It looks like that's primarily for gamma. In space, cosmic rays are much much more powerful and catastrophic for cells.

Water is actually probably the best shield, because you'll need it to support humans along the way. Gamma still is a risk but I think the concern has mainly been higher speed subatomic particles.

Anything with heavy nuclei actually produces significant and also highly damaging secondary radiation when hit by fast moving, heavy nuclei, cosmic rays.

Another interesting thing: Apollo astronauts could see sparkles in their eyes from the radiation effects of getting hit by cosmic rays travelling through their skulls.

[https://en.m.wikipedia.org/wiki/Cosmic_ray_visual_phenomena](https://en.m.wikipedia.org/wiki/Cosmic_ray_visual_phenomena)

<comment><USER4> < sparkles in their eyes

Does the iron core of Earth imply magnetic repellent of the sight of these Cosmic ray retina inducing sparkles?

<comment><USER3> No, the atmosphere blocks almost all of it. If it weren't for that, we'd be hit constantly. Their influence on weather/cloud formation is an active area of research [https://home.cern/news/news/experiments/cosmic-rays- clouds](https://home.cern/news/news/experiments/cosmic-rays-clouds)

<comment><USER5> I stood by this cosmic trays detector [1] in a station of the metro of Naples, Italy, for a few minutes. I saw quite a few cosmic rays passing through the detector.

[1] [https://www.researchitaly.it/en/news/surprise-in-naples- subw...](https://www.researchitaly.it/en/news/surprise-in-naples-subway-there- is-an-infn-cosmic-ray-detector/)

</comment></comment></comment></comment></comment></comment><comment> GuB-42 When talking about big rockets, it is hard not to talk about Sea Dragon. It was a rocket where the entire design is based on the "bigger is better" philosophy.

The design was simple. No need for lightweight, high-tech materials, because it is big. No need for highly efficient high pressure engines, just make one that is bigger. That thing would have dwarved the Saturn V. The name "Sea Dragon" comes from the fact it would have been launched from the sea, it would have been too big for a ground-based launchpad. It would have been built in a shipyard like a submarine that can stand upright.

[https://en.m.wikipedia.org/wiki/Sea_Dragon_(rocket)](https://en.m.wikipedia.org/wiki/Sea_Dragon_\(rocket\))

<comment><USER6> The Orion interplanetary ship would also have been huge - it was planned to be able to reach Jupiter: [https://en.m.wikipedia.org/wiki/Project_Orion_(nuclear_propu...](https://en.m.wikipedia.org/wiki/Project_Orion_\(nuclear_propulsion\))

<comment><USER7> An early draft of 2001 A Space Odyssey had Discovery as an Orion, but apparently Kubrick having just done Dr. Strangelove didn't want to do another film with nukes.

</comment></comment></comment><comment><USER8> Personally I think it'd be interesting to compare the expected price/weight to how much it cost to cross the Atlantic back in the 1600s. Does anyone happen to have any good references for goods/people crossing back then?

For instance, one person writes on Quora[0] that between 1600 and 1800 one could cross the Atlantic from Europe by becoming an indentured servant, working 4-7 years for someone. By looking at the average US income, this corresponds to roughly $2-300,000 per one-way "ticket".

This is somewhat comparable to Musk's aspirational price for a one-way ticket to Mars, no?

On another note, I'm sure there were discussions back then about why bother to spend months crossing the Atlantic..!

[0] [https://www.quora.com/How-much-did-it-cost-in- today%E2%80%99...](https://www.quora.com/How-much-did-it-cost-in- today%E2%80%99s-currency-to-travel-from-America-to-London-in- the-1600s-the-1700s-and-the-1800s)

<comment><USER9> I imagine indentured servitude path should be dramatically more expensive by the end of it than paying straight up -- it's like taking money from a loan shark; it's not actually a good deal -- but you don't have the resources to get anything better.

I imagine the actual cost of buying a ticket would probably be like 50÷ the cost of indentured servitude

<comment><USER10> > like taking money from a loan shark

A loan shark that owns the air you breathe.

<comment><USER9> Yes, a bad deal. But if it's the only offer on the table...

</comment></comment></comment></comment><comment><USER11> > while storage tanks can be built from local materials

Just use the starships themselves. Actually,to further reduce cost, I would design starship to be useable as a Mars habitat: even fuel tanks could conceivably be converted into living quarters,I guess. Further the efficiency by recycling other parts of the starship as building materials.

Also, most of the reasoning in this article revolves around power plant mass. I wonder how a nuclear power plant would affect the outcome.

<comment><USER12> The trouble is that the Starships need to refuel very quickly after landing to hit their return launch window. If you need to generate all the fuel right then, you need a much larger fuel plant. If you can store the fuel ahead of time,before the Starship has arrived, you can use a much smaller fuel plant, but you need storage space.

<comment><USER13> You build a version of Starship which produces fuel. You launch a fleet of them to Mars and have them operate for a year or so.

Then, you send the human-carrying version.

I think the way this is going to work, is when there are 1000 Starships on the surface, some of them with workshops, some with power plants, others with science labs, human quarters, and so on .. and they land in a big field.

Humans arrive, string them all together.

<comment><USER14> Similar to the approach seen in "Red Mars" by Kim Stanley Robinson.

</comment></comment></comment></comment><comment><USER10> Since it seems we are on the verge of having an off-planet colony, I'd like to launch a couple questions:

1- What are the colonists' fundamental rights and who protects them?

2- Under what jurisdiction will they be?

3- Who owns the air?

4- If someone can't pay for their air or food, what happens?

<comment><USER15> > _Since it seems we are on the verge of having an off-planet colony_

Has SpaceX even had a successful manned space flight yet? I don't think we're quite on the "verge" of colonizing space...

<comment><USER16> > Has SpaceX even had a successful manned space flight yet?

That flight will likely happen in the next quarter.

Meanwhile, while SpaceX has been wading through NASA design reviews and red tape (some of which is probably good for them!) for Falcon 9 + Crew Dragon, they've been hard at work on this next-gen rocket for years (the engines since 2009, the rocket itself since 2014). We will likely see a SpaceX Starship reach Low-Earth Orbit within a year, so it's time to start considering what other requirements for getting to Mars might take longer to build.

</comment></comment></comment><comment><USER17> > Synthesizing that much fuel would require about 1 MW of electricity for 500 > days, requiring in turn 5 hectares of solar panels. Per Starship, per launch > window. At 50 kg/kWe, the solar farm would weigh 50 T.

Given those power and mass requirements, would it make sense to deploy the PV in earth orbit and use it to power an ion drive? Those things need a lot of electricity to be useful, but 1 MW _is_ a lot of electricity — not the 200 MW for the VASIMR 39-days-to Mars proposal, I'm still thinking of a standard "slow" journey, but this could also mean only one LEO refuel (for powered landing) required.

</comment><comment><USER18> Two aspects in favor of mini-starships

1\. economies of scale: if you manufacture 12 engines smaller by a factor of 10, the total manufacturing cost is not going to be 20% higher, but most likely 2-3 times lower.

2\. engineering knowledge: more smaller engines means more engineers. Some of whom would leave to start their own startups, or to join Blue Origin, or Skunkworks, or some other aerospace company. That's not necessarily good for SpaceX, but it's good for humankind. Maybe some would go and fix Boeing's problems :)

<comment><USER19> Yeah, right, it must be a child game to scale by an order of magnitude the only full flow engine that ever flew in Human history...

</comment></comment><comment><USER20> This seems to completely miss the point of the Starship architecture. With orbital refueling, staging as discussed in the article, or a smaller Starship isn't something that would provide a big savings anyway.

Big Starship or small Starship, you get the same Delta-V assuming both are fully fueled. In fact, you'd probably get more Delta-V out of a large Starship since you might be able to get a better mass fraction.

</comment><comment><USER21> The 5 million per starship must be the cargo ship only. The engines alone are going to be half that cost.

<comment><USER22> I assume that's the cost when taking into account the reuses, not the construction cost.

<comment><USER23> Your assumption is totally reasonable, but wrong. That's the construction cost Musk has said he's aiming for.

</comment></comment></comment><comment><USER24> Is 'Starship' even a real thing? Last I heard, it was an empty stainless steel can ('aerodynamic model') that blew over in a strong wind. Has that changed? Are they actually going to try and make this a real launch vehicle?

<comment><USER16> The Starship Hopper flew a couple hundred meters up into the air using the new Raptor engine, hovered, and then landed. A full size prototype had a fuel tank fail a pressure test due to some bad welding. The most recent fuel tank pressure test succeeded, so it's looking like a 20km altitude test flight will happen in the next few months.

</comment></comment><comment><USER25> I have a few interesting questions ... to be fair, I've done no science or math to make a conclusion but there would certainly be a sense of irony involved.

1\. Could the green-house gases produced to launch a civilization to Mars be the final straw that breaks our eco-system's back?

2\. What are the moral implications of terra-forming Mars and moving a small population there, knowing that the population remaining on Earth is doomed?

3\. If you're willing to allow an epic depopulation of the Earth, why not stay here and let it happen?

4\. If any of the above are true, why would you expect the (current) larger population of the Earth to fund the colonization of Mars?

I realize this is a very dystopian view ... and that I read/watch too much science fiction, but if this is a novel (or a Netflix original), the Mars population moves back to Earth after it's "recovered"

EDIT: I'm not against the StarShip, SpaceX or Musk at all - in fact I'm a big fan as I was in elementary school during the Apollo missions and believe that SpaceX in particular has reinvigorated the passion for engineering and tackling big problems. This is only a Gedankenerfahrung.

<comment><USER26> I want to use a Starship to put a solar sail factory on an NEO and send the sails to Earth-Moon L1 to block sunlight to buy us some time.

If you think you can change human nature fast enough to curb climate change you should think again; introduce new energy sources that are cheaper than fossil fuels and you can make them.obsolete.

<comment><USER27> "buying some time" would be the most underwhelming use of such a technology. If you are putting large enough sunshade to change the climate, you can use it to actually control the weather, make sahara green, make siberia warm, melt greenland ice sheet in controlled way moving it to antarctic.

<comment><USER28> Making the Sahara green is a good idea, Siberia warm, much less so. Actually the thawing of the perma frost is currently one big danger, as it would release a massive amount of greenhous gases (mostly methane).

<comment><USER27> You would do it in a controlled manner so that the amount of released gases from arctic is compensated by gases absorbed by greening deserts.

</comment></comment></comment></comment></comment><comment><USER29> Im no less a science fiction fan than the next person but the whole "colonize Mars" thing is stupid and wasteful and arrogant and really pounds the message that billionaires are deeply deeply out of touch with the rest of society.

Not only will colonizing Mars never work, there's no reason at all to want to. What a dead, barren place.

And in the meantime back down to earth people are really starting to care about inequality. Meanwhile billionaires pour resources into childish flights of fancy when the world is literally burning.

Ugh. I really think billionaires have a place in our society but these sorts of projects make me understand why others question whether some people should have such huge control of resources.

No one is even visiting Mars, let alone colonizing it.

<comment><USER30> I think you'll get downvoted but I largely agree with you about the futility of the exercise. The complexity of the Earth's system for sustaining life still far exceeds our understanding, and I think going to Mars will at best turn out to be a powerful way to learn that we cannot replicate it.

The typical moral justification is that the Earth may be threatened and so it would be prudent to have some humans somewhere else in the solar system.

Well the number one threat to Earth is an impact event. If we can hypothesize a rapidly growing lift capacity, why not use that mass budget to develop a solar-system-wide system for detecting and if necessary altering the trajectory of potential impacting objects? It would be WAY better to protect the Earth than any other backup plan.

The other big threat to the Earth would be a fast gamma ray burst but that would very likely get Mars and any other human colony as well.

The reality is that people want to go to Mars for the same reason people want to go climb mountains: because it is there. Our economic system provides a very few people with the resources to pursue those dreams. Whether that takes away from everyone else depends on how you think about the economy—to what extent you believe it is zero-sum.

Personally I think we should go to Mars for the simple purpose of going—I like exploration and climbing mountains too—but not fool ourselves about establishing a new human society there. To me it's like say let's establish a new human society on the summit of Everest. Which would be way easier than doing so on Mars, by the way!

<comment><USER31> > _Well the number one threat to Earth is an impact event. If we can > hypothesize a rapidly growing lift capacity, why not use that mass budget to > develop a solar-system-wide system for detecting and if necessary altering > the trajectory of potential impacting objects? It would be WAY better to > protect the Earth than any other backup plan._

Detection is a solved problem.

Altering the trajectory of an asteroid requires a large amount of lifting capacity to be available on relatively short notice. That is, it has to already exist when the crisis is identified.

Congratulations. You've identified a positive externality of Starship.

<comment><USER32> Conversely, of course, the trajectory of a non-threatening near-Earth asteroid can be known well in advance, but there's no obviously benign reason for anyone to bring a lot of delta-v to one.

So having a steady traffic in commercial heavy lift could be a positive externality as well, for whoever wants to find a close-call asteroid that has been recently marked as 100% safe and give it a little nudge.

<comment><USER31> Making it easier for mustache-twirling supervillains to destroy Earth is not a concern of mine, personally.

Weaponizing smallpox and distributing it in major airports is the lower bound of effort. Anything that exceeds this is not worth worrying about.</comment></comment></comment></comment></comment>


Super small Docker image based on Alpine Linux - <AUTHOR> https://github.com/gliderlabs/docker-alpine/tree/d751bb2bcacd2a6536280cdc7d313bc6584aa40e <comment><USER3> Size is such a tiny concern. I'm surprised people make such a big deal about it. When all of your images use the same base, it's only a one-time cost anyway.

And there are FAR more important concerns:

\- Are the packages in your base system well maintained and updated with security fixes?

\- Does your base system have longevity? Will it still be maintained a few years from now?

\- Does it handle all of the special corner cases that Docker causes?

That's why I use [https://github.com/phusion/baseimage- docker](https://github.com/phusion/baseimage-docker)

<comment><USER4> Sorry - but the phusion images are unnecessarily bloated. The existence of the them has been defended by 'fixing' many so-called problems that are actually no problem at all - or at least shouldn't be a problem if you know what the hell you're doing. No well, written software won't spawn zombie-processes - sorry. Reaping dead child processes is something pretty basic if you're using "fork".

And then - a logger daemon. Guess mounting /dev/log into a container is too complex if you care about this?

Logrotate - sure, useful - but if you care about logs and aren't sending them to your logger daemon or /dev/null, you probably want to store them externally - in a volume or mounted host directory - and have a separate container taking care of that.

The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong - unless that container's only job is running SSH (which can be useful for example for Jenkins build slaves).

Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs.

That is for me the essential thing about containers: separate everything. But sure, you could treat containers as a special VM only for one service - <USER2> is going to stop you. I however prefer isolating every single process and explicitly telling it how to communicate with other processes. It's sane from many perspectives: security, maintainability, flexibility and speed.

<comment><USER3> Yeah that's cool, but my main point is that images which make use of the stable debian package system and are actively maintained are a better approach than an image that makes use of more obscure technology that could be abandoned, or worse, maintaining your own container infrastructure.

> No well, written software won't spawn zombie-processes - sorry.

And yet it happens.

> The ssh server... Containers are no vm's, if you have to log in on a > container running in production - you're doing something wrong

The SSH server is incredibly useful for diagnosing problems in production, so I for one applaud it (although it's not really necessary anymore with docker exec).

> Cron - again - same thing: run in a separate container and give access to > the exact things your cronjob needs.

Or just run it in-container to keep your service clusters together.

> That is for me the essential thing about containers: separate everything.

It's a question of degree. Where you draw the line is almost always a personal, aesthetic choice.

<comment><USER5> >And yet it happens.

I can understand that argument. It's an edge case, and building a sane Dockerfile on top of Alpine that runs applications through S6 (or runit), which developers use for their applications is the way to go for me. This is what phusion baked in?

>The SSH server is incredibly useful [...] (although it's not really necessary anymore with docker exec).

It's an additional attack vector and, by your own admission, it's useless. docker exec has been baked into docker for over a year.

>Or just run [cron] in-container to keep your service clusters together.

Per-container cron sounds painful. Then you have to deal with keeping every container's system time in sync with the host (yes, they can deviate). Not only that, if you have a periodic cron job that runs an app to update some database value, scaling becomes bottlenecked and race conditions (and data races) can get introduced. You are prevented from running multiple instances of one application to alleviate load because the container has the side-effect of running some scheduled job. Cron should be separate.

One can also choose the degree to which they want to throw out good practices that prevent them from repeating others' mistakes.

<comment><USER6> Have you ever seen a container's system time deviate from a host? This makes sense with boot2docker since it runs in a VM but I can't think of a reason this would happen in a container.

<comment><USER7> Yes, time keeping is up to the host kernel. The time can't deviate in the container.

</comment></comment></comment></comment></comment></comment><comment><USER8> I like this. It makes a lot of sense to use something like Alpine Linux for Docker images. If you're going to build a 'process container' like Docker -- something that does not encourage the same mindset as a traditional container or VM -- it makes sense to start with a stripped-down operating system and then build it up to be exactly what you need.

Perhaps loud suggestions like these are necessary due to a bias in the group that uses Docker. 20% people that really know what they're doing and have chosen Docker for a specific reason, and the hangers-on who try to emulate them by using the same tools.

Docker is an interesting, useful, and extremely overhyped tool. I may be wrong, but I feel like its popularity has caused a bunch of people who don't really need Docker to use it. Besides popularity, they can't really explain why they are using it over something like LXC or FreeBSD jails.

I imagine (again, no data to back this up) that this same large percentage of people are also the ones that just keep using the default Ubuntu image once they finish the "Get Started" tutorial.

I'm glad to see suggestions like this gaining popularity. If you're going to make the most of Docker, I think there's value to be found in really committing to the mindset of a 'purpose-built, no-frills environment for running a single process.'

From what I can tell right now, a huge number of people are using Docker "sort of like a VM but you need more of them, and Git is integrated and you have to tell it to do something or it stops running".

</comment><comment><USER9> I think one of the main problems with Alpine adaption is due to how the official run-times are set up on the Docker hub.

\- Python-slim uses debian:jessie

\- Ruby-slim uses debian:jessie

\- Node-slim uses debian:jessie

Your web application is probably going to pull in from one of those run-times which automatically sets you up to use jessie.

I'd also like to see someone take a random large project and see if their native extensions compile under Alpine without any other dependencies and to compare the final image size of a real world web app with alpine vs jessie.

It's sort of a micro benchmark to compare it like this because a project with 75 gems/packages and a couple of native extensions that need to be compiled will drastically increase the size of your image, with or without Alpine.

I absolutely do think it's worth optimizing your images, but this seems like something that may end up being quite personal to your app because it will require a bit of tinkering to get everything your app needs to work. I also wouldn't bother doing it until I was constantly pulling them down in production to auto-scale.

<comment><USER10> actually, in this case it totally makes sense. the issue is that alpine uses musl, and many things only compile for glibc. if you're writing in any of those languages, chances are you're going to install a library that requires some c compilation (yaml parsing, database libraries, numeric processing, etc) and this becomes an issue

*edit: which is what you were saying all along, and this didn't sound enough like "yes I agree"

<comment><USER11> Have you had trouble with any specific libraries? We're using alpine-based images with statically-linked binaries and haven't had any issues compiling third-party libs. One area you're likely to run into trouble is RPC, but I only discovered that in messing about with something experimental.

The real problem with musl in these environments is its DNS behavior, particularly if you're running on a platform like Kubernetes that uses DNS search domains for service discovery. Not hard to work around, but the workarounds are a bit, er, inelegant. See [http://www.openwall.com/lists/musl/2015/09/04/4](http://www.openwall.com/lists/musl/2015/09/04/4) and [https://github.com/gliderlabs/docker- alpine/issues/8](https://github.com/gliderlabs/docker-alpine/issues/8)

<comment><USER12> Yes, I found out Rails containers were problematic with Alpine because therubyracer would segfault when run under musl. It appeared to be a known issue at the time, though I haven't looked into whether it's fixed.

</comment></comment></comment></comment><comment><USER13> Alpine is a great example of a lightweight, container first approach.

Please stop using Ubuntu as your base images people!

There's no excuse for using a full Linux distribution (especially one that's really aimed at the desktop) for a container unless you're doing a staged migration or something along those lines.

* Edit: Formatting.

<comment><USER14> > Please stop using Ubuntu as your base images people!

I think Ubuntu images are a symptom of a much more serious disease: Ubuntu usage in general. Ubuntu is not really concerned with software freedom (its origin was Debian-plus-proprietary-blobs), nor does it strongly care about privacy (although it can be shamed into doing the right thing), nor does it care terribly much about getting along with everyone else (c.f. Mir vs. Wayland).

As a distro for my family, it's fine. But I expect my fellow developers to run something which indicates more technological prowess than does Ubuntu: Debian or Arch or Gentoo or Slackware are all good choices for different reasons.

<comment><USER15> Except that Ubuntu provided a decent Linux on my desktop that is relatively polished to be used by a normal human being.

I did more than Debian, Redhat, Mandriva, Gentoo and other could do even though they had a longer head start.

Once I run that on my desktop, I don't really want to learn another distro, I'll just use that the server as well.

> run something which indicates more technological prowess than does Ubuntu:

There one difference between how I develop -- I don't develop to show my technological prowess, in fact when I do that, I start making mistakes and generate complicated and hard to maintain systems.

<comment><USER14> > Except that Ubuntu provided a decent Linux on my desktop that is relatively > polished to be used by a normal human being.

They did, and they should be congratulated for that. I like to believe that Debian learnt a hard lesson from its long delay.

> Once I run that on my desktop, I don't really want to learn another distro, > I'll just use that the server as well.

Ubuntu on the server has essentially been Debian unstable-ish. It's not really a case of learning another distro.

Your argument would also apply to running OS X Server, and I don't think anyone outside of Cupertino thinks that's a good idea…

> There one difference between how I develop -- I don't develop to show my > technological prowess

If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like running Windows: it's popular; it's not really _wrong_ ; it even has advantages; but running Windows doesn't indicate any level of competence. In Bayesian terms, P(competence | Ubuntu) < P(competence | ~Ubuntu).

<comment><USER15> > Your argument would also apply to running OS X Server,

And it does! Old work had a few in house servers with OS X. If it was free, we'd see a lot more of it, I am convinced.

> If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like > running Windows: it's popular;

Isn't the ability to quickly ship a stable, reliable product that customers are happy to pay for, a better sign of competence than say picking Slack or FreeBSD for server for now good reason except to show competence?

The question is who is the show of competence for? Other developers, customers, management? I can see developers boasting who knows how to configure and run obscure distros and use exotic functional languages and that's cool. I was just saying after a while you realize that show of prowess is not what is important.

<comment><USER14> > Isn't the ability to quickly ship a stable, reliable product that customers > are happy to pay for, a better sign of competence than say picking Slack or > FreeBSD for server for now good reason except to show competence?

Sure! What I'm saying is that if someone is unable or unwilling to run something other than Ubuntu then I suspect he is less likely to be able to build that stable, reliable product in the first place.

It's like how I suspect I'm likely to have a better meal if the cook prepares it from fresh ingredients than if everything comes pre-made off of a truck.

</comment></comment></comment></comment></comment></comment><comment><USER16> Why not? Let's run the numbers.

* [http://wiki.alpinelinux.org/wiki/Special:ActiveUsers](http://wiki.alpinelinux.org/wiki/Special:ActiveUsers)

14 active users. That is not a lot. In fact, that is tiny. Maybe their redmine has more? [http://bugs.alpinelinux.org/projects/alpine](http://bugs.alpinelinux.org/projects/alpine) says 16 users in the 'developers' group.

But maybe they're very pro-active on the mailinglist? Let's check their security announce list:

* [http://lists.alpinelinux.org/alpine-security/](http://lists.alpinelinux.org/alpine-security/)

1 message. From 2009. Hmm. Well, their alpine-devel list then? 5110 messages in 10 years. 9 Messages per week. By comparison: the debian developers mailinglist had 492 messages in November 2015 alone.

So even though Alpine Linux looks nice and lean, it is maintained by a very small group of developers.

Now. If building your own container were very very hard, I'd sure understand grasping for something like Alpine.

But here's how you build an Ubuntu Trusty container:

         debootstrap --variant="minbase" --include="systemd-sysv" trusty ${TMPDIR} ${UBUNTU_MIRROR}
         chroot ${TMPDIR}
         dpkg-divert --local --rename --add /sbin/initctl
         ln -sf /bin/true /sbin/initctl
         dpkg-divert --local --rename /usr/bin/ischroot
         ln -sf /bin/true /usr/bin/ischroot

Just tarball it and throw it in 'docker import'. Your done.

Need to add or remove software? Use Ansible to configure specific containers with specific confgurations.

Need security-updates? chroot into the folder, apt-get update; apt-get upgrade.

Throw the new tarball into docker import again. You use long-term supported methods and systems. There are tens of thousands of packages. Bazillions of PPAs to use.

Edit: typo in codesnippet

<comment><USER17> OpenBSD is likewise developed by a small number of users. A Linux distribution is arguably easier to maintain for a smaller group because the core components are developed upstream.

Alpine does well at making security measures like SELinux accessible. Meta- distributions like Debian serve a different purpose.

<comment><USER18> Alpine Linux supporting selinux is only relevant in this discussion if you run Alpine as the container host. To the Alpine containers it is of no consequence.

OpenBSD has more than a great track record on security, maintainability, community spirit. As has Debian.

Alpine, after ten years, was simply not on the radar as a distro.

It is merely developers that do not seem to care about the actual systems these containers are built from that find Alpine interesting.

It's small, so even on a 3g connection you can download those containers and get the functionality a developer seeks. Fast. And that is fine. It gets alpha code out in a timely manner without too many resources.

Just do not pretend that this way of working will deliver sustainable, maintainable and consistent code that will work just as well inside as well as outside containers.

Maintained, secure, stable and proven distributions have served any purpose given in the past. From embedded systems to HPCs, from trading floors to satellites.

Saying any of the "old school" distro's are a bad fit for running in a container is a display of ignorance at best.

<comment><USER19> quantity-of-people-involved is a terrible, irrelevant metric for code quality.

<comment><USER20> Maybe, but it's a fantastic metric when guessing how many undiscovered bugs and security vulnerabilities there are.

GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.

<comment><USER19> Nonsense, it's just a straight up ridiculously uncorrelated, terrible metric. Which would you say has been more buggy and broken, djbdns or php? nacl or mysql? qnx or openssl? windows 95 or ping? Which one of each do you think has had more "discussion and updates"? Which one of you think is better code?

Code quality has nothing to do with how much jibber-jabber there is on some mailing list, nor with how widely used a piece of code is. It has to do with the actual code.

In the case of Alpine Linux (which I've never used), probably 50% of the code is the linux kernel itself, another 20% is musl and busybox, and the rest is random gnu utilities. Which of those things is 'low quality' and has 'undiscovered bugs and security vulnerabilities' that broken, random, low- quality high-politics tire fires like most linux distributions don't have?

But conversely, is it not intrinsically obvious that not having the grotesque pile of random freshman desktop apps and terrible init systems that other distros have, could reduce the attack surface to a point where a single organization could conceivably make sense of it?

<comment><USER16> You are correct on all points concerning the quality of code of Alpine Linux. I do not doubt it. But it is irrelevant to the discussion. The Linux kernel is not part of the containers that are based off of Alpine. That is the whole point of this level of virtualization: sharing the kernel.

Furthermore, the problem I have with Alpine-based containers is that using those as the basis of tooling used for building your own product, your own product will have a hard time becoming maintainable, sustainable an secure.

I've had developers doing make; make install in Dockerfiles just because Alpine doesn't have some library or version packaged.

Containerization brings all manner of sweetness to the table, but the current way it is used is a throwback to 1998.

Not having desktop software inside a small container does reduce the attack surface. Debian, Ubuntu, Centos can handle that requirement just fine. What is your point?

<comment><USER19> Your sentences don't make sense next to each other. If you're unable to point to any fault in the quality of Alpine Linux, then why are you trying to create FUD about how Alpine Linux is unmaintainable, unsustainable, and insecure? Could you maybe, instead of just repeating it over and over without evidence, provide some example of how Alpine is concretely any one of those things?

While you're at it, please show me the Debian, Ubuntu, or CentOS distribution that doesn't have desktop bus installed. I'll wait.

<comment><USER18> Appologies if I am unclear.

> why are you trying to create FUD about how Alpine Linux is unmaintainable, > unsustainable, and insecure?

I never tried to make that claim.

What I am trying to say is that if YOU built YOUR software against Alpine, IT will be hard to maintain/sustain/insecure. Because your software will probably have dependencies. Dependencies not found in Alpine. And now you have to maintain and test those dependencies. You'll have to keep informed on all the security advisories of those dependencies. All the changelogs. And by then, you've started to reinvent wheels that the fine folks of Debian, Ubuntu, Centos have invented already.

That is a resource drain on companies that is inefficient and cumbersome with little to no added value.

> While you're at it, please show me the Debian, Ubuntu, or CentOS > distribution that doesn't have desktop bus installed.

A container is not the same beast as a distribution. It does not have the same requirements. It is just a tarball. And you can throw anything into it, or out of it.

I'm just saying to use debootstrap to throw stuff in that tarball so you have the benefits of an enterprise-level, proven distribution, instead of using this something that has not yet proven itself. So if you ever need to take your software OUT of the container and run it on an AWS instance, or on your own hardware, you'll have no problem with it.

In short: I see no added value for Alpine. It does not address my operational concerns, and raises a bucketload of new ones when I compare it to Debian, Ubuntu or Centos.

<comment><USER19> That makes a little more sense, thanks. Although, I will disagree that your software will probably have dependencies that are not in Alpine; I tested it out and installed a large software stack and found no such issue. And I think you radically underestimate the crumminess and incompetence of the, e.g., debian package system. Nevertheless, good luck with your systems and Merry Christmas.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Alpine Linux has been a fantastic choice for docker images. Small, light and has a package manager that keeps getting better. I had one big snag using it with kubernetes, DNS based service discovery didn't work ([https://bugs.alpinelinux.org/issues/4371](https://bugs.alpinelinux.org/issues/4371)). The work around was fairly simple and used env vars, but if you dig on this bug I'm not sure when (if ever) that will get fixed.

</comment><comment><USER22> Interestingly, alpine doesn't use systemd.

<comment><USER23> I'd like to point out that a docker container, usually doesn't run an init system. [I get that OP was talking about standalone alpine]

<comment><USER24> We use phusion baseimage, which does have an init system (runit). We have been happy with that. Our customers are not ready for us to provide our product as 6 distinct linked docker containers. The image we build is more like a VM in that it contains multiple processes (pg, nginx, and some apps/services).

<comment><USER25> If you're providing an all-in-one solution like that, it sounds like you would be better served by just providing an OVF image to them.

Or better yet, keep 6 distinct containers like you should, and use docker- compose to spin them up together. Makes upgrades easier because you can simply point to a newer version of whatever service containers you're using without having to take out everything.

If you're using containers as a VM, you're essentially adding overhead for no good reason.

</comment></comment></comment></comment><comment><USER26> Alpine is so cool. grsec, musl libc, openRC. If you are sad about the direction most distros are headed, Alpine represents a good stab at "the way things should be".

</comment><comment><USER27> Love Alpine. The biggest use case I've found for small images so far is for testing a microservices system on Travis or a similar CI. You package each of your services in a container, then use docker-compose1[1] to start everything up. The faster it can pull down the images, the faster your CI build runs, so size can be important here.

One interesting thing about Alpine is that it uses MUSL[2] for its libc. If you want the bare minimum image size, you can use a scratch or busybox image and statically compile your binaries[3].

[1] [https://docs.docker.com/compose/](https://docs.docker.com/compose/)

[2] [http://www.musl-libc.org/](http://www.musl-libc.org/)

[3] [http://blog.xebia.com/create-the-smallest-possible-docker- co...](http://blog.xebia.com/create-the-smallest-possible-docker-container/)

</comment><comment><USER28> For simple containers, this is a great base image. I have been using it for an rsync server for a few months. [https://github.com/Thrilleratplay/docker-ssh- rsync](https://github.com/Thrilleratplay/docker-ssh-rsync)

The only problem is that the package library is not as extensive as Ubuntu or Arch. [https://pkgs.alpinelinux.org/packages](https://pkgs.alpinelinux.org/packages)

</comment><comment><USER29> For anyone who is using Digital Ocean, I have written up a little guide on how to install Alpine directly onto a droplet:

[https://github.com/bontibon/digitalocean- alpine](https://github.com/bontibon/digitalocean-alpine)

</comment><comment><USER30> When packaging up various npm components, BusyBox was recommended to me as a great solution for creating containers with a low overhead -- I eventually stumbled across Alpine (which is built on top of BusyBox) and have been really happy.

Alpine has a tiny footprint, which is great for wrapping Node.js which itself is tiny; But wait, there's more, Alpine has a great package-manager similar to apt, called apk -- this is what sold me on it over BusyBox.

</comment><comment><USER31> Alpine looks great and has grsecurity baked in.

I've been struggling to find a lightweight PHP image, they're all huge. I'm starting to see a big advantage for Go in the container world where I've seen containers 10MB in size instead of the 200-600MB I'm getting in Python, PHP or Ruby. The nature of these dynamic languages and their libraries I guess.

<comment><USER18> Grsecurity is a patch on Linux. The kernel. As far as I know this does nothing for a container unless your container host runs Alpine.

</comment></comment><comment><USER32> Having been running Docker in a production system now for 6+ months, the size of the images is really a non-issue if you're using the Docker layer cache effectively. We use all of the official language images and builds are under a minute, with deploys happening in ~5-10 seconds (machines generally only need to download a single layer).

</comment><comment><USER33> Alpine linux is great, however lack of JDK (needed for Java/Scala/Clojure/JRuby/Groovy projects) keeps me from using it. Hopefully this can be fixed soon :)

<comment><USER34> Why can't you build an image with the JDK based on Alpine and use that as your base image for everything else?

<comment><USER10> glibc. alpine uses musl, and from what I understand this is actually not a thing you can do very easily. not that I use jvm in an way (thankfully)

at the very least, it's probably not worth spending too much time on, because you'd get better optimisations from doing other things

<comment><USER35> Alpine has Sable, and you can also compile your own OpenJDK (if it doesn't have it already). There are plenty of reasons to use Alpine and just as many not to use it, but lack of a JVM isn't one of them (Pretty much same with Docker- it added nothing of apparently value to me more than that LXC did (or BSD jails like someone above me mentioned), but I'm sure it provides value to some people.)

</comment></comment></comment></comment><comment><USER36> What's the difference between FROM gliderlabs/alpine & FROM alpine:latest ?

Love Alpine though I did run into an annoying nginx permission issue: [http://lists.alpinelinux.org/alpine- user/0002.html](http://lists.alpinelinux.org/alpine-user/0002.html)

<comment><USER37> They're more or less the same, just that gliderlabs/alpine includes the apk- install convenience script that removes the apk cache for you.

Although with 3.3 that isn't necessary anymore if you use the --no-cache flag.

</comment></comment><comment><USER38> In what context would the 100MB-ish saved help a lot? It feels like such a tiny amount compared to modern storage capacity (the cheapest SSDs are like 100GB). And I wouldn't think of tiny devices (raspberry pi, etc) as good candidates for hosting lots of docker containers.

<comment><USER39> It's a good practice nonetheless

It's not about only size (though getting something that's 10x-20x smaller is helpful)

It's about getting only what you need, reducing security issues, disk usage, memory usage, etc

<comment><USER38> Makes sense.

<comment><USER40> Impressive, I can't think of another time I've seen someone just acknowledge a response like that on the interwebs. Most Impressive.

</comment></comment></comment></comment><comment><USER23> But there are cases in which you'll have to decide not to use alpine. If your application and library needs glibc support, you are pretty much your own - and you have to patch the build scripts to use the busybox tools rather than the gnu ones [eg, sed and other tools].

<comment><USER41> You can install the Gnu tools in alpine, at which point they replace the busybox versions. They are all packaged up, just not installed by default.

</comment></comment><comment><USER42> Alpine Linux looks great. Unfortunately there is an outstanding issue ([https://github.com/gliderlabs/docker- alpine/issues/8](https://github.com/gliderlabs/docker-alpine/issues/8)) with its DNS implementation that makes it tough to use in Kubernetes or similar environment that uses DNS for service discovery.

It does look like a fix is on the way though.

</comment><comment><USER43> Interesting to see Alpine, which began life as an embedded linux project is now being used for server deployments. This has to be a win for open source style of projects. Also reminds me of the time when Kroah-Hartman mentioned that people working on embedded linux ended up improving power efficiency of Linux saving the data center guys tons of money.

<comment><USER44> > Also reminds me of the time when Kroah-Hartman mentioned that people working > on embedded linux ended up improving power efficiency of Linux saving the > data center guys tons of money.

This right here. There's so many here decrying Alpine who can't see the bigger picture: having options for different Docker deployments will create possibilities currently undreamt of. Maybe you can't use it on your project; fine, keep on keepin' on with what suits you best, but don't knock another project just for a different approach, especially when it might have huge benefits to the overall environment in the future.

</comment></comment><comment><USER45> Fun fact: the creator of Alpine Linux, Natanael Copa works at Docker :)

</comment><comment><USER46> Although not clear from the GitHub link, this is actually the official Docker image of Alpine: [https://hub.docker.com/_/alpine/](https://hub.docker.com/_/alpine/) \- see the Dockerfile links.

</comment><comment><USER47> If you like Alphine and it works for you great, but it's not always an option. If you use Ubuntu and you still want small containers there are a number of options. DockerSlim ([http://dockersl.im](http://dockersl.im)) is one of these options. A sample node app container build from Ubuntu is around 14MB.

<comment><USER48> Is that used heavily in production? Looking at a container based on usage, and slimming sounds very risky to me.

</comment></comment><comment><USER49> Would Alpine be the best idea in-general to use as a replacement for Ubuntu even when not using Docker? What are you giving up by going with Alpine?

Since I've never even heard of Alpine before today, I'd say you are at the very least giving up on a community of users and support, but maybe Alpine will gain a large community and this is the start?

</comment><comment><USER50> It would be nice if most of the package manager and basic shell commands could be kept out of the docker image too. I think this would require a utilities image that could be mounted during the build of the docker image. Some images would still require a shell for startup scripts or other tasks, but they can include them when needed.

</comment><comment><USER51> > Alpine Linux has a much more complete and update to date package index

> ...

> (5/5) Installing nodejs (0.10.33-r0)

They should really update their examples, as that makes it look worse than it actually is (the current repository contains 4.2.3).

And while I'm at it: "use % as a wildcard" on the package page? Really?

</comment><comment><USER52> What I like about Alpine is grsec being bult in, and personally I like grsecs new distribution model. Remove openssh, put tinyssh (curve25519) ossec, hiawatha, a few ither tweaks and you have a pretty secure system. I wish they were more gnu friendly but still...

</comment><comment><USER53> Anybody using Alpine for a minimal Desktop OS? How does it compare to something like Arch?

<comment><USER54> I gave it a try, but it's a bit less well documented and has less packages than Arch.

If heading this route, perhaps Guix or Nix are a nice option too. As you can get something declarative and with traceable builds.

I'm hoping a minimal distro that has a nix-like package manager gets mainstream soon.

<comment><USER35> You can use the Guix package manager on top of any distribution and get declarative builds. [https://www.gnu.org/software/guix/manual/html_node/Invoking-...](https://www.gnu.org/software/guix/manual/html_node/Invoking- guix-package.html) Like the main GNU page says, it's not distribution ready, but it's close. In fact if you run it on top of Arch (just install the minimal requirements via pacman, then defer to guix) or Alpine you've pretty much got your minimal distribution with declarative package management.

</comment></comment></comment><comment><USER55> Of course all the HN comments on a page about making a small docker image are just bitching about the person making a small docker image because of <reasons> that would all make it not a small docker image any more

</comment><comment><USER56> It's been great for us. We use it for deploying applications such as curl or netcat in containers without overhead of Ubuntu potentially being downloaded onto a host.

</comment><comment><USER57> Alpine's size combined with its simple package manager is great, I use it for easy image pull, but of course it lacks some packages.

</comment><comment><USER58> Except, well, I don't care. All my images derive from ubuntu, so I pay the download cost once, due to docker having this whole delta thing going on, and storage cost really isn't a problem. Developers know how to apt-get usually, so that's less support cost on me. In fact, most of them run ubuntu themselves, which is a massive help with dev to prod parity. Oh and of course, there are more packages and a whole lot more forums/community etc etc.

<comment><USER37> > so I pay the download cost once

Not if you're spinning up new hosts via autoscaling.

<comment><USER58> Sure. I'm still paying it once per box lifetime, which really isn't too bad. And given I'm orchestrating stuff etc etc, I can use fairly large boxes and get quite a lot of work out of one lifetime.

</comment></comment></comment><comment><USER59> Alpine Linux has packages for Inkscape.

This runs against the notion of minimalism in the context of a harness for containers in my view.

</comment><comment><USER60> I'm currently using rancherOS, it's awesome!!

</comment><comment><USER61> It comes with its own package format, naturally.

</comment><comment> mickael-kerjean Sounds great. Will definitely give a try !

</comment><comment><USER62> For anyone wondering what "APK" is, I think it's the Android packager. Interesting choice!

[https://en.wikipedia.org/wiki/Android_application_package](https://en.wikipedia.org/wiki/Android_application_package)

<comment><USER63> Different apk format. Alpine linux apk is just a tar.gz of a signing key, .APKBUILD file and the files rooted in /

<comment><USER62> Whoops, yeah.

[http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package](http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package)</comment></comment></comment>


Italian lawmaker wants to make it a crime for parents to feed their kids vegan - <AUTHOR> https://www.washingtonpost.com/news/morning-mix/wp/2016/08/11/an-italian-lawmaker-wants-to-make-it-a-crime-for-parents-to-feed-their-kids-vegan-diets/?wpisrc=nl_mix&wpmm=1 <comment><USER2> Finally! Good to see this since it's clear that some people don't understand.

Arguing with them is pointless. I guess it takes a law.

<comment><USER3> Priorities are way skewed

Obesity rates in Italian two-year-olds are the highest in Europe with a rate of 42%.

[https://en.wikipedia.org/wiki/Obesity_in_Italy](https://en.wikipedia.org/wiki/Obesity_in_Italy)</comment></comment>


The Halving of the Centre: Covid and Its Effect on London Property - <AUTHOR> https://zwischenzugs.com/2020/07/25/the-halving-of-the-centre-covid-and-its-effect-on-london-property/ <comment><USER2> Sadiq Khan should be worried by this. TFL has been blowing money on cycle schemes and is under a mountain of debt. They have been trying to bring in money from the ULEZ, Congestion Charge, but if traffic declines...

</comment><comment><USER3> My question is - if 50% of people can/will work from home, but everybody in the office needs twice the space, on average, shouldn't demand stay the same rather than halving?

</comment><comment><USER4> Related: [https://news.ycombinator.com/item?id=23950599](https://news.ycombinator.com/item?id=23950599)</comment>


Failed many times before raising $13M on Kickstarter - dnt404-1 http://www.washingtonpost.com/news/the-intersect/wp/2014/08/28/ryan-grepper-inventor-of-the-coolest-cooler-failed-many-times-before-raising-11-million-on-kickstarter/

<comment><AUTHOR> This article confuses success with raising money. Success will be raising money, and then manufacturing and shipping 70,000-odd coolers to the satisfaction of 60,000-odd people within the next 4 months.

Crowdfunding projects in general don't have a sterling record of actually fulfilling shipments on time and to spec.

<comment><USER2> _This article confuses success with raising money._

And you're confusing a single event with the entire process of running a project. The fact is raising money is a success, because a success is simply a positive event. You need a lot of them to successfully complete a project. Equally, failure is an event - you can have lots of failures and still succeed.

<comment> UVB-76 This is just a dispute over terminology, but to succeed is to achieve an aim or purpose; unless your aim is simply to raise money, you haven't achieved success at that stage.

Even if, for the sake of argument, we take your definition of success as simply a positive event, I would dispute the implication that raising $13m in this manner is necessarily a positive event.

The inventor hasn't accrued $13m with no strings attached; he has accepted the money in lieu of an obligation to deliver product. Whether entering into such an exchange is a "positive event" or not for the inventor depends on whether he can uphold his end of the bargain.

<comment><USER3> I don't understand this line of thought at all.

For this guy a step to get to whatever his goal is was to raise funding on Kickstarter. He was successful in that.

</comment></comment></comment></comment><comment><USER4> Can you imagine going to the beach and hearing someone using a blender every 15 minutes!

I read about this sort of thing the other day. You always hear about the few successes and people who struck it rich. They kept trying and never gave up, but you never hear about the 10 million other failures. People ruin their lives trying to fulfill dreams or ideas that weren't worth pursuing from the beginning and pay dearly for it. Empty bank accounts, ruined credit, relationships, etc.

<comment><USER5> What a crazily negative comment on a cool story... So are we to conclude that people shouldn't pursue their dreams?

There are really two kinds of dreams: Dreams of arrival, which involve riches and fame and usually end in sorrow; and dreams of process, which involve the simple liberty of doing something interesting with your life. That's the kind of dream everyone should have access to -- the real American dream if you will.

I know Ryan personally. We grew up together. He "failed" for a long time and it didn't ruin his life. He had a great wife and two kids even after many "failures." But his dream was a dream of process. He was already doing what he enjoyed before you heard of him.

Actually, almost all of us are surrounded by people who haven't struck it rich yet. We're swimming amid the 10 million "failures." Some feel they are failures because they're not Jennifer Lawrence; some feel they are failures because they're trapped in an awful job; and some only appear to be failures, because you haven't heard of them yet. But they're already doing what interests them, and they don't feel like failures at all.

I'm the third kind. Ryan was the third kind until a few months ago. We should try to celebrate him, not ignore what he did.

<comment><USER6> But I understand the OPs point.

I'm frequently reminded of Bulletball [https://www.youtube.com/watch?v=WOOw2yWMSfk](https://www.youtube.com/watch?v=WOOw2yWMSfk)

Guy gave up pretty much everything, job, home, family, 25+ years of his life, to come up with a very mediocre table sports game.

It's hard to parse good ideas from bad ideas. I hope this is a good idea, but lots of people chase bad ideas for far too long.

It turns out Bulletball has found a niche in handicap therapy, which is awesome. But it's been a really hard road to get there.

<comment><USER7> 2 minutes into that video and I am incredible stressed out.

</comment></comment></comment></comment><comment><USER8> What a confusing product! Its like a swiss army knife in a cooler, as in it does many things you are likely to rarely use, except everything needs electricity.

<comment><USER9> It strikes me as something that will do a lot of things poorly, rather than a few things really well. I want a cooler that's big, waterproof, has wheels and strong handles. If I want music, or for some reason a blender, I'd much rather have dedicated appliances. Weak/cheap blenders are _terrible_ , basically anything less than $100 winds up being more frustrating than useful. I can't imagine that the battery powered DC blender in this cooler is going to be a winner.

<comment><USER10> In his prototype he used an 18v angle grinder, which I think would do a decent job blending. Given the blender setup seems to be one of the key features, I think more of the feature budget will go towards the blender. If they upgrade to a higher rpm motor for production, I believe it would be sufficient for making drinks.

Prototype build: [http://www.instructables.com/id/Cooler-with-Blender-and- Blue...](http://www.instructables.com/id/Cooler-with-Blender-and- Bluetooth/?ALLSTEPS)

</comment></comment></comment><comment><USER11> Just saw the ks video, is just me or did anyone else get a big infomercial vibe from it? is like I was waiting for Billy Mays to show up and say _" Hi I'm Billy Mays and this is the Coolest!"_

Aside from that it's a relatively simple product that harks back to the age of all-in-one solutions like Tvs with VCRs built-in, microwave ovens with toaster and coffeemaker, and who can forget that boombox with a Sega Genesis?

<comment><USER12> Boombox with a Sega Genesis?

Want.

<comment><USER13> [https://imgur.com/a/SMb74](https://imgur.com/a/SMb74)

</comment></comment></comment><comment><USER14> I'm surprised none of these break-out Kickstarters have sold their product to an established consumer products company, who would handle the Kickstarter fulfillment and then sell the product at retail

Because it's pretty clear that the people who run these products generally have no idea what they are doing when they get 100x the money they wanted.

<comment><USER15> I'm sure this guy has been approached by Coleman or other camping related companies looking to purchase the product. I imagine the inventors think "I've had success up until now, I can keep going." And I would agree with them. Why not continue to try and go on your own? The nature of Kickstarter is that you have to try, but if you fail, you don't really owe anyone money.

<comment><USER16> Those product sectors are not known for compensation of inventors, and presumably he would like more revenue than the $1 unit cost Chinese assemblers or the $8/hr walmart shelf stocker. Not a high margin business.

I don't think that supply chain has the institutional memory and skills to ship anything other than large quantities of traditional, by the standards of their field, commodities.

The primary effect of getting a big company involved would be giving the gray market Chinese a big head start, so people can buy the product for 50% off on dx.com and related sites.

These reasons probably are what discourages the megacorps from entering this small field, or rephrased, those are the reasons why he's got something new instead of competing with existing mfgrs.

</comment></comment></comment><comment><USER17> I'm interested in finding out about how you get prototypes made. Do you need special training in some field? I take it there are several fields. At the moment I'm only implementing my software ideas. Have an EE degree though.

<comment><USER18> Prototype SMD boards are easy. Much easier than buying caustic chemicals and doing it yourself.

Molded plastic has traditionally been harder since you needed a mold injection machine and doing a prototype mold is hardly cost effective. But with 3D printing even the local Staples can print you prototype now.

The complication for most people has been the 3D software. They are still complex and except for the most basic of shapes requires days of intense training and practice. A lot of people have a hard time converting a mental 3D image, to a 2D display, and back to 3D.

<comment><USER19> Exact opposite for me. Getting fabbed boards where I live takes forever (and is expensive) so I etch my own. Populating an SMD PCB takes forever, but, no interns for me as a small indie so I work in my basement till 3am with tweezers and a hot soldering iron.

Injection molding is actually super cheap in volume -- the expensive part is the metal mold which costs an arm and a leg. Mess up a mold and, bam, your project is no longer profitable (or breaking even, if you were lucky).

3D modeling is actually easy now with packages like Sketchup. If you have the dough the pro's use Solidworks or Inventor (my fav), which abstracts the development process to 2D sketches which can then be pulled, extruded, cut etc... analogous to what you would do with your hands on paper or with clay (or legos or whatever). It's really best to have a vision and use a designer to bring it to life but when you don't have that option it's still possible to get _something_.

You didn't mention it but setting up and running a crowdfunding campaign is time consuming, difficult and crazy stressful. I'm about to launch mine in a few days and am basically not sleeping.

Props to Ryan -- what he has done is NOT easy and he deserves all the success he as achieved so far.

<comment><USER20> Fabbing boards: Why does it matter where you live? As for cheap, try sharing a panel: [https://oshpark.com](https://oshpark.com)

Parent's talking about prototyping, so injection molding ain't going to work. A good path is to test with 3D prints, iterating with cheap consumer-quality stuff until you need to test mechanical/fit more accurately, then get a shop to print your forms with a professional printer.

I've never heard of anyone going from Sketchup to injection moldable files, but I suppose that's... possible? Rhino for Mac is in free beta right now - not ideal, but easy enough to learn as far as these programs go. 3D modeling really is not that easy to get a handle on, and then doing it for manufacturable parts is another thing. Uploading your files for Protomold to auto-analyze is a good way to learn about what's manufacturable, at a really basic level (because Protomold can only make basic parts).

But physical prototyping depends on what you're making, of course. The above makes sense if you're just making a case for electronics, and it doesn't have to have any particularly interesting performance characteristics itself. If you're prototyping something flexible, for example, that's really hard to prototype with a 3D printer since the likelihood of finding a printed material close to your final is small. In that case, you may have better luck with casting silicone, etc.

For Coolest, I guess you'd want to prototype the novel user-manipulable features, but a cooler is a cooler and presumably his partners know how to make those. If he hasn't prototyped the novel features, I predict there'll be a delay if he's got a reasonable standard of quality, and at least, the final will look different from what people have seen so far.

</comment></comment></comment></comment><comment><USER21> I'm just waiting for Coolest to release an API for their cooler...

</comment><comment><USER22> Probably could have stood to fail one more time.</comment>


Michael Lopp on Managing Werewolves - <AUTHOR> http://www.alistapart.com/articles/managing-werewolves/

<comment><USER2> I thought everyone would have heard of this by now - the original version of the game is called Mafia and it's been around for ages.

Even has a wikipedia page: <http://en.wikipedia.org/wiki/Mafia_(game)>

<comment><USER3> I thought the original was called Dungeons & Dragons. Interesting game, actually.

</comment></comment><comment><USER4> His blog (<http://www.randsinrepose.com/>) is just as good, which is to say very.</comment>


Why Users Click Right Call to Actions More Than Left - <AUTHOR> http://uxmovement.com/buttons/why-users-click-right-call-to-actions-more-than-left

<comment><USER2> Nice in principle, but it'd be better if it could show real data. This post is basically "why _we would expect_ users to click right-side call-to-actions more than left-side" without actually backing it up and showing that they _actually do_ so.

<comment><USER3> I agree. I can even corroborate the hypothesis anecdotally, since CTAs on the right side "feel" right to me, but without data it's still just a hypothesis.

</comment></comment><comment><USER4> I'm amused that a UX article has such a poorly written headline that I had to read it 5 times before I my brain parsed it properly.

<comment><USER5> I thought it was going to have to do with left click vs right click until half way into the article. In retrospect it was kind of a silly thing to assume, but thats what my first pass saw, and I use enough software at work that likes to throw everything important under the right click anyway that it seemed plausible.

<comment><USER6> I agree. I had assumed it was a reference to Right Click>Open in New Tab, and the the whole idea was the a user would open your call to action for after reading the current (something I do constantly).

</comment></comment></comment><comment><USER7> It's disappointing how many UX blogs, sites and "professionals" don't back up their claims with data.

Too many articles give rationale behind design decision while presenting reasoning as fact without supporting them with real data. There's nothing wrong with providing readers your reasoning, but in an area such as UX, I think these posts are more dentrimental than they are beneficial to those coming up in the field.

</comment><comment><USER8> There is no data in the article to back up the author's hypothesis. Further no control for colors or even action/offer button language. I have read other papers with data and conducted my own UX studies that show completely different results.

<comment><USER9> Care to share?

<comment><USER8> I really would but I'll have to check with my clients. They were commissioned reports. Perhaps once I get everything compiled into something consumable by the public I'll release it as it's own HN post.

The gist of it was that to drive interaction with a website, cursor position is more important than following the "active corners" design philosophy.

So from a pure graphic design point of view placing the action button in the lower right is correct. We all learned that in design class.

However if you want people to actually interact with your action button then it's better to put it closer to where the cursor normally resides. All of my heat map testing shows there to be a natural cursor well on the left hand side.

</comment></comment></comment><comment><USER10> Flipping through ABTests.com, I was hard pressed to find pages that tested having the call to action (CTA) on the left vs. CTA on the right.

I did find one for basecamp where they flipped left to right but it may not be the reason for the improvement. <http://www.abtests.com/test/150001/homepage- for-basecamp>

Without any evidence from the OP, how can we take the article seriously?

</comment><comment><USER11> I cannot parse this title at all. How about "Why it matters where you place buttons that call for action."

</comment><comment><USER6> I don't know a ton about internet marketing, but I DO know that it pisses me off when reading through the archives of a webcomic, and the Next Page button is on the top instead of the bottom (it should really be in both places, though).

Seems like a similar idea.

</comment><comment><USER12> You can also do the opposite to your advantage. For instance, the ad pop-ups on salon.com have the close button on the left, which means I end up looking at the ads a little longer.

</comment><comment><USER13> The Ballpark site has the CTA at the right bottom part of the page as well. So even they are following the principle/assumption rather than neglecting it.

</comment><comment><USER14> This seems utterly groundless to me, especially because it doesn't describe my eye movement.

Perhaps it's because I'm left-handed. Perhaps it's because I know content is always left-justified (and let's understand each other- I'm not at your web page for anything other than content). Either way, I don't pay much attention to the bottom right area of a web page.

<comment><USER15> You must read a lot of websites that are all forums, plain text. Web services and online stores on the other hand need techniques like this to lay out things in a way that makes sense. Imagine if Wal Mart had its cash registers in the back and only niche expensive items at the front. Sales would drop. In fact I think I just realized why malls suck so bad.

</comment></comment><comment><USER16> This is unlikely to apply to the billions of people that read right to left however.

<comment><USER15> Those sites are designed oppositely. This principle applies to movies and in fact anything with a frame around it, there are certain emotions and intents communicated with framing. Think of this as website framing.

</comment></comment><comment><USER17> Hmmm, I was expecting some interesting explanation _why_. (It's obvious enough I guess, but sometimes even 'obvious' facts have explanations more intriguing than you might at first suspect.) This article just tells me the fact of it and what to do about it.

</comment><comment><USER18> This article is nonsense. Disregard.</comment>


22 tips on how to operate a trade show booth - <AUTHOR> http://calacanis.com/2009/09/08/22-tips-on-how-to-operate-a-trade-show-booth/ <comment><USER2> Though dated (2009) that was an extraordinarily generous read. If were an ebook I would have paid for it.</comment>


Show HN: Automatic, private time tracking for macOS - <AUTHOR> https://timingapp.com <comment><USER2> Very cool, like RescueTime but modern and stored locally! How's the feature parity with [https://www.screenaware.com](https://www.screenaware.com) and RescueTime?</comment>


Your Abomination Is My Clever Hack - <AUTHOR> http://odetocode.com/Blogs/scott/archive/2009/11/30/your-abomination-is-my-clever-hack.aspx <comment><USER2> Is this really seen as an abomination in the C# community?

My argument for why this is good seems pretty simple:

1) The code that does this isn't _that_ hard to understand

2) All code that uses it becomes much more readable

3) The total of all code in #2 is going to be modified more often by several orders of magnitude than the code in #1

<comment><USER2> After reading the stack overflow discussion, it's clear there are some reasonable arguments, particularly that it is not good for interoperating with other languages on the CLR.

However, it also appears that most people on that discussion would disagree with my point #2 (code using this becomes more readable). That's probably where the interesting things come in to play.

For me, I don't care about abuse of syntax, etc. as long as code does what a casual observer would guess it does. Perhaps I'm spoiled by working somewhere where people actually write readable code, and if I worked somewhere else, I would want to forbid any syntax magic whatsoever, but more likely I would just be updating my resume :)

</comment></comment><comment><USER3> Python's optional arguments feature is useful for these kinds of polymorphic usages - and I miss them every time I program in other languages (especially Java). In JavaScript I miss named arguments (e.g. _def fun(name, age, gender=1, height=None)_ ), which is very useful especially if one calls stuff like _Person("Bob", 13, height=150)_.

Generally, I don't think these kind of improvements are appreciated in C# as they are polymorphic and make it much harder for the compiler.

      The optional arguments feature is to define a function like def fun(..., **kw)

<comment><USER4> C# 4 has exactly this feature.

</comment></comment><comment><USER5> Blogspam, devoid of content. See the original for a much more thorough discussion.

[http://stackoverflow.com/questions/1718037/abuse-of-c- lambda...](http://stackoverflow.com/questions/1718037/abuse-of-c-lambda- expressions-or-syntax-brilliance)

<comment><USER6> Clearly not blogspam by any reasonable definition, but I agree that the Stack Overflow post has more interesting content.

</comment></comment><comment><USER7> Way to break alpha-substitutability, guys. I expected this from the Rails crowd, but somehow I thought better of the .NET community.

Or, as Steve Summit put it to me when I told him about this, "The audience leaps to its feet and shouts 'NO!'"

</comment><comment><USER8> I don't really get it. Is => not a pair constructor in C#?

<comment><USER4> What's a pair constructor?

"=>" is the C# lambda operator, which makes an anonymous function. Args go on the left of it, the return value on the right. In most cases, the names given to args don't matter.

<comment><USER8> Ah, then no, it's not a pair constructor.

<comment><USER8> (I should also say that in Perl it is, and that's why this code looks perfectly normal to me. I imagine it's frightening to a C# programmer!)

<comment><USER4> _I imagine it's frightening to a C# programmer_

C# programmers everywhere are heartened by your condescension. Not. Thinking of it as a pair is not going to help you understand it.

from TFA:

 _The syntactic trick is how the API uses the name of the lambda's parameter as the name of the HTML attribute_

If your function is passed a function of one parameter, then it is a bit of a hack to vary behaviour based on the _name_ of that parameter. But I'm OK with it, since it works quite well.

</comment></comment></comment></comment></comment><comment><USER9> I don't get what the problem is. This seems equivalent to Hibernate using reflection on fields in Java classes. Distilling your own syntactic sugar can be a great thing.

</comment><comment><USER10> As a rubyist who also programs in c#, i'd say that this is pretty gross. Internal DSLs are part of the ruby culture. In c#, the ability to look at code and understand its execution _and_ its intent is the objective. With syntax manipulation like this, the underpinnings of the language that are normally hidden now must be considered... it is out of character.

<comment><USER8> Isn't LINQ, an internal DSL, one of C#'s main selling points?

<comment><USER4> LINQ is an internal DSL, and it's a big selling point of the C# 3.5 release. I don't think I'd go as far as to call it " one of C#'s main selling points".

The thing is, c# coders cannot build their own LINQ-style DSLs in c#. Rubyists do build thier own DSLs in Ruby.

</comment></comment></comment><comment><USER11> I personally do not like it. My problem with it is not readability (because it looks very clean) but consistency. When developing an API I always strive to make it as intuitive to use. My #1 goal is always, could you use this without documentation? This hack would make me answer no, its too inconsistent from the norm. I can only hope he mentions how to use it in the ///<summary> comment</comment>


Linux disto for network analysis and security: The third SELKS is out - <AUTHOR> https://www.stamus-networks.com/2016/08/12/the-third-selks-is-out/ <comment><AUTHOR> [https://github.com/StamusNetworks/SELKS](https://github.com/StamusNetworks/SELKS)

[https://github.com/StamusNetworks/scirius](https://github.com/StamusNetworks/scirius)</comment>


Suicide Is Not A Choice - <AUTHOR> http://archlinux.me/dusty/2013/02/10/suicide-is-not-a-choice/

<comment><USER2> You could say the same thing about externally directed violence, but I don't think anyone wants to hear that.

<comment><USER3> Or that free will in its entirety is an illusion (which I would, actually).</comment></comment>


SSL Dor Free Switched from Let's Encrypt to ZeroSSL - <AUTHOR> https://www.sslforfree.com is a well-known website for offering Let's Encrypt SSL Certificates for free SSL For Free switched from to ZeroSSL, all old accounts are removed.<p>Users are now limited to 3 Free Single-domain SSL Certificates, Multi-domain and wildcard are now a paid option. <comment><USER2> Why would one use this rather tan Let's Encrypt?

<comment><AUTHOR> If you are asking about why SSL For free went to this instead of Let's encrypt, it's pretty obvious money

If you are asking about why someone would use this instead of just using acme.sh or certbot, it's because some people doesn't even know how to show their current working directory (or even what a working directory is), so it's not that easy for them to understand more advanced topics like TCP ports, DNS records, they just want to optimize their SEO</comment></comment>


Why is is a bad idea to use one SSL cert for many domains? - <AUTHOR> I assume it is against best practice, but aside laziness, can anyone identify some specific reasons why a website host would actually want their ssl (LetsEncrypt) certs to cover hundrds of different customer domains? Seems like a bad idea, if only that it serves as a cold-call list for competators. <comment><USER2> We do because it increases costs and complexity to have a cert per domain. On AWS, you only get 25 certs per load balancer. We'll do a cert per domain if they ask, but we have to pass on the cost.

As for a cold call list, I can already Google and find a list of sites we host. It isn't as easy, but we aren't hiding it.</comment>


Monoid: A coding font with ligatures - <AUTHOR> https://medium.com/@larsenwork/ligatures-coding-fonts-5375ab47ef8e

<comment><USER2> Nice! I've got ligatures in my Haskell with the default spacemacs set up, this font looks really nice.

How is it implemented? One of the problems with Haskell code is that there are quite a few instances where the examples given are within a larger infix operator for example:

>-> from pipes looks like this >→

Still a net win, but is there anything that could be done about it?

</comment><comment><USER3> Too bad emacs doesn't do ligatures. :-(</comment>


The ad tech renaissance - <AUTHOR> http://bokonads.com/the-ad-tech-renaissance/ <comment><USER2> I'll concede that the analysis isn't completely without merit, but having spent the last few years in ad tech, I sincerely hope that there won't be a revival. It's a race to the bottom. Publishers are struggling and are increasingly willing to accept ever more outrageous ad products. Advertisers are desperate for advertising that actually works, but will mostly only do what agencies tell them, and the agencies are only interested in maximizing their own margins. In the middle we've got any number of middle men scrambling for some pieces of the cake, sometimes but usually not providing some value, leaving the publishers with a pathetic fraction of the advertiser spend.

So essentially we've got a whole bunch of companies with no growth desperately vying for the attention of 23-year old media buyers who in turn are mostly interested in getting someone to take them clothes shopping and picking up the bill. These companies are doing it mostly by doing ever more intrusive things, since advertisers can't accept that the reason their ads don't perform is that nobody wants their stuff and keeps looking for a silver bullet.

I've come to believe that the only reasonable justification for most advertising is that it's in some sense a way for other industries to subsidize journalism. Since that's going away, I'm looking forward to the inevitable ad tech carnage ahead, and if a potential next wave actually brings higher quality advertising and better end user experiences I'll happily eat my shoes.

<comment><USER3> All of this, plus the vast amounts of bot traffic that no one wants to look too closely at, because everyone except the advertiser is making money off of it...

<comment><USER4> Bot traffic is accounted for in the price advertisers pay for ads. Advertisers don't run unprofitable ads.

<comment><USER5> Advertisers do run unprofitable ads and marketing campaigns all the times.

And they are fine with that too. That's the case of VC-backed startups: they accept a negative ROI to get the chance to start making money one day.

Then you have the less consciuous ones, which might be big brands who want to experiment a bit with new media/ad formats.

In any case, if you think about it, the real losers are...the honest publishers. Because the money on the table is not increased by fraud, it's just shared in a way that takes something away from good publishers to bad/fake ones.

<comment><USER4> I agree honest publishers are at a definite disadvantage. Advertisers aren't because the roi calculation they come up with judges their campaigns based on its performance, which incorporates good and bad clicks over time.

</comment></comment></comment></comment></comment><comment><USER6> I don't see any mention of ad blockers. Are these seen as having a significant effect on the online advertising industry? Are there any serious proposals to deal with them other than continuing the ad-blocker-blocker-blocker... arms race?

It seems that there's an increasing understanding among publishers that low- quality and intrusive ads encourage their visitors to use ad blockers or another site. Several relatively high-profile sites (like The New Yorker) have stopped using networks like Outbrain and Taboola. (Obnoxious ads from the latter, along with autoplaying video ads on numerous sites, resulted in me finally installing an ad blocker after resisting for years.)

Adblock Plus offered a way forward with its "Acceptable Ads" program but it seems like that has been roundly rejected by both advertisers and blocker users. Maybe publishers and advertisers could work together to develop a stricter set of advertising guidelines that show respect for users? I suppose such a program is essentially doomed without cooperation from Google and Facebook, and I don't know if they'd be willing to work with the little fish (or each other).

It seems like an intractable problem. I'm not convinced technology (machine learning! the solution to all problems!) is capable of providing the solution.

<comment><USER7> The problem is that most ads suck. Facebook knows more about me than I do, but they can't come up with ads for things I want. What possible chance does a random newspaper have?

<comment><USER8> I completely agree. 99.99% of the ads I see on facebook are for things I don't want. They really need to get more AI and more information about the user for better targeting. They may have world class targeting, but it still sucks compared to advertisement that can read my mind (doesn't exist yet).

<comment><USER9> A common misconception is that targeting is about _your_ interests. An AI won't select ads for things you want. Instead, it will use all of that tracking data to select ads that are more effective at misleading you or _changing_ your interests.

<comment><USER7> What is easiest? Sell me things that I already want but don't know about, or changing my interests and then convince me to buy a particular product?

Incidentally 5 years after moving into an apartment I still need a good curtain for the kitchen. If I see an ad for a place I can upload measurements and get the results sent to me I would be very happy to pay.

</comment></comment></comment></comment></comment><comment><USER10> _> The end of impressions and banners in favor of views and "publisher rendered" (aka native) creative_

Native advertising, which I'd re-phrase as 'sponsored content' or 'content placement', I can actually enjoy, if the sponsorship is made clear and the topic is genuinely relevant to the audience. After all, who better to tell what kinds of content readers want to see besides the publisher who puts it out there? But it _has_ to fit -- out-of-place content will be painfully obvious, and cause further user aversion for ads.

But the thing is: all of this can be accomplished without ad networks that track your travels through the web. The client can engage the publisher directly or through a broker. Where does that leave today's adtech?

<comment><USER11> That seems unduly optimistic. The content will be uploaded from the same old terrible content farms, and be the same old rubbish only with a heavier local server load.

</comment></comment><comment><USER12> Very interesting read, thanks OP! I've started using some platforms with integrated ml, and it seems to be much better. Its difficult to get used to starting a campaign, and instead of meticulously setting up targeting (males, $50k income, denver, into football and skiing, etc) the ml lets you just .. upload an ad and a web page. No targeting. Click GO and it will find your customers. If Google or facebook can get into this space they'll succeed greatly because they have so much data and users already trust them.

<comment><USER13> can you please name those platforms ???

<comment><USER12> I'm at an agency and have access to some closed betas, but I've been pretty impressed with StackAdapt for their native. They just added video and display I believe but I haven't used them. You do a little bit of manual targeting but their ml really does well.

<comment><USER14> When you say "does well," what type of goal or kpi are referring to?

<comment><USER12> White paper downloads for elderly people. For some reason their interface underreports conversions though. But we've tied their traffic directly to purchases! One note though.. like some other channels you're buying a mixed bag. There is a lot of low quality traffic, but the diamonds in the rough do make up for it.

</comment></comment></comment></comment></comment><comment><USER15> Since there's rarely any widely interpretable public data available, articles like this and many others are my best gauge for noting that even the Internet advertising industry itself recognizes that it's dying. This is very pleasant to observe.

Personally, I can't remember the last ad I've seen while browsing. The combination of AdBlock Origin (with a very generous combination of various blocklists), Ghostery / Privacy Badger and NoScript effectively renders most adtech useless. The few remnants that refuse to be blocked I happily skip outright rather than enable. As far as I'm concerned, the only acceptable form of advertising consists of things like hardware companies supplying free samples to review sites without any preconditions and even there a slippery slope exists, as evidenced by the sad state of the games "journalism" industry, where corruption is endemic.

And the best part is that, unlike many political and social issues, users really do have all the power here, and it's trivially easy to exercise it. Install a few trusted browser extensions and you've helped hasten the demise of a harmful parasite of an industry, and improved your own security at the same time. And nowadays it's easy to persuade even non-technical users to do this due to how disgusting and intrusive ads have become.

<comment><USER16> Congratulations! You are in the 10% of people who have adblock :) Within the 600B advertising industry. You get the point right? Normal people think different. In addition, mobile is overtaking everything and adblocking there is more tricky, thats why Facebook is generating 80%+ of their revenues via mobile ads (fun fact, in 2010 it was 0%). You can ask your parents for instance whether they know how to limit ad tracking.

</comment></comment><comment><USER17> I _feel_ like another piece missing from why these companies are "flat" year over year is the fact that they are running into a wall of what people will tolerate. I don't think that there will be a renaissance like the author concludes. As a guy who worked in ad tech these tricks have been exhaustively tried. I think right now the industry trend is to pay for premium content rather then be inundated with Ads especially when it comes to games, video and music. I imagine we will see this pattern continue especially with the mobile gaming industry figuring out the key to everyone's wallet: in app purchases.

</comment><comment><USER18> This article is mostly bullshit.

AppNexus is one of the major SSPs (sell-side platforms) but they still have major fraud and legacy tech issues. They are also one of the primary causes of miserable user experiences across the web. They will not be part of any adtech renaissance.

Google won't flinch if margins really do go down to single-digit margins. They're already built for worse conditions than today and are just pacing the market, as seen with the whole header bidding scenario. They also have Google Cloud rapidly scaling and will likely be a bigger source of revenue than their entire ads division in a few years.

Meanwhile AppNexus can barely survive on their current margins and will be out of business if it hits single-digits. The disintermediation mentioned in this article will also apply just as harshly to AppNexus.

The lame insights about machine learning and formats aren't anything special. This is why Google and Facebook get all the money already, because they have a much faster, cleaner, more relevant, and more effective ad experiences. The renaissance is already here and it's getting increasingly harder to compete with these data behemoths. It's not impossible though and there are several niche focused ad startups, but there's no big sea change about to happen. This is all just business as usual.

</comment><comment><USER19> This is a space I wish I knew more about- but it seems like it has it's own sub-culture that to me, is hard to parse.

Can someone tell me what some of the things are that he refers to in this article?

\- dfp, dsp, ssp, gdn, dbm, adx, dcm, dfp

Is there a good technical-minded rundown of all the players in the ecosystem and what they do? Internet ad industry information is impossible to google because it mostly turns up spam.....

<comment><USER20> I've tried to find a long form piece on it (ideally a physical book as reference), but failed.

DSP: Demand Side Platform, is the tool agencies and advertisers use to buy the ad spots automatically based on tracking profiles.

SSP: Supply Side Platform, is the tool publishers use to sell their ad spots (publishers push an impression to an SSP, a DSP will evaluate it and an agency will buy an ad on it - Google is main SSP and DSP [I think?] so people are wary about them.)

DFP: DoubleClick for Publishers perhaps, as in, ad tech for media sites to manage the display process (guess it could be called Google's SSP).

DBM: DoubleClick Bid Manager, is Google's DSP

ADX: guessing just an ad exchange, so a place advertisers and publishers do the deal.

GDN: Google Display Network, posh AdSense where you can place your ads across 3rd party sites, not just the SERP.

Then we get into the world of Header Bidding (which, as far as I understand it, is even more tech to bypass your usual SSP/DSP process to get the best deal from different ad exchanges) and that whole murky world...

I've only been on the advertiser end, speccing a programmatic campaign through a specialist agency. It makes me nervy as our only marketing attribution is last touch and that rarely works with broad reach display. Retargeting is a much more valuable one to explore.

If anyone would be interested in a guide, I can look to put one together with definitions and a few anecdotes from some players? Username @ gmail.

<comment><USER21> I think it's worth adding how DSPs and ADXs fit together. There are only a handful of ad exchanges out there -- Google ADX, OpenX, AppNexus, etc. Some brands and agencies are large enough to buy inventory directly through these but for most brands and agencies, it's too expensive and cumbersome to do so. This is where DSPs fit in. DSPs buy large batches of inventory from the ad exchanges and resell them to brands and agencies and try to add value where they can.

</comment></comment></comment><comment><USER22> I've come to believe that this isn't a technology problem. It's a people problem - specifically a "publisher people are lazy" problem. That lazyness made them hand their value over to Google and Facebook, and now there's just no easy way to get it back.

</comment><comment><USER23> 85% of new ad dollars are going to fb and google. Everyone else is fighting for scraps.

<comment><USER16> Not actually true, these scraps are still worth billions => google AppLovin

</comment></comment><comment><USER24> I know it's not for everyone but I hope more publishers can work out a shift to a no-graphics-needed-to-render-this "advertisers<->publishers" approach.

Are your readers the sort of people advertisers want to connect with? Great! Sell space and support to them. Or is your audience so diverse and ephemeral that advertisers don't care? Move into publishing stuff that's useful to an audience advertisers value, because when everyone else is slipping down the ladder, it's a great time to try climbing it.

</comment><comment><USER25> >The internet needs an ad tech renaissance, one based on creating real value for publishers and marketers,

Could not disagree more.

Advertising as a whole needs to die in ignominy. Obviously that'll never happen, but we should be working towards ways to make advertising obsolete or unprofitable, and we should be ostracizing people like the author who try to or want to make things better for advertisers.

The promise of the internet was users as first-class citizens, not users as mindless consumers of hostile advertising.

<comment><USER26> Hostile advertising and advertising in general aren't the same thing.

I'd be the first to point out that advertising has motivated a wide array of terrible things, especially in the last few years. But advertising at its barest sense can be and usually is a net positive force.

<comment><USER25> >Hostile advertising and advertising in general aren't the same thing.

Are you sure?

<comment><USER26> Good point.

</comment></comment></comment></comment><comment><USER27> We don't need an ad tech renaissance. We need to burn it to the fucking ground.

<comment><USER28> ^ this.

</comment></comment><comment><USER29> > The tracking tech renaissance

FTFY

</comment><comment><USER30> I don't know if it was due to manual ad reviewers being on holiday or what, but i was getting a bunch of ad hijacking or malvertisements over the weekend from legit websites. If even legit sites can't keep up with this then no wonder everyone is running ad blockers just to keep safe from legit sites.

</comment><comment><USER31> really nice article detailing some nuances

<comment><USER31> really surprised by the downvote without any reason. so much for tolerance of opposite views. The author is an authority in adtech (CEO of App Nexus). I expressed an opinion of the piece (which you are free to disagree with and maybe the disagreement is downvoting??)

</comment></comment><comment><USER32> Very good read that highlighted the current state of the industry - G and FB reign as kings. I'd expect the fraud cycle to restart in gaming industry seeing that display and mobile are essentially saturated.</comment>


The US Army successfully flies its hoverbike prototype - <AUTHOR> https://www.engadget.com/2017/01/18/army-flies-hoverbike-prototype/ <comment><USER2> Presumably its more reliable than the Boston Robotics walkers in getting out for re-supply. I'll be interested to see if these things show up on UCAV decks. It seems that loading up an M249 equivalent on it with a remote operator station you could deploy flanking suppression fairly quickly in an amphibious assault.</comment>