I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype.
At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI.
I made some observations:
1) We can create a prototype right now in Chrome, with its incumbent versatility.
2) The chip running the UI can actually reasonably run Chrome.
3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs.
4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform.
The prototype was a great success; we were able to implement a lot of interesting UI in just a week.
I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger.
As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display.
Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.
Wow a real SWE showing up and explaining how you can actually approach a real problem using a browser. Instead of just going "well its not compiled so clearly it will just randomly explode".
I am always amazed how HN doesn't realize many mission & life critical systems are powered by JS - especially as a front end through a browser.
This is how most of the YouTube clients work. They shipped a strip down web renderer (I forget if based off chrome or not) with an extremely stripped down set of HTML/CSS/JS features - just enough to run the YouTube UI.
Still get a familiar development experience, live updates, and able to run on constrained devices.
At a minimum it should use typescript, no? Also web pages get out of sync sometimes, and need to be reloaded, which doesn’t sound great for mission critical reliability. Compiled, typed UI lib sounds like a better fit.
Unless something actually crashes, which any code could do, then why would you need to reload? Just send a websocket message that requests the current full state.
But if it's implemented correctly, it probably won't get out of sync.
Remote code doesn’t load correctly sometimes, just a fact of life in a distributed system. Maybe loading it locally reduces that to almost zero, but I’d still be more comfortable risking my life with a desktop app.
>I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype.
Other games have 'start with partial download' technology. In fact, the core tech of the team that eventually created Valve's Steam was downloading assets on-the-fly so that you could start playing a game before everything was downloaded.
I worked on Guild Wars 2, which has this feature. I made a first prototype of it that streamed all content on-the-fly. It's pretty easy to implement - you have an abstraction that asynchronously loads a file off of the disk, and you can just make that download from the network instead.
The tricky part is when you want to ensure all the assets are there for a specific area before you load in, or simply knowing what order to download things in. For example, there was a starter area of Guild Wars 2 that spawned monsters from many other areas, this meant that the manifest of what was needed was enormous for that area.
So the 'playability' threshold becomes a trade-off between game experience (assets popping in as you play) and quick entry.
Guild Wars 2 needs more respect from the MMO community. The ability to do testing on the live servers, or enable patches with a client reboot and no server downtime, is great.
The website says you're planning to build your own manufacturing plant. What will that plant do? Will you actually be manufacturing your own medication?
If so, would that include manufacturing the active pharmaceutical ingredients or will you be sourcing them from generic manufacturers and then making the final drugs at your plant?
It will be a sterile fill-finish facility. The facility will fill vials of sterile injectable medicine. Those tend to be the drugs which are most affected by shortages and price gouging overall. The facility will just do finished drug products.
Our initial drugs are supplied on "private label" arrangements where other companies actually do the manufacturing, and we just add our labels and our own NDC code so we can set the price. Since we don't go through middlemen, that price can often times be a lot lower.
We'll have to source API (active pharmaceutical ingredients) elsewhere for now. At some point, would like to completely internalize our supply chain, but one step at a time. :-)
I know this is crazy, but have you talked with Bill Gates?
He planned to pre-fund several coronavirus vaccine manufacturing plans _prior to FDA approval_ just to speed up vaccine production. He expected several of those would end up being wasted money. [1]
If you haven't read it, I highly recommend the book 'Bottle of Lies' which was released a few months ago. It details systemic corruption in a number of generic pharmaceutical manufacturers.
It also details how the FDA is struggling with monitoring overseas manufacturing.
DOTT is a totally free-standing game -- and amazing.
They address this in the linked article (also from personal experience) -- you really don't need any context from Maniac Mansion to thoroughly enjoy DOTT and they are really totally different games in style and substance.
Awesome, thanks for that! By the way: that integration has been co-opted for use by a bunch of overlay software, like gw2taco [1].
So, even if not used for Mumble, it's now a pretty big feature for other 3rd party software. I use it regularly myself.
(For the unfamiliar: gw2taco et al use position/viewport data, I guess, from the GW2 Mumble API to draw an overlay on top of the game with navigational markers/aids.)
Spatial audio support in mumble was just coming around in its early stages when I looked at integrating mumble as a VoIP solution to a Unity3D training simulator project. Good to see it's still around and kicking!
Fair point...right now we associate your salary with with where you live. If you are open to relocating, we'll reach out to find out where and then make sure salary is adjusted...our intent is to help you find something great, so we'll work with you to make that happen.
On the homepage, there is an example of an incrementing counter. Is this actually an atomic operation, or if two users hit the button at the same time, will it potentially only increase the count by 1?
At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI.
I made some observations:
1) We can create a prototype right now in Chrome, with its incumbent versatility.
2) The chip running the UI can actually reasonably run Chrome.
3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs.
4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform.
The prototype was a great success; we were able to implement a lot of interesting UI in just a week.
I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger.
As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display.
Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.
reply