alexandros

So we're taking out regulatory credits but leaving in the CEO award, right? I guess if you cherry pick your one time items you can make any number appear.

Balena | REMOTE | Backend Engineer

Hey there! We're Balena, a startup laser focused on a single goal: enabling every developer to succeed on the new frontier of Edge/IoT computing and building fleets of devices that work as reliably as servers in a datacenter. In the process of creating this bridge, we've built many tools and services, from cloud services (balenaCloud) to desktop utilities (balenaEtcher), to operating systems (balenaOS), single-board computers (balenaFin), and much much more.

Engineers at Balena have the ability to work on issues and features from inception to deployment, from talking to users to solving architectural riddles to learning new technologies as needed. Engineers are empowered to take on a user problem and chase down its solution to any part of the stack, working alone or coordinating other engineers in service of improving users' lives, without regard for internal silos or barriers.

Full description here: https://apply.workable.com/balena/j/8BF6036D98/

...wouldn't that be $12 billion that Apple has to poach MS engineers with, then?

Tesla has run a factory in Shanghai post-COVID, so far as we know successfully. Also most if not all the other car factories in the US are already operating. Also workers aren't forced to come in. This focus on Tesla is not taking into account all the data equally, unless folks are also outraged at every other factory in the US.

The Taycan is not yet released, and not slated to until "Spring/Summer 2020". And since that's a lot of time till then, it might slip more.

https://insideevs.com/news/383171/porsche-taycan-delivery-de...

Balena | REMOTE | Product Engineer

Balena is laser focused on a single goal: to enable mainstream developers to succeed on the new frontier of Edge/IoT computing in building fleets of devices that work as reliably as servers in a datacenter. In the process of creating this bridge, we've had to build many and varying tools and services, from cloud services (balenaCloud) to desktop utilities (balenaEtcher), to operating systems (balenaOS), single-board computers (balenaFin), and much much more.

The role of product engineer at Balena is for a truly full stack engineer, ranging from talking to users to solving architectural riddles to learning new technologies as needed. Product engineers are empowered to take on a user problem and chase down its solution to any part of the stack, working alone or coordinating other engineers in service of improving users' lives, without regard for internal silos or barriers.

The ideal product engineer has a wide variety of background experience and isn't afraid to learn to use more technologies when needed, but also is comfortable deferring to experts within the team when their particular skills are required.

If you think this role is for you, please let us know of a problem you see in one or more of our products, and how you would improve it. All who submit a non-trivial answer to this challenge are guaranteed to have an interview with a member of our leadership team.

Drop us a line at producteng@balena.io with a CV and your answer to the question, as well as any other relevant info that makes you particularly suitable for the role. We appreciate non-standard backgrounds and encourage you to focus your material on the substance and not on formalities. We look forward to speaking with you!

Being wrong for 12 years and counting is a bit of a concern, no? Also, if he has no credibility, then the points in the article require more scrutiny, we can't just take him at his word, can we? That's why credibility matters.

Mind substantiating the whole "recall worthy metalworking" claim? First I hear of it. Are you sure it's up to date?

All these flaws you talk about on other cars are not accidents. Everyone is running up against the same fundamental tradeoffs, and only one company has done the insane optimization of everything to get to the other side. It's not a matter of just deciding to do so. The nio example you mention for instance, Tesla famously was initially planning to use the lotus Elise body for the roadster, but ultimately had to redesign essentially every part to get to production, since the weight changes invalidated all the assumptions of the original.

Yes, they're not the best at every single thing. But producing the safest car ever for a newcomer is pretty nuts. Producing the most efficient electric car ever is pretty nuts. Producing the best OTA story ever is nuts. Producing the most advanced driver assist feature is pretty nuts. Doing all these things together requires explanation. It can't just be "oh, the others just made bad choices".

"quite rightly", "sticking some batteries"... Its fascinating that you do realize that the people who disagree with you have been right, and yet you're not updating your model. Look up Sandy Munro, a car guy's car guy, talking about his teardown of the model 3[1], or even just focus on his comment about the superbottle, and perhaps you'll get a better sense of why nobody has matched the 2012 Model S yet, nevermind the 2019 one.

[1]: https://cleantechnica.com/2019/04/06/auto-industry-expert-in...

Critically, this doesn't take into account that the model 3 has the lowest probability of injury [1] of any car ever tested by the NHTSA. Driving a car with a higher probability of injury means you must calculate the cost of a fractional injury and what this might cost you and your passengers in lost time and/or quality of life, nevermind the case where the injury is fatal.

[1]: https://insideevs.com/news/356489/tesla-model-3-safety/

Persistent logging is only there for cases we need to debug something, in other words where it's the only choice. Even so, it writes to a circular buffer so it should be reasonably safe. But it's not intended to be on by default, more like an emergency measure. We do push logs to our server to some degree, and some customers use proper devops platforms to manage their logs, but we definitely want to do more in the future.

The pricing model is along the lines of "essentials is for people looking for a better OTA solution whereas microservices is for people who consider their devices mini-servers". So it's more a difference of perspective of the customer that allows us to group features and give more to the one crowd without alienating the other crowd with high prices. Not sure if that makes sense.

Yup.

We're currently focused on devices that can run Linux. The smaller devices are a different kind of challenge, and while we do have some ideas about how to achieve the same level of developer experience for them, it's not out yet. :)

You can't ask a founder this and not expect a pitch, so here goes:

Having built a similar bespoke stack in the past, Balena would have been a steal! It gives you the development, provisioning, build & deployment, configuration, management, and even remote debugging workflows out of the box. On top of that, it's built to require web/cloud developer skills, not embedded skills.

To do that, we have created several companies worth of infrastructure, from a cross-architecture container build system, to a bespoke OS supporting many device types, customized docker engine for embedded use cases, container deltas for bandwidth saving, etc. Even simple things like "how do I make sure my device gets DNS in an arbitrary home network" are incredibly tricky, and balenaOS gets it right almost always.

Which brings me to my next point. We are fanatical about support. We take responsibility for our customers succeeding, which means we constantly find and improve sources of friction. Using Balena gets you that backup team, but most importantly gets you hooked up to the flow of improvements we make all the time. Cloud companies charge $15 per server per month for various devops type services. We do very similar things but for devices that are smaller, more diverse, in tougher conditions, with less reliable networking, and ask for just $1 per device per month.

In other words, when I was in the shoes of our customers, producing even a fraction of the value and piece of mind that Balena provides in house took a lot of work, which was money, and that's not accounting for the time and risk of not getting there in the end. If I found myself in that situation again, knowing Balena and not using it would essentially be negligent. Our most fanatical customers are those who have tried to build something like it themselves, because infrastructure is so easy to underestimate.

Hey, balenaOS has been designed for long term deployment. As such, we have a read-only partition for the hostOS. We also have a second host partition so we can update the OS remotely and atomically. In general, we've tuned all sorts of elements in this direction as our customers really don't want to run around collecting sd cards from all over the world.

Hey folks, balena.io founder here, just chiming in to mention that Chris is one of our Hardware Hackers in Residence, and if you think that doing HW projects with all sorts of cool technologies and writing them up for the world is your dream job, we're hiring! https://balena.workable.com/j/27A101659C

Happy to answer any balena (or train station sign) related questions, of course :)

Slack (and chat-in-general) has replaced email for many things it used to be used for. And we're all better for it. Other things still go over email and slack can't ever touch them. It's called disaggregation. Why does everything have to be "x wants to replace y", "is x the y-killer?", "x will destroy y" etc etc. I wonder who wants to replace clickbait headlines...

Boston Dynamics was spun out of Google (sold to SoftBank) years ago. And before that was primarily a DoD contractor so they didn't need to productize anything.

No brakes pulled whatsoever. They're discussing about further expansion beyond 35gwh.

Your TPU point makes no sense. If Google's TPUs are on par with NVIDIA GPUs for NN workloads (I assume that's what you mean on par?) then they suck at making chips, which they don't. What's even the point of making them, and why has e.g. Deepmind been using them if they could have been using NVidia chips in the first place? I don't think they're budget constrained. It sounds to me like you're using a non-relevant definition of "on par".

About the stuff that's based on Elon's assertions:

First, yes, he is often wrong on timelines. Nobody doubts that. By the way, for other car companies (even Waymo!) who claim they'll have X milestone by Y date, everyone is understanding, since timelines slip. For Tesla, apparently it's a capital crime to say "I think we'll have it by then" and not have it. But your original points were not about timelines.

As for the miles they have registered with the DMV, Tesla's self-driving programme does not follow the same path as others. They are progressing from level 2 upwards, and deploying improvements to their fleet of cars in production. Other companies are working with tiny fleets and aiming directly at level 4+. So basically, you're looking in the wrong place. But even so, Elon's latest prediction is that they'll have "feature completeness" by end of year, and then they'll start working on regulatory approval. So I assume that's when you'll start seeing miles there, and you will very likely see lots of them, all at once.

You make no mention of HW3, which will be installed on the cars that bought FSD for free, and includes Tesla's own chip, (I assume some kind of TPU) designed by Jim Keller. It has been described by Tesla as having 100x the FPS processing capability that the nvidia PX2, the one they use now, has [1]. So they're more or less in full agreement with, and have been working on making happen, the things you say need to be done, for the past 3-4 years.

Tesla's head of AI is Andrej Karpathy, who many in this community hold in high esteem. I know this is "argument by authority", but we're working with a black box here, so it will have to do. Do you really think he is wasting his best years on a project that anyone in the field can "guarantee" will never happen? Or could it be that he knows something you don't?

By the way, it seems you also don't know that they hold most FSD revenue in reserve on their financials, it's not being spent. So if they need to return it, they can.

[1]: https://www.inverse.com/article/47683-tesla-elon-musk-just-d...

That's a good point! We should try that as an alternative next :)

Hey there - BalenaOS is built to run containerised workloads on small devices and is quite stripped down otherwise, kinda like coreOS. So in that sense our architecture allows you to have less stuff you don't need floating around, saving you overhead. We focused on Docker containers since balenaCloud is built for fleets. It's important that our stack supports not just one but many copies of the same device running the same code, and then it can be updated in production etc, just like a set of servers. If one is optimizing for a single device, just naked Raspbian will do fine of course. Our approach has a bit of overhead up front in terms of setup, but you get a production ready setup from day one in return.

Balena (formerly Resin.io) | Technical Sales Lead / Sales Engineer (Europe) | REMOTE | FULL-TIME | https://balena.io

Balena is solving the myriad problems that come up when developers try to manage software on thousands of intelligent devices in edge computing/iot/embedded scenarios. Our customers are working on everything from self-driving trucks to drones to sea turtles with cameras on them to smart buildings and smart everything else.

We run sales like we run engineering. While closing deals is important, we’re more interested in helping customers succeed with balena and solving their technical challenges. We’re also a process-driven team and work to make our sales process as efficient as possible.

This is an ideal position for anybody currently in an engineering role interested in transitioning to a more customer-facing role, though previous sales experience is also welcome. Our customers are usually engineers themselves, so you’ll be answering sophisticated questions about our product and building solutions for our customer’s needs.

Apply here: https://balena.workable.com/j/39F9C34AA8

Elon has not lied to the SEC. Please provide link or other evidence. He settled a claim that he manipulated the stock without admitting guilt, in order to avoid damaging the company, but that is completely different.

The author doesn't really state that he did that, but I ran the numbers, and it seems he's doing that indeed. Not sure how he came to the conclusion that 25T fuel is in the 737, as that doesn't seem to be the case. He still didn't consider the engines that would be almost completely gone weightwise, and of course the main point stands -- the 737 is a specific model, with specific tradeoffs, to handle specific cost variables, including engines and fuel. If one is considering a new design, with drastically different variables, different cost of fuel (almost 1/5th or less) different weight distribution, different acceleration capabilities, different aerodynamics (no more bulky engines at the wings), different takeoff strategies, then this kind of "what if I flipped the fuel on the 737 for a battery" approach cannot be used as proof that an idea is "ridiculous". The author comes to the fight extremely underprepared, and honestly if we all reasoned like that we'd still be in caves. I'm all for calling Elon out on things he's more vulnerable on, but the author tips his hand with shoddy work like this.

Many of the flaws with the article have been pointed out, but can I just point out the author is so lazy that he doesn't even remove the weight of the fuel from the Boeing 737, nevermind the jet engine and the many other optimisations that can be done when designing from scratch without the ICE constraints. His thought experiment is literally a Boeing 737 with a 25T battery attached to it, and he takes that to be the best case of what Elon is proposing... What makes smart people write things so trivially dumb?

And in case the author objects to me dissecting his rough sketch of an argument and drawing conclusions about him from it, he should have thought of that before taking 5 sentences spoken in a podcast and assuming he understands what the complete idea someone else has in mind is.

This one is one of those things that took us so many iterations to nail. Very happy it finally got to a good place. We'll integrate it into balenaOS soon by default, hopefully.

Hey there -- we have a bunch of case studies on our blog, click the "case study" links on this page -- https://www.balena.io/customers/

And if you're interested in a board that is as easy to program as the Pi but more robust, you can check out -- https://www.balena.io/blog/introducing-project-fin-a-board-f...

Hey there -- so this is a bit of a terminological thing, but we don't consider balenaEngine to be a docker fork -- it's a sibling project descending from the Moby Project, just like Docker, and of course highly copmpatible with Docker. The things we've done in balenaEngine aren't things that Docker would do. Shrinking the size to a quarter, removing Swarm, adding container deltas, changing the tradeoffs around durability -- most of the changes we have made relate to the embedded use case. As such, we intend to keep evolving balenaEngine alongside Docker, also because it's important for us to control the size of the binary. It goes into our root partition, and if Docker keeps adding things to their engine, we can't have that variable affect our ability to update devices.

We've done a lot of things to make sure balenaEngine is rock solid in an embedded environment, and our fleetOps team is pretty hardcore in helping customers get out of hard situations (which help us further evolve the OS and the engine to avoid those by default).