alexandros

Hi everyone, resin.io founder here, happy to answer any and all questions. We just released resinOS at ELCE a few hours ago (Embedded Linux Coference, Europe), happy to see it made HN!

thanks for the heads up, fixed now.

thanks, and fixed.

We're open to people who want to just contribute to the project (it's being run in the open) or people who want to do it as a full-time occupation.

Resin.io | REMOTE | Linux engineers, Security engineers, Backend engineers, UI/Front-end engineers, Sales engineers

Resin.io allows IoT developers to push Linux Containers to embedded devices. See our demo of updating a drone in-flight at DockerCon [1]. We're very emphatic about our remote culture [2].

The resin.io team is composed of people passionate about quality code, well-thought out architecture, and great user experience. Etcher.io, a tool we recently released, is a good example of all those things. Most of our code is node.js though we're transitioning some parts of the stack to Go. Some details on the individual roles:

Linux engineers - We're building a minimal OS for embedded devices[3]. Knowledge of Yocto Linux very helpful. Security engineers - Passionate about building an end-to-end secure code delivery pipeline, from the cloud to the device, all the way down to the bootloader and CPU? Backend engineers - Resin's backend is composed of ~10 node.js microservices, each with unique challenges. UI/Front-end engineers - We're passionate about UX, and have a lot of cool features to build. Most of our UI is in AngularJS but knowledge of other frameworks a plus. Sales engineers - (ideally in the bay area) - End-to-end understanding of resin.io, ability to work with customers to both teach and guide them to use resin.io effectively. You may need to spend time on-site with customers. Workflow engineers - Looking for full-stack developers passionate about optimising the way a remote team works. Our interview process is a first call to go through programming competence, as well as a follow up with the corresponding team lead. If any of the above sound exciting, drop us an email at join@resin.io

[1]: https://youtu.be/75vm6rRb6K0?t=1569 [2]: https://resin.io/blog/how-we-run-a-remote-team/ [3]: https://github.com/resin-os/

Etcher.io | REMOTE | node.js & frontend javascript engineers

Etcher [1][2] is an open-source project by resin.io, the only cross-platform, open-source flash drive writer. Etcher is developed with Electron, node.js, and Angular.js. We're growing Etcher to solve more IoT device problems and looking to bring on board experienced javascript engineers who love to create incredible user experiences and solve hard, cross-platform problems for hundreds of thousands of users, all while working in the open.

If the above sounds exciting, drop us an email at join@resin.io

[1]: https://etcher.io [2]: https://github.com/resin-io/etcher

Etcher.io | node.js & frontend javascript engineers

Etcher [1][2] is an open-source project by resin.io, the only cross-platform, open-source flash drive writer. Etcher is developed with Electron, node.js, and Angular.js. We're growing Etcher to solve more IoT device problems and looking to bring on board experienced javascript engineers who love to create incredible user experiences and solve hard, cross-platform problems for hundreds of thousands of users, all while working in the open.

[1]: https://etcher.io, [2]: https://github.com/resin-io/etcher

Open source does not entail any responsibility to work or not work together with any pre-existing project. What you describe is more cathedral than bazaar. There are thousands of possible reasons, from architectural choices to personalities, that someone may have not chosen to work with an existing project. I will not fault them for giving me a superior result, for free (in both senses). To compare this with Microsoft in the nineties is sheer madness.

here's an alternative interpretation: Due to their unique requirements, they were forced to investigate alternative approaches to the problem, and the approach they went with, they believe, is useful to a lot more people than just themselves. This is both plausible and matches the announcement, so why take a bad faith approach to someone releasing some code to the open source? Would you prefer if they kept it closed?

And since we're talking about github, haven't they already launched a highly successful pair of projects in atom/electron, in areas where both had competition? why start with negativity before we see what they come out with?

Resin.io | REMOTE | Linux engineers, Security engineers, Backend engineers, UI/Front-end engineers, Sales engineers

Resin.io allows IoT developers to push Linux Containers to embedded devices. See our demo of updating a drone in-flight at DockerCon [1]. We're very emphatic about our remote culture [2].

The resin.io team is composed of people passionate about quality code, well-thought out architecture, and great user experience. Etcher.io, a tool we recently released, is a good example of all those things. Most of our code is node.js though we're transitioning some parts of the stack to Go.

Some details on the individual roles:

Linux engineers - We're building a minimal OS for embedded devices[3]. Knowledge of Yocto Linux very helpful.

Security engineers - Passionate about building an end-to-end secure code delivery pipeline, from the cloud to the device, all the way down to the bootloader and CPU?

Backend engineers - Resin's backend is composed of ~10 node.js microservices, each with unique challenges.

UI/Front-end engineers - We're passionate about UX, and have a lot of cool features to build. Most of our UI is in AngularJS but knowledge of other frameworks a plus.

Sales engineers - (ideally in the bay area) - End-to-end understanding of resin.io, ability to work with customers to both teach and guide them to use resin.io effectively. You may need to spend time on-site with customers.

Workflow engineers - Looking for full-stack developers passionate about optimising the way a remote team works.

Our interview process is a first call to go through programming competence, as well as a follow up with the corresponding team lead. If any of the above sound exciting, drop us an email at join@resin.io

[1]: https://www.youtube.com/watch?time_continue=1573&v=75vm6rRb6.... [2]: https://resin.io/blog/how-we-run-a-remote-team/ [3]: https://github.com/resin-os/

Oh god, a deontic argument for slowing down self-driving cars. Yes, we choose to let several people die every day by not spending every available dollar on healthcare. Even then, we would have to decide where the large but still limited budget would be invested. There's no pure white way to get out of consequentialism. Might as well accept it and work with it rather than shutting your ears and singing la-la-la.

Sorry for the rant, for those that care for a reasoned argument along the lines of the above, Scott says it better than I ever could -- http://raikoth.net/consequentialism.html

Resin.io | REMOTE | Linux engineers, Security engineers, Backend engineers, UI/Front-end engineers, Sales engineers (for the last one only, bay area preferable)

Resin.io allows IoT developers to push Linux Containers to embedded devices. See our latest demo at DockerCon [1].

We're very emphatic about our remote culture [2].

The resin.io team is composed of people passionate about quality code, well-thought out architecture, and great user experience. Etcher.io, a tool we recently released, is a good example of all those things.

Most of our code is node.js though we're transitioning some parts of the stack to Go.

Some details on the individual roles:

Linux engineers - We're building a minimal OS for embedded devices[3]. Knowledge of Yocto Linux very helpful.

Security engineers - Passionate about building an end-to-end secure code delivery pipeline, from the cloud to the device, all the way down to the bootloader and CPU?

Backend engineers - Resin's backend is composed of ~10 microservices with unique challenges. Most of the code is in node.js and CoffeeScript, JS knowledge required.

UI/Front-end engineers - We're passionate about UX, and have a lot of cool features to build. Most of our UI is in AngularJS but knowledge of other frameworks a plus.

Sales engineers - (ideally in the bay area) - End-to-end understanding of resin.io, ability to work with customers to both teach and guide them to use resin.io effectively. You may need to spend time on-site with customers.

Workflow engineers - Looking for full-stack developers passionate about optimising the way a remote team works.

Our interview process is a first call to go through programming competence, as well as a follow up with the corresponding team lead.

If any of the above sound exciting, drop us an email at join@resin.io

[1]: https://www.youtube.com/watch?time_continue=1573&v=75vm6rRb6... [2]: https://resin.io/blog/how-we-run-a-remote-team/ [3]: https://github.com/resin-os/

There is no universal dictionary in the sky that defines what words mean. To some people, "hacker" means one thing, to some another.

sorry for the self-plug, but we're doing exactly that at resin.io

While the CHIP comes out looking good, it's important to note the horrendous AllWinner software stack. Last time I checked, Linux support meant using an out-of-tree sourcedump that was tied to a specific version of Linux (I think 3.0.x?). The sunxi project[1] was trying to mainline a bunch of stuff, but not sure how far that is now. In general, working with the AllWinner chip is much more of a pain if you want to do non-trivial things. Perhaps the CHIP will help improve that situation.

[1]: https://github.com/linux-sunxi

You appear to believe the author is making a global appeal and has deliberately put this on the HN front page. Please remember that this is the author's personal blog, the readers there probably know who this is, and some of them shared the link which made it here. Take the content for what it's worth, spare the author the patronising lecture.

You might be throwing out the baby with the bathwater. Science, as a method, works. Science, as a field, has areas where it doesn't work very well. Diet, in particular, is probably one of the worst. The good thing with Science, the method, is that it is predicated on improvement by iteration. Dietology itself is getting a bit better (though there's a lot more to do), so unfortunately, until we find a better method, we have to work on human time. No need to discard every reasonable scientist's work just because of some (many?) bad apples. They are nowhere near the majority.

It's also wrong because it implies that having the .com today is as important as when those companies got their .com. Anecdotally, many (most?) developer tools companies go for .io, so much so that a .com sounds strange these days.

Another reason why you shouldn't take this year as idicative. However, you said "2015 Greece has begun privatization" whereas the article says the exact opposite. I'm not sure what point you're debating at this point.

It's not the intrinsics. It's the whole list of special one-off factors at play. By the way, Greece started privatization in the 90's, not in 2015.

When there's no external assistance and the government pays loans out of its budget, it means it's not paying something else internally, usually some business it owes money to. If you feel that that is a non-factor in economic destruction and therefore tax receipts, then sure, have your own numbers.

The question is how the country would fare if the debt wasn't there, but the rest of the economy was functioning properly.

As a disclosure, I am Greek and have intimate knowledge of facts of the ground. If we can't agree the past six months are not "normal" there's very little to talk about.

Yes, I think you will concede that 2015 is not a year to use for forward projections. The country has been paying loans without external help, the uncertainty means no investment incoming, tourism is hit, and people in the country are withdrawing cash from the banks and hiding it in their houses, not spending it.

As for the punitive Troika, they had 5 years to run the country and they failed in every single projection they made. Every memorandum was meant to be the last, and they had the governments of their choice. How many more years of full cooperation do they expect before they accept that yes, perhaps the system isn't working. But I refuse to believe they're idiots at this point. The programmes are meant to appease the average German voter and serve as a warning to the Spaniards and Italians. Basically, punitive.

You said there was no surplus, which I take to mean expenses == receipts. In that case, it's obvious how it will support itself (if you ignore the loans). Do you have sources for a deficit?

First, as long as you're retracting your original statement about 8-10% deficit, we're good. I'm not going to argue 1.5% down or up.

Nobody's talking about paying the loans and keeping the country going without help.

What people are saying is that Greece can support itself, minus the loans.

Nobody says Greece is running a surplus today. It has been paying loans for a year without external assistance. Plase read the thread and what I was responding to.

Googled, "greece primary surplus". First result: http://www.forbes.com/sites/timworstall/2015/02/16/greece-st...

Second paragraph, krugman quote:

"Despite this catastrophe, Greece is making payments to its creditors, running a primary surplus — an excess of revenue over spending other than interest — of around 1.5 percent of G.D.P."

How much did you look, and where are you seeing the opposite information on primary deficit the last few years?

It's not that simple. Research the story of the ODROID-W and their quest to make an rpi-compatible SBC.

the idea is to make deployments repeatable, so while we may allow sshing in the future, it will be for diagnostic/experimentation reasons, not for altering the device state, so I think you understand the problem we're solving pretty well.

We keep adding devices and will soon release a guide on how users can add their own devices to the mix. That said, the primary determinant on whether we can support a device is whether a yocto/openembedded BSP exists and is relatively modern (uses a kernel above 3.8). If that exists, it's almost certain that resin support will be relatively easy. Happy to chat more, email in profile.

Hey there, resin.io founder here (we're working on this with adapteva) this should be possible, let me ask around internally and get back with more details

Fascinating document. I always wondered if these well-worded explanations and positionings in historical context serve to get the logo accepted by biasing the reader, or if they genuinely add something. In other words, I wonder if the same logo, supported by a different document, will lead to a different answer by the client. Given all the work that's obviously been put into this document, I suspect it does matter.

As an entrepreneur, I will endeavour to be presented the logo of my project in the same light and context that my customers will see it, and not with a heavy serving of storytelling, as that can only make things worse for my poor brain when it comes to choosing.

Don't get me wrong, I'd love to read the context and process that led to the design, but only after I've made a choice.

I thoroughly agree that this is something we developers have to fix instead of adding yet more hoops to jump through. Like you I am also working on the problem of tools/infrastructure to solve this problem though probably a different aspect of the problem, with my startup resin.io