QEMU Advent Calendar: A surprise disk image each day until Christmas - <AUTHOR> https://qemu-advent-calendar.org/ <comment><AUTHOR> QEMU Advent Calendar is back again this year with a surprise disk image each day until Christmas.

It features disk images of interest to hackers or to show off features from the many emulated hardware platforms that QEMU supports.

Happy holidays! And if you have a bootable image you'd like to contribute, check out the calendar website to get in touch.

</comment><comment><USER2> Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time.

It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.

<comment><USER3> Hi, owner of [https://netboot.xyz](https://netboot.xyz) here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve the installer kernels directly from the OS supported mirrors when possible so that they are pulled from trusted sources.

<comment><USER2> Hi, thanks for the work! I believe I first discovered netboot.xyz on a show HN. I have set up the DHCP in my lab to serve netboot.xyz, so I can experiment with different OS'es without much hassle. It has been great so far.

<comment> m-p-3 I even used it successfully on a VPS which had a limited about of OSes available. Awesome project!

</comment></comment></comment></comment><comment><USER4> The source for F-Bird the boot sector game (day 1) is here: [https://github.com/nanochess/fbird](https://github.com/nanochess/fbird) and it's an incredible bit of engineering. 3 unused bytes too :-)

</comment><comment><USER5> This year also marks the 15th anniversary of QEMU.

</comment><comment> m-p-3 netboot.xyz is such an awesome project. I added it to most of my USB boot disks as a grub entry (on my SystemRescueCD USB thumbdrive, etc), so I'm almost never stuck when I need to deploy an OS on the go.

</comment><comment><USER5> There are still a couple of open slots, so feel free to send ideas (or even better -- prepared images) to the contact e-mail address mentioned on the website.

</comment><comment><USER6> Hoping for some cool non-x86 and non-Linux systems.</comment>


Reconstructing Artistic Style - <AUTHOR> https://hacktilldawn.com/2017/05/02/reconstructing-artistic-style/ <comment><USER2> How easy it is to try this stuff out now? I remember when google first came out with the deep dream stuff I could never get it working.

<comment><AUTHOR> It's much easier now since people have had time experimenting with hyperparameters. But I've never implemented deep dream so idk how difficult that is</comment></comment>


How do towels stay on hooks? - <AUTHOR> https://physics.stackexchange.com/a/381877 <comment><USER2> I love questions that get blown up into giant answers.

But in this case he goes on with: "Also, we ignore the folds of the towel."

In my experience as a human, if you don't fold the towel it will fall off, it's only the combination of the fold + the answer that in general will keep it in place.

</comment><comment> King-Aaron I didn't realise I needed to learn about this today.

</comment><comment><USER3> I should have went on to be a physisist.</comment>


Patent for dropping an image file on a textarea and having it uploaded - <AUTHOR> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&d=PTXT&s1=imageshack&OS=imageshack&RS=imageshack

<comment><AUTHOR> Issue date on Google Patents <http://www.google.com/patents/about?id=KdHbAAAAEBAJ>

</comment><comment><USER2> I saw this being done way before 2007, U.S. patents are funny.

</comment><comment><USER3> Also on Google+ post editor

</comment><comment><USER4> Like what imgur does?</comment>


Deprecate CSS - <AUTHOR> https://dxwc.gitlab.io/rant/abolish_css.html <comment><USER2> > HTML5 has semantic markups, we might need a few more.

Deprecating CSS will not encourage developers to use more semantic markup. In fact, it will have quite the opposite effect: coupling styling to the semantics will encourage developers to choose elements based on what they look like rather than what they mean.

Do you want more websites to be laid out with tables? Do you want more websites to use jpeg icons rather than accessible labels and pseudo-classes? Do you want website splash pages to be giant unresponsive images?

I think people underestimate how ridiculously hard it is to get developers to use semantic markup. Getting rid of CSS wouldn't cause devs to stop styling the web, they'd just do it worse.

> It makes more sense for users to be able to tweak looks as it works for them

That's... that's exactly what CSS was intended to do. That's why we have the cascade.

Yeah we've gotten away from that core of user control, and definitely browsers could be doing a better job on that front. But it's not like it's gone. I have custom CSS scripts for a variety of websites right now, including Youtube and Hackernews. As a user, CSS gives me more control over the web.

It sounds like what OP is really upset about is developers not using semantic markup. In which case, join the club. We've been fighting that battle on the web for years, and throughout that process CSS has been a valuable tool to help encourage developers to stop building fragile DOM layouts[0].

[0]: [http://www.csszengarden.com/](http://www.csszengarden.com/)

</comment><comment><USER3> Let's also go bad to CLI only interfaces, since your points apply to operating systems too.

While I agree modern design trends often go for beauty before utility, and more often than not distracts from the actual content, it is no reason to go back to a more "pure" time. We just need to set new trends that will put content back in the foreground and use other design elements to augment more integral parts.

No need to deal in absolutes here.</comment>


The electromagnetic fortification of the suburbs - <AUTHOR> http://bldgblog.blogspot.com/2015/01/the-electromagnetic-fortification-of.html

<comment><USER2> I'm put in mind of Neal Stephenson's dog pod grid.

<comment><AUTHOR> If all else fails, saturate the airspace in which the drones travel.</comment></comment>


Google claims uploading our entire minds by 2045 - <AUTHOR> http://www.dailymail.co.uk/sciencetech/article-2344398/Google-futurist-claims-uploading-entire-MINDS-computers-2045-bodies-replaced-machines-90-years.html <comment><USER2> Don't get me wrong Ray Kurzweil is very brilliant, but a bit strange. He take more vitamins a day than I think your liver can handle.

P.S. Thought Police.</comment>


Ask HN: Funding, Secrets & Disclosure - <AUTHOR>

My question requires a little background, so please bear with me: This is a story of 2 startups S1 & S2. They have both spent some time building their products and have been trying to get funding for their respective companies. But the founders of S1 & S2 are buddies and before their funding they had been brainstorming and spending time on a side project. They have been thinking that if this side project gets any traction, they will spawn it as a separate company and work on it in parallel. But until then they are committed to their primary startups and this will remain a side project. Now that both the startups are getting funded by different guys, they are debating whether they should disclose their side project or keep it a secret.
So, I have 2 questions:
1. What could be the consequences of a disclosure before taking investment money?
2. What is the fair and sensible thing to do? <comment><USER2> Put yourself in the investors shoes. How would you like to be treated if you were the investor?

Right so disclose it.

If you don't want to make a big deal out of it, just "over-disclose" EVERYTHING that takes time away from your Primary start-up.

Are you a meet-up group organizer, speaker at conferences, contributor/maintainer to open source libraries, responsible for your cousins online shoe-repair website, coach a little league team, are in the national reserve, planning a wedding, etc

</comment><comment><USER3> 1\. Definitely disclose it. Disclose everything that would potentially be an issue. Things that take your time away, any legal issues, the whole nine yards...

2\. If you are going to take on funding, move off the side project, or rather put it on the shelf. As an investor, no one wants to invest money into a company or its founder only so they could spend any spare time they have on another project when they could be spending it on the startup they were suppose to push 24/7.</comment>


Trust and security in the Snap Store - <AUTHOR> https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store <comment><USER2> I've used (X)ubuntu for a long time.

This paragraph: Evil, naive or interesting? And their conclusion that malware is not a bad thing.

I will never install it again on a personal machine.

<comment><USER3> Did you read that paragraph?

I don't see anything wrong with it. Mining coins isn't illegal, and won't get you banned from the Ubuntu store.

The developers point of view isn't valid, but that's their problem. I think most would agree mining on someone else's hardware without their permission is evil.

Ubuntu's point of view is misrepresenting what you app does is grounds for removal, which I think is quite reasonable.</comment></comment>


Google Preps Chrome For IPv6 Test Day - <AUTHOR> http://www.conceivablytech.com/7616/products/google-preps-chrome-for-ipv6-test-day

<comment><USER2> I might be more excited about IPv6 Day if the router my ISP has saddled me with supported IPv6, or if they'd give some indication they intend to upgrade it (or replace it). Assuming anything above their router even supports it....

Everything on my side is ready, has been for years, and my local IPv6 tests have gone swimmingly. But their box routinely drops the ball (or the packet). Irritating.

<comment><USER3> Same here, my ISP doesn't seem to have the hardware on it's side, i've bought myself a new router that is ipv6 compatible, but i won't get an ipv6 address from them and the techsupport says its nothing i'd have to worry about. Fun thing for them to say.

</comment></comment><comment><USER4> so is everyone aware that your ipv6 address will make you uniquely globally identifiable?

<http://en.wikipedia.org/wiki/IPv6#Controversy></comment>


Android 7.0 Nougat - <AUTHOR> https://android.googleblog.com/2016/08/android-70-nougat-more-powerful-os-made.html <comment><USER2> I hope iOS takes up on the multitasking capabilities next year.</comment>


Show HN: Brydge – A brand new professional network - <AUTHOR> https://brydge.com <comment><USER2> Seems interesting. I'm not a fan of LinkedIn, so this piques my curiosity. I am concerned about the "1:1 relationship" feature though. It seems core to the experience, but personally i'm not sure i will like it, and am hesitant to sign up as a result.

Why? I fear needing to ask meaningful questions, and / or respond with meaningful answers, as a public display of my networking power.

Eg, if i was asked a question about development, maybe with a tool i'm not too familiar with, i now have to go "on record" explaining what little i know about the tool, just to form a relationship i might want. Sure, that person may be most interested in that tool, but i'm sure i can fit "their needs" for many other aspects, just maybe not that one tool, and not at this time.

How permanent are these Q:A things? What if i learn said tool, do i re-answer? What if i want to revise any inaccuracies i post? From the description, this seems more important than a normal forum (eg: Stackoverflow).

I'm probably wrong on the concept, as i have only watched the video, but i figure even if i am wrong it might help explain confusions i took from the video.

<comment><USER3> Good question. And the video doesn't explain this well enough, but questions will only show on your profile if you answer. If you do not answer them they are not displayed publicly to anyone. That said, you can also hide previously asked/answered questions from your profile too. Do sign up and give it a chance. We're in beta and we're all ears for feedback.</comment></comment>


Show HN: Find profitable niche in App Store and Google Play Market - <AUTHOR> http://appsleak.com Hi,
This is my brand new project which helps indie iOS/Android devs discover the most profitable phrase niches in Apple App Store and Google Play Market for their apps and monitor position of their apps in markets.
Please give me your feedback :)
Regards, Wiktor <comment><USER2> I'm used to playing the "UK, United Kingdom, Great Britain, England..." guessing game in drop down lists but putting "United Kingdom" in between Gabon and Grenada is a new one. I'd almost given up looking by that point.

(Presumably the list is sorted by country code.)

<comment><AUTHOR> Yes. I have to change this. Thanks

<comment><USER2> Thanks for the interesting tool.

Perhaps a couple of examples (from the time of writing) of niches you've identified with it would be helpful to first-time visitors?

I know there's the slideshow on the homepage, but after putting a search phrase in there's nothing that immediately grabs me and makes me think "wow that's a big opportunity". Perhaps it's just me being mostly ignorant of the mobile market, but it's some honest feedback.

There's a typo in the App Store/Play headings ("Competiton").

<comment><AUTHOR> Yes, I have corrected this typo. Thanks

</comment></comment></comment></comment><comment><USER3> I'm a founder and CEO at MobileDevHQ[1], a startup focused on App Store optimization. We have been doing this work for almost a year and a half now and have built powerful tools for understanding the App Store, including keyword research and market/niche finders.

Appsleak looks interesting, congrats on launching! The app ecosystem needs more tools to help it mature and advance.

To those of you interested in understanding markets/niches and keywords in the app stores, it is important to note a couple main points:

First, there are large differences between Google/other web search volume and search volume in the App Store. At MobileDevHQ, we do lots of work to uncover those differences and provide realistic pictures of what is happening in the app stores themselves. For example, the volume on Google for "puzzles" likely has little relation to the volume in the app stores.

Also, competition as defined by number of search results is a great start to understanding the difficulty it will take for you to rank highly for a particular term, but it doesn't go far enough. At the end of the day, it is not just about number of results, but also the factors that the app stores use to rank results, and how "entrenched" those factors are in current results. You can only begin to understand this with lots of data, which is why we have been collecting this for years now and have even released a tool we call Sonar to help developers and marketers understand when an App Store changes its search algorithm.

There are tons of things I could riff on about App Store search, but those are the 2 most common thigs I see people missing, so I wanted to make sure I mentioned those in particular.

[1] <http://www.mobiledevhq.com>

<comment><USER4> Your sales page says:

"We track over 400,000 searches representing almost 50,000,000 results. "

Really? Where do you get this data? Apple is certainly not making it available (for obvious reasons).

<comment><USER3> We do a lot of crawling various data sources. We spent over 3 years building a really great infrastructure to do this well. This is how we can present rank tracking for you and your competitors over time. The last time I checked, I think the number was actually over 500k... I should update that page!

</comment></comment></comment><comment><USER5> Page says 'Closed'. Too bad, title piqued my interest.

<comment><USER6> That page is lying, it's not "Closed": <http://appsleak.com/app/how_it_works/>

</comment></comment><comment><AUTHOR> What do you think about this idea? Please give me your feedback :)

<comment><USER7> What happened? It just says "closed".

</comment></comment><comment><USER8> You misspelled "competition" as "competiton".

Also, the phrases don't really seem good, and seem to be based on unfiltered web searches, instead of app store searches or at least filtered web searches.

For example with "photo" I get: \- shutterfly \- photobucket \- photo editor -whited00r_tested.ipa \- walgreens photo \- photo editor

Obviously, aside from the obvious "photo editor", none of these are useful.

Also, it's down now.

The abstract idea is interesting, but the current implementation doesn't seem useful.

<comment><AUTHOR> I think it depends on type of phrase, but yes some phrases will not seem good because it is still based on searches from Google

</comment></comment><comment><USER9> Interesting. It's a bit like Market Samurai with app store search results thrown in. I would love to see it pull in sales and grossing rank figures but they're a little harder to capture.

<comment><USER10> That was my conclusion as well. I'm working on a Market Samurai competitor, currently in pre-launch at: <http://KeywordSear.ch>

I'm wondering how they got this data, I would love to be able to offer App store specific research. I agree, sales and gross rank would really be slick.

</comment></comment><comment><USER11> Site's down.</comment>


Gyroscope X - <AUTHOR> https://blog.gyrosco.pe/introducing-gyroscope-x-5a4bb8280454 <comment><AUTHOR> > Since the original idea for Gyroscope was to integrate all the best sources, > we waited for years for someone to build our ideal food tracker. > Unfortunately that never happened—and the experience here is so critical to > successful health—so we've done it ourselves.

> So what is the best way to track food? Fortunately, most of us already have > a thousand dollar food sensor in our pocket. It's a camera.

…

> Once the [meal] photos are synced, your health team figures out what was in > them and adds those details for your account. This adds an order of > magnitude more data than has ever been available before.</comment>


Monads: From Web 2.0 to Hardware Drivers - <AUTHOR> http://www.well-typed.com/blog/105/ <comment><USER2> > Functions that take a callback argument are called asynchronous functions.

Just to nit pick... Passing a callback to a function as an argument doesn't magically make that function asynchronous, in JavaScript. For example:

        var block = function(callback) {
          while(true) {}
          callback();
        };

Only those functions that are implemented asynchronously (such as Node.js' fs.readdir, from the article's example) will _actually_ be asynchronous.

<comment><USER3> Asynchronicity doesn't necessarily mean the function will be call at a later time. Rather it should mean the function will not be called by me at a previously known time without knowing the implementation of the function I am calling. Encapsulation, you know.

Using callbacks means giving up control of when things will happen. The fact that it will actually happen very soon is out of the question.

</comment></comment><comment><USER4> The Javascript example kind of confuses the solution with the problem. The convoluted syntax of the 'callback-hell' is the problem. Monads does not solve this problem, rather the use of monads leads to that kind of syntax. The solution proposed for the syntactic mess is Haskells do-notation. Do-notation is not monads, rather it is syntactic sugar to make the use of monads bearable. Something like lisp macros would be a more general solution to the same problem.

<comment><USER5> But lisp macros don't give you the strong type safety properties that Haskell gives you with monads. The most general solution is not always the thing you want. Sometimes you want the solution that gives you the strongest guarantees about the potential behavior of code.

<comment><USER4> My point is that do-notation is comparable to macros since it is a kind of syntactic sugar. Monads on the other hand are a type (or design pattern, depending on perspective), not a kind of syntactic sugar. So you can't compare lisp macros to monads.

</comment></comment></comment><comment><USER6> That javascript code is awful (and yet probably typical). There are three asynchronous readdirs that don't depend on each other (and should be able to run parallel) which now depend on each other and any asynchronous benefit is lost. Maybe haskell is smart enough to run them in parallel. For javascript, Promise.all would be better and avoid the pyramid of doom. Or, just use synchronous code for your, well, synchronous code.

<comment><USER7> Every monadic expression needs to be "run", and it turns out that with a different run function that exact code could be made to execute in parallel. In practice, though, you would probably use an explicit parallel combinator.</comment></comment>


Simit: A language for computing on sparse systems - <AUTHOR> http://simit-lang.org/index.html <comment><USER2> If you like this, you should also check out Ebb, a DSL for physical simulation built on Terra: [http://ebblang.org/](http://ebblang.org/)

Both were presented back to back at SIGGRAPH this year.

<comment><USER3> Are the videos available on Youtube?

<comment><USER4> Only a few sessions are available. [http://s2016.siggraph.org/live-streaming- sessions](http://s2016.siggraph.org/live-streaming-sessions)

BTW, ACM had fairly strict no photography policies this year. Authors clearly put up content on their slides that were supposed to be photographed liked URLs and QR codes, but volunteers went around telling people not to. I'm not sure if ACM failed to make the policy clear to authors or if they overstepped on copyright claims.</comment></comment></comment>


Future Scanner: A Digg Clone That Tracks The Future - <AUTHOR> http://www.techcrunch.com/2007/12/05/future-scanner-a-digg-clone-that-tracks-the-future/ <comment><USER2> Neat idea of crawling articles relating to the future, but I think the information is presented incorrectly. It should allow people to see trajectories and compare differences between what was predicted before, and the articles written in that particular year.

Even better (but almost too hard), if given the historical trajectories and how the graph of technologies enable each other, you can give prediction accuracy scores to current articles about the future.</comment>


How We Build Code at Netflix - <AUTHOR> http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html <comment><USER2> I'm interested in knowing more about the "25 Jenkins masters" that they have, and how much they have modified/built for Jenkins to make it work for them.

We are currently in a state of "big ball of plugins and configuration". A bunch of plugins have been installed, and lots of manual configuration has been put into jobs so that everybody has what they need to build their software. It has led to Jenkins being a "do everything" workflow system. The easy path that Jenkins provides, to me, seems like the wrong one - it makes it easy to just stuff everything in there because it "can" do it. This seems to leads to tons of copy/paste, drift, all types of different work being represented, and it is starting to become unmanageable.

Have others seen this happen when using Jenkins? How have you dealt with it?

<comment><USER3> Netflix have been quite involved in the Jenkins project, including the Job DSL Plugin, which enables the automated creation of new Jenkins jobs, e.g. when a new Git branch is created, by defining the job structure with a simple Groovy- based DSL.

Taking this further, the upcoming release of Jenkins 2.0 is going to put a lot more emphasis on pipelines-as-code, where entire workflows can be defined in code, and version-controlled, as opposed to clicking everything together via the web UI.

See [https://jenkins-ci.org/2.0/](https://jenkins-ci.org/2.0/)

<comment><USER4> For the last 4 months, Groovy has been known as "Apache Groovy".

</comment></comment></comment><comment><USER5> For those wondering about how this applies to Node.js use a Netflix like myself, it's in there towards the bottom of the article:

> "As Netflix grows and evolves, there is an increasing demand for our build > and deploy toolset to provide first-class support for non-JVM languages, > like JavaScript/Node.js, Python, Ruby and Go. Our current recommendation for > non-JVM applications is to use the Nebula ospackage plugin to produce a > Debian package for baking, leaving the build and test pieces to the > engineers and the platform's preferred tooling. While this solves the needs > of teams today, we are expanding our tools to be language agnostic."

<comment><USER6> Twitter has an agnostic tool called Pants [1]. I run a JVM shop and we are just now using some NodeJS so we are have been trying to figure out that as well.

[1]: [https://pantsbuild.github.io/dev.html](https://pantsbuild.github.io/dev.html)

</comment></comment><comment><USER7> > The Netflix culture of freedom and responsibility empowers engineers to > craft solutions using whatever tools they feel are best suited to the task.

I absolutely love that. I'm a huge fan of what Hastings and company have done over there in terms of culture and making Netflix a unique and desirable place to work.

I think it's time for another round of "find a way to make Netflix hire me."

<comment><USER8> There's an open house coming up. Let me know if you'd like to come (if you're in the bay area) firstname.lastname@example.com

<comment><USER7> Awesome. I just sent you a message. Thank you!

</comment></comment></comment><comment><USER9> Spinnaker is an amazing tool. Really makes it easy to confidently deploy applications via immutable infrastructure.

<comment><USER10> Can some one explain to me what immutable means in terms of "infrastructure" ?

<comment><USER11> The other replies here are great but let me give you the layman's version of what "immutable infrastructure" means:

If it works for me it works for everyone.

You never patch or upgrade immutable infrastructure. You just replace what you've got with a new VM or container. Containers being preferred because they can be started & stopped near instantaneously and there's nothing like a virtual BIOS that could have different configurations like with VMs.

You don't stand up a VM or container then "log in to configure it". Once the VM is "up" that's it. You're done. At that point you just need to point your load balancers/DNS at the new stuff then take down the old stuff.

One interesting aspect of immutable infrastructure such as this is that it is completely incompatible with _loads_ of existing security policies and what would have been considered "best practices" just a few years ago. For example, you might have a security policy that states that everything must be scanned within 30 days for malware/out-of-date packages/whatever. Yet with immutable infrastructure your hosts or containers may only be up for a few days before being replaced!

So when your security team freaks out because none of your hosts/containers are showing up in their systems you'll have a _lot_ of explaining to do =D

"We need to scan your hosts so we can ensure that you're installing security patches."

"We don't do that."

"You don't install security patches?!?"

"Yeah, well, you see..."

Trust me when I say that trying to explain how it all works and why it's more secure than old school deployments is _not_ easy!

<comment><USER12> this is why your security team should be integrated into how you (securely!) build and deploy software. in this specific case, that would mean maintaining the OS layer Dockerfile and scanning the dependency tree for build artifacts.

<comment><USER11> Yeah, it's actually a lot more complicated than that. Let's assume the security team creates the Dockerfile. It'll look like this:

        FROM ubuntu
        WORKDIR ${foo}   # WORKDIR /bar
        RUN developer_script.sh

So now with each new container update you'd need someone from the security team to audit/review `developer_script.sh`. It's kind of pointless if your goal is fast deployments.

If you just need to make sure your developers don't make a mistake in terms of securely configuring their containers (and making sure to always use the latest software) then you simply scan them before the canary stage. The problem there is, "what are you looking for?"

Also, there exists only _one_ tool to scan Docker containers (OpenSCAP) and if your security team doesn't like it, well, you're screwed: [https://github.com/OpenSCAP/container- compliance](https://github.com/OpenSCAP/container-compliance)

The other problem is that OpenSCAP only checks the container's packages for compliance. It doesn't actually scan the container's filesystem for things like JREs and bundled libs. So if you're using Docker best practices by keeping your images as minimal as possible you may not even _have_ a package tool inside your containers. In that case how do you check for things like out-of-date versions of Java?

Another problem is you assume there's some modicum of control over what's inside the containers before they're deployed. We're in charge of creating the _infrastructure_ for running containers with the promise that end users (who would be various application teams) can make their own containers (or at least their own Dockerfiles) and deploy them on our infrastructure.

We can work with them to help develop, say, a Kubernetes pod config for their app but as far as _what their app is_ or what gets bundled with it we'll have no knowledge after the first successful deployment.

<comment><USER12> I never said you need or should have the package tools inside your container, but you do need to be able to track the lineage of what was put into those containers so you can easily search for ex. deployed container revisions with an out of date Java version. This is where you need a team devoted to build that creates this kind of infrastructure. Otherwise, you end up with difficult to answer questions about your infrastructure.

tl;dr I assume there's some control because there should be.

</comment></comment></comment></comment></comment></comment><comment><USER13> Very cool article. Amazing how much tooling Netflix has built themselves.

<comment><USER11> What's amazing is that Netflix _let_ their teams develop solutions from scratch. Usually at big companies when their developers say something like, "can't we just build a solution ourselves?" they're laughed out of the room or, more likely, marked down as candidates in the next round of layoffs.

<comment><USER14> It helps that they have repeatedly proven this strategy works. When the CTO goes to the CEO and says "we're going to build this, not buy it," the CEO obviously trusts his decision making because he's seen him successfully execute his strategy so many times.

It sounds like Netflix engineering culture is built a lot around trust. Management trusts that only top engineering talent works there, and the sink- or-swim culture, coupled with performance bonuses and a rising stock price, ensures that the engineers are making the best decisions _for the company._ It's a lot easier to approve a "build" vs "buy" decision when you know that the interests of the engineers pushing for it are actually aligned with the company business interests.

Contrast this to a company with a large separation of incentives between the stock price and the engineers. In that scenario you end up with a bunch of engineers who are bored and want to prematurely optimize systems because there is no clear personal cost to doing so.

<comment><USER11> > It helps that they have repeatedly proven this strategy works.

I laughed at this because you can't "repeatedly prove" you're capable of developing your own solutions if you're never allowed to do it in the first place!

The enterprise mantra is: COTS or it doesn't happen.

</comment></comment></comment></comment><comment><USER15> Major outage being reported worldwide.

[http://downdetector.com/status/netflix](http://downdetector.com/status/netflix)

Anything interesting deployed in the last hour?

Something in the CI/CD tool chain, Spinnaker, failed for it to move all the way to Live without being caught.

<comment><USER16> There are many reasons that a site can go down, aside from a code deployment.

</comment></comment><comment><USER17> What are the reasons for Netflix choosing nodejs for their front-end server and not java like in their back-end?

<comment><USER18> I'm guessing it's their use of React both on the front-end and back-end.

<comment><USER19> there is also this [https://github.com/Netflix/falcor](https://github.com/Netflix/falcor)

</comment></comment></comment><comment><USER20> I'm a Netflix fan, as a consumer and an engineer, and this blog post just reinforces my fanboi status. Amidst the descriptions of deployment tools and pipelines one thing stood out for me: the fact that AMI bake times are now a large factor, and that "installing packages" and the "snapshotting process" were a big piece of this. Containers are definitely the answer to this problem. You can deploy base images with the OS and common dependencies, and have the code changes be a thin final layer. Of course with such a sophisticated pipeline based on AMI deployment this change would not be trivial for Netflix, but the bottom line is they have described the primary container use case perfectly, imo.

<comment><USER2> I am fairly certain it is on the Spinnaker roadmap. There was a recent talk by Sangeeta Narayanan on "Containers so Far" [1]. At 37:10~ you can see how they will essentially be allowing for containers to replace AMIs in the "bake" process. I'm looking forward to seeing how Netflix start to roll out more container support, and seeing how Spinnaker progresses.

[1] [http://www.infoq.com/presentations/netflix- containers](http://www.infoq.com/presentations/netflix-containers)

</comment></comment><comment><USER21> How do they 'externalize config' with respect to [http://12factor.net/config](http://12factor.net/config)?

<comment><USER22> There are many ways to accomplish an external configuration. I do not know how they do it at Netflix, but one could have the prebaked AMI reach out to a service discovery tool to pull its configuration at run time. For example, Consul [1] or etcd [2].

One advantage of this approach is that you can use the exact same AMI in testing as in production. All you would have to do is change the configuration which is pulled. You could determine which configuration to pull based on AWS tags on the EC2 instance, for example.

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

[2] [https://github.com/coreos/etcd](https://github.com/coreos/etcd)

</comment></comment><comment><USER23> Another Spinnaker: [http://arxiv.org/pdf/1103.2408.pdf](http://arxiv.org/pdf/1103.2408.pdf)

<comment><USER24> Good point - curious what do you exactly mean by this though, and how did you compare Spinnaker with it. Can you elaborate a bit more?

<comment><USER23> Really just a naming collision. IBM Spinnaker is a data store, Netflix Spinnaker is a software builder. The paper I linked is interesting if you're researching distributed data stores.

</comment></comment></comment><comment><USER25> Isn't Netflix using Mesos (see [http://techblog.netflix.com/2015/08/fenzo-oss- scheduler-for-...](http://techblog.netflix.com/2015/08/fenzo-oss-scheduler- for-apache-mesos.html) )? I don't understand what role it plays here.

<comment><USER26> The Fenzo scheduler is, if I recall correctly, used to do scheduling for Mantis and Titus (formerly Titan). Think of these as a streaming job infrastructure and a container service respectively. Spinnaker can assist you in deployments to both (I use Spinnaker to deploy Mantis jobs, for example) but the two platforms are not completely prolific -- we still deploy much of the ecosystem as baked AMIs.

</comment></comment><comment><USER27> Seems like a nice system, but would be improved by building with Bazel or Buck instead of Gradle.

<comment><USER28> What do you see as advantages/disadvantages of each tool?

</comment></comment><comment><USER29> This is how my company used to build software 10 years ago.

Now we have Docker containers, cloud VMs, GitHub, 1 click deployment, advanced metrics, Grafana, Go microservices, Slack bots, etc.

Sounds like Netflix is stucked in the past.</comment>


Show HN: I made a tool that lets you schedule frequent Digital Ocean Snapshots - <AUTHOR> https://snapshooter.io/ <comment><USER2> This is perfect. I'm running a Discourse forum and I needed something like this. Just signed up!

<comment><AUTHOR> Hey Justin, thanks for signing up. Yeah we are perfect for people like you running forums. Any issues message me directly simon snapshooter.io</comment></comment>


Whiteboard Interviews Suck, Get Good at Them Anyway - <AUTHOR> https://www.alexkras.com/whiteboard-interviews-suck-get-good-at-them-anyway/ <comment><USER2> I've never understood the hate that WBI get here and elsewhere on the internet. I see them the same way as standardized tests: without them, there's no good way to independently evaluate people's abilities in a way that is immune to cheating, dishonesty, or fraud (e.g. stealing someone's code and putting it on your github repo, being a terrible employee at previous jobs but just scraping by long enough to move onto the next company, straight up lying on a resume, etc.).

Sure, as the author notes, WBI have a high false negative rate. But if you're actually a good programmer, learning basic CS concepts should be extremely easy, and these types of problems, perhaps with a bit of practice, should be relatively trivial. I personally wouldn't want to work with someone who can't extract a path from a DFS, not out of any sense of elitism but just because such an employee likely would be unable to do many other problems properly.

<comment><USER3>
      > there's no good way to independently evaluate people's
      > abilities

And all WBI let you do is to evaluate someone's ability to do WBI.

<comment><USER2> I'd argue that there is a not-insignificant amount of overlap between whiteboarding and coding. Most coding in practice is not as "algorithmic" (in the sense that the problems are theoretically challenging) but having the knowledge and know-how of how to write optimal/efficient algorithms will definitely be echoed throughout any code you write.

In addition, in my experience most WBI are not particularly challenging problems that you have probably never seen before. I mentioned the ability to extract a path from a DFS; I would argue that this is such a basic CS skill that being unable to solve that problem indicates an insufficient amount of knowledge of CS.

There are definitely WBI that are poorly matched with real job requirements and knowledge. I think these are often seen at smaller companies trying to copy FB/Google without knowing what they are doing. WBI that involve using important CS constructs such as a binary tree or a directed graph IMO are testing important concepts

</comment></comment></comment><comment><USER4> _I used to believe that I got rejected after many whiteboard interviews, not because I did poorly, but because I didn't have the same (right) background as the interviewer. I served in the military, I was a Front End Engineer, I didn't go to a fancy school, I used the wrong language, I've used the wrong framework etc._

I think the author is hitting on some deep-seated psychological aversion people have to white board interviews. If you can identify that you were turned down based on your failure to do it well, you have to accept that it's your fault - not that you happened not to be good at that tech stack, or didn't have a "personality fit".

(I know there are different kinds of white board interviews - I'm assuming the generic pseudo-code algos and data structures type in keeping with the article's generality.)

Exposure to that kind of evidence of your inadequacy can be hard to accept. But it's also remediable. Get cracking and practice.

</comment><comment><USER5> The article makes the following statement:

Whiteboard interviews have a very high false negative rate (rejecting people who are good), but they also have a low false positive rate (hiring people who are not good).

On what basis is this statement made? No study or source appears to be cited. The specific false negative and false positive rates are not given. Also, what exactly is the definition of "good" used?

<comment><USER6> It's not possible to compute the false negative rate because once you turn down a candidate you get no more information. I suppose if people apply multiple times and are accepted later and then go on to do well on the job, you can count them as false negative in the first interview. The sample size for that would be small though. And I'm sure the true believers would say that these candidates improved their programming skills between the two interviews, not their interviewing skills.

I am quite interested in the false positive rate which can be computed by correlating performance reviews with interview performance.

<comment><USER7> > I am quite interested in the false positive rate which can be computed by > correlating performance reviews with interview performance.

You would still be excluding all the false negatives making it kind of relative performance of interview survivors. Meaning that you won't have anything to compare your false positive rate to proclaim it as low or as high.

<comment><USER6> You could compare it to other interview techniques if you were willing to test them.

</comment></comment></comment></comment><comment><USER8> Reasoning behind why whiteboard interviews suck is based that doesn't model real job skills. Maybe our org is an outlier but but we heavily rely on whiteboards to plan out architecture(ERDs,flow), problem solving, training/knowledge sharing. Our trello cards sometimes contains images of whiteboarded diagrams. Being able to explain and whiteboard your stuff is a very important skill at organization.

<comment><USER3> How many images in your trello contain C code for reversing string?

<comment><USER9> Yep, whiteboard programming - not good . Whiteboard interviews is too generic a name to use for that.

</comment></comment></comment><comment><USER10> i 1000% agree with this. there is no good way to really _know_ whether a candidate is good or not, but their ability to express their thoughts, in code, on a whiteboard is a really strong indicator that they can _think through a problem and (more importantly) communicate a solution as a software engineer_.

the next best approach --- a take home assignment --- is also good at this (or better, IMO, since you're free to implement that solution however you damn well please and it more closely translates into the work they'll actually be doing), but people complain that this is too invasive of their time and that they are doing free work. which is it?

I have to imagine that what most people want is to be asked about their experience, talk through it, and expect that to be enough. which is a very solid first pass filter. it's just not strong enough of a filter to extend an offer with confidence in many situations; it's too easy to bullshit and most of us engineers are damn expensive. (it's not just salary; we want dedicated offices and sit stand desks and super comfy chairs and free food and drinks and games and cadillac health insurance and 401ks and so on and so on)

i also never understood why whiteboarding was hard. if you know how to code and know your language passably well, then why can't you write code on something that isn't a computer?

</comment><comment><USER11> I have hired a _lot_ of developers, working for different companies in different countries. And I have never _ever_ seen a case where a developer did well in the WBI interview, was hired, and then turned out later to not be a good developer. However I have seen _plenty_ of examples of developers (interviewed by somebody else) who didn't do a WBI interview and later was fired because they were not good developers. My point is that if you can't do a WBI, well then perhaps you are simply not as good a developer as you think you are. Developing is about _thinking_. And WBI style interviews force you to _think_ for yourself without copy-pasting a solution from Google.

</comment><comment><USER12> WBIs will go away if the developer community rallies around not doing them. Companies can offer crazy incentives to work there like free massage, organic lunches, and game rooms, but they can't figure out a better way to hire than conducting WBIs? I call BS. They'll figure it out when they're pressured to do so...aka they can't find good talent anymore. Let's put on the pressure.

<comment><USER13> There is no benefit for people who are good at WBI's to join you in protest, and the bad people weren't going to pass them anyways, so the companies won't care either. On top of that, anyone _giving_ a WBI got _hired_ with a WBI, so the cycle continues.

I am not saying WBIs are good or bad - just stating that this kind of rally won't have the desired effect.

</comment></comment><comment><USER14> I think one of the real problems that doesn't get discussed very much is Google-envy. A lot of companies that don't really have problems like Google, and don't really have organizations like Google, and don't really have applicant pools like Google, will yet interview the same way Google does.

It really might be the correct way to interview for Google. Certainly they've put a lot of thought into how to manage their hiring process and they still lean heavily on the whiteboard. I'm almost positive, however, that most companies are really nothing like Google and really should not be using the same interviewing techniques.

Smaller companies with more quotidian problems would be better served with a more conversational and less time-pressured interview style.

<comment><USER15> Google explains here their interview observations : [https://www.google.ro/amp/s/www.wired.com/2015/04/hire- like-...](https://www.google.ro/amp/s/www.wired.com/2015/04/hire-like- google/amp/)

</comment></comment><comment><USER16> >Whiteboard interviews have a very high false negative rate (rejecting people who are good), but they also have a low false positive rate (hiring people who are not good).

That's a pretty bold assertion. Is there data to show this?

</comment><comment><USER17> Im a 'competent' programmer who has done few whiteboard interviews in my time and I have failed in most of them. Here is why ?

I consider myself a competent programmer since I have developed decent work@work and my peers recognise it too. But how would any interviewer can know about this ? My resume is like any other resume in tech world. They cannot. So I've to be put through WBI. For many years I couldn't have known what was wrong with me. Every time I failed I felt miserable to be honest. Eventually, I have narrowed down the reason. It is not just at interview I fail to problem solve - even when I try doing at home with a white board and 'explanation' I fail. English is not my region language but one would not doubt on my conversation abilities as I manage it ok. It is that I simply fail to explain solving programming puzzles in english since while programming I 'do' think in my regional language and most of the time in 'silent' mode in my head. Now 'silent' mode is again dreaded in interviews - as interviewers they want to know 'how you approach solving a problem'.

I think a better solution to WBI would be to make interviewee do programming questions on a laptop (alone) where interview is held - say make it an hour worth of exercise. Have that program run through some time bound tests (like google code jam etc) and may be do a code walk through later with interviewer. This way interviewer is sure interviewee can code.

Also, one of things that will definitely help would be to have some sort of evidence that you can code (git, code competitions etc). This gives some sort of confidence to interviewer.

</comment><comment><USER18> Whats funny about WBIs is that if you decide for yourself during the interview that this is not the company for you- you can derail the conversation into unfamiliar territory's and watch the interviewers struggle.

<comment><USER19> Why is that funny? Most interviewers are just doing what their company asked them, to give a whiteboarding problem to a potential candidate and figure out if they're worth hiring based on that.

I agree the process sucks and it's a hoop to jump through, but why take it out on the interviewer?

<comment><USER20> Because they are complicit. Saying they're just doing their job is not an excuse for propagating exclusionary and low signal interview practices.

<comment><USER21> "Exclusionary?" Seriously? I didn't know you're entitled to a job.

<comment><USER22> Notice how it's a whiteboard and not a board of colour.

<comment><USER20> There are blackboards as well. Color or ethnicity of the board is not the problem.

<comment><USER23> But whiteboards are far overrepresented. Definitely an issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> What I remember about much of that code I looked at in DS classes way back in the 80's was that, due to very limited memory space, all the variables were like I,J,K and X,Y,Z.

You have no idea how much more difficult that made it to follow sorts and tree algorithms. Thankfully, I seemed to have some sort of coding gift that allowed me to write the damn things at the terminal and make them work.

I got A's in all my CS classes, but now I guess I am so used to the magics of PHP object handling I've literally stopped caring about that shit.

It's hard to see why I would want to again.

</comment><comment><USER23> I think whiteboard questions are great if you make them either pretty easy questions, or more complex questions that you just diagram and discuss. In the first case, you filter out poor coders very easily, and see how the better coders apporach the problem. In the second case, you learn about their thought process when approaching a problem where you can't just modify an algorithm you have already practiced and answer it.

</comment><comment><USER20> Much better to go through triplebyte or interviewing.io. Pretty sure the signal from them is much higher than whiteboard interviews.

</comment><comment><USER25> Any company with an interview process where the key to passing the interview is "Pay more attention in your Algorithms and Data Structures classes", is a company that I'm never taking a job at.

<comment><USER26> Why would I want to hire a candidate that paid thousands of dollars for Algorithms and Data Structures classes but didn't feel the need to pay attention? Don't you think that says something about the candidate?

<comment><USER25> I've been out of college for 10 years, writing software professionally... it's so rare to have to calculate the big-O of an algorithm, or use a data structure much fancier than an array or a hash table, or implement my own search algorithm. And if I had to do any of those things, I would look it up and leverage this collaborative thing we've created called the internet.

So why should I be expected to regurgitate trivia at a whiteboard to get your job?

<comment><USER26> It's weird to me seeing statements like this because I don't work on any esoteric or fancy code, just frontend UIs, but I'm frequently making data structure and algorithm decisions.

<comment><USER27> Then ask questions about the UI framework the developer has experience in and ask about real problems faced with that framework for a complex UI.

</comment></comment></comment></comment></comment><comment><USER28> If you select stringently for WBI ability, you'll get strong WBIers. However, you're also paying the opportunity cost of not selecting for other traits and skills that might matter a lot more.

+1 though for "Senior Whiteboard Engineer"\--that term is genius!

</comment><comment><USER9> I see a lot of naysayers for whiteboard, but pretty much no opinion on what they think is better than whiteboards.

<comment><USER29> Talk to them.

Have a conversation about "how would you solve this (real) problem" \- the same kind of conversation you have with a peer when they're stuck on a problem. If both you and they are professional developers, you will be able to get into a nice in-depth discussion of the pros and cons, and go into nice tangental discussions along the way.

If they aren't a professional developer, it will show in no time at all; the longest I've let such a conversation go was 10 minutes just to see how long the interviewee would keep trying and snowball me.

I've found this is simply much faster and more informative about their experience with subjects that matter in the daily work of a software dev.

</comment></comment><comment><USER30> In a similar vein, I view whiteboard interviews (and required prep) similar to professional exams, like the Bar exam for lawyers. While I think it's unreasonable to expect good professionals to be able to pass such exams without a lot of practice, it's perhaps not as unreasonable to expect good professionals to be able to pass such exams if they study. Nobody likes tests, but I suspect that a high percentage of the good programmers who belly ache about whiteboard interviewers could in fact get good at them if they put in the time.

So yes, whiteboard interviews or not optimal and they are unfair, but if you are rejecting them out of hand and refusing to study for them, you are only taking away some opportunities.

I say this as someone who hasn't had to do a whiteboard interview for 10+ years. The jury is out as to whether I'll take the pain to study for them again should I do a full job search among tech companies again.

Also: note to author, I believe, "They have little co-relation" in your opening paragraph should be "They have little correlation".

</comment><comment><USER31> If an org does WBI's then it's a good indication that they are not choosing the best applicants. Instead of either getting good at them or trying to get the industry to change, we should embrace this.

If they do WBI's then they probably do lots of other things which run counter to best practices. Isn't it so much better to expose to the outside world a culture of cargo culting inability to evaluate techniques for the efficacy.

There are so many orgs who do run themselves well. The real tricky party is how to determine that quickly. With WBI's we can get a short cut.

Long Live The White Board Interview!

<comment><AUTHOR> How would you hire?

<comment><USER28> Conversation, half technical and half to figure out what the person would be like to work with. For example, tell me about the most interesting/difficult/satisfying problem was that you've worked on. Or, tell me what happens when you point your browser at a web site, in as much detail as you can muster. What are your go-to tools to solve problems</comment></comment></comment>


Steve Blank's list of the best books for building a startup - <AUTHOR> http://www.microsoftstartupzone.com/v2/Blogs/gettingstarted/Lists/Posts/Post.aspx?ID=117&ID=117

<comment><USER2> Latest version is here: <http://steveblank.com/books-for-startups/> Always looking for new suggestions/additions.

<comment><AUTHOR> I came across the list while searching for insight on value props (I'm at the "articulate your value proposition" stage of Four Steps). The end of the story is I just ordered "Delivering Profitable Value" off Amazon after being blown away by the first few pages. The idea of focusing on 'resulting experiences' has me gripped!</comment></comment>


Ask HN: how easy is it to create my own part-time, remote help desk? - <AUTHOR>

I'm currently paying a US-based call center about $55/hr to provide 24/7 frontline tech support via phone, e-mail, and live chat.
They're horrible at it, and I'm wondering if I can't just do it better. Switching vendors is tough because our case/incident volume is so low that most companies either won't deal with us OR will deal, but at outrageous prices.
So I'm toying with using something like Grasshopper and Zendesk to basically create my own help desk. One of the big unknowns is the staff: are there people willing to be on-call for an 8-hour shift, yet be paid per case? Or paid per minute of support time? Is that even legal? I can't afford to pay for two or three full 8-hour shifts, which is why we have an outsourced vendor now (where agents are shared across multiple clients and we're only billed per minute).
Any ideas or suggestions, especially from folks who have done something similar? <comment><USER2> If you pay by case or commission, expect someone to stick around only if they're making as much or more than if you paid hourly.

I think you should look into a service that sells you minutes and takes calls from several different companies. I recommend CallRuby (<http://www.callruby.com/pricing.html>).

<comment><AUTHOR> CallRuby seems very interesting, I hadn't heard of them before. Thinking of ways I can utilize them, but for my current situation I need more of a tech support rep than a receptionist.

</comment></comment><comment><USER3> Someone literally just posted this not too long before you did: <http://news.ycombinator.com/item?id=4361136>

<comment><AUTHOR> Thanks, I'll look into it. However, I guess one of my biggest questions currently is around staffing— it looks like Supportfu is just a competitor to Zendesk, Kayako, etc.</comment></comment>


Thorium Instead Of Uranium: Solution To Our Energy Woes? - <AUTHOR> http://wmbriggs.com/blog/?p=2970 <comment><USER2> I'm a big fan of Thorium, but I'm also a big fan of nuclear in general. It just makes sense.

In fact, this is a lot like the issue of not building any oil refineries in the United States since the 1970s. While I'm sure there are good reasons for our lack of needed nuke plants, at the end of the day it looks like the system has let us all down.

I hate to sound like old cranky guy again, but frack, if you really wanted to get off oil you could do the math for how many nuke plants you'd need -- it'd be a lot! But it wouldn't be impossible, and we've known all of this for decades. It's just very frustrating. Things like the thorium ideas just make things worse because we can't even solve our problems using the old technology, much less the new stuff. It's almost like rubbing salt in the wound to see such potential and realize how improbable it will be to see the light of day (in a massive production sense). I find the state of our energy policy completely incredible, but the tech continues to look better with each passing year. Sigh.

<comment><USER3> Nuclear power plants can't replace oil- or coal-powered plants, because nuclear plants can't adjust output over the day to fit actual usage. Nuclear power plants are great for providing the baseline power production, but you need something adjustable to handle the morning and evening peaks, like oil or coal or wind or hydro or really big batteries.

So no, you can't do the math for how many nuclear plants you would need to get off oil.

<comment><USER4> France is using some of their nuclear plants to provide peak load, and they adjust the power output of most of their plants over the day to better fit the actual usage. Their reactors are not ideal for this; there are better ways to design nuclear plants for load-following. But it can certainly be done.

Alternately, you could make enough nuclear capacity to provide your peak power levels _all the time_ , and dump excess energy into some energy-hungry industrial process, like aluminum smelting, or synthetic fuel production, or ammonia synthesis.

So yes, you _can_ do the math. It's just that there are a bunch of different ways to do that math, and most of them involve a lot of cleverness, large budgets, careful engineering, and a fair dose of uncertainty.

<comment><USER5> _Alternately, you could make enough nuclear capacity to provide your peak power levels all the time, and dump excess energy into some energy-hungry industrial process, like aluminum smelting, or synthetic fuel production, or ammonia synthesis_

Heck, you don't _have_ to do anything with it, just disconnect your turbines from your generators.

<comment><USER4> Technically, sure. Economically, since most of the cost of nuclear power is the capital cost of building the plants, you want to be running them as close to 100% capacity as you can, all the time. If you can smelt some aluminum while you're at it, that really helps.

</comment></comment></comment></comment></comment><comment><USER6> This is a classic case of a solution to a problem that does not exist.

Firstly, Uranium is practically an insignificant cost of a nuclear power station. The price would have to go up by a factor of a 100 before it made a difference.

Secondly, the supplies of uranium are currently limited because the demand is limited. The moment the price shifts up by even a little, supply will grow because several other mining locations will become profitable.

<comment><USER7> We have already mined something like 100 years worth of Uranium that is just waiting around to be used in power plants. Or, if the US moved to breeder reactors we could go for something like 1000 years without mining any new uranium.

<comment><USER8> The trouble with fast breeders is that you need a huge fissile inventory to get one started.

A study of the PRISM design, a modern fast breeder that uses integral reprocessing to reduce the inventory of plutonium that's sitting around, not fissioning, indicates that if we reprocessed all spent fuel in the U.S. today, we'd have enough Pu to power about 33 MWe worth of breeders, about 1/3 of the current fleet.

It comes down to energy vs power. "Fast" breeders can tap a huge energy resource, but they can only produce a low level of power because they tap that energy slowly. That's the whole reason they use highly reactive sodium as a coolant; to reduce fissile inventory per unit of power, you need a coolant with incredibly high heat conductivity. Lead is a much easier material to handle, but a lead-cooled fast reactor has 1/3 the power density of a sodium reactor, which means 3x the fissile inventory.

Fast breeders, therefore, can sustain energy production over a long period of time, but they can't drive a rapid expansion of nuclear energy, like the 5-fold increase we'd need to replace fossil fuels and stop global warming -- it becomes hard to justify the economics of a plutonium economy in the same way... You have to be thinking more than "seven generations" ahead to see the economic boon.

Thermal reactors effectively trade a moderator material (water, graphite, etc.) for (relatively scarce) fissile material. Thermal reactors (even today's LWR) extract 10-20x as much power from fuel than do fast reactors with less aggressive design (although the LWR extracts only 2% as much energy, in the long term, as a breeder could.)

A thermal breeder, based on thorium, could provide the best of worlds. With small inventory, it's possible to meet high power requirements, but by using abundant thorium instead of rare U-235, be able to sustain that power for thousands of years.

<comment><USER9> > if we reprocessed all spent fuel in the U.S. today, we'd have enough Pu to > power about 33 MWe worth of breeders, about 1/3 of the current fleet.

That should be "GWe" not "MWe".

Also, I dispute your choice of statistic. Why not show what happens if you start fast breeders on mined uranium, just like LWRs?

<comment><USER8> Sorry I missed a factor of 1000. Fast breeders on mined uranium have the same problem as plutonium breeders... Except you can breed plutonium faster (but less efficiently) in LWRs!

<comment><USER9> I mean, it's an odd statistic. You can use U-235 directly, or you can burn it in an LWR, getting back just 1/5th its equivalent in Pu-239, and use that. If you're trying to maximize fissile input for fast breeders, LWR spent fuel isn't an efficient way.

And moreover, with mined uranium there's no limit to your rate of expansion other than mining. You don't have to sit and wait for your atoms to reproduce (doubling time 20-40 years), when you can just dig up new ones.

Some back of the envelope numbers:

Assuming 3% enriched fuel burned to 40 GWd/ton, and 33% thermodynamic efficiency, the US nuclear fleet (~100 GWe) consumes around 100 tons/year of U-235 in fuel. At about 10 kg/MWe fissile inventory, just 10 years' of present US uranium consumption would be enough (1,000 tons) to start up a 100 GWe fleet of fast breeders -- same as the current LWR fleet.

I found a table of fissile inventories here:

[http://nuclear.inl.gov/deliverables/docs/msr_deliverable_doe...](http://nuclear.inl.gov/deliverables/docs/msr_deliverable_doe- global_07_paper.pdf)

</comment></comment></comment></comment></comment></comment><comment><USER10> The short answer is that there are many entrenched interests who are not keen on the idea: Uranium mines, nuclear industry, weapons manufacturers, not to mention the oil, gas and coal lobbies, even the alternative energy suppliers like solar. Thorium would rain on all their parades.

<comment><USER7> The real answer is the R&D costs are not worth it because Uranium is still extreamly cheap. The fuel costs for a modern reactor are a small fraction of total cost.

Also, fosil fuels a not going to be replaced with wind, solar, fission or fusion any time soon because they are not really portable for anything smaller than a boat.

<comment><USER11> You're both right.

"The real answer is the R&D costs are not worth it because Uranium is still extreamly cheap."

This answers why the market won't develop the technology on its own. But the government could still sponsor research as they did with uranium fission.

"The short answer is that there are many entrenched interests who are not keen on the idea..."

And this answers why the government would never fund it.

<comment><USER12> As soon as the market has to bear the cost of long-term storage of waste, they'll be interested in thorium.

<comment><USER4> That "waste" is still perfectly usable fuel. You could extract the plutonium and uranium and use that to make more fuel rods. You could burn it in fast breeder reactors, in a hypothetical future where mined uranium becomes expensive enough to warrant the use of fast breeders. Or you could just ship it to Canada, where they have heavy-water-moderated reactors that can use regular nuclear waste directly as fuel, without any chemical reprocessing.

I keep saying that nuclear waste storage shouldn't be thought of as permanent disposal. It should be thought of as keeping a reserve of nuclear fuel for the future.

<comment><USER13> To add, <http://en.wikipedia.org/wiki/Nuclear_reprocessing> \- see the last two paragraphs in history for some problematic decisions.

</comment></comment></comment></comment></comment></comment><comment><USER14> I thought all of the arguments against nuclear were overwhelmingly about NIMBY (not in my backyard). People just look at Three Mile Island and Chernobyl and think "hell no."

Maybe after the BP spill, we'll think a little more about nuclear.

</comment><comment><USER15> I've read somewhere that one problem with Thorium is it can easily be converted to a fissionable isotope (of Uranium?) which _can_ be used to build bombs. So there's that.

<comment><USER16> One of the anti-proliferation points is that U233 (which is the isotope you're thinking of) is mixed with U232, which decays to products with high gamma output, meaning that it's more dangerous to work with than the more typical fissionable materials, and much easier to detect. For a state this probably wouldn't be a significant barrier, but it's a fair point with respect to terrorist bombs. Of course, we haven't seen any of those, which implies that there's some non-obvious factor at work, here.

<comment><USER17> From the OP:

 _You will hear that we can't make bombs out of U-233 because it is a virulent gamma-ray emitter. This is not true, and I find it curious that it is used as a reason. U-233 has a 158,000-year half-life. What they are referring to is the protactinium-233 contaminant, which has a 27-day half-life, beta-decaying into U-233 with gamma-ray involvement. Chemically scrub the protactinium, of course, or just wait a year and it will be gone._

<comment><USER4> No, that's wrong. The claim is that the bred U-233 will be contaminated with U-232, which is very hard to get rid of, and has the hard gamma emitter Thallium-208 in its decay chain.

<comment><USER18> Where would the U-232 contamination come from, if it's bred U-233? Does thorium also just sometimes decay into the lighter isotope?

<comment><USER4> Sometimes the thorium, when it absorbs a neutron, will emit two neutrons and turn into thorium-231, which decays (though a couple more isotopes) into U-232. It can also be formed when U-233 absorbs a neutron and emits two, forming U-232.

How hard this would be to separate depends on the type of LFTR design you're using. However, you could also include some thorium-230 in the fuel mix to denature any protactinium produced, so there's really no way around having U-232 mixed with the bred U-233. Here's a blog post with more details on the entire process:

[http://energyfromthorium.com/2006/10/06/denaturing- thorium-w...](http://energyfromthorium.com/2006/10/06/denaturing-thorium-with- ionium/)

<comment><USER15> What about this?

<http://www.technologyreview.com/blog/arxiv/25855/?ref=rss>

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'm all for thorium and nuclear energy, BUT only if we in the US stop with the NIMBY-ing and find a permanent storage location for nuclear waste.

<comment><USER20> No need for a 'permanent storage solution' for thorium waste. What little waste there is decays to safe levels in less half a century.

</comment></comment><comment><AUTHOR> The post doesn't give a definite answer to the question in the title, but it is interesting.

<comment><USER21> It could be a plausible solution to our electricity woes to a degree. Mainly in baseload electricity supply which is about 60% of the U.S. grid. Small liquid flouride thorium reactors (LFTRs) can fit on a flatbed truck and mass manufactured. The idea is that we can connect these to existing coal plant secondary systems around the country and replace the coal boilers.

Thorium is extremely abundant. We have 3000 tons of it sitting in nevada gathering dust because we have nothing better to do with it. Also, you can get an incredible amount of energy and little waste out of a liquid thorium reactor. See <http://energyfromthorium.com/>. That's Kirk Sorensen's blog. A NASA engineer who's really led the movement on LFTRs and got featured in Wired for it.

<comment><USER4> If we can get the cost per megawatt of capacity low enough, liquid fluoride thorium reactors could even be used for peak power. They can scale their power output up and down pretty rapidly, since they would use Brayton-cycle gas turbines for power conversion, and it's possible to continuously (or very frequently) remove xenon-135, which is a neutron poison and has traditionally made it harder to adjust the power output of nuclear reactors.

<comment><USER21> Isn't it wonderful how we've barely scratched the surface on what potential fission has?

</comment></comment></comment></comment><comment><USER22> Wouldn't getting over our fear of reprocessing Uranium make this a non-issue? That seems the simplest and most straightforward path... Just have to figure out a way to lock down the resulting plutonium.

</comment><comment><USER23> If you need lots of thorium you can usually find a ton of it Winterspring or the Burning Steppes!

<comment><USER21> You can find it pretty much anywhere actually. It's a by-product of many mining processes and India has literal beaches of it.

<comment><USER24> I believe magamiako is referring to areas in World of Warcraft where thorium can be found.

<comment><USER4> Incidentally, comments like that are why it's so irritating to try to have discussions of thorium on Reddit. Of the people who post in those threads, a significant fraction are just there to make WoW references.

<comment><USER5> I have the same problem with discussions of Uranus.</comment></comment></comment></comment></comment>


Health startup uBiome just raided by the FBI, had been double billing insurers - <AUTHOR> https://uk.finance.yahoo.com/news/fbi-just-raided-health-start-203830494.html <comment><AUTHOR> Another article I saw about this mentioned that while the CEO stated she had "no knowledge whatsoever," of the search, but a person familiar with the matter told CNBC that some employees were told to stay home from work on Friday. The person, who asked not to be named because the matter is confidential, also said that the FBI broke down the door of the company's offices and requested access to employees' computers.

[https://www.cnbc.com/2019/04/26/the-fbi-just-raided- ubiomes-...](https://www.cnbc.com/2019/04/26/the-fbi-just-raided-ubiomes- office-for-billing-practices.html)</comment>


Microfiber Pollution and the apparel industry - <AUTHOR> http://brenmicroplastics.weebly.com/ <comment><USER2> If they are fibers I would imagine they would break down quickly in sunlight since it contains UV light. But I guess like the article mentions, there is just so much pollution that the environment is unable to support it.</comment>


Is Mark Zuckerberg the Howard Roark of the web? - <AUTHOR> http://www.thisisgoingtobebig.com/blog/2010/5/17/is-mark-zuckerberg-the-howard-roark-of-the-web.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+thisisgoingtobebig+(::This+is+going+to+be+BIG::)

<comment><USER2> seriously? i clicked on this link thinking it would be satirical, but boy was i wrong..

to compare zuck and roark like this is quite ridiculous. saying that we need less privacy in our society is an opinion and if you so please give up your privacy. but to be zuck and fool people into giving it up is quite another thing. it not only attacks our right to privacy but also our right to choose.

</comment><comment><USER3> > but I do know that a government and regulatory pile-on to "fix" Facebook's > privacy issues will feel just as wrong as when the Cordlandt Homes was > altered from Howard Roark's original vision.

Yes, a thousand times yes.</comment>


Is tomorrow Armageddon for Mac developers? - <AUTHOR> http://www.zdnet.com/blog/government/for-traditional-mac-developers-armageddon-comes-tomorrow/9825 <comment><USER5> Put another way - in the last Ten years as an owner of:

      o PowerBook - <USER2>
      o PowerBook - <USER3>
      o MBPro - <USER4>
      o MBAir - 2010

I have purchased the following Applications:

      o VMware Fusion+Upgrade
      o Windows XP
      o Microsoft Office (Twice - 2011 rocks my world)

Yet - I have 40 or 50 apps on my laptop (VLC, Colloquy, Acorn, ChickenofVNC, etc, etc..)

Looking at my iPad + IPhone, I see that I have approximately 200 applications, purchased, on average, for about $3 each + a few premium apps (Omnigrafflle, OmniFocus - $50/each) Subscriptions to the Economist, Zinio, PressReader, WSJ, and copies of Time, Wired, The New Yorker, PosSCi.

Reviewing my itunes Bills - I see I have spent approximately $40/month on applications - or about $1500 in the last three years, not even including content - which adds another $2k I don't even _think_ about purchasing $1.00 Apps, I just do it. I'm also comfortable buying, with a bit of research, the nicer $5- $10 Apps.

None of which seemed to have hurt the price points of Applications like Omnifocus/Omnigraffle that much.

I expect that my behavior on the iPhone/iPad will carry over to the Macintosh, once a nicely curated store is available for me.

I _love_ rewarding developers - I just need the channel that I feel comfortable in doing so. The Apple Store is that channel for me.

<comment><USER6> I've had the same experience with Steam.

I don't think I purchased a single PC video game since I discovered torrents and usenet (unless I needed a multiplayer key).

But recently I've been buying games on steam for the pure convenience of having a nice store with trailers, one click purchases and quick downloads.

Compared to having to deal with shady torrent sites, torrent download speed shaping from my ISP and cracks.

<comment><USER7> There's also lots of $2 games on Steam and it hasn't killed the premier developers' ability to charge $30 or $40 or more for their AAA titles.

</comment></comment></comment><comment><USER8> These used to be shareware-level games that (at best) would get bundled for $5 with 99 other games and the author hoped for some payment (or would unlock a feature for a small price). So think of it as a massive pricing _increase_ , not a price _decrease_. As fun as, say, Angry Birds is, it doesn't compare to, say, Worms 2.

Seriously: I remember playing an Air Hockey line-drawn 3D game on my friend's Macintosh LC (I think it was). His dad had downloaded it free.

I'm not denigrating the work of these devs: let's just not pretend we're creating epic worlds and employing hundreds of designers for these releases. And as always: if your product is worth more, people will pay more for it. If you've been able to keep your price high solely because of some platform insulation, be happy the ride lasted as long as it did.

<comment><USER9> > As fun as, say, Angry Birds is, it doesn't compare to, say, Worms 2.

Except for me Worms is currently £1.79 for the iPhone. Worms 2 is £2.99. I get what you're trying to say, but this Christmas EA had their games on sale for 59p (about 99c I think) and they were mostly good games too. The Mac game market is nowhere near as mainstream as PC and Consoles, and there's a risk that mainstream developers may choose not to port games if they're competing with £2.99 games with equivalent quality to Worms 2 or Fifa 11 on the iPhone (in terms of use of native platform).

</comment></comment><comment><USER10> IMHO The author is blowing this out of proportion. He is comparing an iPhone photo editing app to PhotoShop or asimple iPhone game like chopper to games like Halo.

These are two different levels of software. It is amazing what software can be written for mobile apps today but they are still not as fully functional as their desktop equivalents. The Mac App Store is going to be a big push for Desktop App developers to lower their costs slightly but you are still getting more functionality out of Pages for Mac OS X rather than Pages for iPad.

Though Mobile Apps may continue to grow as an industry I think we are still a few years away from seeing a serious threat to high functionality desktop applications.

<comment><USER11> Also, iPad applications seem to be up to twice as expensive as iPhone applications -- even if they're essentially the same app. I expect the same mystical price expansion will happen for Mac apps.

<comment><USER12> I always thought this was a result of developers realising they started too low with the iphone and adjusting accordingly.

</comment></comment></comment><comment><USER13> Only a little. While prices will get driven down, the total amount of money getting spent on Mac apps will increase hugely.

I've been using macs since the days of the Plus, but when was the last time I actually paid money for a boxed piece of software apart from MS Office? Probably about a decade ago. And I'm not talking about piracy -- I just haven't felt a sufficient desire for any third-party piece of software that would entice me to go down to one of the very few places where such things are available by retail (even the Apple Store has a rather embarrassing small corner of mac software).

It's times like this I wish I had some time to actually write some Mac apps.

</comment><comment><USER14> Nope. Look at Steam, for a good example. There are plenty of indie games priced at the ~$10 dollar level, and there are also AAA titles priced at ~$60. Neither one has doomed the other. The games market allows for simpler, low priced indie games, but there is still space for the blockbuster games that cost 5 times as much. They're different products, and different markets.

I don't know enough about Mac software to speak for that though. I'm a Windows/Linux user, and virtually every piece of software I use is free or a corporate application.

<comment><USER6> But most mac apps _are_ created by indie shops.

Are there ever any "Blockbuster" mac app releases?

You rarely see marketing for mac apps. Most of the big names (ex photoshop, word) are so established that they don't need to bother worrying about price (or possibly even using the app store). But still thats a small percentage of the market.

<comment><USER7> Omni Group are the best example of a great Mac developer that isn't huge like Adobe or MS. They sell best-of-their-kind software for the iPad for quite high prices, and are doing very well. I don't see this changing in the Mac app store.

</comment></comment></comment><comment><USER15> The app store means

      * nearly zero worry about piracy*
      * much much easier discovery process for average users
      * much higher purchaser confidence (due to b and c)
      * lower purchase activation energy

All of these together mean that apps which traditionally scraped by as shareware, thrilled if they got 5% conversion, can now just sell at an impulse-purchase price of $1-5. Larger professionally-produced titles, like games, that have always had problems with piracy, no longer have to overcharge the people who do pay in order to compensate for those who would have paid, but didn't.

*: Part of this analysis is based on the assumption that if the app store DRM gets cracked (likely), the procedure is sufficiently unpalatable that it cracking is not widespread. There are a large number of pirates of convenience out there, who if faced with an app store where what they want is noticeably less expensive than it was before, might decide it's not worth the risk/bother.

<comment><USER16> _Part of this analysis is based on the assumption that if the app store DRM gets cracked (likely), the procedure is sufficiently unpalatable that it cracking is not widespread._

There are no jailbreaking hassles with Macs, so probably all pirates will have to do is download a single app/kernel extension/whatever. And I wouldn't be surprised at all if Apple uses that as an excuse to lock down Macs in the next few years.

<comment><USER15> I don't think any of us know that until we see it in action.

</comment></comment></comment><comment><USER17> Sure the price will drop by an order of magnitude, but the number of units sold will skyrocket. I bet by at least that same order of magnitude. The current number of units sold by a developer through their own store is microscopic. The incremental cost for selling another unit is almost zero.

The ability to be part of a store that every mac computer has installed automatically, with super easy purchasing, credit card processing, and installation, will offset the drop in price.

It also gets developers out of the business of maintaining their own storefront, payment processing, etc. A cost that is a burden on many of the existing developers.

</comment><comment><USER18> No. <http://bit.ly/a4Qb2Z>

EDIT: Bit.ly'd because apparently HN doesn't allow apostrophes in links.

<comment><USER19> Link that works: <http://en.wikipedia.org/wiki/Betteridge%27s_Law_of_Headlines>

<comment><USER18> Derp. Thanks, completely forgot about URL encoding.

</comment></comment></comment><comment><USER20> Doesn't the smaller Mac market mean that prices will be higher than those for iOS?

<comment><USER21> Yeah that's exactly what I was thinking. If iOS developers try to sell a ton of copies for a dollar, they'll soon discover there are less people buying. Prices may go down some but they won't hit iOS levels.

</comment></comment><comment><USER22> This article is ridiculous because the author does not address the fact that volume will increase dramatically: a $3 app on the Mac app store will undoubtedly sell many times, perhaps 10+ x, more than the app distributed on a CD/DVD via Amazon for $30.

</comment><comment><USER23> How many copies does a typical Mac application sell? What are the margins, marketing expenses for comparable apps in both worlds? Or are mobile apps almost always tinier and less capable or just too different to compare?

And do you even have to sell your app in the new store? Or will you have to because you will now suddenly have competitors? Is your app that easy to duplicate or is it that selling will be so much cheaper or it will be easier to get attention? And if its not better in some way, why would you stop selling your app the old way?

</comment><comment><USER24> Commoditize Your Complements. Cheaper and more abundant Mac software improves the experience for users, which should increase the appeal of the platform. If it works then it should mean more money being spent on Mac software in the long run, even if it's less per unit. If it works out any way similar to iOS the most popular apps will make a ton. The traditional developers just need to make sure that their software is the best, and if they can't beat the new guys then can they really complain?

</comment><comment><USER25> This is a testable prediction. Rather than speculate, is anyone willing to bet money on the price movement of Mac apps over the next 6 months, and at what odds?

</comment><comment><USER26> Prices are dictated by the market, since everybody wants to generate as much profit as possible. Not to mention covering development costs as soon as possible.

iOS is more popular than OS X. Selling for iOS means more copies sold. It's not hard to do the math and nothing stopped the hordes of iOS developers from attacking the OS X market anyway.

If anything this will provide a channel for crappy apps that you can develop in a weekend and still generate some revenue for it (instead of giving it away for free).

And Windows has had a shareware culture for quite some time (tones of crappy games included, e.g. Zuma). It did nothing to stop the selling of quality apps for higher prices, as prices are only affected by other apps in the same category.

</comment><comment><USER27> I agree that there could be some price pressure due to increased competition and choices. However, given the inherent differences between iOS and OS X apps, I don't see many iOS developers being able to instantly compete with the established independent Mac developers and companies (e.g. Panic, Omni Group, etc.). The years of experience of the established Mac developers shows through in their quality. If anything, they may need to alter their marketing a bit to justify the premium pricing.

</comment><comment><USER28> One person's app store is another person's package manager.

</comment><comment><USER29> I've been selling $5 apps for Mac and Windows for over 3 years now already, completely independently and homegrown, so this won't impact me much. :)

There was a point in the past where I did a lot of research in the traditional PC/Mac shrinkwrapped boxed retail bricks-and-mortar software market, and the pricing model was rather shocking. Speaking in very general terms, and especially more about PC software, what I found was that for a say $50 priced unit of software, in a box there at a retail store, about 50% of that went to the retail store, about 25% or so went to the distributor, 20% to the publisher, and then only about $3-5 went to the actual developer. (Approximately, details varied.) Add-in traditional publishing industry shenanigans that try to turn developers effectively into sharecroppers, and almost require huge hype-driven sale numbers, and the situation is even worse.

Now with things like Steam and the App Store and with PayPal, etc., developers can publish software directly, much more easily, and the distributor/online- retail middleman takes a smaller cut, so say the retail price can be $5 and the developer takes home 70%-97% of that, depending on if more like App Store or PayPal model, respectively. So the take home income per unit for the developer can be about the same, but at a much much lower retail price point, which is a net win for consumers. And since there are less publishing shenanigans with compensation structure, it's actually possible to sell a small number of units per month and achieve at least Ramen profitability. Which at least buys you runway to develop additional stuff or work on side ventures, so it's a virtuous cycle/snowball effect.

<comment><USER30> Which begs the question, would _you_ publish on the Mac app Store?

I agree with what you are saying about the traditional bricks and mortar approach being an exercise in rogering the developer. Which was why when the iTunes App Store opened up I thought it was a _huge_ deal that they were _only_ taking a 30% cut, and yet were doing all this other stuff effectively for free: hosting, payments processing.

But - if you already have all that set up and in place, is it still attractive to you? If only for 'marketing' purposes? E.g. to say that you're on there, to be searchable etc.

NB: I realise that the walled garden is very restrictive, so your particular apps might not apply, ignoring that, is there any aspect of the deal that appeals to you?

<comment><USER29> I am considering making distributions for the Mac App Store, yes. But I've had higher priority things on my plate in recent months.

But yes, it could be a net win, or at least an additional channel. The biggest potential net win, in my mind, is that even if my net take home pay per unit is about the same for a Mac App Store sold unit, if it gets exposed to a larger number of eyeballs, the overal revenue stream should be higher. And may be a different, non-overlapping demographic as well. So yes, I am considering it and if it looks like a net win I'l do it. I haven't studied their packaging/platform requirements yet, however. Some of my apps may have technical or content qualities which are disallowed or at least problematic due to their requirements/policies.</comment></comment></comment>


TakeOff Conf 2013 - A broad look at all the trends of the upcoming year  - <AUTHOR>

Hello all,
The first TakeOff edition will take place in Lille, France on Jan 17 & 18 2013. Lille is close to London, Paris and Brussels. TakeOff is about the future of the web. There will be 250 people, with 2 days of talks, fun and 1 night of music and partying.
Everything is almost all inclusive. Food, drinks, shuttles. Some early birds tickets are still available, get quick!
More information on http://takeoffconf.com
The call for papers is still open and is the following :
[CFP] Take Off is a conference for passionate web developers and designers about trending topics for the upcoming year. From server side to pure front end through mobile, from design and philosophy to new languages, frameworks or development techniques, Take Off is your chance to show the world how the future of development and design should be.
Possible topics include, but are not limited to : code (all languages are welcome !) - server-side or front-end, web experiments, tools and frameworks, new cloud usages, new user interface innovations, typography, (practical) innovations in user interfaces and data visualisation.
We are a bunch of open-minded guys and gals waiting to discover what's hot and new.
Our people using Ruby enjoy discovering new tricks in Javascript or Python (and vice-versa), our backend geeks enjoy scaling their virtual machines while coding cool data visualisation dashboards with HTML5's canvas tag and our web designers want to know how to deploy.
The attendees will know how to code and what we want is to give them the opportunity of launching new projects with new approaches in 2013, especially if it means switching a langage or shifting to a new platform...
Please email us at email@example.com with your proposal, with one email per proposal !
We do have an open proposal policy. Proposals are peer-reviewed. [/CFP] <comment><USER2> We tried to build the event that we all would like to attend. I hope that European Hackers will enjoy our proposal !</comment>