Optimising for Concurrency: Comparing the BEAM and JVM virtual machines - <AUTHOR> https://www.erlang-solutions.com/blog/optimising-for-concurrency-comparing-and-contrasting-the-beam-and-jvm-virtual-machines.html <comment><USER2> the author leaves out Kotlin which adds support for coroutines on the language level and still compiles to java bytecode. These are not classic continuations because they cannot be cancelled, but they're still very useful and true fibers.

There's also the Quasar library that adds fiber support to existing Java projects, but its mostly unmaintained since the maintainers were pulled in to work on Project Loom.

Then there's Project Loom, an active branch of of OpenJDK with language support for continuations and a fiber threading model. The prototype is done and they're in the optimization phase. I expect fibers to land in the Java spec somewhere around JDK 17.

I figure its fair to mention these as the authors criticisms are somewhat valid but will not be for very long (few years max?)

In summary: Java will have true fiber support "soon". This will invalidate the arguments for Erlang concurrency model. They are already outdated if you are okay using mixed java/kotlin coroutines or Quasar library

The newer Java GC's Shenandoah and ZGC address authors criticisms of pause times. They already exist, are free, and are in stable releases. Dare I say they are almost certainly better than Erlang's GC. They are truly state of the art, arguably far superior to the GC's used in Go, .NET, etc. Pause times are ~10 milliseconds at 99.5%ile latency for multi terabyte heaps, with average pause times well below 1 millisecond. No other GC'ed language comes close to my knowledge. His points 1 and 2 no longer exist with these collectors. You don't need 2X memory for the copy phase and the collectors quickly return unused memory to the OS. This has been the case for several years.

Hot code reloading. JVM supports this extensively and its used all the time. Look into ByteBuddy, CGLIB, ASM, Spring AOP if you want to know more. Java also supports code generation at build time using Annotation Processors. This is also extensively used/abused to get rid of language cruft

<comment><USER3> > This will invalidate the arguments for Erlang concurrency model.

What about failure domains? As far as I'm concerned, this is the strongest reason for actor-based concurrency. I can design my architecture so that groups of processes that need to die together die together. And it's usually one or two lines of code, if any.

Here's a real life example. I have a process that maintains an SSH connection to a host machine, and that ssh connection is used to query information about running VMs on that host machine. If the SSH connection dies, it kills the process that is tracking the host machine, which in turn kills the processes tracking the associated VMs, without perturbing any of the other hosts' processes or vms. This triggers the host process to be restarted by a supervisor, which then creates a new SSH connection to query for information (possibly repopulating VM processes for tracking information). All of this I wrote zero lines of code for (which, importantly, means I made no mistakes), just one or two configuration options. More importantly, the system doesn't get stuck in an undefined state where complex query failures can cause logjams in the running system.

<comment><USER2> You can tie the fates of threads together in Java using thread groups. If you need more flexibility, or want it to be managed for you, Akka framework offers this. I believe Akka gives you a model very similar to Erlang.

In Java you would create a thread pool and configure it to restart the threads if they die. Each thread would wake up every so often to query SSH and dump their results into a queue. If the query threads die, the processes reading the queue at the other end have nothing to do so they won't execute. Its easy to make a consumer queue that executes some code on another thread whenever data arrives.

Java's exposure of the underlying OS threads and cheap transfer of data between threads lets people build libraries on top that offer memory models used by Erlang and others. Its not built in or quite as convenient, but you can use actors and fibers in Java if you want to.

<comment><USER3> Yeah that's exactly the problem. It's an afterthought in the system. How certain can you be that the system you're using is compostable with any other code brought in to your system, even from libraries outside? In erlang, failure domains are the raison d'etre of the language, so everything in the ecosystem will play nice.

Ultimately, systems like akka are extremely complicated to get right, even for experts, because you have to think about all of the vm bits underneath. I can (and have) teach a junior programmer basic OTP concepts with the confidence that they can't mess things up. Now, they wouldn't be able to come up with the architecture I designed as a good idea, but I could tell them to implement it (with tests!) and expect them to get it right.

</comment></comment></comment></comment><comment><USER4> > Programming with concurrency primitives is a difficult task because of the > challenges created by its shared memory model.

I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching.

It was all pretty simple and concurrency & parallelism were never an issue but simply a necessity to make things run fast enough.

Am I a concurrent programming genius? Were the types of problems/challenges I was solving too simple? When is concurrency in Java ever hard+?

\+ I know about Java masterpieces like the LMAX Disruptor that are mostly beyond my skill level, but those are low level writte-once libraries you wouldn't write yourself.

<comment><USER5> > When is concurrency in Java ever hard?

Potentially-racey stuff:

* Synchronized primitives don't compose. You can safely `synchronized get(...)` and safely `synchronized put(...)`. But their composition put(get(...)+1) isn't synchronized. And it's hard to mentally revisit it at the end of the day: if you have a class with some methods marked synchronized, nothing will tell whether you've synchronized the right methods. You just have to think it through again and hope you reach the same conclusions as before.

Other (non-racey) stuff:

* Threads are heavy, CompletableFutures are light. But CFs lack the functionality of Threads. A CF can't decide to sleep for a while, nor can it be cancelled. (As an aside, BEAM threads are super light).

<comment><USER6> Java has a large set of higher level abstractions for concurrency. You don't have to use low level locks but you can. (And that's just Java, there's also Scala, clojure ...)

<comment><USER7> I'm pretty firmly in the "shared memory parallelism is a Good Thing" camp, but the counter argument to your point is that having a larger set of concurrency abstractions is a Bad Thing in that any particular piece of code has to consider all of the different permutations. In a shared-nothing world, there's a lot less to worry about (except occasionally performance).

<comment><USER8> The world writeable cross thread also has implications on how your GC algorithm is designed.

Erlang for instance scopes gc pools per process so short lived processes just drop the pool. Also GC of one worker doesn't stop any others. Can't remember if it even needs to be generational because the heaps are already sliced by process. It's the closest thing to heap arenas I've seen in a VM based language.

Or take Lua which is single threaded and doesn't require VM safepoints since everything is done via cooperative coroutines.

Java needs to assume worst case and as such has to be conservative in some of it's approaches.

</comment></comment></comment></comment></comment><comment><USER9> BEAM is amazing and IMHO there's one very sweet spot ready for optimization: math functions. I know I can escape out to C/Rust/etc. yet the majority of what I do is simple float math such as stddev and vector normalization.

The article states benchmark of 5000% speedup on floats when switching from BEAM to the JVM. I would like to offer $100 as a gift incentive to anyone here who wants to work on optimizing BEAM math.

<comment><USER10> People say this isn't what BEAM is intended for an it excels elsewhere, which yes I'm sure it does.

But why can't it be both? Why can't you do everything that BEAM does... and then also have an optimising JIT for the straight line maths code? Couldn't you leave all the other parts of the system the same and keep all the existing benefits? Improving one doesn't damage the other does it?

<comment><USER11> Co-author here.

The problem with number crunching or maths is that it is very difficult to cut the whole computation into smaller units and pre-emptively schedule it. If it is possible for a specific use case, then it is moderately easy to replace that part with NIFs. For effective maths you need to convert the internal tagged number representation to machine native code that is also expensive. Solving these two things in the generic case is very difficult while preserving all the good parts.

<comment><USER12> Am I correct in saying that functions written in C do not get pre-empted like Erlang functions? If that is true, you could write computationally intense code in C within a BEAM app. But I think this misses the point. Pre-emption is really cool for concurrency abstractions, and the trade off is being less good at single threaded computation. Trying to turn Erlang into something like a Bitcoin miner is kind of like combining a bunch of Roombas to make a Shop-Vac.

<comment><USER13> You are correct.

It's actually worse than that; as I recall, the internal numerical representations of numbers do not necessarily map to the CPU's (for instance, there is no byte sizing; you have integers and floats, and they can be arbitrarily large). The work to perform that conversion, do the math, and convert back, would almost assuredly make it so that a single calculation takes more time than just doing it within the BEAM. The only way to save time would be to convert once, do a bunch of math, and convert back. Which would, yes, prevent pre-emption, AND require indication of intent (so brand new language constructs, minimally).

That's a lot to expect of the user, and a lot to implement in the language...all to avoid just writing a NIF.

<comment><USER10> > Which would, yes, prevent pre-emption, AND require indication of intent

I don't understand why. If you have a maths-intensive operation like matrix- multiplication using untagged maths, why does that prevent pre-emption? Why does it require indication of intent?

And there's already a basically zero-overhead way to implement pre-emption - safepoints - that's what the JVM does when it wants to pre-empt in user-space.

<comment><USER13> Uh...no. A safepoint is when all threads in the JVM have blocked (which is purely cooperative, and happens during thread transitions), and, importantly, when OS threads running native code _still are running_ , but can't return/respond to the JVM. The JVM doesn't pause those threads.

Which is the point. You can't preempt crunching those numbers if it's not within the BEAM. Which might be fine. Or it might not. Making it invisible to the user is not really a good idea when going for soft realtime properties; at least with a NIF and dirty scheduler you're being explicit about it.

<comment><USER10> > A safepoint is when all threads in the JVM have blocked

And having blocked them, you can then pre-empt them.

> You can't preempt crunching those numbers if it's not within the BEAM.

I still don't see why sorry. If you had a JIT and you compiled maths intensive code to native code, it could run efficiently in BEAM and still be pre- emptible by having a safepoint in the generated code.

How do you think Java is doing optimised numerical code that is pre-emptible from user-space? Safepoints! BEAM could do the same thing.

<comment><USER13> You, uh, realize that's not actually preemptive right? Like, having to thread in checks, that are cooperative, is by definition not preemptive?

<comment><USER10> Yes I think that's a reasonable definition of pre-emption because they don't interrupt the numerical pipeline. They cause zero data or control dependencies. But even if you don't think it fits the definition, what do you think the practical difference is when you argue about this terminology?

What did we want to achieve? We wanted to be able to run a tight loop of highly optimised, untagged numerical code but still be able interrupt it to switch threads on demand from user-space if needed.

Safepoints let us do that.

What else did we need that this doesn't cover?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Can someone steer me to some good benchmarks, discussions of perf characteristics and gotchas of the BEAM? My search-fu is weak and I'm not finding the sort of content I'm after.

I'm trying to learn Elixir and being a systems thinker so before I (can) get too comfortable I'm gonna want to dive into origin stories to build up my holistic map of why things are the way they are, what can be done and what can't be done, and understanding bottlenecks in the BEAM seems like it's gonna have to be part of that (the way I studied JVM tech documentation when I did perf and architecture work in Java)

<comment><USER15> In general I would say there's no good single book or resource that describes everything comprehensively. There's a lot of resources, though, but mostly scattered in various places.

The BEAM Book [1] is a good, though unfinished resource talking in general about the implementation - the memory model and the interpreter.

If you're interested in some very low-level details of the runtime, the internal documentation [2] also holds a lot of interesting details.

There are also some additional details on internals at Spawned Shelter [3].

[1]: [https://blog.stenmans.org/theBeamBook/](https://blog.stenmans.org/theBeamBook/) [2]: [https://github.com/erlang/otp/tree/master/erts/emulator/inte...](https://github.com/erlang/otp/tree/master/erts/emulator/internal_doc) [3]: [http://spawnedshelter.com/#erlang-design-choices-and-beam- in...](http://spawnedshelter.com/#erlang-design-choices-and-beam-internals)

<comment><USER14> I want to know the constraints to, and evolution of, sequential computation on the BEAM. I want to form opinions on how that landscape is likely to change within the lifespan of a project I'm affiliated with.

I get mostly false positives trying to find those sorts of discussions or metrics.

<comment><USER16> I am not sure i understand the problem you are trying to find information about. Maybe explain it a little bit more ? or go ask for it in the elixir forum, people can try to be your librarians there

<comment><USER14> To an outsider, it seems like the BEAM documentation [and particularly, videos] go out of their way to discuss how process management and IPC communication works and how certain classes of data are managed. They talk about what makes the BEAM the BEAM to exclusion of all other concerns.

Prior to finding this document ([http://www.cs- lab.org/historical_beam_instruction_set.html](http://www.cs- lab.org/historical_beam_instruction_set.html)) I had no idea whether you could actually do computation on the BEAM. I was starting to wonder if they had misappropriated the term VM, and some sort of inline assembly trick was being used for everything but control flow and IPC.

Interpreted code has very, very real computational constraints and you can't assume people will know this, even now. Especially if your system is noteworthy for how it is _not_ like other systems. Where does it stop being 'weird' and start being conventional? The boundaries describe both sides of a distinction. Even if you're only interested in the exotic part, leave some breadcrumbs for others.

<comment><USER17> Hmm, are you maybe after this page?

[http://erlang.org/doc/efficiency_guide/advanced.html](http://erlang.org/doc/efficiency_guide/advanced.html)

</comment></comment></comment></comment></comment></comment><comment><USER18> The JVM supports hot code loading, although this article seems to imply only BEAM supports it.

<comment><USER19> Do you have a reference on that?

I want to make sure you're talking about the same thing.

<comment><USER20> Clojure does hot code reloading as a built in. You essentially send code to a running system and you change it. It's enabled by a dynamic class loader. I wouldn't say it's common outside of Clojure though, the whole language and ecosystem is built around this concept.

To be clear: JVM enables the feature, so "technically" JVM allows hot code reload. Not sure how useful this is in practice for non-Clojure JVM users.

<comment><USER2> Runtime code generation is a common optimization in java frameworks. End-users may never see it but the majority of popular frameworks use it under the covers.

Debuggers also use the functionality to allow live code editing and expression evaluation when paused on a breakpoint

</comment></comment></comment></comment><comment><USER21> They mentioned this for the beam virtual machine but not for the JVM, the JVM actually can also do hot code loading as long as call site signatures are not changed or added. In some cases you you can make major changes to the current stack and restart the frame which is a pretty handy feature for developer. Some commercial extensions to the JVM get around all of these limitations.

</comment><comment><USER22> Of interest might also be Erjang, Kresten Krab's port of BEAM to JVM. [https://github.com/trifork/erjang](https://github.com/trifork/erjang)

As I understand it, it is feature complete and actually runs Erlang pretty well. Could be interesting to see some benchmark testing.

</comment><comment><USER23> Apparently this is an Erlang BEAM, not Apache BEAM [https://beam.apache.org/](https://beam.apache.org/)?

<comment><USER24> Yes. It's about Erlang's BEAM VM.

</comment></comment><comment><USER25> Tl,dr. The point seems to be, "shared nothing makes concurrency and GC easy". Congrats. But also lots of big fast systems use shared memory, so just relax, STFU, and understand that tradeoffs exist.</comment>


Show HN: Backbone.bootstrap - <AUTHOR> https://github.com/TruffleMuffin/backbone.bootstrap <comment><AUTHOR> I created this small bower library to enable simple usage of bootstrap data with Backbone.</comment>


Would anyone consider sponsoring me for the 2-year Make School Program? - <AUTHOR>

The program works by allowing students to pay for their Make School education a percentage from their salary for two years after the program. If I can pay up front, I would have reduced overall expenses. If someone would consider it, I would like to talk to someone or a company who would be interested in working out a deal. Possibly contract work or part time employment for the next two years or something like that. I am open to suggestions. <comment><USER2> sponsor a user too cowardly to use their actual account to post this? why i'd love to!</comment>


Statistician Who Debunked Sexist Myths About Skull Size and Intelligence - <AUTHOR> https://www.smithsonianmag.com/science-nature/alice-lee-statistician-debunked-sexist-myths-skull-size-intelligence-180971241/ <comment><USER2> Too bad she was wrong (which is not a surprise when you read OP's description of her ludicrous research - so you criticize direct measurements of brain volume as biased and offer as a replacement... some facial measurements, of range-restricted unrepresentative samples, by someone with her own axe to grind in a statistically-meaningless stunt? wow) and her debunking has been debunked. We have enormous brain imaging datasets now and the connection between human brain size and and intelligence is borne out in every sample and is real: most recently [https://scottbarrykaufman.com/wp- content/uploads/2018/08/Gid...](https://scottbarrykaufman.com/wp- content/uploads/2018/08/Gideon-et-al.-2018.pdf) (not to mention the more obvious between-species correlations and other within-species correlations, most notably recently in dogs: [https://link.springer.com/article/10.1007/s10071-018-01234-1](https://link.springer.com/article/10.1007/s10071-018-01234-1) ).</comment>


It's 2019 and I Still Make Websites with My Bare Hands - <AUTHOR> https://medium.com/@mattholt/its-2019-and-i-still-make-websites-with-my-bare-hands-73d4eec6b7 <comment><USER2> _I'm not even kidding, this is how I still make websites: I open a text editor, and stub this out (by hand, it only takes like 30 seconds — I'll even do it as I write this post to be authentic — except stinkin' tab doesn't work here):_

      <!DOCTYPE html>
      <html>
        <head>
          <title>I code stuff with my bare hands</title>
          <meta charset="utf-8">
        </head>
        <body>
          Hi there
        </body>
      </html>

_Then I open a new tab and make a CSS file; something like this:_

      * { margin: 0; padding: 0; box-sizing: border-box; }
      body {
        font-size: 18px;
        color: #333;
      }
      p {
        line-height: 1.4em;
      }

Same here. The main advantages are brevity, speed, and debuggability.

Having tried CSS frameworks like Bootstrap on the one hand and vanilla HTML/CSS on the other, I really don't see the attraction of frameworks.

It's not hard to quickly build something that works decently without prefabricated components. In the later phases of a project, I find it much easier to maintain a code base free of third party material.

<comment><USER3> I am interested in learning this style but keep getting drawn into some frameworks. What order would you recommend learning to create sites in this style?

<comment><USER2> I can think of two approaches:

1\. Get a better idea of the tools already at your disposal (HTML5, CSS3). I can recommend Dive into HTML5 [http://diveinto.html5doctor.com](http://diveinto.html5doctor.com)

2\. Start building. Literally, start with the barebones Hello World given in the article. Then gradually turn it into your site, making liberal use of Stack Overflow (direct search) and Google.

<comment><USER4> Thanks for the link. This whole thread is refreshing. I am someone who does not do web development for a living but occasionally builds a website. Every time I start building a new site I am at a complete loss where to start. Yet I have been doing HTML and CSS since 1999. I am going back to basics, starting with your link.

<comment><USER5> Open web inspector when you develop a website. You can get a better feel for how changing CSS on the fly take place on the actual webpage.

I would save a copy of the HTML from the top level comment of this thread and use it as a base to start any new project.

I like to start from scratch and add Bootstrap should I need responsiveness once I get to that point. L

<comment><USER4> Thanks for the tips.

</comment></comment></comment></comment></comment></comment><comment><USER6> Great article, but the takeaway is something so profound I fear a lot of people will miss it entirely when getting into the details.

It is:

Understand your tools.

And a second but equally important takeaway is:

Use the least amount of tooling to implement your functionality.

If you understand your tools and you use the least amount of tooling in order to implement your functionality, your website or app will be easier to maintain, more performant, possibly more secure (less code = smaller surface area of bugs and other problems to exploit), and it will train future developers in a more sane art of programming.

I recently inherited a codebase that was a monstrous combination of a Rails backend broken out into multiple namespaced modules + a giant grabbag of service objects + a React front-end with a shocking number of various components — all to accomplish a relevantly small number of basic web app-ish things. (And to top it all off, it was a failed product and I'm only working on it now because a biz dev friend of mine had purchased the product from the original devs.)

All that extra "web-scale" work…for a product that didn't even succeed. They probably could have _halved_ their dev time with a vanilla Rails app and some simple JS sprinkled on top (Stimulus for example), it would have worked perfectly fine, and they would have proven the app in the market (or not). Wait to get a thousand paying users — THEN rewrite with whatever fancy-pants frontend framework and microservices backend you like.

We really need to do a better job as an industry of pushing back against complex tools and complex development processes until they're _absolutely_ necessary. Don't reach for a jackhammer when a chisel will do just fine.

</comment><comment><USER7> Is anyone else the backend version of this? Instead of using Docker, Kubernetes, AWS, etc. write your own bash scripts to provision servers, deploy code, etc.

Instead of using fancy monitoring frameworks, just have a cron job that SSH into all your servers, and send an email if disk or memory usage spikes too high.

<comment><USER8> Lots of people are the backend version of this. And the front end. In one person.

If you add the backend skills above to the original post... It's what a full- stack developer originally was, and in my mind still is.

These folks can imagine a bug, features and architecture from different breadths and depths.

</comment></comment><comment><USER9> I prefer the workflow that the author does, minus the Jquery just so I can maintain some street cred. document.querySelector solved 90% of what jquery solved for me anyhow. For consulting clients, I've done plenty of what I consider the "exotic workflows".

My determination is that the primary benefits of react, angular, et al is that they organically create hierarchies among a group of multiple developers. It also creates a sense of depersonalization / derealization that helps everyone feel like they're working on their own while they're surrounded by people. Woe the walls we build!

Proxy was the nail in the coffin for ever using a framework in my personal projects again. I'll still use whatever your hip new project leader wants for money though.

<comment><USER10> "depersonalization" and "walls" is one way to put it. Though think of it from another perspective: You'd need to keep a team pulling in the same direction and speak a common language. When one person coded up something without any framework, they may understand the code structure perfectly, but the others who collaborate with them can easily get lost/be detoured. Publicly existing frameworks have conventions, docs and communities and a certain way of organizing things, which makes it much easier for a team to avoid wasted efforts.

</comment></comment><comment><USER11> Erh, I did the same for small personal websites but maintaining the content and having to change things on multiple pages made me switch to a build step. I do not understand how the author would deliver a website to clients without pulling in content from a (headless) CMS.

<comment><USER12> Sometimes you gotta do that. The Caddy blog is run with Hugo after every git push.

</comment></comment><comment><USER13> For web sties this makes sense, but what about applications that happen to run in the browser. There must be a certain size / number of contributors where this no longer is the best option?

<comment><USER14> The key is that modal number of contributors is probably 1.

</comment></comment><comment><USER15> I used to make websites likewise (html boilerplate, css links and script tags at the bottom of body). I liked the no frills simplicity of it. But years ago I switched to using frameworks and don't think I would go back. Yes I _could_ implement my sites in vanilla js and frankly it would be fun! But I would spend too much time reinventing the structure I get ootb with frameworks.

</comment><comment><USER16> I'm not sure I quite get the author's long running (over)use of the term 'bare hands.'. I don't think the analogy works well in programming, and doesn't convey what it actually means.

</comment><comment><USER17> love caddy

</comment><comment><USER18> Same.

</comment><comment><USER19> This article is just a poor ad attempt for the author's commercial products.

I don't mind when someone advertises their product through a good article, but this was way too condescending.

The title is also click bait as in he only occasionally writes extremely basic static websites for his own products.</comment>


Firefox 29 sucks - <AUTHOR> http://www.dedoimedo.com/computers/firefox-29-sucks.html

<comment><USER2> Very diplomatic. The author could fork it instead of degrading their hard work that is, even if not perfect, work done. "To the world out there, I demand a fundraising project..." But instead author 'demands' others funding?

</comment><comment><USER3> i don't see what's wrong with it. same as before, only i can move everything around.

that said, some people don't like change, which is fine, it's what themes and extensions are for. [https://addons.mozilla.org/en- US/firefox/addon/classicthemer...](https://addons.mozilla.org/en- US/firefox/addon/classicthemerestorer/)</comment>


Ask HN: How do Startups Look for Employment Candidates?  - <AUTHOR>

Hey there HN.
I went from a grunt-level help-desk employee, to team leader, to office support specialist, to IT Manager in about two years.  Almost all of this came from resourcefulness in my field, making connections with larger companies and helping my parent company attract new business.  Towards the middle of 2009, I struck out on my own and used my oversized wallet, full of business cards to my advantage.
I turned into a business consultant who specialized in candidate placement and HR assistance.  This started with me making cold calls to companies I had made connections with, reintroduced myself and offered my services to scout, review, interview and recommend outstanding individuals new and emerging companies.  A lot of what I did was very old fashioned, but it worked and everyone was happy.
Well, just a few minutes ago I read through the Dropbox: Startup Lessons Learned presentation, which got some gears turning in my head: exactly how do startups go about hiring?  I know a few post job postings here on YC, what about the others?  Do they have hiring managers?  Do they outsource?  Do they throw up a job posting, hope someone will reply and then pull a senior team member away for a few days to review the applicants?
That's my question: for the average software startup, what is your candidate review process?  Is outsourcing candidate placement even a viable option for startups?  It works well in corporate environments, but I think this is something I want to start looking at more seriously. <comment><USER2> In my experience:

Their network. So you're doing well there.

When that's exhausted, if they can't afford recruiter fees, classified ads. I would assume Craigslist nowadays.

Only if and when they can afford recruiters fees _and_ there is one good one in their area do they turn to them. My last experience there, in 1997 or so, was that only 1/2 of the resumes sent to us by one of the two best in the D.C. area were potentially viable (I can't remember how many we made that judgment about before or after the interview).

Outsourcing candidate placement ... yow. I don't know. If a company takes recruiting seriously, its top people are going to spend the time it takes to do it right. To the extent you could off load some of that burden it would be great, but for technical staff you're going to have to get a good programmer in your team, someone who can administer the "can you program your way out of a paper bag" tests. Ditto for systems, unless you've developed enough skills on the side in that area.

Good luck; this is a field that is not done well and needs all the help it can get. I'd recommend spending a lot of quality time on this site <http://www.asktheheadhunter.com/> for some additional tips and such.

Pay particular attention to this essay, "Death by Lethal Reputation": <http://www.asktheheadhunter.com/halethalrep.htm>

" _On the surface, the company's problem was a nasty reputation for a number of bad hiring habits. At a deeper level, the problem was a lack of pride and a lack of concern about how it presented itself to its professional community. If the company had been able to shake the bad habits, it might have been able to regain the respect of its community._ "

To the extent you can help companies avoid problems of this nature while they're in furious heads down startup mode you could add serious value to your services.</comment>


Why Earth's History Appears So Miraculous - <AUTHOR> https://www.theatlantic.com/science/archive/2018/03/human-existence-will-look-more-miraculous-the-longer-we-survive/554513/?single_page=true <comment><USER2> It brings to mind the sentient mud puddle.

If a mud puddle were sentient, it might marvel at how the mud around it was so perfectly shaped so as to exactly match the shape of the water the puddle was made up of. Amazing. Unbelievable. Couldn't be a coincidence, that there's such a perfect fit. What are the chances that this unique shape of the water outline would be matched exactly by the shape of the mud around it. A true miracle, it might think.

Unless the sentient puddle gave the matter just one more moment's thought, in which case it might conclude that the water and the shape of the mud around it matched for no reason other than that the water flowed to fit the mud.

<comment><USER3> The anthropic principle doesn't make our universe any less surprising. It's like saying "of course I survived that catastrophic accident, otherwise I wouldn't be observing the fact I survived the accident."

<comment><USER4> The difference is that we have a decent amount of information on the number of catastrophic accidents that occur and the number of people who survive them. Since that number is known to be low, there's nothing unsurprising about your own survival of such an accident.

But we don't know the number of times life has emerged in the universe, except that it is at least 1. Every intelligent life form we are aware of are one "survivor," but we knew very little about the number of total survivors in the universe. Thus it is a little odd for us to claim that our "survival" is surprising.

<comment><USER5> I haven't read the article, yet, so I'm not sure it didn't mention this, but the fact that the universe we see appears natural and unworked is a powerful argument for the number of "survivors" being ultra-low.

<comment><USER6> Or maybe we're just first? Depressing either way.

</comment></comment></comment></comment></comment><comment><USER7> This is a good way to solve problems in NP. First, guess an answer uniformly at random. Check if it's correct (in polynomial time). If it isn't, blow up the planet. Conditioned on surviving, you also have solved the NP problem in polynomial time.

You can also use a world-ending device to prove that this reasoning works. Blow up the world with probability .99999999999. Conditioned on surviving, you will then be nearly certain that quantum hell is real- more certain than about nearly any other physical theory.

The other problem is that depending on how you count, almost all observers are actually hallucinating Boltzmann brains. There are duplicates of us, but there are arguably even more pocket universes with hallucinating brains that just very briefly remember being something like us and then die.

So that's not very reassuring.

</comment><comment><USER8> What a great trippy article... most pop-sci articles are not worth reading, but this one really held my attention the whole time. Even though I have heard of a lot of these ideas before, I never heard them put together in this way, like your consciousness is a thread in the multiverse constantly avoiding destruction! I always thought if the multiworlds thing was true, it would be like each person living their lives unaware of the others... but maybe not. Pretty weird to think about and probably we will never know... All though if I end up living to 1000+ years old, maybe I will become convinced.

</comment><comment><USER9> This principle is also why creationists don't understand how the world around us seems so engineered for us. That's because it was engineered... by our ancestors. The peach is a great example of this. Peaches didn't exist 3,000 years ago, but were engineered from a bitter, mostly-pit fruit through artificial selection into what we enjoy today. The same is true of corn, tomatoes, lettuce, cows, chickens, and so many other agricultural products. These things never existed in nature, we engineered them, but we just see the end result.

A fascinating aspect of this I learned about recently was the importance of fire to human development. I always imagined this tool in the context of humans huddled around a campfire for warmth and cooking, but our ancestors actually applied it on a much more epic scale. They burned down entire forests to create open fields where predators couldn't hide and where they could forage for well-cooked critters amid the ashes. Everywhere we migrated, we geoengineered forests into savannas.

</comment><comment><USER10> Makes me think about the Fermi paradox [1] and Great Filters [2]. But for all we know the universe could be full of life at chimpanzee intelligence; no way to know unless we send probes [3] or seriously up our telescopes [4].

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

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

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

[4] [https://en.wikipedia.org/wiki/FOCAL_(spacecraft)](https://en.wikipedia.org/wiki/FOCAL_\(spacecraft\))

<comment><USER11> The Fermi paradox is unlikely to be answered by something making it very unlikely for our chimp level ancestors jumping to human level. The number of Homo species on the planet that co-evolved to human level intelligence suggests this is not extremely difficult.

What is a huge filter is the requirement of a stable climate over million of years. The key to this is the Moon which keeps the Earth's axis of rotation from wandering over a wide angle on geological timescales. The Moon is so large and unlikely (we still don't have a good theory for how it was formed and captured by the Earth) that this alone could explain the lack of other intelligent life in the visible universe.

<comment><USER12> >>"[..] Homo species on the planet that co-evolved to human level intelligence [..]"

Can you elaborate on this? I'm a little at lost about what you mean.

<comment><USER11> There were at least two other _Homo_ species that co-evolved to human level intelligence separate from the one that arose in sub-Sahran Africa. The reason we know this because at least two inbred with the African _Homo sapiens_ ; _Homo neanderthalensis_ and _Homo_ "Desnisovan" [0].

0\. [https://en.wikipedia.org/wiki/Archaic_human_admixture_with_m...](https://en.wikipedia.org/wiki/Archaic_human_admixture_with_modern_humans)

</comment></comment></comment></comment><comment><USER13> Once I dreamed that I lived through a nuclear war, I dreamed the aftermath and my life scraping and scrapping through a shredded world. The dream brought me to the house in the woods where I live now, but in that world it was tattered and burned and no children lived there. I laid down, grateful for a dry spot and a wall that split the wind. I woke here, but not there.

</comment><comment><USER14> The article mentions Max Tegmark; if you thought this content was interesting I highly recommend reading Tegmark's book _Our Mathematical Universe._ A totally mind expanding read.

<comment><USER15> It is the most satisfying GUT I have seen described, even if it isn't rigorous, formal, etc. It simply satisfies my inner voice saying "the feeling that we are special in any way is wrong".

Naturally, that's only true for a very emotional level of special :) but so far, I'm happy with _just_ the specialness of being a massively complex life form.

</comment></comment><comment><USER16> Many worlds hypothesis is the atheistic solution to the observation that our universe appears to be tuned for life.

<comment><USER17> Not so long ago, it was scientific dogma that all life on this planet was dependent upon photosynthesis. Then some oceanographer types sent some cameras down to the sea floor to look at some hydrothermal vents and... there went that idea! Is our universe tuned for life or is life tuned to its universe?

<comment><USER16> That would be a great comparison if the many worlds hypothesis were proven or even provable. As it stands, it is basically just a belief which is held to explain the scientific facts. Not much different from ancient man's belief that spirits had influence over the weather cycle. Check out [https://strangenotions.com/flew/](https://strangenotions.com/flew/)

<comment><USER18> Many worlds is an interpretation of quantum uncertainly, but what we seem to be talking about here are multiverse theories.

One of these, M-Theory is an extension of string theory and is the only theory known to elegantly unify quantum mechanics with general relativity's gravitational force in a mathematically consistent way. It's not supported by experimental evidence yet, but I'd hardly characterise it as no different from belief in spirits.

<comment><USER16> Actually, I _am_ referring to 'many worlds' (at least according to the technical explanation in this article: [http://blogs.discovermagazine.com/cosmicvariance/2011/05/26/...](http://blogs.discovermagazine.com/cosmicvariance/2011/05/26/are- many-worlds-and-the-multiverse-the-same-idea/#.WqxexpPwbh8)) and not a multiverse. And yes, there is some hope that there will be some testable empirical evidence at some point, but if in the end it turns out that there are not 'many worlds', then I don't see that big a difference. I'd love it if there were parallel dimensions but it is fantasy at this point.

<comment><USER19> Really your arguments work equally well for any multiverse theory, be it quantum or cosmological or mathematical.

</comment></comment></comment></comment></comment></comment><comment><USER20> I didn't get through the whole thing, but if there are big meteor impacts, wouldn't we see them on other planets in the solar system? They mention Hale- Bop for instance. Surely we can work out a probability distribution from the evidence we have besides Earth.

<comment><USER21> The two largest impact craters we know of are on the Moon and Mars, and those happened about four billion years ago. Of course we'll never know for the gas giants. Not doing the math, but this makes the odds seem pretty low after the initial "flurry" of our solar system's birth, barring Jupiter perturbing an existing asteroid into a collision into earth. [https://en.wikipedia.org/wiki/List_of_largest_craters_in_the...](https://en.wikipedia.org/wiki/List_of_largest_craters_in_the_Solar_System)

</comment></comment><comment><USER22> I think this provides a new answer to the "Great Filter" question. Is it before us or after us? The answer is both.

</comment><comment><USER23> "It could be that we've been shielded from these existential threats by our very existence."

Lots of misleading casualty statements like this in the article.

Still enjoyed it.

</comment><comment><USER24> Kind of ironic to think that humans survived a million-year ice age, then might be destroyed by some fool with a button.

If 'our universe' is 'tuned for life', it certainly isn't specifically tuned for human life (e.g. plague, volcanos). Nature offers us no guarantees. Unless we stay in tune with that accord, we will be removed.

<comment><USER21> Aren't homo sapiens here only because an asteroid strike around 70 million years ago caused a culling that killed the dinosaurs and sort of reset life to favor small mammals over the dinosaurs? If perhaps that had not hit the earth, we would not be here and something that evolved from dinosaurs would be the top of the food chain and typing comments here! We had to get that one strike in at the right time (from our perspective) and then not another semi- apocalyptic event to get to here.

</comment></comment><comment><USER25> Trippy article. Wikipedia, as always, is a good place for a deeper dive into this:

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

</comment><comment><USER26> That's the stuff of nightmares right there.

<comment><USER27> Kinda bums me out that with data on so many galaxies, we see absolutely zero evidence so far for any galaxy wide effects from intelligent life. It seems likely that intelligent life arising in a single galaxy is rare, and that it's almost certain we are the only intelligent species in our own.

</comment></comment><comment><USER28> Great mind fuck.

</comment><comment><USER29> I can't help but think of what the 17 families in Parkland, Florida would think of this article. Especially this quote:

"This is a defense against instantaneous, violent death, which you will find was avoided, but anything that sort of maims or injures or mangles you or whatever is still fair game."

<comment><USER30> On the macro scale, he's right. On the human scale, however, your number could be up any second. When I get into debates with people about security and the erosion of rights under the guise of security, I'll eventually say, "You can only be so safe. In the end a determined killer WILL kill someone, even if it's only by biting them to death. There WILL be successful terror attacks. There WILL be random attacks of violence, the question is, how much freedom do I want to lose before I realize that there will always be danger in the world?" That makes people feel I'm a nihilist or something, but it's the truth. I enjoy living, I Want safety for people, but we can't wrap the world in Nerf. Life is a trap no one gets out of alive. If you're alive today, you're lucky nothing killed you along the way, enjoy it while you can. With stuff like the Florida school shooting, we should absolutely do something about guns and gun culture because it's needlessly killing kids. But making me take off y belt at the airport isn't saving anyone, or worse, saying the TSA /customs/the gov't in general should have the right to my passwords to get into my computer because "if you're not doing anything wrong you have nothing to hide" is absolutely terrifying and wrong.</comment></comment>


The Evolution of the Web - <AUTHOR> http://www.evolutionoftheweb.com/#/evolution/day <comment><USER2> This is a nice web technologies demo, and there is good information in here ( I especially like the browser screenshots), but the thing I find most striking about this is how useless it is at visually illustrating the 'evolution' of the web.

I wrote a blog post about this when it first appeared last September: <http://halfblog.net/2011/09/01/the-evolution-of-the-web/>

Now it has become even flashier, and even more cluttered and confusing. The swooping colourful lines mean absolutely nothing. I realise they arc through the different browsers to (roughly) the point at which those browsers adopted the technology, but the swoops themselves only serve to confuse the information.

Very much a case of style over substance. This is a horrible infographic, and I'm confused why it seems to be so popular.

<comment><USER3> I agree.

The swirling lines begin to tell an interesting story: from 1994-1997, and then again from 2008-2012, lots of technologies enter the picture, so we get some sense of when the bursts of innovation happen.

The clutter of the lines - and their tending to vertical rather than more horizontally slanted - suggests that browser adoption of technologies is quicker from 2008 on.

But this is impressionistic at best, and vertical vs. horizontal in the technology adoption lines is mostly a side effect of how close the lines representing the browsers adopting the tech are to one another.

I'm also wondering about when the tech lines are introduced. E.g. web fonts (in purple, swooping in from the bottom) shows up around 2000 but doesn't hit a browser version till 2008.

CSS2D transforms (purple, from the top) starts in 2009, swooping backwards in time to hit Safari 3.1 in 2008.

If these two swoops correspond to the real story that web fonts were designed much earlier than they were adopted, and CSS2D transforms were implemented before they were formally designed (perhaps by W3C), then that would be very cool. But I fear it's just as likely that the introduction points are arbitrary.

If anyone knows the stories of the design and adoption of CSS2D transforms or webfonts, I'd be grateful for a little enlightenment.

</comment></comment><comment><USER4> Very cool demo of modern web technologies, though things get messy towards the end with all the intersecting lines.

The most interesting thing about the evolution of the web is when Chrome arrives in 2008. Chrome has essentially remained unchanged visually since 1.0. Look at the design of browsers change once Chrome hits. Pretty remarkable.

It's pretty clear that Chrome's release was vital to the modern web of today. The most obvious one is the GUI, but they changed the game for web technologies and the speed at which we interact with the web.

Firefox introduced extensions and changed the game for a lot of us. Then they basically took a nap for 5 years until Chrome came out. I wish I knew what went wrong...

</comment><comment><USER5> Nice visualisation, very pretty but as others have stated, not very usable. One thing this demonstrates clearly is at the breakneck speed the web is evolving at the moment, the mess from 2008 onwards clearly shows this.

While i wasn't worried before, it kind of reaffirms my feeling of security of the ability to make a living as a web developer, I doubt i'll starve in the next 10+ years...

</comment><comment><USER6> Technology wise I think it's great. However, from a clarity point of view and ease of interpretation I think it needs more work as it takes a fair amount of brainpower to try and digest. It's no easy task though picturing the evolution of the web so hats off to them!

</comment><comment><USER7> This is about as clear a visualization as you can get to show that the mere existence of Chrome has rewritten what "evolution" means for the web.

</comment><comment><USER8> According to the graph, there were 100 million internet users in 1996, and the same number in 2001.

I find that questionable.

</comment><comment><USER9> No Netscape Navigator?

</comment><comment><USER10> Where is HTML5?

<comment><USER2> Bottom, below Chrome.</comment></comment>


Ask HN: When to use a Wifi Pineapple? - <AUTHOR> I tend to travel. It would be nice to not connect directly to public Wifi but rather have my own Wifi device that connects to it that I am then behind. <comment><USER2> There are other devices that would probably be more appropriate for this use. I bought this device [https://www.amazon.com/gp/product/B01K6MHRJI/ref=oh_aui_sear...](https://www.amazon.com/gp/product/B01K6MHRJI/ref=oh_aui_search_detailpage?ie=UTF8&psc=1) for travel. I wanted a robust firewall and VPN client capability. It has worked very well. I use my Wifi Pineapple as a learning tool. It gives practical experience with hacking techniques.

<comment><AUTHOR> This devices supports OpenVPN and Tor, does it update it's software easily?

What is the difference between the one you mention and this: [https://www.amazon.com/GL-iNet-GL-MT300A-Pre-installed- Perfo...](https://www.amazon.com/GL-iNet-GL-MT300A-Pre-installed-Performance- Programmable/dp/B01DBS5Z0W/ref=pd_sim_147_5/142-7064876-8269134?_encoding=UTF8&pd_rd_i=B01DBS5Z0W&pd_rd_r=95M33K7WS6GD6Q36GGY1&pd_rd_w=3beLG&pd_rd_wg=Wq7Z6&psc=1&refRID=95M33K7WS6GD6Q36GGY1)

Can I upgrade the antennas, do you know?

Edit: it looks like it can take PR-SMA female as a connector.

</comment></comment><comment><USER3> I use a DIR-505L. It's a wallwart and runs OpenWRT. 2.4Ghz only, but isn't too expensive (~$15). Has USB/ethernet if you want more. Really convenient and kind of looks like a phone charger so it doesn't raise eyebrows.

Mine runs OpenVPN in bridge mode to an SSID. I rarely use the ethernet. And I sometimes use the USB port as a charger. Having a usb cable connected to the wallwart makes it look like a charger. :)

Was also looking at the TP-Link TL-WR710N, but I preferred the more wallwart looking and slightly more compact D-Link. It does have an extra ethernet port if that's a requirement. TP-Link's locking down of thirdparty firmware also led me to keep the D-Link and return the TP-Link. I think they got better about that though.

<comment><AUTHOR> Thank you! They seem to be about $60 on Amazon. [https://www.amazon.com/D-Link-SharePort-Companion- Certified-...](https://www.amazon.com/D-Link-SharePort-Companion-Certified- Refurbished/dp/B010U9FFI2/ref=sr_1_4?ie=UTF8&qid=1499457094&sr=8-4&keywords=DIR-505L)

<comment><USER3> Check out the dlink shop on ebay! :) [http://www.ebay.com/itm/D-Link- DIR-505L-SharePort-Mobile-Com...](http://www.ebay.com/itm/D-Link- DIR-505L-SharePort-Mobile- Companion-/171994892670?hash=item280bb1c97e:g:4TMAAOSwu-BWQkdQ)</comment></comment></comment>


Front End vs. Back End - <AUTHOR> https://zellwk.com/blog/frontend-vs-backend <comment><USER2> I'm a backend developer. I like the switchboard analogy, but I usually think of myself as a plumber, piping information from one place to another.</comment>


Ask HN: My Startup Needs Better Access To _______. - <AUTHOR>

<comment><USER2> Marketing and promotion consultants.

</comment><comment><USER3> Customers

</comment><comment><USER4> Advisers</comment>


Bad Ranchers, Bad Cows - <AUTHOR> http://dailypitchfork.org/?p=742

<comment><USER2> That's an excellent set of essays on how we give carte blanche to ranchers, as well as ones pointing out the real problems in Allan Savory's much hyped grazing proposal.</comment>


Crash course to Amiga assembly programming - <AUTHOR> https://www.reaktor.com/blog/crash-course-to-amiga-assembly-programming/ <comment><USER2> Awesome article OP, thanks for linking it here; I've been looking for something along these lines for the Amiga for a while, actually.

Tangentially related: if you haven't already, I'd suggest dabbling in development for these "retro" systems. Not only will they teach you about memory management, &c but you will also be able to familiarize yourself with architecture of decades past. Much like a Shakespearean scholar doesn't just reader William's texts, but also attempts to understand the sociopolitical climate in which they were written; so, too, ought a proficient programmer see where she has come from to integrate not just "best practices" but an optimism which guides her progress.

Or one could just read Stack Overflow. _shrugs_

<comment><USER3> I'm a huge Amiga fan, but what is there to learn from it that couldn't be obtained by working at the lower levels of a modern system?

<comment> white-flame Devices are memory-mapped without going through many nested protocols (USB, PCIe, etc). What drivers do is completely transparent. Library calls are a simple subroutine which jumps into the real details, without a privilege barrier.

Much of the accessibility of the architecture is that it's a single address space, with no MMU interference to speak of (later models had MMUs, but where only used for a few enhancements here & there at best).

Besides, 680x0 code is _much_ more pleasant to deal with than x86. But that's the case for pretty much any non-x86 ISA. ;-)

</comment></comment></comment><comment><USER4> Nice to see articles on how to code from a modern host. Last time I coded Amiga assembly was on an actual Amiga 2000. Blitter, Copper, non maskable interupts, ahh the memories

as an aside, the VR community right now in 2017 is in the very early Amiga stage. Theres Atari ST vs Amiga, ( Oculus vs Vive ). Also individual coders can have a widely played and adopted game / experience. The games are fun and not overly complex and there's some great early adopter communities ( /r/Vive )

<comment><USER5> What did you use NMI for?

I've coded a lot of asm, blitter and coppper on the Amiga but I don't recall ever using NMI's.

<comment><USER4> 1) I think the debugger used it 2) I had an Action Replay that used it 3) It existed 4) I had some off computer hardware I was talking to

memory a bit hazy !

</comment></comment></comment><comment><USER6> It seems like every month or so on HN there's a new Amiga post, and this has resulted in me becoming slightly obsessed with the machine (even though I never had one as a kid since they weren't terribly popular in the US).

Learning the assembly sounds like it could be a fun weekend project, so thank you!

</comment><comment><USER7> The beauty of old school 68k assembly is _astounding_ compared to the unstructured, messy piece of garbage that is X86 assembly.

Intel should be ashamed of themselves for 20 years later still not having cleaned up their act.

<comment><USER8> Indeed.

        mov esp, 0

"Move 0 into esp".

Seriously, X86? Who came up with that?

<comment><USER9> What is wrong with that? Besides the fact that the canonical way to zero a register on x86 if flags are of no concern is

      xor reg,reg

(recommended way) or

      sub reg,reg

<comment><USER10> It's wrong if you try to read it as "move 0 into esp" because the source and destination are reversed in code from how it's expressed in English. The way to fix that is to use the other syntax, or change how you think of the English. If read like Lisp, then it's "set esp to 0" and 'mov' is just a poor mnemonic.

</comment></comment></comment></comment><comment><USER11> If you think that article is awesome, you should fasten your seatbelts and check out this video tutorials by Photon of Scoopex (Demo Group).

[https://www.youtube.com/watch?v=p83QUZ1-P10&list=PLc3ltHgmii...](https://www.youtube.com/watch?v=p83QUZ1-P10&list=PLc3ltHgmiidpK-s0eP5hTKJnjdTHz0_bW)

<comment><AUTHOR> That looks awesome - thanks!

</comment></comment><comment><USER12> Arrrgh! Great article (and there goes my weekend) - but this article reaches my eyes 25 years too late. I would have killed for this information as a kid!

<comment><USER13> I actually got started coding Assembly on the C64. I found the C64 was much easier to code to. I keep telling my kids, "If I had youtube tutorials when I was a kid I would be ruling the world."

</comment></comment><comment><USER14> I saw this at the end of the article, was hit by a huge wage of nostalgia, and had to comment:

> Update 9.10.2015: exec.library base address is stored in > memory address > $4. The library base address itself is not $4.

I learnt 68k assembler for the Amiga in high-school and made _exactly_ this mistake. After many "guru mediations" (the flashing red and black box) and much head-scratching I finally realized the problem.

It was a big breakthrough in my early days as a programmer and taught me a solid lesson about indirection and pointers.

</comment><comment><USER15> This was an interesting read, though I've never really delved into 68k assembler, even when I was playing with the Amiga.

In the early 1990s I purchased an Amiga 2000, then a couple of years later an Amiga 1200. A few years after that, Commodore "died" and I moved to a 486 and Windows (though I had used a DOS-base laptop prior to that). A few years later I move to Linux.

I still have my Amigas, and my 1080S - but I have no idea if any of it still works; they haven't been booted in over 20 years (though I have kept them stored well). I've thought about getting them running again; maybe someday (I've got more actual retro hardware than I have time and space for, honestly).

</comment><comment><USER16> Great Article!

The Amiga community is 100% alive and well, with new software and hardware being developed all the time. If you were a fan of the Amiga then now is a great time to jump back in and see the fun stuff that the community is doing.

</comment><comment><USER17> I'm tempted to jump back in. Back in the day programming involved books and a lot of guess work. Now I can google the hell out of any problem.

</comment><comment><USER18> A bit off topic:

I'm looking to get an Amiga mainly to run Octamed and get that Paula chip sound. Can someone suggest a model to buy?

<comment><USER19> Paula is exactly the same across the whole Amiga range AFAIK, so no difference when it comes to sound.

Not sure how much resources Octamed requires though.

An A1200 with CF hard disk + ACA board seems like a safe bet

<comment><USER20> There are differences in audio low pass filters between different Amiga models. It can't be ever entirely disabled. I think Amiga 1200 filter affects the sound the least.

IIRC, AGA chipset (Amiga 1200, 4000) is also capable of up to ~56 kHz sample rate.

OCS/ECS is just up to 28 kHz.</comment></comment></comment>


Back to the Future attack on HTTPS - <AUTHOR> http://arstechnica.com/security/2015/10/new-attacks-on-network-time-protocol-can-defeat-https-and-create-chaos/ <comment><AUTHOR> Since a catchy name is now de rigueur for an attack to get recognized and get coverage, and given the perfect timing of this announcement, I hereby donate this name to science.

<comment><USER2> It breaks the HN guidelines to editorialize the titles of stories you submit to HN, so please don't do that.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


Bay Area Housing Hack Guide - <AUTHOR> http://info.meteor.com/blog/housing-hack-guide <comment><USER2> This... is an odd post on Meteor's blog. Cool, I guess?

</comment><comment><USER3> Cool! This is a super awesome guide. Wish I had this when I was looking for an apt. in SF...</comment>


Show HN: Yumcoin - Share and sell your digital creations for Bitcoin - <AUTHOR> https://yumcoin.com

<comment><AUTHOR> We built Yumcoin because we think existing solutions for accepting Bitcoin are too complicated. A few people have to built custom sites to accept Bitcoin for their products (eg. Knife Party, James Altucher), but we think the process can be a lot simpler. We host your product, give you a short link you can share with your audience, and manage the Bitcoin payments for you.

There's lots of new features we're working on, but it's already useful and fun.

Here's an example Yumcoin link: <https://yumcoin.com/p/osZO>

Check it out, and let us know what you think.

</comment><comment><USER2> Here's the way to build your own online store for $0 and pay $0 + 0% on every sale:

1\. Install self-hosted wordpress - usually few clicks via your hosting company's CPanel.

2\. Install WooCommerce wordpress plugin to make online store: <http://wordpress.org/plugins/woocommerce/>

3\. Install BitcoinWay plugin to make sales in Bitcoins as well as in any other currency: [http://wordpress.org/plugins/bitcoin-payments-for- woocommerc...](http://wordpress.org/plugins/bitcoin-payments-for- woocommerce/screenshots/)

NOTE: Your bitcoins are completely safe as above setup sends bitcoins directly into your personal Electrum wallet without relying on middleman and it does not need to store your bitcoin private keys anywhere whatsoever.

<comment><USER3> A _lot_ more effort and predicates you already have hosting.

<comment><USER2> One-time, few clicks effort to build your own business, earn residual value and avoid paying percentage of your hard earned sales to middleman.

Your mileage may vary.

</comment></comment></comment><comment><USER4> > _Yumcoin takes just 1% + .0025 BTC from each sale._

A fixed component of the commission for a deflationary currency? The only people putting that into their critical path were not paying attention in economics classes.

</comment><comment><USER5> I'd like to know more about the security measures you guys take. I've been working on a personal project, and haven't found any good guides to securing bitcoin transactions and managing private keys properly (assuming you host the bitcoin client on some server somewhere).

<comment><AUTHOR> Obviously, the security and scalability of our platform is a big part of the value we provide to buyers and sellers.

For now, know that there are a number of measures we take to ensure that the site and users' bitcoins are secure: The site runs entirely over SSL (HTTPS). We protect against CSRF and XSS attacks. The addresses used for purchases are generated offline. Withdrawals are handled separately from the application server. Importantly, sellers can withdraw their balances quickly to the Bitcoin address of their choice. As we scale up, we'll store the majority of sellers' funds offline, keeping enough for transaction fees and withdrawals.

We'll be writing a more detailed overview of how we handle security here: <https://yumcoin.com/security>

<comment><USER5> Thanks for the overview. It's refreshing to get straight answers.

Which wallet are you guys using? I've heard good things about armory which make it easier to do hot / cold storage. Keeping withdrawals separate from the application server makes a lot of sense; is this using the SSL protocol for JSON-RPC on a non-standard port, and then closing off internet facing ports for that computer/server?

Are you doing any sort of 2 factor authentication to limit hacked accounts getting emptied?

I'd be happy to email or something if you're up for it.

</comment></comment></comment><comment><USER6> Your email validation is too strict, my perfectly valid email (.me TLD) was denied.

<comment><AUTHOR> Email validation has been fixed. The .me TLD is working fine now.

</comment></comment><comment><USER7> So this is quite much like Gumroad but with bitcoin. I think that it is perfect for ebooks.

As there is now a bitcoin-gumroad, is there anyone planning a bitcoin- kickstarter?

<comment><AUTHOR> Music, video, and ebooks are three of the most popular types of products you'll find on Yumcoin.

</comment></comment><comment><USER8> I was just reading another thread and remarked to myself how negative people can be on this site, yet here I go. Sorry - Absolutely terrible logo, guys. Completely awful.

</comment><comment><USER9> Is there a list of of examples somewhere?

<comment><AUTHOR> Here's what the product page looks like:

<https://yumcoin.com/p/osZO>

<comment><USER9> Thanks, the service looks pretty cool, you should maybe consider a categorised catalog of items.

<comment><AUTHOR> Glad you think it's cool! We have big plans for launching online stores and catalogs through the site, but this is the "MVP". Right now we're focused on making it fast and easy for creators to share products with their audience and accept Bitcoin.

</comment></comment></comment></comment><comment><USER3> I'm impressed and excited to see where this is going.

Are all creations previewed?

<comment><AUTHOR> Thanks! The product preview is optional, but it makes the page look better and can help to sell the product.

The preview media link is provided by the seller in addition to their product's file. For example, it could be a YouTube link to the trailer for an independent film, or a SoundCloud link to the preview for a full album.

<comment><USER3> I've just purchased the Atlantis Lemuria track and it worked great. I got the file a few seconds after I transmitted the funds.

One suggestion: as a customer, the landing page could display the items that I've bought.

<comment><AUTHOR> That's a great idea and we'll add it soon. Really glad you like Yumcoin!

</comment></comment></comment></comment><comment><USER10> Nice site design. Is that a freely available Bootstrap theme?

<comment><AUTHOR> Thanks. It's a custom design based on Bootstrap.

</comment></comment><comment><USER11> Could this be changed to also accept other cryptocurrencies?

</comment><comment><USER12> I'm not going to create an account just to browse a catalog.

<comment><AUTHOR> There's no catalog yet, and you only need an account to sell products. Buying a product is easy and does not require an account. You just need some Bitcoin... here's an example: <https://yumcoin.com/p/osZO></comment></comment>


:CueCat is back - <AUTHOR> http://www.joelonsoftware.com/items/2008/01/29.html <comment><USER2> There are several ways this is different than the :CueCat.

1) I don't have to install an unsightly hardware component

That's right. I already have my chic phone tucked snugly at my hip. It's already with me wherever I go. The only thing I install is an applet that 'grabs' photos that meet certain requirements. And I don't know about you, but my phone cam is 1 click away (2 to actually get the picture taken).

2) The information can be immediately useful.

So there's a new restaurant in town. I want to check it out...but what's on the menu? And I -could- take 4 minutes to type it into my phone, but why? Snap, and I have an address I to which I can tell Google Maps to direct me. That's -far- more than typing in a 7-letter word.

3) Note taking

If I'm at home (where my :CueCat is), there's no motivation to do much more than walk over to my computer and type in a URL. But I've often seen products on the road or where I can't easily access my computer. Maybe I'm the only person, but by the time I get home, I forget some things from my day. If I could take a snapshot and browse at my leisure, I could be forgetful without stress.

4) Proprietary?

I don't know if the system is proprietary, but if it's not, there's no chicken-egg problem. You're already printing in print. You already have fine print. Why not put a little square that means something to a substantial chunk of people?

5) Controversy?

The :CueCat lost out on a lot of techheads because of privacy concerns. While the same concerns -could- apply here, they're not nearly as problematic. Plus, the techheads are ALREADY using the device, albeit overseas.

</comment><comment><USER3> There are instances where it is in widespread use. Japanese print ads have 2D barcodes on them. Even blogs and webpages have 2D barcodes, so you can access URL from your phone. (You can use the 2Dbarcode to forward the blog to your friends, which your phone already has a list of them)

There are a couple things different there. Most Japanese peoples' access to the internet has been through their cell phones, rather than through their computers. Landlines are much more expensive than having a cell phone. In addition, the majority of Japanese are in urban areas where they use public transportation. That gives them a lot of down time to play with their phones. The print ads in the train have the 2D bar codes on them, so people can check out the ad while they're riding the train. Given that unless you have a full keypad (real or virtual), it's still harder typing in a phone, than using a 2D barcode.

That said, I don't think Americans (Don't know about europe) will find as much use for 2D barcodes for print ads, as we drive everywhere.

However, if I'm walking around the city, I'd find it very handy to be able to check out how many tickets are left for a show and being able to buy tickets for the show from the URL in a 2D barcode on the print ad for a show across town for some impromptu entertainment.

It would also be useful if sewn onto tags of pillows, clothing, other products, etc, so that would provide product information, or at least a URL that has the manual, or specs. That way, if some piece were broken, it'd be an easy way to order replacement parts.

</comment><comment><USER4> Believe it or not, I still have a :CueCat.

I hacked it to output standard barcode numbers (unmodified it uses some silly obfuscated encoding to lock people into their software).

</comment><comment><USER5> Yes typing a short URL is relatively easy in current phones.

But 2D bar codes allow you to make each URL very long and contain a ton of other information. Which can be immensely useful for tracking the effectiveness of each print ad and each campaign.

</comment><comment><AUTHOR> It seems like this could be useful on product tags. Lets say you walk into a clothing store, find something, but they don't have it in your size. You image the barcode on the tag, find your size and order it online without ever leaving the store. Or, it could be used to display items that go well together...just a thought.

<comment><USER6> I don't understand why they force you to install an app.

Why not just txt msg (MMS) or email it (iphone/blackberry) and then get a response with a URL or even some basic inline text commands?

<comment><USER7> If you have to send a picture message or email in order to get a url back you might as well send a blank message. The most popular technique in the UK seems to be sending a keyword to a shortcode, eg "EAT to 2580"

There's an interesting breakdown of QR code usage vs blank message at [http://whatjapanthinks.com/2008/01/07/accessing-urls-in- adve...](http://whatjapanthinks.com/2008/01/07/accessing-urls-in- advertisements-from-mobile-phones/)

<comment><USER6> What if I send a picture of a barcode w/ the text "buy" and bam.. it shows up in the mail a few days later.

<comment><USER7> Perfect, bringing the impulse of real world transaction to ecommerce. Could even do it with a normal upc barcode instead of Qr/semacode.

Imagine being to do that with a music CD and the songs automagically start downloading to your phone (possible iPhone app?)

<comment><USER6> That would be very cool... I've read that scanning regular barcodes with a cameraphone is difficult, but I believe there are some people making headway with it.

If it were music, I'd rather just make a call to a number, have it listen to whatever song is in the background, and then download it for me.

Fred Wilson has talked about txt based commerce a bit as well - <http://avc.blogs.com/a_vc/2008/01/texting-in-purc.html>

<comment><USER7> I think you can do the phone call music purchasing in the UK with Shazam (2580)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> oh man i had one of those! high-quality cable for free..

</comment><comment><USER9> I still have one.</comment>


Beson – Binary Extended JSON - <AUTHOR> https://github.com/GoblinBear/beson-go <comment><USER2> I would strongly recommend to avoid any direct resemblance to the unsafe and illdesigned BSON format by mongodb which allows objects, js code or datetime being deserialized, whilst this one looks very safe. I'm just not sure yet if BSON allows arbitrary data being added by a MITM attacker, due it's support for primitive data to be encoded directly. This is the major weakness being added to the first JSON RFC in the 2nd.

There are still better designed, faster and more popular binary serialization formats available, such as MessagePack or Cap'n Proto.

</comment><comment><AUTHOR> BESON, short for Binary Extended JSON. Beson library is similar to BSON format used in mongodb. The major difference between beson and bson is that beson allows primitive data to be encoded directly. Beson is designed to transfer or store data in a binary format, not specialized for database storage.</comment>


AOL, Private-Equity Firms Explore Bid for Yahoo - <AUTHOR> http://online.wsj.com/article/SB10001424052748703673604575550661101743360.html?mod=WSJ_hps_MIDDLETopStories

<comment><USER2> Yahoo buying AOL or AOL buying Yahoo?

<comment><USER3> I think, neither of that.

It's more like Alibaba and Softbank are buying out Yahoo's Asian assets, then private equity firms take over the rest of Yahoo. After that they can merge it with something else or leave it alone.

Btw, a day ago YHOO was 14.58, today in after hours it was as high as 16.91.

(I am at Yahoo but have no insider information - this is just how I understand the press. Can be completely wrong.)</comment></comment>


A tutorial on the free-energy framework for modelling perception and learning - <AUTHOR> https://tmorville.github.io//finprojects/free-energy/ <comment><USER2> For the probabilistic graphical model and belief prop perspective, check out Friston et al. (2017) "The graphical brain: Belief propagation and active inference": [https://www.mitpressjournals.org/doi/pdf/10.1162/netn_a_0001...](https://www.mitpressjournals.org/doi/pdf/10.1162/netn_a_00018)

For the neural corollaries of predictive coding, check out Shipp (2016) "Neural Elements for Predictive Coding": [https://www.frontiersin.org/articles/10.3389/fpsyg.2016.0179...](https://www.frontiersin.org/articles/10.3389/fpsyg.2016.01792/full)

For a state-of-art CV framework that fits with the free energy principle, check out the Recursive Cortical Network from George et al. (2017) "A generative vision model that trains with high data efficiency and breaks text- based CAPTCHAs ": [http://science.sciencemag.org/content/358/6368/eaag2612](http://science.sciencemag.org/content/358/6368/eaag2612)

<comment><USER3> How does RCN model uncertainty?

<comment><USER2> Max-product BP inference propagates local uncertainties in the model to arrive at a globally coherent solution. An example of where this is particularly useful is resolving border-ownership amongst neurons representing a common contour.

</comment></comment></comment><comment><AUTHOR> Disclaimer: I am not the author of the page. I've read the tutorial paper they refer to, and work with related material. In our lab, we've had a _very_ hard time finding accessible material on predictive coding that's actually amenable to equations and code, and so this is something of a godsend.

</comment><comment><USER4> Anybody familiar with this method? It looks very intriguing as it looks to be combinging Bayesian posteriors with the neural activation function. Haven't had time to dig into myself, and it would be nice to know an outside perspective on it.

<comment><USER3> A few years back I spent some time reading and following the equations in Friston's papers, maybe understanding like 90% of it. you have to know dynamical systems, differential equations, multivariate matrix stuff, etc. Basically stuff physicists are good at. Seemed that the theory wasn't detailed enough to inspire the next deep NN revoluation, basically the form of the generative model Friston used is very general. My impression was that the coded matlab examples reqired you specify known quantities, like velocity or position. But that requires a human to input, not like a NN where you can just point it at some data and it learns. Would love to be shown otherwise...

<comment><USER4> Nice! Finally could put my physicist training to use... I skimmed the cited papers but they seemed very generalized as you mentioned. I'll have to find the matlab code examples to understand how a complete system model would look. The linked post seems to deal with just a single perceptron/activation function AFAICT. The embedded constants don't bother me too much as both physics models have embedded constants and I presume evolved neurobiological systems would have been tuned over time to incorporate the appropriate constants for dealing with useful quantities (force, mass, etc). Could be fun to port the matlab code to Julia!

<comment><USER3> OK, here's what I was referring to:

[https://www.fil.ion.ucl.ac.uk/spm/software/spm12/](https://www.fil.ion.ucl.ac.uk/spm/software/spm12/)

in this package there are (was?) some scripts for running dynamic expectation maximization. Cheers

</comment></comment></comment></comment><comment> bra-ket That's not how the brain works

The proposed method is wasteful in terms of energy spent to get an answer, specifically in this step : ' sum the whole range of possible sizes', even with approximations and clever algo

Perception is much more economical as it's done via memorized heuristics that restrict the search space very quickly.

As a rule of thumb, If your method requires many iterations to converge on some minimum it's a wrong method to model perception. Brain doesn't solve a mathematical optimization problem.

<comment><USER5> > The proposed method is wasteful in terms of energy spent to get an answer, > specifically in this step : ' sum the whole range of possible sizes',

Er, the entire approach is motivated by the fact computing p(u) is intractable. That summation is explicitly not done in active inference...

</comment></comment><comment><USER6> > The non-linear function that relates size v to photosensory input u is > assumed to be g(v)=v^2

I am having a hard time understanding this sentence - how does g(v) = v^2 relate the size v and the input u if the expression mentions only v?

Is it meant to be v = g(u) = u^2? Is it u = g(v) = v^2?

<comment><USER7> "We assume that this signal [i.e. _u_ ] is normally distributed with mean _g(v)_ and variance _Σ_v_."

That means that there's no deterministic function that fixes _u_ for a given _v_ , but only a distribution of possible values. (It's closer to _u = v^2_ than the opposite, though.) The precise relationship is expressed symbolically in the likelihood function given in the next part.

<comment><USER6> Thank you!

</comment></comment></comment><comment><USER8> I don't think this post is correct. The Bayes theorem is mixing up variables v and u in both the source code and the equations.

</comment><comment><USER9> This is a pretty site. Anybody know how they did the code snippets?

<comment><USER10> [https://mmistakes.github.io/minimal- mistakes/](https://mmistakes.github.io/minimal-mistakes/)

And looks like the content is in markdown.

<comment><USER9> Thank you!

</comment></comment></comment><comment><USER11> Can anyone ELI5 what's going on here for the layman?</comment>


Microsoft and IBM Partner with Red Hat: Why You Should Care - <AUTHOR> https://www.lightreading.com/enterprise-cloud/infrastructure-and-platform/microsoft-and-ibm-partner-with-red-hat-why-you-should-care/d/d-id/742996 <comment><AUTHOR> It was there a long time back. Sensible people tune out when vendors announce partnerships, but the deals Red Hat made with Microsoft and IBM during May 2018 were significant and push forward Red Hat's ambitions to dominate cloud platform software, as well as driving containers and Kubernetes into the mainstream. And today the announcement was kinda proof.</comment>


On the Epic side of history - <AUTHOR> https://mough.xyz/17987/on-the-epic-side-of-history <comment><USER2> A few comments that do not contradict the OP:

IANAL, however the term in law which would be most useful is "market power." Monopoly (or oligopoly) is just one species of "market power." It is the abuse or extension of market power with is illegal. Charging ANY fee for installing an app on an OS might be seen as the extension of market power.

Public utilities are subject to regulation, even if they are not in a monopoly position, (such as two private roads necessary to get to a town) if their market power - separately or together) appears to have led to abuses or inefficiencies (such as unnecessarily large fees.)

The root of "antitrust" law is English common law against "restraint of trade." Statute law, such as the Sherman act in the US, has generally been enacted in order to limit (not extend) the penalties already possible under common law. Common law is an English thing, going back to Henry II, I believe. Most nations have legal systems that descend from Roman law (or similar systems) and don't include common law. (I'm going by a book by Churchill, here, who also was not a lawyer, however.)</comment>


Guide to Writing Dockerfiles for Go Web-Apps - <AUTHOR> https://blog.hasura.io/the-ultimate-guide-to-writing-dockerfiles-for-go-web-apps-336efad7012c <comment><USER3> 1\. Running strip on go binaries is a BAD IDEA: [https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47...](https://github.com/moby/moby/blob/2a95488f7843a773de2b541a47d9b971a635bfff/project/PACKAGERS.md#stripping- binaries)

Use -ldflags="-s -w" instead

2\. Production build should NOT be running glide install - you want ALL your dependencies vendored, locked and commited to your repo before you build it. Bonus: you can have your Docker image build by CI pipeline and know it's going to be exactly like the one you've got locally.

3\. If you're including external resources in your container (upx in this case) via url it's common sense to verify GPG signature or, when one isn't available, at least file hash

4\. If your app doesn't need things like ca-certs you don't need Alpine - <USER2> can just use "FROM SCRATCH" to only have the statically linked binary in your container slashing another 50% off the final size of container.

<comment><USER4> I really don't understand the obsession with small docker final images, unless you're doing something silly like export/import and throwing away the benefits of layers. Removing temporary files from layers is great, but you get very little benefit from starting smaller. _Especially_ so if that means your final layer is bigger. That's actually a lot worse storage-wise than having a fat base image and a bunch of tiny final layers.

I do understand the desire to omit unnecessary attack surface, but if you have a good common base image, then you're not incurring any additional storage beyond once per docker host for all the layers your images have in common.

<comment><AUTHOR> When a container is scheduled to a node in Kubernetes, if the image is already available, it takes only ~2s for it to be up and running. But, if it is not present on a node and the image is of 2GB, the download speed is the rate limiting factor, taking start up times well beyond 2 seconds. And in a multi node environment where you do scaling up and down or maybe autoscale, new nodes could come up a lot. So, Leaner images are always better.

<comment><USER4> > So, Leaner images are always better.

That's a very vague statement, though, given the layer concept. The same final filesystem image can use any number of layers to get there. The way you organize the layers in your images, and share data between multiple apps, is important on top of generally keeping things reasonably small.

What I think you're trying to say is that fast startup is preferable. What you have not addressed is average startup time, which is where you still benefit dramatically by understanding layers.

The smallest average amortized image size is best. That means if you can get all the services for a new node started with 2GB total download, it's better than 3GB total download.

Using layers appropriately, and perhaps adding dependencies used by 80% services to your base image, may be best for overall efficiency. Know the tool and know your usage patterns.

<comment><AUTHOR> This adds an un-necessary dependency between services. Team working on service A would need to coordinate with team working on service B to keep same layers. The contract should be to keep the image size as small as possible, and teams can work independently.

Also, python:3.6 doesn't always mean the same layers, since it could be rebuilt with entirely different layers with same tag, unless FROM is locked to a particular layer.

</comment></comment></comment></comment></comment><comment><USER5> I don't understand what is the advantage of using Docker in production to run Go. It can already emit static binaries, can contain embedded assets and you can cross-compile for all supported systems using xgo... Ship your binaries, drop them anywhere in the filesystem, run them however you wish and you're done.

Even for building, a proper build system (like Bazel) is a better tool than building in Docker containers...

<comment><USER6> Running in container only environments (Kubernetes) would require it to be packaged in a container.

<comment><USER7> This is definitely seems to be the use case the blog was written for, seeing the author's background.

</comment></comment></comment><comment><USER8> Why not use GOOS/GOARCH to cross-compile, so you don't have to do the compilation step in a virtualized environment? You can build on the host and just copy the resulting binary in like all the rest of your artifacts.

</comment><comment><USER9> I've been using Habitat[1] for shipping all my Go applications. That way I can run the go binaries on whatever kind of infrastructure I need (containers, vms, bare metal). I can mix and match for different environments, or change my mind later without needing to repackage my application or my infrastructure automation.

Ultimately at the end of the day I need to work on a team with other operations-minded developers, and shipping them a dockerfile / docker container is kind of a spit in the face, so this has been a good solution for me.

[1] [https://habitat.sh](https://habitat.sh)

</comment><comment><USER10> I've been following this pattern by Kelsey Hightower on his blog [https://medium.com/@kelseyhightower/optimizing-docker- images...](https://medium.com/@kelseyhightower/optimizing-docker-images-for- static-binaries-b5696e26eb07). I love because the end result is a small base image.

<comment><USER11> I would strongly advice on using multi-stage dockerfiles instead of building binaries on host. Conveniently Docker manual has an example for Go already: [https://docs.docker.com/develop/develop-images/multistage- bu...](https://docs.docker.com/develop/develop-images/multistage-build/#use- multi-stage-builds)

</comment></comment><comment><USER12> Someone should make a collection of these for all languages. I'd love to see an equivalent for Swift.

</comment><comment><USER13> Question, is Docker actually a reliable way of distributing software? I have toyed with it a couple of times and all I ever got was errors about incompatible client and server versions.

<comment><USER14> I found it akward when running docker "standalone". However after I learned about k8s, all the things started to make sense. So my advice is, start using it. If it doesn't click at least try to use it in k8s, if you still can't grasp it you probably do not need it.

</comment></comment><comment><USER15> Related: Anyone have experience with Go and Unikernels? Saw a dead discussion a week ago on unik ([https://github.com/solo-io/unik](https://github.com/solo- io/unik))

For security purposes, the idea of a unikernel rather than a container has been very interesting. Wanted to use them in a test soon.

<comment><USER16> Docker Inc. bought a unikernel startup a while back. Presumably they see that as a possible endpoint.

</comment></comment><comment><USER17> Why is it a problem to have different versions of Go on the same machine?

<comment><AUTHOR> Having two different versions is not an issue, tools like GVM helps in managing them. Docker helps in handling this easily without any extra tools. But, if something is built with a version, it cannot be easily changed without thorough testing.

For e.g. when Kubernetes was built with Go 1.8 instead of 1.7, emptyDir teardown path was broken due to the change in behavior of os.Rename in Go 1.8 [1]. This bug caused other issues like the one with minikube [2] and they had to rebuild with Go 1.7 and update new binaries for already released v0.20.0

[1] [https://github.com/kubernetes/kubernetes/issues/43534#issuec...](https://github.com/kubernetes/kubernetes/issues/43534#issuecomment-288824459) [2] [https://github.com/kubernetes/minikube/issues/1630#issuecomm...](https://github.com/kubernetes/minikube/issues/1630#issuecomment-310275970)</comment></comment>